Tomadoras de BaaS: quando a fintech ultrapassa o perímetro regulatório sem precisar

O BaaS nasceu para aprimorar a oferta de serviços financeiros por empresas não financeiras, com apoio institucional e operacional de uma instituição autorizada. Em tese, cada papel é bem claro: a prestadora regulada detém a licença e responde perante o Banco Central; a tomadora distribui a experiência ao seu cliente; e o prestador tecnológico integra sistemas e sustenta a operação. O problema é que muitas estruturas crescem deslocando funções da prestadora para a tomadora e, com isso, criam risco regulatório desnecessário.

Esse risco nem sempre decorre de uma decisão consciente da tomadora. Às vezes, a prestadora não está preocupada se os termos contratuais podem potencialmente fazer com que a tomadora avance no perímetro regulatório sem necessidade. Em determinados contratos de BaaS, por exemplo, acaba constando que a tomadora será responsável pelo cadastramento e qualificação de clientes, pela coleta documental, pela análise cadastral, pela prevenção a fraudes, por bloqueios operacionais, pelo atendimento ao usuário, pela gestão de contestação, pela parametrização de limites, pelo controle de acesso à solução ou até por determinados fluxos de repasse, sem que o instrumento esclareça que tais atividades são executadas “por conta e ordem” da prestadora regulada — expressão que, nesse contexto, deve significar atuação meramente operacional e instrumental da tomadora, sob orientação, supervisão, controles e responsabilidade final da instituição autorizada, e não como atividade própria ou autônoma da tomadora. Melhor ainda seria que o contrato dissesse expressamente que essas atividades são realizadas pela tomadora como apoio operacional à prestadora regulada, sob sua supervisão e responsabilidade final, sem assunção, pela tomadora, de função regulada em nome próprio. A ausência dessa delimitação formal pode trazer um “liability”, ou seja, uma responsabilidade regulatória desnecessária para a tomadora.

Esse descompasso aparece em três camadas. A primeira é o contrato assinado entre as partes envolvidas, que normalmente descreve a “plataforma”, a “orquestração” ou a “integração”. A segunda é a operação real, ou seja, aquilo que ocorre de fato: a tomadora controla o cadastramento de clientes, regras de bloqueio, parametrização de produto, emissão de cartões, repasses, atendimento e até o livro-razão que organiza saldos e eventos. A terceira é o discurso institucional: sítio eletrônico, aplicativo e peças comerciais passam a sugerir que a tomadora “oferece conta”, “emite cartão”, “faz pagamentos” ou “concede crédito”, dando a entender, ainda que implicitamente, que atua em nome próprio.

Entretanto, a arquitetura regulatória do BaaS aponta em direção oposta. A norma parte da prestação de serviços financeiros ao cliente por intermédio da tomadora, mediante integração de sistemas, mas preserva a centralidade da instituição autorizada. O desenho separa o BaaS de figuras como correspondente no país, processamento e armazenamento de dados e parcerias no âmbito do Sistema Financeiro Aberto. Também exige que a prestadora seja identificada de forma visível ao cliente. Em outras palavras, o Banco Central não olha apenas para o rótulo comercial do arranjo, mas para a função exercida, para a alocação de responsabilidades e para a transparência da jornada do cliente.

É nesse ponto que surgem os comportamentos juridicamente mais arriscados. O primeiro é o controle material da operação. Se a tomadora mantém o livro-razão que, na prática, se torna a fonte de referência para saldo, movimentação, limites ou travas, ela deixa de ser apenas uma interface. O segundo é o ciclo de cartões: vender o cartão como “seu”, definir regras críticas e ocultar a prestadora regulada na jornada do usuário aumenta o risco de o Banco Central entender que a atividade exercida possui natureza regulada. O terceiro é o trânsito financeiro: repasses, recebimentos em conta própria, liquidação informal e comandos financeiros sem delimitação nítida de quem decide, registra e responde costumam deslocar a discussão de tecnologia para função financeira.

O mesmo vale para o cadastramento de clientes, a prevenção à lavagem de dinheiro, a prevenção a fraudes e a comunicação com o usuário. A tomadora pode cooperar com a coleta de dados, a conferência documental, a parametrização de fluxos e os canais de atendimento, mas isso não autoriza ocultar a figura da prestadora regulada nem transformar o aplicativo em vitrine de uma instituição financeira invisível. A diferença jurídica é relevante: uma coisa é a tomadora executar tarefas operacionais em apoio à instituição autorizada; outra é o contrato fazer parecer que a tomadora é responsável direta por funções que deveriam permanecer sob vigilância, comando e responsabilidade da regulada.

Esse ponto merece atenção porque o contrato pode criar risco mesmo antes de a operação apresentar um problema concreto. Se o instrumento atribui à tomadora obrigações de natureza sensível, sem ressalvar que sua atuação ocorre “por conta e ordem” da prestadora regulada, o documento passa a produzir uma aparência regulatória indesejada. A tomadora, que buscou o BaaS justamente para não precisar de autorização própria, acaba assumindo, por redação contratual, uma posição mais próxima de agente regulado do que seria necessário para o seu modelo de negócio.

O novo marco do BaaS reforça exatamente esses pontos. O contrato precisa delimitar papéis e responsabilidades, prever medidas de segurança, garantir o acesso da prestadora a informações, vedar recebimentos e depósitos em conta própria da tomadora para serviços do arranjo, restringir subcontratações centrais e deixar claro ao cliente que a tomadora não atua em nome da instituição autorizada. A lógica é simples: a execução pode ser distribuída; a responsabilidade regulatória, não.

Para fundadores, equipes de produto, conformidade, bancos parceiros e investidores, o ativo mais valioso da operação não é apenas a interface tecnológica, mas a coerência regulatória do modelo. Empresas que crescem com narrativa comercial mais ambiciosa do que sua arquitetura jurídica real, tendem a descobrir tarde demais que o problema não estava no produto, mas na forma como ele foi contratado, documentado e apresentado ao mercado. É exatamente esse tipo de desalinhamento que trava parcerias, endurece diligências, encarece captações e reduz valor estratégico em operações de fusão e aquisição.

Assim, podemos sugerir um roteiro de verificação, conforme segue: compare contrato, fluxo operacional e jornada real do cliente; identifique quem controla livro-razão, regras críticas, saldos e bloqueios; revise cadastramento de clientes, prevenção à lavagem de dinheiro, prevenção contra fraudes e trilhas de evidência; verifique se as atividades atribuídas à tomadora estão expressamente delimitadas como tarefas de apoio, realizadas “por conta e ordem” da instituição regulada, quando for o caso; valide se a prestadora regulada aparece com clareza no aplicativo, no sítio eletrônico, no contrato e no cartão; teste cláusulas de incidente, continuidade, auditoria, suspensão e saída; elimine recebimentos em conta própria e subcontratações indevidas; submeta comunicação comercial, denominação de produtos e materiais institucionais à revisão regulatória antes do lançamento do próximo produto.

Em 2026, o BaaS maduro não é aquele que promete mais. É aquele que distribui melhor as responsabilidades, produz evidências e cresce sem invadir o perímetro regulatório por vaidade comercial, redação contratual imprecisa ou conveniência da prestadora.

Se a empresa opera, contrata ou investe em estruturas de BaaS, a coerência entre contrato, operação e comunicação institucional deve ser tratada como parte da própria governança do modelo. Identificar eventuais desalinhamentos antes da expansão da operação tende a reduzir atritos com parceiros, questionamentos em diligências e riscos regulatórios que poderiam exigir ajustes mais complexos no futuro.