Embedded finance e a fronteira entre o regulado e o não regulado

A tecnologia permite incorporar serviços financeiros e de pagamentos a praticamente qualquer jornada digital, ainda que esses serviços não façam parte do core da empresa. Um dos principais desafios, do ponto de vista jurídico-regulatório, é definir até onde uma empresa pode “embeddar” serviços financeiros e de pagamentos em sua jornada, sem assumir funções reservadas a instituições reguladas, e quais riscos permanecem com ela mesmo quando toda a infraestrutura financeira é terceirizada.

Hoje, uma varejista oferece uma conta digital dentro de seu aplicativo. Um marketplace disponibiliza crédito aos vendedores de sua plataforma. Uma empresa de tecnologia permite que seus clientes façam pagamentos, transferências ou utilizem cartões sem sair de seu ambiente. Em todos esses casos, produtos financeiros deixam de ser uma jornada separada e passam a integrar a experiência originalmente oferecida pela empresa.

Essa é, em essência, a lógica do embedded finance. A expressão, porém, descreve um modelo de negócio, e não uma categoria jurídica. E essa distinção é importante, pois incorporar um serviço financeiro ou de pagamento à experiência do cliente não significa que qualquer empresa esteja autorizada a exercer diretamente as atividades necessárias para prestá-lo.

No Brasil, a legislação reserva determinadas atividades a instituições submetidas a autorização e supervisão do Banco Central do Brasil. A lei 4.595/1964, por exemplo, define as instituições financeiras a partir da atividade de coleta, intermediação ou aplicação de recursos financeiros e estabelece que seu funcionamento depende de autorização. No segmento de pagamentos, a lei 12.865/13 disciplina atividades como a gestão de contas de pagamento, emissão de instrumentos de pagamento e execução ou facilitação de transações de pagamento.

A fronteira jurídico-regulatória, portanto, não é determinada pelo nome dado à solução, pela aparência do aplicativo ou pelo contrato firmado entre as empresas. O que importa é a substância da operação, ou seja, quem contratualmente presta o serviço, quem mantém a relação financeira com o cliente, quem recebe ou movimenta os recursos, com quem se contrata a operação de crédito, quem toma as decisões que caracterizam a atividade regulada e quem assume as obrigações decorrentes dela.

Isso não impede que uma empresa não financeira ou de pagamento tenha participação relevante na jornada. Ela pode disponibilizar a interface, integrar sistemas, desenvolver a experiência do usuário, realizar atividades comerciais e executar tarefas operacionais permitidas. A arquitetura jurídico-regulatória deve, contudo, assegurar que as atividades sujeitas a autorização permaneçam efetivamente sendo executadas e sob responsabilidade de uma instituição devidamente competente a exercê-las.

Essa separação ganhou contornos ainda mais claros com a regulamentação do BaaS - Banking as a Service. Desde novembro de 2025, a resolução conjunta 16 do Conselho Monetário Nacional e do Banco Central do Brasil disciplina expressamente estruturas em que uma instituição autorizada disponibiliza, por intermédio da plataforma de outra empresa, determinados serviços financeiros e de pagamento, como contas, pagamentos, credenciamento e crédito. A própria norma deixa claro que a instituição prestadora dos serviços de BaaS, enquanto entidade regulada, permanece responsável pelos serviços financeiros e de pagamento e exige que sua identificação seja apresentada ao cliente de forma acessível e visível.

O avanço regulatório também evidencia outro ponto relevante: nem toda estrutura de embedded finance é caracterizada como BaaS. Dependendo da atividade desempenhada por cada participante, a operação pode se enquadrar em regimes específicos de correspondentes bancários, Open Finance, subcredenciamento, dentre outras. A resolução conjunta 16, inclusive, exclui expressamente algumas dessas relações de seu conceito de BaaS.

Por isso, um dos principais erros na estruturação de soluções de embedded finance é começar pela tecnologia ou pelo contrato comercial antes de definir o enquadramento regulatório apropriado.

A primeira análise deveria ser funcional. É preciso avaliar o tipo de serviço e a forma com que será prestado por cada parte na jornada. É necessário realizar uma análise da jornada do cliente e identificar, etapa por etapa, quem realiza cada atividade, seja ela o onboarding, processamento da transação, movimentação dos recursos, emissão do instrumento de pagamento, análise de crédito, contratação, desembolso, cobrança, atendimento, tratamento de reclamações e prevenção a fraudes. Só depois dessa análise é possível determinar qual participante pode executar cada função e sob qual regime jurídico.

Terceirizar a infraestrutura não significa terceirizar o risco

O segundo cuidado é evitar a ideia de que a contratação de um banco, fintech ou instituição de pagamento transfere automaticamente toda a responsabilidade relacionada ao produto financeiro ou de pagamento.

Em uma estrutura de BaaS, a regulamentação atribui responsabilidades relevantes à instituição autorizada, inclusive em relação ao cumprimento das normas aplicáveis aos serviços prestados. A instituição deve também assegurar sua identificação perante o cliente e observar requisitos relacionados a governança, controles, segurança e gerenciamento de riscos.

Isso, entretanto, não transforma a empresa que incorpora o serviço em mero espectador.

Se a jornada ocorre dentro de sua plataforma, utilizando sua marca e integrada aos demais produtos oferecidos ao cliente, essa empresa continuará exposta aos riscos decorrentes de suas próprias atividades. Publicidade inadequada, falhas na interface, informações incorretas, tratamento irregular de dados pessoais, vulnerabilidades tecnológicas ou falhas nos processos que estejam sob sua responsabilidade não desaparecem simplesmente porque existe um parceiro que está fornecendo a infraestrutura financeira.

O mesmo raciocínio vale para a relação de consumo. Dependendo de como a cadeia de fornecimento estiver estruturada e da participação de cada empresa na oferta, contratação e execução do serviço, poderá haver responsabilização de mais de um participante perante o consumidor. A alocação contratual de responsabilidades e indenizações entre os parceiros é essencial, mas não necessariamente limita os direitos que a legislação atribui ao cliente perante os fornecedores envolvidos.

Esse ponto costuma ser subestimado em projetos de embedded finance. Um contrato pode estabelecer que determinado parceiro será responsável por uma fraude, por uma indisponibilidade ou por uma violação regulatória. Essa cláusula poderá definir quem suportará economicamente o prejuízo entre as empresas. Ela não necessariamente impedirá, contudo, que o consumidor ou uma autoridade responsabilize outro participante da cadeia quando houver fundamento legal para isso.

O contrato precisa refletir a operação real

O contrato entre os parceiros, portanto, não deve ser tratado apenas como um acordo de integração tecnológica.

Além do escopo de cada empresa, é recomendável estabelecer uma matriz detalhada de responsabilidades sobre onboarding, controles de prevenção à lavagem de dinheiro, análise e concessão de crédito, autenticação de transações, prevenção e tratamento de fraudes, atendimento, contestação de operações, estornos, chargebacks, guarda de documentos, prestação de informações às autoridades e continuidade dos serviços.

Também devem ser definidos níveis de serviço, procedimentos para incidentes, direitos de auditoria, mecanismos de acompanhamento e compartilhamento de informações, responsabilidades por perdas operacionais, hipóteses de indenização e, principalmente, regras de transição ou continuidade da operação em caso de encerramento da parceria.

Esse último aspecto é particularmente relevante em serviços financeiros e de pagamentos. Encerrar a relação entre dois parceiros tecnológicos é diferente de encerrar uma estrutura na qual existem contas abertas, operações de crédito em curso, recursos de clientes ou obrigações regulatórias pendentes.

Dados pessoais e sigilo bancário exigem atenção própria

Embedded finance pressupõe intensa circulação de informações. Dados cadastrais, transacionais, financeiros, comportamentais e de crédito podem transitar entre a empresa que oferece a experiência ao cliente e a instituição responsável pela infraestrutura financeira.

Nesse contexto, a análise não pode se limitar à LGPD - lei geral de proteção de dados (lei 13.709/18). Dependendo das informações envolvidas e de quem as detém, também será necessário observar as regras de sigilo bancário, especialmente aquelas previstas na LC 105/01, que impõe às instituições financeiras o dever de preservar o sigilo de suas operações ativas e passivas e dos serviços prestados. A legislação estabelece hipóteses específicas em que essas informações podem ser reveladas sem caracterizar violação do dever de sigilo.

As duas disciplinas não se confundem. A LGPD regula o tratamento de dados pessoais e exige, entre outros aspectos, finalidade legítima, base legal adequada, transparência e segurança. O sigilo bancário, por sua vez, estabelece uma proteção específica sobre informações relacionadas às operações e aos serviços financeiros. Assim, a existência de uma base legal para determinado tratamento de dados pessoais não significa, automaticamente, que uma informação sujeita a sigilo bancário possa ser compartilhada com qualquer participante da estrutura.

Esse aspecto ganha especial relevância quando uma empresa não regulada passa a ter acesso, por meio da integração com uma instituição regulada, a informações sobre contas, pagamentos, operações de crédito ou movimentações realizadas pelos clientes. O compartilhamento dessas informações deve ter fundamento jurídico próprio, ser compatível com a estrutura regulatória adotada e ficar restrito ao que seja efetivamente necessário para a execução das atividades atribuídas a cada participante. A própria LC 105/01, por exemplo, trata o consentimento expresso do interessado como uma das hipóteses em que a revelação de informação sigilosa não caracteriza violação do dever de sigilo.

Por isso, não basta incluir no contrato uma autorização genérica para compartilhamento de dados. Antes do lançamento do produto, é necessário mapear quais informações circularão entre os parceiros, distinguir dados meramente cadastrais daqueles relacionados às operações financeiras dos clientes, identificar as bases jurídicas que legitimam cada fluxo e limitar os acessos às finalidades necessárias à prestação do serviço.

Sob a perspectiva da LGPD, também é necessário identificar, a partir das funções efetivamente desempenhadas, quais participantes atuarão como controladores ou operadores em cada atividade, definir responsabilidades pelo atendimento aos titulares, estabelecer critérios de retenção e eliminação de dados e disciplinar procedimentos para incidentes de segurança.

Segurança e fraude são parte do desenho do produto

Por fim, segurança cibernética e prevenção a fraudes não podem ser tratadas exclusivamente como temas técnicos.

Quanto mais integrada for a experiência, menos o consumidor percebe onde termina a plataforma comercial e começa a infraestrutura financeira. Uma vulnerabilidade no ambiente de qualquer dos participantes pode comprometer toda a jornada.

A arquitetura deve definir previamente quem autentica o cliente e quais critérios mínimos deverão ser adotados por ambas as partes, quem monitora transações, quais informações são compartilhadas para detecção de comportamentos suspeitos, quem pode bloquear uma operação, como são tratadas contestações e qual empresa suporta financeiramente as perdas em cada cenário.

É justamente nesse conjunto de interfaces que reside boa parte do risco jurídico-regulatório do embedded finance.

A inovação proporcionada pelo modelo é relevante e tende a ampliar cada vez mais a presença de serviços financeiros e de pagamentos em empresas cuja atividade principal está fora do sistema financeiro. Mas a facilidade tecnológica de incorporar uma conta, um cartão, um meio de pagamento ou uma oferta de crédito não elimina a necessidade de identificar quem, juridicamente, está prestando cada serviço.

A pergunta central, portanto, não deveria ser apenas “podemos integrar esse produto à nossa plataforma?”, mas “qual atividade cada participante exercerá depois que essa integração estiver pronta?”.

A resposta define o perímetro regulatório, as responsabilidades contratuais e os riscos da operação. E, em embedded finance, desenhar corretamente essas fronteiras antes do lançamento costuma ser muito menos custoso do que tentar reconstruí-las depois.