Supervisão de Prevenção à Lavagem de Dinheiro (AML) de Bancos Patrocinadores em Programas de Fintech

Última atualização: setembro de 2026

A supervisão de PLD (Prevenção à Lavagem de Dinheiro) do banco patrocinador é o trabalho que um banco faz para se manter responsável por como cada programa de fintech que ele patrocina detecta e relata crimes financeiros, mesmo quando a fintech realiza esse trabalho no dia a dia. A escala é o que torna isso difícil: um programa pode ser supervisionado por meio de relatórios e reuniões, mas uma carteira de programas, cada um com seus próprios fornecedores, regras e notas de caso, não. Este guia aborda o que faz a supervisão funcionar em muitos programas: visibilidade do cliente final, uma visão única de uma pessoa entre os programas, regras adequadas a cada programa, acesso unidirecional a dados e evidências que um auditor possa acompanhar.

Resumo (TL;DR)

• O banco patrocinador não pode se desvencilhar de sua responsabilidade por meio de contrato. Uma fintech pode realizar o cadastro (onboarding) e o monitoramento de primeira linha, mas o banco responde pelo resultado.

• A supervisão falha quando cada programa reporta em seu próprio formato a partir de suas próprias ferramentas, de modo que o banco vê resumos em vez de clientes.

• A atividade incomum geralmente chega ao banco como um relatório de atividade incomum (UAR) e o banco decide se ela se tornará um relatório de atividade suspeita (SAR) e faz o envio.

• Os auditores estão questionando como o banco detecta a atividade de uma mesma pessoa em vários parceiros fintech, e não apenas dentro de cada um deles.

• As regras específicas de cada programa precisam de controle de alterações: quem escreve uma alteração de regra não deve ser a pessoa que a coloca em produção.

• As diretrizes interinstitucionais de terceiros de 2023 ainda estão em vigor, mas uma substituição foi proposta em 11 de setembro de 2026. A regra do programa de PLD/CFT da FinCEN também ainda é uma proposta.

O que a supervisão de PLD do banco patrocinador deve abranger

Um banco patrocinador deve ser capaz de responder a quatro perguntas sobre qualquer programa a qualquer momento: quem são os clientes finais, o que estão fazendo, quais regras analisaram essa atividade e o que aconteceu com cada alerta. Se o banco só puder respondê-las enviando um e-mail para a fintech, ele estará dependendo do parceiro em vez de supervisioná-lo. Um vice-presidente de operações de crédito e conformidade em uma fintech de crédito com bancos parceiros descreveu o padrão de forma simples: "Você tem que provar que fez, certo? Não basta apenas fazer a coisa certa. Você tem que ser capaz de provar que fez."

Na prática, isso se divide em cinco componentes de trabalho. Cada um deles é um ponto onde a supervisão falha silenciosamente quando um novo programa é adicionado.

Cada linha representa uma decisão de design separada. Um banco pode ter regras de programa fortes e ainda assim falhar na segunda linha, que é para onde a atenção dos auditores está se voltando.

Por que a supervisão falha à medida que o número de programas aumenta

A supervisão falha à medida que novos programas são adicionados porque cada fintech chega com sua própria estrutura tecnológica. Um diretor de risco de fintech em um banco patrocinador disse que a supervisão hoje significa coletar diferentes formatos de relatórios de cada fintech, dependendo das ferramentas que a fintech utiliza. O banco acaba gastando seu tempo conciliando formatos em vez de analisar riscos.

O volume piora a situação. O mesmo diretor de risco de fintech resumiu o aspecto econômico em uma frase: "Não podemos cobrar o suficiente para adicionar uma pessoa a cada vez que adicionamos um programa." A supervisão que depende do aumento de pessoal para cada programa deixa de funcionar à medida que a carteira cresce.

O crescimento do programa também distorce o cenário de alertas. Um gerente de sistemas de BSA/PLD em um banco patrocinador disse que o efeito de uma alteração de ajuste foi ofuscado pelo pico de alertas que se seguiu à integração de um novo parceiro de processamento, de modo que foi necessária uma análise separada para diferenciar os dois. Um novo programa muda a linha de base, e um banco que não rastreia de qual programa veio cada alerta não consegue dizer se o seu ajuste funcionou.

Padrões de falha aos quais ficar atento

Um gerente de UIF (Unidade de Inteligência Financeira) em um banco patrocinador descreveu o segundo padrão diretamente: os alertas para diferentes produtos de depósito eram todos revisados em uma única lista de correspondência, de modo que uma regra escrita para um produto era disparada para os clientes de todos os programas.

Quem monitora, quem relata, quem envia

A fintech ou seu gerente de programa geralmente executa o onboarding e o monitoramento de primeira linha de acordo com o contrato com o banco, e o banco patrocinador é o proprietário da decisão do envio do SAR. Um diretor de tesouraria e conformidade em uma fintech de pagamentos resumiu o lado da fintech: "Não enviamos nenhum SAR. Se tivéssemos que fazer isso, provavelmente seria o nosso banco patrocinador."

O fluxo comum tem quatro etapas:

1. A fintech detecta. Seu monitoramento ou sua equipe de operações identifica uma atividade que parece incomum para o cliente.

2. A fintech relata ao banco. Ela envia um relatório de atividade incomum, com o trabalho de caso de apoio, para o banco patrocinador.

3. O banco investiga e decide. A equipe de BSA do banco patrocinador analisa o UAR, adiciona o que sabe de seus outros programas e decide se a atividade justifica um SAR.

4. O banco envia e dá retorno. O banco envia o SAR e orienta a fintech sobre qual ação tomar em relação à conta.

Um vice-presidente sênior de regulamentação bancária em um provedor de BaaS core descreveu este como o modelo comum: a fintech gera o UAR, envia-o ao banco patrocinador e o banco patrocinador decide se ele se torna um SAR. O ponto fraco é a etapa três. Um vice-presidente e diretor de BSA em um banco patrocinador apontou: "Recebemos um UAR de um parceiro e não temos necessariamente um mecanismo para associar esse agente nocivo a outras contas em nossos outros parceiros."

O fluxo também funciona no sentido inverso para fintechs com mais de um banco. Um líder de conformidade em uma fintech com vários bancos patrocinadores disse que um cliente com relacionamentos em vários deles gerava atividades que precisavam ser relatadas a cada um, e não era possível mostrar a atividade de um banco patrocinador a outro. A fintech não pode preencher essa lacuna, portanto, cada banco precisa ver sua própria exposição de forma completa.

Controles baseados em funções também são importantes na fase de envio. O analista que prepara um SAR não deve ser a pessoa que o envia, o que é um requisito padrão de segregação de funções para programas de BSA. Quando as equipes da fintech e do banco trabalham nos mesmos casos, essa separação precisa ser mantida em ambas as organizações, o que é mais simples quando os UARs, as notas de caso e os rascunhos de SAR ficam em um gerenciamento de casos compartilhado com os parceiros fintech, e não em conversas de e-mail.

Os dados que um banco patrocinador precisa de cada programa

Um banco patrocinador precisa de dados de transações e de clientes no nível do cliente da fintech, e não de resumos no nível da fintech. Um diretor de risco em um banco comunitário explicou o motivo: "Se monitorarmos no nível do parceiro, nunca encontraremos nada porque é um monte de transações de varejo homogêneas."

Contas integradas e FBO (For Benefit Of) tornam isso mais difícil. Em uma conta FBO (mantida em benefício dos clientes da fintech), o sistema core do banco vê uma única conta, enquanto a atividade pertence a muitas pessoas. O mesmo diretor de risco disse que o banco não oferecia suporte a contas FBO porque seu monitoramento não conseguia chegar a essa segunda camada e agrupar as transações pelo cliente do parceiro, e que, como resultado, estava recusando possíveis contas.

Documentos são tão importantes quanto transações. Um diretor de controle de qualidade de conformidade de BSA em um banco patrocinador disse que obter documentos coletados por uma fintech no onboarding ou em uma atualização de KYC era um processo totalmente manual: o banco tinha que pedir ao parceiro a cada vez. Cada solicitação manual atrasa uma investigação e não deixa rastros do que o banco viu e de quando viu.

O acesso deve ser unidirecional. Um diretor de BSA em um banco comunitário com parceiros fintech queria que o banco visse os clientes de todos os parceiros e os seus próprios, enquanto nenhum parceiro pudesse ver os clientes de varejo do banco ou de qualquer outro parceiro. Essa regra define cada escolha de ferramenta, pois a infraestrutura compartilhada só é aceitável se a separação entre parceiros for aplicada no sistema, e não apenas por políticas. Programas com fluxos internacionais adicionam uma camada de corredor a corredor a isso, o que é abordado em um guia separado sobre processos de PLD internacional.

Os auditores também testarão os dados. Um gerente de sistemas de BSA/PLD em um banco patrocinador esperava que os auditores solicitassem as regras subjacentes e a lógica de consulta, e fizessem testes consultando diretamente os dados de monitoramento. Os dados que o banco possui apenas como relatórios de parceiros não podem ser consultados dessa forma.

Visualização de um único cliente em todos os programas

A resolução de entidades entre programas significa reconhecer que o cliente em uma fintech é a mesma pessoa, empresa ou dispositivo em outra, e tratar sua atividade como uma única imagem. Um diretor executivo de BSA em um banco patrocinador de BaaS, que acabou de passar por uma auditoria conjunta federal e estadual, disse que os auditores de embedded banking estão cada vez mais focados na detecção de atividades em múltiplos parceiros fintech, e não apenas dentro de cada um deles.

A matéria-prima geralmente já está nos dados do banco. Um gerente de UIF em um banco patrocinador de BaaS descreveu clientes com o mesmo CPF/CNPJ ou SSN aparecendo em vários parceiros fintech sob diferentes IDs de cliente, conectados mas não vinculados, de modo que a conexão deles no gerenciamento de casos era manual. A resolução funciona a partir de identificadores compartilhados: CPF/CNPJ, SSN, dispositivo, telefone, endereço e conta da contraparte.

Uma descoberta em um programa deve chegar a todos os programas com os quais a pessoa interage. Um diretor de conformidade de crimes financeiros em um banco patrocinador de BaaS disse que, quando alguém comete fraude contra uma fintech, o banco quer essa pessoa fora de todos os programas de sua plataforma. Como o banco não controla quem cada fintech cadastra, ele precisa identificar a correspondência rapidamente após o onboarding, e não na entrada.

É também por isso que alguns bancos patrocinadores estão repensando quem executa o monitoramento. Líderes de BSA em dois bancos patrocinadores perguntaram quanto do monitoramento e da triagem de transações o banco poderia retomar de seus parceiros fintech, em vez de depender deles. Um banco que monitora todos os programas em um único perfil de cliente consegue enxergar através dos programas; um banco que apenas coleta os alertas de cada parceiro não consegue. Quando a atividade da mesma pessoa também atinge outras instituições, a mesma lógica se estende ao compartilhamento de informações entre instituições.

Uma linha de base do banco com regras específicas do programa

Os programas diferem entre si, portanto, o monitoramento deve ser diferente por programa, mantendo-se sob as regras que o banco define e pode alterar. Um vice-presidente sênior de operações de UIF em um banco que está lançando programas de fintech disse que os auditores continuam pedindo para ver um monitoramento adequado a cada fintech e ao seu risco específico.

Um diretor de risco em um banco patrocinador que atende gerentes de programas pré-pagos deu um exemplo concreto: "Personalizamos nossas regras para cada programa. Então, um cartão de um determinado programa pode permitir recargas em dinheiro e outro cartão pode não permitir, certo? Portanto, temos parâmetros de monitoramento diferentes configurados para cada um de nossos programas." A mesma tipologia no nível do banco, como estruturação de depósitos em dinheiro, por exemplo, é executada com parâmetros diferentes em cada programa.

As regras também devem se adequar ao risco do parceiro. Um programa de maior risco, seja pelo produto, base de clientes ou canal de pagamento, deve trazer parâmetros mais rígidos e mais revisões do que um de menor risco. Executar regras idênticas em todos os lugares gera alertas excessivos nos programas de baixo risco ou monitora insuficientemente os de alto risco.

O controle de alterações é onde as regras específicas do programa costumam enfraquecer. Um diretor de risco de produto em um banco patrocinador de BaaS descreveu o controle duplo sobre alterações de regras: a pessoa que escreve uma alteração a apresenta, e o responsável por BSA a coloca em produção, o que, segundo o banco, os auditores viram com bons olhos. Cada alteração deve ser versionada e datada para que qualquer alerta possa ser rastreado posteriormente até a versão da regra que o gerou. Como testar e documentar uma alteração de ajuste para que a cobertura seja mantida é abordado em um guia separado sobre a redução de falsos positivos em PLD.

O que os auditores esperam e em que pé estão as regras

Os auditores esperam que um banco patrocinador demonstre sua supervisão de parceiros fintech por meio de registros, e uma política escrita por si só não atende a essa expectativa. Um vice-presidente sênior de BSA, PLD e fraude em um banco que está lançando um programa de BaaS resumiu a realidade regulatória em uma frase: "Uma vez que você se torna um banco de BaaS, os holofotes nunca mais saem de você."

Essa atenção agora recai sobre as evidências por trás do modelo de supervisão. Um banco deve ser capaz de produzir, a partir de seus próprios sistemas, o histórico de alertas, as versões das regras e o registro de escalonamento para qualquer programa que um auditor escolher analisar.

Os textos regulatórios estão mudando, por isso o status atual é importante:

Leia a tabela como um panorama momentâneo. Um banco patrocinador que constrói seu modelo de supervisão hoje trabalha com as diretrizes de 2023 enquanto acompanha uma substituição que pode alterar os detalhes. A regra da FinCEN é uma proposta, de modo que o banco ainda não deve tratar seus termos como requisitos obrigatórios.

A aplicação das normas adiciona peso a tudo isso. Desde 2024, os reguladores bancários dos EUA têm emitido ações de fiscalização de BSA/PLD contra bancos que atendem a programas de fintech e, posteriormente, encerraram alguns deles. Falhas na supervisão de parceiros fintech e nos programas de BSA/PLD são recorrentes nessas ações. As rescisões mostram que a remediação é fundamental.

Desde que o Federal Reserve encerrou seu programa de atividades inovadoras, as parcerias com fintechs são examinadas como atividades bancárias comuns, com a mesma expectativa de controles que o banco possa demonstrar.

Onde os agentes de IA se encaixam entre os programas

Os agentes de IA se encaixam na supervisão do banco patrocinador como montadores de casos que recomendam caminhos, cabendo aos analistas tomar a decisão. Um agente pode reunir um UAR, a atividade do cliente em outros programas, alertas anteriores e entidades vinculadas em um único caso de forma muito mais rápida do que um analista conseguiria fazer manualmente. O analista ainda dá o aval final.

A governança passa pelo banco patrocinador, inclusive para os agentes que uma fintech deseja usar. Um líder de conformidade em um neobanco com bancos parceiros disse que os requisitos de seu banco parceiro interromperam uma prova de conceito de agente de IA, e que tudo o que o neobanco executa precisa ser auditável e aprovado tanto pelo banco parceiro quanto internamente. Um banco patrocinador deve esperar definir esses requisitos para seus programas.

O risco a ser evitado é a automação sem revisão em dados que ninguém verificou. Um diretor adjunto de BSA em um banco cripto disse: "A próxima onda de termos de compromisso (consent orders) pode vir justamente das empresas que criam agentes internos de IA que encerram alertas automaticamente, com dados ruins entrando e saindo deles."

O modelo que responde a essa preocupação mantém um humano em cada decisão e registra o motivo. A página de agentes da Oscilar afirma que "Os agentes nunca encerram ou escalam alertas de forma autônoma — cada recomendação é revisada e confirmada por um analista humano antes que qualquer ação seja tomada." O envolvimento humano também pode ser dimensionado de acordo com o risco. Um líder de risco em uma fintech disse que a equipe mantém uma forte presença humana no circuito para cada classificação de risco, o que importa mais para a due diligence aprimorada e clientes de alto risco. O mesmo princípio se aplica entre programas: agentes de risco que recomendam enquanto analistas decidem podem assumir a montagem, e o nível de revisão humana acompanha a faixa de risco.

Como a Oscilar aborda isso

A Oscilar constrói a supervisão do banco patrocinador em uma única plataforma que o banco controla, de modo que cada programa de fintech roda no mesmo modelo de dados e cada decisão deixa um registro. Para regras específicas do programa, a solução para bancos patrocinadores oferece "modelos de risco duplicados com um clique entre fintechs. Personalize facilmente os modelos de risco por fintech de forma visual e intuitiva". Para o fluxo de UAR para SAR, ela oferece "escalonamento com um único clique de alertas de SAR/UAR dos parceiros fintech para o banco patrocinador".

Para fins de auditoria, a Oscilar mantém uma trilha de auditoria completa por decisão com justificativas armazenadas, sendo estruturada para ter sempre supervisão humana por padrão. A avaliação antes da produção é estruturada como uma parceria de design de quatro semanas: configuração de dados, um teste retroativo (backtest) contra alertas históricos, uma execução em modo de teste e uma apresentação dos resultados com a sua equipe.

Os detalhes do produto estão na página de supervisão de PLD para bancos patrocinadores.

Perguntas frequentes

Quem é responsável pela conformidade de PLD em uma parceria entre banco patrocinador e fintech?

O banco patrocinador continua sendo o responsável pela conformidade de PLD em seus programas de fintech, pois as contas ficam registradas em sua licença operacional. O acordo do programa pode atribuir o onboarding, o monitoramento e a investigação de primeira linha à fintech, e esta é responsável por realizar esse trabalho de forma adequada. O que o acordo não pode fazer é transferir a responsabilidade final do banco perante os órgãos reguladores.

Quem envia o SAR quando o cliente da fintech é o investigado?

O banco patrocinador geralmente é quem envia o SAR. A fintech normalmente envia um relatório de atividade incomum acompanhado de sua análise do caso, e a equipe de BSA do banco investiga, decide se a atividade é de fato suspeita e realiza o envio. O banco também deve verificar o cliente em seus outros programas antes de tomar uma decisão.

De quais dados um banco patrocinador precisa de seus parceiros fintech para o monitoramento de PLD?

Um banco patrocinador precisa de dados de transações e de clientes no nível do cliente final da fintech, incluindo o sub-razão por trás de qualquer conta compartilhada ou FBO. Ele também precisa de documentos de onboarding e atualização cadastral, sem precisar fazer uma solicitação manual a cada vez. Resumos no nível do parceiro ocultam comportamentos individuais em fluxos de varejo homogêneos.

Como os bancos patrocinadores identificam o mesmo cliente em diferentes programas de fintech?

Os bancos patrocinadores identificam o mesmo cliente entre os programas cruzando identidades por meio de identificadores comuns, como CPF/CNPJ, SSN, dispositivo, telefone, endereço e conta de contraparte. Essa correspondência só funciona se os dados de clientes de todos os programas chegarem ao banco em um único lugar. Uma descoberta em um programa deve ser estendida a todos os outros programas que a pessoa utiliza.

Os agentes de IA podem ajudar um banco patrocinador a revisar alertas entre programas mantendo a aprovação humana?

Sim. Os agentes de IA podem organizar um caso cruzando informações de vários programas, trazendo entidades vinculadas e alertas anteriores, e sugerir uma decisão, cabendo ao analista a palavra final. O banco deve exigir o registro de cada recomendação, sua justificativa e a decisão tomada pelo profissional humano.

A supervisão de um banco patrocinador é tão forte quanto a sua visão dos clientes que utilizam seus programas. Se você estiver identificando onde essa visão está falhando hoje, comece pelo programa cujos dados você menos consegue consultar por conta própria. A página da Oscilar sobre supervisão de PLD para bancos patrocinadores mostra como a plataforma ajuda a resolver isso.