PLAYBOOK
Guia prático para lançar uma fintech que movimenta cripto e fiat com compliance KYC/AML embutido desde o início. Trilhos, custódia não custodial, licenças, stablecoins e emissão de cartões.
Por Lucía 12 min de leitura 
A maioria das equipes fundadoras que se propõem a lançar uma fintech toma a mesma decisão cara no primeiro trimestre: construir os trilhos de pagamento do zero. Seis meses depois o padrão é previsível. Chega o primeiro cliente real, o stack não está pronto para produção, o compliance é um remendo colado no final, e a dívida técnica já é grande demais para ser paga com limpeza.
Lançar uma fintech que movimenta pagamentos cripto e fiat não exige reinventar a infraestrutura. Exige escolher bem os alicerces e acertar de primeira nas partes difíceis de mudar (custódia, compliance, licenças). Este guia percorre o que realmente significa “pronto para produção”, os alicerces que precisam existir no dia um, uma arquitetura de referência e um plano realista de 90 dias.
Equipes de engenharia adoram construir. Esse instinto é exatamente o que afunda fintechs no início. Os trilhos de pagamento parecem um problema resolvido, visto de fora (mover um número de A para B), mas o que quebra em produção é o que você não vê em uma demo: a conciliação, os prazos de liquidação, as transações falhas e estornadas, os positivos de sanções e a trilha de auditoria que um regulador vai pedir.
A armadilha é que construir seus próprios trilhos parece avanço enquanto silenciosamente reduz o seu teto. Uma fintech que cresce sobre infraestrutura própria mal projetada bate num muro rápido: não consegue escalar para um novo mercado sem reescrever o core, não consegue adicionar um novo ativo sem semanas de integração e não sobrevive a uma auditoria sem trabalho manual intenso. Escolher infraestrutura B2B especializada não é terceirizar seu produto. É liberar seus engenheiros para construir o que de fato te diferencia.
Antes de escrever uma linha de código, seja honesto sobre o nível exigido. Uma plataforma de pagamentos cripto e fiat está pronta para produção quando consegue:
Se o seu MVP não faz essas coisas, é um protótipo, não uma plataforma. A boa notícia é que nenhuma delas te obriga a construir do zero.
Cinco coisas precisam estar na sua arquitetura desde o primeiro commit. Pular qualquer uma delas é a decisão que você vai pagar depois.
Seus usuários pensam na moeda local deles. Seus fornecedores, investidores ou contrapartes podem liquidar em USDC, EUR ou USD. Uma plataforma que trata cada moeda como uma ilha transforma todo movimento cross-border em um problema de engenharia.
Comece com contas nominais por usuário e um saldo unificado capaz de manter várias moedas, apoiado em dados bancários reais onde o mercado precisa (PIX e TED no Brasil, ACH nos EUA, SEPA na Europa, Faster Payments no Reino Unido e outros trilhos locais latino-americanos como CLABE ou PSE). Os depósitos deveriam poder se autoconverter para uma stablecoin, para que o valor fique usável instantaneamente no resto do sistema.
Este é o núcleo. O mercado premia a flexibilidade, e a flexibilidade vem de tratar cripto e fiat como um único trilho em vez de dois:
Quando esses três fluxos vivem atrás de uma única API, um pagamento de uma carteira em reais para uma conta bancária em dólares deixa de ser um projeto sob medida e vira uma única chamada.
Um cartão é como a maioria dos usuários de fato toca o próprio dinheiro. A emissão de cartões moderna permite lançar programas Visa ou Mastercard virtuais e físicos em que o cartão gasta direto do saldo do usuário, cripto ou fiat, sem pools de pré-financiamento para gerenciar. A decisão de design importante é que a carteira se conecta à rede de cartões para que o gasto ocorra contra o saldo em tempo real, com limites granulares, controles de bloqueio e 3-D Secure já incorporados.
Aqui muitas equipes cometem um erro silencioso, mas caro: tratam a custódia como um problema puramente de segurança. Ela também é regulatória e operacional.
Em um modelo custodial você retém os fundos e as chaves dos seus usuários. Isso te coloca dentro das regras de salvaguarda e transmissão de dinheiro, obriga a segregação e auditoria no seu balanço, e faz de você o alvo mais atraente da rede.
Em um modelo não custodial os usuários mantêm o controle dos próprios fundos e cada movimento precisa da aprovação deles. Você opera o programa sem nunca deter o dinheiro do cliente. Isso não faz o compliance desaparecer, mas reduz de forma material a superfície que você precisa proteger e muda a conversa sobre licenças. Para muitos produtos, não custodial é a diferença entre precisar de uma licença pesada por conta própria e conseguir operar como agente de um parceiro licenciado.
Qualquer que seja o modelo escolhido, os inegociáveis são os mesmos: segregação de fundos auditável em tempo real, rastreabilidade completa de cada movimento e políticas de assinatura configuráveis conforme o perfil de risco do seu produto.
O compliance adicionado depois do lançamento é o mais caro que existe. Implica redesenhar fluxos, migrar dados e, no pior caso, parar operações. Construir com compliance desde o dia um significa:
As arquiteturas mais limpas entregam isso como parte do stack base, não como add-ons opcionais integrados depois.
As licenças são onde os fundadores travam, geralmente porque assumem que precisam de tudo sozinhos. Muitas vezes não é o caso.
| Pergunta | Resposta típica |
|---|---|
| Você retém ou transmite fundos do cliente? | Se sim, você provavelmente precisa de autorização do Banco Central do Brasil (BCB) como instituição de pagamento. |
| Você é não custodial e age como correspondente ou agente de uma instituição licenciada? | Muitas vezes você pode operar sobre as licenças dos seus parceiros para as partes reguladas. |
| Seu produto envolve crédito direto sem captação de depósitos? | Considere o regime de Sociedade de Crédito Direto (SCD) junto ao BCB. |
| Seu produto envolve tokenização de ativos? | A CVM entra na conversa, além do BCB, dependendo do desenho do ativo. |
| Você atende mercados fora do Brasil? | As licenças costumam seguir onde estão os seus clientes, não onde a empresa é constituída (MSB nos EUA, EMI na Europa, MiCA para cripto, entre outros). |
O passo prático é mapear seu perímetro de licenças cedo: quem controla os fundos, quais mercados você atende e quais partes reguladas podem se apoiar em licenças de parceiros. Consiga esse mapa com seu advogado antes de escalar, não depois.
Para um MVP cripto e fiat em produção em menos de 90 dias, a arquitetura mínima viável é menor do que a maioria espera:
Uma opção white-label permite lançar todo esse stack com a sua própria marca, o que encurta o time-to-market sem abrir mão do controle da experiência. Seus engenheiros integram contra uma única API em vez de costurar um provedor de liquidez, um custodiante, um provedor de KYC e um processador de cartões, cada um com seu próprio contrato, seus modos de falha e suas manias de conciliação.
Dias 1 a 15, escopo e perímetro. Defina os fluxos exatos de que você precisa (contas, on/off-ramp, cartões, cross-border) e os mercados que vai atender. Mapeie seu perímetro de compliance e licenças com um advogado. Consiga uma sandbox key e valide a API contra um fluxo real de ponta a ponta.
Dias 16 a 45, integre o core. Conecte contas, a API de pagamentos unificada e o motor de compliance. Construa o onboarding com KYC no fluxo. Implemente webhooks e idempotência para que seu livro-razão fique auditável e nenhum evento seja processado duas vezes.
Dias 46 a 75, endureça e adicione trilhos. Adicione emissão de cartões e payouts cross-border. Teste os caminhos infelizes: estornos, positivos de sanções, atrasos de rede. Levante o painel operacional e seu monitoramento e relatórios.
Dias 76 a 90, lançamento controlado. Rode um piloto fechado com usuários e dinheiro reais, com limites baixos. Confirme que a conciliação, os prazos de liquidação e a trilha de auditoria aguentam em condições reais, depois suba os limites e abra as portas.
A variável desse cronograma nunca é a tecnologia. É o escopo do seu produto e o perímetro de compliance que os mercados escolhidos criam.
Construa as partes que são o seu produto e a sua diferenciação: a experiência, a lógica vertical, os dados e os relacionamentos pelos quais seus usuários vêm até você. Integre as partes indiferenciadas, difíceis de acertar e caras de manter: os trilhos, a custódia, a parte operacional de compliance e o processamento de cartões.
O teste é simples. Se um componente pareceria quase idêntico em qualquer fintech competente, é infraestrutura, e infraestrutura não é onde você ganha. O tempo da sua equipe de engenharia é o seu ativo mais escasso; gaste-o nos 20% que só você consegue construir.
Análises detalhadas de cada alicerce acima:
A Tokelia é a infraestrutura para o dinheiro programável: contas virtuais, trilhos unificados de cripto e fiat, emissão de cartões, pagamentos transfronteiriços e stablecoins, atrás de uma única API, com arquitetura não custodial e compliance incorporado no stack base em vez de vendido como add-ons. Os serviços de dinheiro são prestados pela Tokelia LLC, uma empresa registrada como Money Services Business perante a FinCEN, com a atividade bancária regulada entregue por instituições licenciadas, de modo que você pode lançar com a sua própria marca enquanto as partes pesadas e difíceis de mudar já estão resolvidas.
Se você está dimensionando um lançamento, a forma mais rápida de testar isso contra o seu próprio caso de uso é percorrer um fluxo real com nossa equipe.
Nem sempre. Se você nunca custodia os fundos do usuário e opera como agente ou correspondente de uma instituição licenciada, muitas vezes é possível lançar se apoiando nas licenças dos seus parceiros. Se você retém, converte ou transmite o dinheiro do cliente, precisa dos registros correspondentes (por exemplo, autorização do Banco Central do Brasil como instituição de pagamento). A resposta depende de quem controla os fundos e de onde estão seus clientes, então confirme com um advogado especializado em regulação fintech.
Em um modelo custodial você retém os fundos e as chaves dos seus usuários, o que te coloca em cheio nas regras de transmissão de dinheiro e salvaguarda. Em um modelo não custodial os usuários mantêm o controle dos próprios fundos e aprovam cada movimento, então você opera o produto sem ter o dinheiro do cliente no seu balanço. Não custodial não elimina as obrigações de compliance, mas muda o seu perfil de risco e regulatório e reduz a superfície que você precisa proteger.
Sim. Uma plataforma bem projetada trata cripto e fiat como um único livro-razão desde o início, então você pode ativar os trilhos de stablecoin e cripto de forma incremental sem redesenhar o core. A chave é escolher uma infraestrutura que unifique os dois desde o dia um, em vez de encaixar cripto mais tarde.
A verificação de identidade (KYC/KYB), a triagem de sanções e PEP e o monitoramento de transações rodam no cadastro e em cada transferência. Para cripto, adiciona-se a triagem de carteiras e a troca de dados de travel rule onde exigido. As melhores montagens incorporam esses controles no fluxo em vez de adicioná-los como uma etapa separada depois do lançamento.
A travel rule exige que as informações do originador e do beneficiário viajem junto com as transferências que atingem o limite entre instituições reguladas. Se suas transferências tocam trilhos cripto ou fiat regulados acima do limite aplicável, ela se aplica a você. A infraestrutura moderna anexa esses dados à transferência automaticamente, sem travar a liquidação.
BaaS permite integrar funções financeiras reguladas (contas, cartões, pagamentos) ao seu produto por meio de uma API, com a atividade regulada prestada por instituições licenciadas por trás. Isso encurta o time-to-market porque você constrói a experiência enquanto o provedor cuida dos trilhos e de boa parte da parte operacional de compliance.
No Brasil, o comum é a autorização do Banco Central do Brasil (BCB) como instituição de pagamento ou como Sociedade de Crédito Direto (SCD), dependendo da atividade. Fora do Brasil, aparecem regimes como MSB nos EUA, licença EMI ou de instituição de pagamento na Europa, e registros VASP ou de criptoativos sob regimes como MiCA. Você não necessariamente precisa de todas sozinho, já que operar por meio de parceiros licenciados pode cobrir as partes reguladas enquanto você fica com o produto.
Com infraestrutura baseada em API e uma arquitetura não custodial, equipes com experiência em APIs REST conseguem ter uma integração funcionando em poucas semanas e um MVP em produção em menos de 90 dias. A variável não é a tecnologia, mas o escopo do seu produto, os mercados que você atende e o perímetro de compliance que esses mercados criam.
A cobertura segue as instituições licenciadas por trás de cada trilho e os mercados onde seu compliance está funcionando. Os trilhos locais instantâneos (como PIX), as redes de cartões e os corredores de stablecoin têm alcances diferentes, então a disponibilidade se decide mercado a mercado, não é global por padrão.
Temas
Escrito por
LucíaCompliance e Regulatório
Lucía cobre compliance e regulação na Tokelia. Ela escreve sobre as questões de licenciamento, KYC/AML e travel rule que surgem quando uma fintech começa a movimentar cripto e moeda fiduciária, e as transforma em decisões que uma equipe fundadora pode colocar em prática.
Conte-nos seu caso de uso e indicamos a camada certa: infraestrutura, tokenização ou Yakopay.
Usamos cookies essenciais para o site funcionar e, somente com o seu consentimento, cookies de análise para medir o tráfego. Você pode mudar a sua escolha quando quiser. Política de Cookies