Preciso de licença bancária para lançar um app fintech?
"Preciso de licença bancária para lançar um app fintech?" são, na verdade, três perguntas em um só casaco. Você vai manter o dinheiro do cliente? Vai movimentá-lo? E a autorização regulatória de quem cobre essa movimentação — a sua ou a de outra pessoa? Responda a essas perguntas e a questão da licença praticamente se responde sozinha. A versão curta, que surpreende a maioria das equipes: a maior parte dos apps fintech nunca tem licença bancária, porque a maior parte deles nunca faz a única coisa para a qual uma licença bancária existe. O que segue é um mapa do espectro, não aconselhamento jurídico — o objetivo é saber quais perguntas fazer antes que alguém lhe passe um prazo ou um preço.
Para que serve, de fato, uma licença bancária
Uma licença bancária plena — em termos da UE, uma autorização de instituição de crédito — permite uma atividade específica e fortemente protegida: captar depósitos do público e emprestar esse dinheiro. Esse descasamento de prazos, financiar empréstimos longos com saldos que os clientes podem sacar a qualquer momento, é o motivo pelo qual os bancos têm exigências pesadas de capital, obrigações de garantia de depósitos e um supervisor lendo o balanço linha por linha. Se o seu app não capta depósitos nem empresta com base neles, quase certamente você não está diante de uma licença bancária. Está diante de algo mais leve, mais adiante no espectro — e o espectro é a história toda.
O espectro das permissões, da mais pesada à mais leve
As permissões financeiras vêm em camadas. No topo está a instituição de crédito — o banco — que pode captar depósitos e conceder empréstimos. Abaixo dela, uma instituição de moeda eletrônica (EMI) pode emitir moeda eletrônica: pode guardar o valor dos clientes e colocá-lo em cartões ou carteiras, mas o saldo que mantém precisa ser protegido — segregado e intocado, nunca emprestado. Mais abaixo, uma instituição de pagamento (PI) pode executar pagamentos — iniciar transferências, cobrar, remeter, adquirir transações de cartão — mas não é feita para guardar valor ao longo do tempo; o dinheiro passa por ela, não fica parado. E na base, um agente ou distribuidor não tem licença própria, operando sob a autorização de uma entidade licenciada que o registrou.
O padrão é que cada degrau abaixo abre mão de uma capacidade e, com ela, de uma parcela de capital e de obrigações. Captar depósitos é o que há de mais pesado que você pode ser autorizado a fazer; ser agente de quem pode é o mais leve. A maioria dos apps fintech de consumo — carteiras, cartões, transferências, links de pagamento — vive na faixa de EMI e instituição de pagamento, ou em cima de um parceiro que detém uma dessas permissões. Muito poucos precisam ser um banco, e saber disso cedo poupa muito esforço mal direcionado.
Um jeito rápido de se situar: se seus clientes vão manter saldo no app — uma carteira que recarregam, um cartão que pré-carregam — você está no território da moeda eletrônica, porque guardar valor é a permissão que define uma EMI. Se o dinheiro apenas passa — você inicia uma transferência, cobra um boleto, repassa um pagamento direto — a permissão de instituição de pagamento é o encaixe natural, mantida por você ou por um parceiro. Se você nunca toca nos fundos e só apresenta informações sobre contas mantidas em outro lugar, até isso tem um registro próprio, mais leve. Quanto mais pesado o seu enquadramento, mais capital e supervisão vêm junto; o objetivo do projeto é ficar no enquadramento mais leve que o produto realmente exige.
Alugando a permissão: modelos com parceiro
Você não precisa ter a permissão para construir em cima dela. O caminho comum é alugá-la. Em um arranjo de banco patrocinador ou Banking-as-a-Service, um banco ou EMI licenciado mantém as contas, emite os IBANs e os cartões e protege o saldo; você desenvolve o app sobre a API deles e entrega a experiência. No modelo de agente, você se registra como agente de uma instituição de pagamento — ou como distribuidor de um emissor de moeda eletrônica — e a licença deles cobre a sua atividade, com o regulador conhecendo você por meio deles. Contratos diferentes, mesmo fato de fundo: em algum ponto da pilha, alguém detém a permissão. A única questão é se esse alguém é você ou um parceiro.
Quem assume qual responsabilidade
Alugar uma licença não transfere a responsabilidade. A entidade licenciada é quem responde ao regulador — pela proteção dos fundos dos clientes, pelo monitoramento de prevenção à lavagem de dinheiro, pela conduta de todo o programa. Mas essas obrigações descem por contrato. Ao usar a licença de um parceiro, você ainda fará KYC e onboarding, ainda monitorará transações para AML, ainda respeitará os limites e relatórios aos quais o parceiro está obrigado. A responsabilidade não é tanto terceirizada quanto repartida: o parceiro responde por ela perante o regulador e cobra de você por contrato, que devolve ao seu lado boa parte do dever do dia a dia. Leia esse contrato com o mesmo cuidado com que leria a licença que você decidiu não obter.
Uma licença é a permissão para guardar ou movimentar o dinheiro de outras pessoas. O software é como esse dinheiro é instruído, conciliado e mostrado de volta ao cliente. Você pode comprar os dois de um fornecedor ou de dois — mas sempre estará comprando os dois.
O software e a licença são compras separadas
Este é o insight que reorganiza o projeto inteiro. Para o cliente, um app de pagamentos parece uma coisa só, mas são duas fundidas: a permissão regulada para guardar ou movimentar dinheiro e o software que comanda a movimentação, mantém o ledger, concilia os créditos e exibe um saldo na tela. As duas são contratadas separadamente. Você pode ter licença própria e comprar o software; ter licença e desenvolver o software internamente; alugar a permissão por meio de um parceiro e comprar software por cima; ou levar as duas de um único fornecedor que as empacotou. Todas as quatro são normais. O que não é normal — e custa meses aos projetos sem que ninguém perceba — é confundir as duas: buscar uma "licença bancária" quando o que você precisava era de um parceiro de BaaS mais um app, ou buscar um app achando que a permissão vem soldada a ele.
Enxergar as duas como compras separadas esclarece porque permite precificá-las e programá-las de forma independente. O software pode ser avaliado pelos próprios méritos — o fluxo de onboarding funciona, o ledger está correto, os operadores conseguem de fato operar a solução — enquanto a permissão é avaliada por jurisdição, proteção de fundos e condições. O Protocore Pay (/products/pay) é um exemplo da camada de software isolada: uma plataforma de apps whitelabel com console de operação que roda sobre os trilhos regulados que você trouxer. Não é uma licença, e nenhum software é — e é justamente por isso que a licença continua sendo uma linha separada no plano.
Perguntas para qualquer fornecedor de plataforma
Quem quer que esteja lhe vendendo uma plataforma de "lance sua fintech", a mesma lista curta dissolve a maior parte da ambiguidade. O seu produto inclui uma permissão regulada, ou eu trago a minha? Se inclui, de quem é a licença, em quais países, e eu sou cliente direto dessa entidade ou agente dela? Quem protege os fundos dos clientes e onde eles ficam? Quem é o responsável perante o regulador pela prevenção à lavagem de dinheiro — vocês, o parceiro ou eu? Quais obrigações recaem sobre mim por contrato mesmo que a licença não seja minha? E, se a parceria acabar, o que acontece com o dinheiro e os dados dos meus clientes? As respostas separam rapidamente os fornecedores entre os que vendem software, os que revendem a permissão de um parceiro e os que de fato empacotaram as duas — e mostram com qual dos três você está realmente falando.
O lado tranquilizador de tudo isso: a maioria dos apps lança com software mais a permissão de um parceiro e só migra para a licença própria quando volume, margem ou estratégia justificam o capital e a equipe de compliance. Saber qual degrau você realmente precisa — e que software e permissão são comprados em linhas separadas — é a maior parte da batalha. O resto é fazer as perguntas acima e ler as respostas com atenção. Nada disso é aconselhamento jurídico, e os limites e os nomes das categorias variam conforme a jurisdição; use como o mapa que você leva para a conversa com um regulador ou um consultor, não como substituto deles.
Tem um sistema para construir?
Conte o problema. Voltamos com uma arquitetura e um plano.