Precisa de licença bancária para lançar uma app fintech?

"Precisa de licença bancária para lançar uma app fintech?" são, na verdade, três perguntas com o mesmo casaco. Está a deter dinheiro de clientes? Está a movimentá-lo? E a autorização regulatória de quem cobre essa movimentação — a sua, ou a de outrem? Responda a isto e a questão do licenciamento resolve-se quase sozinha. A versão curta, que surpreende a maioria das equipas: a maioria das apps fintech nunca detém uma licença bancária, porque a maioria das apps fintech nunca faz aquilo para que uma licença bancária realmente serve. O que se segue é um mapa do espectro, não aconselhamento jurídico — o objetivo é saber que perguntas fazer antes de alguém lhe apresentar um prazo ou um preço.

Para que serve realmente uma licença bancária

Uma licença bancária plena — em termos da UE, a autorização como instituição de crédito — permite uma atividade específica e fortemente vigiada: receber depósitos do público e voltar a emprestar esse dinheiro. Esse desfasamento de maturidades, financiar empréstimos longos com saldos que os clientes podem levantar à ordem, é a razão pela qual os bancos têm exigentes requisitos de capital, obrigações de garantia de depósitos e um supervisor a ler-lhes o balanço linha a linha. Se a sua app não recebe depósitos nem concede crédito com base neles, quase de certeza que não está perante uma licença bancária. Está perante algo mais leve, mais abaixo no espectro — e o espectro é toda a história.

O espectro das autorizações, da mais pesada à mais leve

As autorizações financeiras organizam-se em níveis. No topo está a instituição de crédito — o banco — que pode receber depósitos e conceder crédito. Abaixo, uma instituição de moeda eletrónica (IME) pode emitir moeda eletrónica: pode guardar valor dos clientes e colocá-lo em cartões ou carteiras, mas o float que detém tem de ser salvaguardado — mantido à parte e intocado, nunca emprestado. Abaixo desta, uma instituição de pagamento (IP) pode executar pagamentos — iniciar transferências, cobrar, remeter, adquirir transações com cartão — mas não foi concebida para guardar valor ao longo do tempo; o dinheiro passa, não fica. E na base, um agente ou distribuidor não tem licença própria: opera ao abrigo da autorização de uma entidade licenciada que o registou.

O padrão é este: cada degrau que se desce elimina uma capacidade e, com ela, uma parcela de capital e de obrigações. Receber depósitos é o mais pesado que se pode estar autorizado a fazer; ser agente de quem pode é o mais leve. A maioria das apps fintech de consumo — carteiras, cartões, transferências, links de pagamento — situa-se no espaço das IME e das instituições de pagamento, ou assenta num parceiro que detém uma dessas autorizações. Muito poucas precisam de ser um banco, e perceber isso cedo poupa muito esforço mal direcionado.

Uma forma rápida de se situar: se os seus clientes vão manter saldo na app — uma carteira que carregam, um cartão que pré-carregam — está no território da moeda eletrónica, porque guardar valor é a autorização que define uma IME. Se o dinheiro apenas passa — inicia uma transferência, cobra uma fatura, encaminha um pagamento de imediato — a autorização de instituição de pagamento é a opção natural, detida por si ou por um parceiro. Se nunca toca nos fundos e apenas apresenta informação sobre contas detidas noutro local, até isso tem um registo próprio, mais leve. Quanto mais pesado o enquadramento, mais capital e supervisão trazem associados; o objetivo do desenho é ficar tão leve quanto o produto realmente permitir.

Alugar a autorização: modelos com parceiro

Não é preciso deter a autorização para construir sobre ela. O caminho habitual é alugá-la. Num acordo de banco patrocinador ou de Banking-as-a-Service, um banco ou IME licenciado mantém as contas, emite os IBAN e os cartões e salvaguarda o float; você constrói a app sobre a API deles e entrega a experiência. Num modelo de agente, regista-se como agente de uma instituição de pagamento — ou como distribuidor de um emitente de moeda eletrónica — e a licença deles cobre a sua atividade, com o regulador a conhecê-lo através deles. Contratos diferentes, o mesmo facto de fundo: algures na stack, alguém detém a autorização. A única questão é se esse alguém é você ou um parceiro.

Quem assume que responsabilidade

Alugar uma licença não aluga a responsabilidade. A entidade licenciada é quem responde perante o regulador — pela salvaguarda dos fundos dos clientes, pela monitorização de branqueamento de capitais, pela conduta de todo o programa. Mas essas obrigações descem por via contratual. Ao apoiar-se na licença de um parceiro, continua a fazer KYC e onboarding, a vigiar transações para efeitos de AML, a cumprir os limites e os reportes a que o parceiro está obrigado. A responsabilidade não é tanto externalizada como repartida: o parceiro responde por ela perante o regulador e responde por si através de um contrato que devolve ao seu lado grande parte do dever diário. Leia esse contrato com o mesmo cuidado com que leria a licença que decidiu não obter.

Uma licença é a permissão para deter ou movimentar dinheiro de terceiros. O software é a forma de dar instruções sobre esse dinheiro, reconciliá-lo e mostrá-lo ao cliente. Pode comprá-los a um fornecedor ou a dois — mas está sempre a comprar ambos.

O software e a licença são compras separadas

Este é o ponto que reordena todo o projeto. Uma app de pagamentos parece uma só coisa para o cliente, mas são duas fundidas: a autorização regulada para deter ou movimentar dinheiro, e o software que instrui o movimento, mantém o ledger, reconcilia os créditos e apresenta um saldo num ecrã. As duas obtêm-se em separado. Pode deter a sua licença e comprar o software; deter a licença e construir o software internamente; alugar a autorização através de um parceiro e comprar software por cima; ou ficar com ambos de um único fornecedor que os agrupou. Todas são normais. O que não é normal — e que custa meses aos projetos sem se dar por isso — é confundir as duas: procurar uma «licença bancária» quando o que precisava era de um parceiro BaaS mais uma app, ou procurar uma app a supor que a autorização vem soldada a ela.

Ver as duas como compras separadas esclarece, porque permite orçamentá-las e calendarizá-las de forma independente. O software pode ser avaliado pelo seu mérito — o fluxo de onboarding funciona, o ledger está correto, os operadores conseguem de facto operar o sistema — enquanto a autorização se avalia por jurisdição, salvaguarda e condições. O Protocore Pay (/products/pay) é um exemplo da camada de software isolada: uma plataforma de apps whitelabel e consola de operador que corre sobre os rails regulados que você trouxer. Não é uma licença, e nenhum software o é — razão pela qual a licença continua a ser uma linha separada no plano.

Perguntas a fazer a qualquer fornecedor de plataformas

Seja quem for que lhe venda uma plataforma «lance a sua fintech», a mesma lista curta dissipa a maior parte da ambiguidade. O vosso produto inclui uma autorização regulada, ou trago eu a minha? Se inclui, de quem é a licença, em que países, e sou cliente direto dessa entidade ou do seu agente? Quem salvaguarda os fundos dos clientes e onde ficam depositados? Quem está indicado ao regulador para efeitos de AML — vocês, o parceiro ou eu? Que obrigações recaem sobre mim por contrato, mesmo a licença não sendo minha? E se a parceria terminar, o que acontece ao dinheiro e aos dados dos meus clientes? As respostas separam depressa os fornecedores entre os que vendem software, os que revendem a autorização de um parceiro e os que realmente agruparam ambos — e dizem-lhe com qual dos três está realmente a falar.

O lado tranquilizador de tudo isto: a maioria das apps lança-se como software mais a autorização de um parceiro, e só passa a ter licença própria quando o volume, a margem ou a estratégia justificam o capital e a equipa de compliance. Saber de que degrau realmente precisa — e que o software e a autorização se compram em linhas separadas — é meio caminho andado. O resto é fazer as perguntas acima e ler as respostas com atenção. Nada disto constitui aconselhamento jurídico, e os limiares e os nomes das categorias variam consoante a jurisdição; trate-o como o mapa que leva para a conversa com um regulador ou um consultor, não como substituto de nenhum deles.