Processos de PLD Transfronteiriços, por Corredor e Jurisdição

Última atualização: setembro de 2026

Os processos de prevenção à lavagem de dinheiro (PLD) transfronteiriços precisam lidar com mais fatores do que um programa doméstico: dados de risco que variam de acordo com a jurisdição, informações de pagamento que devem acompanhar cada transferência, tipologias específicas de cada corredor e relatórios de atividades suspeitas enviados a autoridades diferentes com base na origem da obrigação. Um programa que cria um processo separado para cada corredor multiplica regras, filas e comprovações até que desativar os corredores pareça a única solução viável. A alternativa é tratar cada corredor como uma configuração dentro de um único programa, com analistas atuando em uma fila unificada e o contexto de cada jurisdição vinculado a cada alerta.

Resumo prático

• Cada novo corredor adiciona regras, listas, tipologias, destinos de relatórios e comprovações. Se for criado como um programa separado, cada um adiciona a sua própria fila e o seu próprio padrão de comprovação.

• Trate um corredor como um conjunto de parâmetros datados e versionados: dados de risco de jurisdição, limites e cenários, dados de pagamento obrigatórios, escopo de triagem e destino do relatório.

• Uma jurisdição de alto risco é uma informação de entrada para calibrar com base na atividade esperada da empresa. A declaração de junho de 2026 do GAFI afirma que seus padrões não preveem a exclusão de riscos (de-risking).

• A Recomendação 16 revisada do GAFI (junho de 2025) padroniza os dados do remetente e do beneficiário que acompanham os pagamentos transfronteiriços acima de USD/EUR 1.000, com vigência até o final de 2030.

• O relatório é um SAR nos EUA e no Reino Unido e um STR sob a terminologia do GAFI e no Canadá. Execute uma única investigação e faça o envio conforme a origem da obrigação.

• Encaminhe todos os alertas de um mesmo cliente para o mesmo analista, independentemente do corredor. Os agentes de IA podem reunir o contexto e sugerir recomendações; os analistas tomam as decisões.

O que um processo de PLD transfronteiriço precisa gerenciar

Um processo de PLD transfronteiriço é o caminho que um alerta percorre desde um pagamento que cruza uma fronteira até uma decisão registrada. Ele precisa gerenciar os riscos jurisdicionais que variam de acordo com o país e mudam constantemente, dados de pagamento que devem acompanhar a transferência, tipologias específicas de cada corredor e destinos de relatórios que dependem da jurisdição. Ele também deve gerar um histórico de comprovação para cada decisão, permitindo que fiscais de qualquer uma dessas jurisdições consigam fazer a auditoria.

Nada disso exige um programa separado.

Um VP de engenharia de risco e conformidade em uma empresa de remessas descreveu desta forma: "Nosso processo global não é diferente... O que muda são os agentes de relatório e a forma de envio, certo? Então, quando digo que o envio é diferente, significa que os formulários mudam e os portais dos reguladores variam."

Esse é o modelo descrito neste guia: um único processo de investigação, configurado por corredor, com os resultados adaptados de acordo com a jurisdição.

Por que cada novo corredor multiplica o trabalho

Cada novo corredor multiplica o trabalho quando é implementado como um novo manual de regras, em vez de um novo conjunto de parâmetros. Regras isoladas por corredor tornam-se filas de alertas separadas, ciclos de ajuste individuais e padrões de comprovação duplicados. Assim, um único cliente que realiza transações por três corredores diferentes pode gerar alertas analisados por três analistas distintos, sem que nenhum deles veja o trabalho do outro.

Um diretor de conformidade de uma empresa de cripto e remessas explicou esse impasse. Uma única entidade recebia transações de várias jurisdições, impossibilitando a adoção de um padrão único para os documentos coletados por transação, enquanto o regulador local ainda exigia registros padronizados. O volume de trabalho cresce a cada corredor porque não há compartilhamento de informações entre eles.

A visibilidade também diminui ao longo da cadeia de pagamento. Em uma relação de correspondência bancária aninhada, o correspondente processa o pagamento de um cliente do banco respondente e visualiza a transferência, mas não quem está por trás dela. Um gerente principal de produto em uma empresa de pagamentos B2B transfronteiriços resumiu bem: "O maior desafio para as instituições financeiras é que elas possuem clientes subjacentes que podem estar realizando atividades de risco, e não as instituições financeiras em si."

O cenário de falha é a exclusão de riscos (de-risking)

Quando o volume de trabalho se torna insustentável, a saída mais simples parece ser cortar um corredor ou uma categoria de clientes. A declaração do GAFI sobre jurisdições sob monitoramento intensificado, datada de 19 de junho de 2026, descarta essa prática. O documento esclarece que os Padrões do GAFI "não preveem a exclusão de riscos (de-risking) ou o bloqueio de categorias inteiras de clientes, mas exigem a aplicação de uma abordagem baseada em risco", e solicita que os fluxos de remessas "não sejam interrompidos nem desencorajados."

Uma abordagem baseada em risco também significa que o risco jurisdicional não pode ser o único critério. Um diretor de conformidade de uma empresa de remessas afirmou: "De todos os indicadores de risco e alertas, lidamos predominantemente com países de alto risco. E esse fator isolado quase nunca é um bom indicador de atividade suspeita. Na verdade, é o pior indicador para nós, porque representa a maior parte das nossas operações."

Um diretor de conformidade de uma subsidiária de um banco estrangeiro relatou o mesmo problema sob outra perspectiva: a matriz classificava o país da própria subsidiária como de alto risco, fazendo com que as operações fundamentais para a existência do negócio elevassem a classificação de risco dos clientes de forma automática.

Armadilhas que transformam corredores em programas isolados

• Copiar o conjunto de regras para cada corredor, de modo que a correção de uma tipologia em um corredor nunca chega aos outros.

• Utilizar o risco jurisdicional como um multiplicador bruto, o que satura a fila de análise em empresas cuja atividade normal ocorre em corredores de alto risco.

• Listas e alterações de classificação sem data de registro, impossibilitando identificar qual versão da configuração gerou uma decisão no passado.

• Distribuição rotativa de alertas (round-robin), que divide as atividades de um único cliente entre vários analistas.

• Comprovações armazenadas de forma isolada por corredor, forçando o analista a reconstruir o perfil do cliente para cada novo caso.

Canais: correspondência bancária, corredores de remessa e pagamentos fintech

O dinheiro transfronteiriço circula por três canais principais, e cada um altera o nível de visibilidade da instituição monitoradora. O processo permanece idêntico nos três cenários, alterando-se apenas os parâmetros.

Correspondência bancária e relações aninhadas

Na correspondência bancária, um banco fornece contas e serviços de pagamento para outro banco (o respondente), permitindo que os clientes deste enviem e recebam fundos em mercados onde ele não atua diretamente. O controle de PLD na correspondência bancária é complexo por conta do aninhamento: um respondente pode permitir que seus próprios clientes, ou outros bancos, acessem os serviços do correspondente. O correspondente visualiza o pagamento, mas não o cliente final, de modo que seu monitoramento depende da diligência prévia realizada pelo respondente e dos dados que acompanham a transferência.

É por isso que as regras jurisdicionais devem estar vinculadas à transação, e não à relação da conta. Um VP e diretor de BSA em um banco de correspondência comentou: "Qualquer uma das regras de jurisdição ou controles semelhantes deve disparar alertas independentemente de haver ou não um número de conta associado." Um diretor de conformidade de uma subsidiária bancária mencionou a criação de regras específicas para correspondência bancária dentro do programa existente, com revisão e justificativa dos resultados dos alertas anualmente. Bancos que operam esse tipo de programa precisam de um sistema de monitoramento de transações de PLD para bancos que gerencie esse canal como mais um conjunto de regras no mesmo ecossistema.

Corredores de remessa e transferências de fundos

As empresas de serviços monetários (MSBs) e transmissoras de fundos operam por meio de redes de agentes, frequentemente com dinheiro em espécie em uma das pontas. Por isso, os programas de PLD dessas empresas contam com obrigações específicas de corredores que sofrem alterações frequentes. Dois exemplos dos EUA: desde 1º de janeiro de 2026, um imposto federal de 1% se aplica a remessas enviadas ao exterior quando financiadas com dinheiro em espécie, ordens de pagamento, cheques administrativos ou instrumentos físicos similares. O FinCEN relançou sua Ordem de Alvo Geográfico para a fronteira sudoeste em 2 de setembro de 2026, exigindo relatórios sobre certas operações em espécie nas áreas cobertas.

Nenhuma dessas obrigações exige um novo processo. O instrumento de financiamento e a localização da transação tornam-se pontos de dados capturados pelo programa e parâmetros aplicados nos corredores relevantes.

Pagamentos transfronteiriços de plataformas fintech

Plataformas de pagamento enviam dinheiro de um único pagador para vários destinatários em diversos países, e a ponta receptora costuma ser inédita. Um cientista de dados de fraude em uma plataforma global de pagamentos transfronteiriços destacou os padrões que importam: pagamentos fracionados em valores menores para muitos destinatários, URLs compartilhadas entre contas e grupos de contas registradas em períodos semelhantes. Esses sinais independem do corredor, o que reforça a necessidade de manter um perfil único para o cliente e para a contraparte em todos os corredores. Quando esses pagamentos passam por um banco parceiro, a supervisão desse banco sobre os programas é abordada em um guia específico de supervisão de PLD para bancos parceiros.

Trate cada corredor como uma configuração, não como um programa separado

Tratar um corredor como uma configuração significa que seus dados de risco, limites, informações de pagamento obrigatórias, escopo de triagem e destinos de relatórios são parâmetros dentro de um único programa, todos datados e versionados. O processo de investigação, o histórico do cliente e o padrão de comprovação permanecem consistentes. Adicionar um corredor significa incluir um novo conjunto de parâmetros, e não criar uma nova fila de trabalho.

A tabela demonstra essa lógica: somente a coluna da esquerda muda quando um novo corredor é adicionado.

Torne o risco de jurisdição um parâmetro datado

O GAFI atualiza suas listas de jurisdições sob monitoramento intensificado após cada sessão plenária. A última declaração é de 19 de junho de 2026. Uma alteração na lista deve entrar no programa como uma nova versão do parâmetro de jurisdição com sua data de vigência, e não como uma alteração direta nas regras em execução. Quando um auditor questionar o motivo da alteração de risco de um cliente, a resposta será a versão que estava em vigor no dia da decisão.

Os auditores também esperam que a instituição conheça seus próprios corredores. Uma executiva de PLD e compliance em um banco comunitário observou que os auditores desejam ver os países com os quais a instituição opera e a parcela de transações que cada um representa, e que ela faz esse levantamento manualmente hoje. Um perfil de corredor esperado mantido como configuração atende a essa exigência e oferece uma linha de base para identificar desvios.

Ajuste as regras de acordo com o comportamento do corredor

As tipologias variam conforme o corredor, portanto os limites e cenários também devem variar. Um diretor de conformidade de uma fintech de pagamentos transfronteiriços com várias licenças comentou: "Devido às particularidades das transações que acompanhamos em várias jurisdições, é fundamental ajustar algumas regras para incluir avaliações de risco comportamental." O mesmo diretor de conformidade da empresa de cripto e remessas descreveu limites que variam por etapa da operação e uma entidade do grupo que pode transacionar com uma jurisdição proibida para outra. Ambas as situações são resolvidas com configuração: uma variante de regra por corredor e uma permissão por entidade.

Toda alteração de limite requer um registro das simulações feitas e da cobertura mantida. O processo de testar e documentar alterações de limites para manter a cobertura de tipologias é explicado em nosso guia sobre redução de falsos positivos em PLD.

Faça a triagem no momento da transação com escopo baseado em risco

A triagem e o monitoramento trazem melhores resultados quando unificados no momento da transação, em vez de processados como revisões sequenciais. Um banco global descreveu a transição para unificar a triagem de fraude e PLD "no mesmo instante do tempo. Ou seja, no momento da transação." Isso requer uma plataforma rápida o suficiente para decidir durante o fluxo do pagamento; a plataforma da Oscilar entrega decisões em menos de 100ms.

Fazer a triagem de absolutamente tudo não deve ser o objetivo. Um líder de risco em uma empresa de pagamentos transfronteiriços questionou a necessidade de passar todas as transações pela triagem de PEP e buscou formas de separar os fluxos que devem ser analisados dos que não precisam. O escopo de triagem é um parâmetro de corredor como qualquer outro. A atualização das listas de sanções da OFAC e de outros órgãos de controle é um tema específico, detalhado em nosso guia sobre gestão de listas de sanções.

Dados de pagamento que acompanham a transferência

Os dados enviados em uma transferência transfronteiriça servem como entrada para o processo, e o GAFI tornou as exigências sobre seu conteúdo mais rígidas. Em sua Plenária de junho de 2025, o GAFI revisou a Recomendação 16 sobre transparência de pagamentos. A revisão esclarece as responsabilidades de cada participante da cadeia de pagamento em incluir as informações e mantê-las íntegras, padroniza as informações do remetente e do beneficiário para transferências transfronteiriças P2P acima de USD/EUR 1.000 (nome, endereço e data de nascimento) e exige ferramentas para evitar fraudes e erros, como a verificação dos dados bancários de quem recebe. As mudanças entram em vigor até o final de 2030.

Até lá, a qualidade dos dados continuará oscilando. Um diretor de conformidade e risco em um agregador de pagamentos transfronteiriços para remessas comentou que a ponta remetente traz nome, data de nascimento, nacionalidade e documento de identidade, enquanto a receptora muitas vezes traz apenas o nome e o número da conta, gerando a maior parte dos alarmes falsos de triagem. Os campos obrigatórios devem constar na configuração do corredor, permitindo que o programa saiba exatamente o que esperar de cada rota e tipo de pagamento.

Dados ausentes ou ocultados também são um sinal de alerta. Quando um atributo essencial está ausente, o alerta deve ser enviado a um analista com o respectivo aviso de lacuna, e não ser descartado de forma automática, já que validar um alerta sem evidências robustas eleva o risco regulatório. A aplicação das mesmas regras de transparência de pagamentos para transferências de criptomoedas e stablecoins, conhecida como "travel rule", é explicada em um guia separado.

STR ou SAR: o relatório depende da jurisdição

O nome do relatório muda de acordo com o país onde é enviado. Instituições financeiras americanas enviam um Relatório de Atividade Suspeita (SAR) ao FinCEN. A Recomendação 20 do GAFI e o FINTRAC do Canadá usam o termo Relatório de Transação Suspeita (STR), e o Reino Unido utiliza SAR, enviado à Unidade de Inteligência Financeira da National Crime Agency.

A obrigação principal é a mesma em qualquer região: reportar atividades suspeitas à Unidade de Inteligência Financeira (UIF) do país. Os limites, prazos, formulários e gatilhos variam. Um diretor de conformidade em uma empresa global de pagamentos resumiu em uma frase: "Não enviamos SARs, enviamos STRs, pois o processo é um pouco diferente." Um diretor de conformidade em um banco comunitário com operações em várias jurisdições destacou que "o prazo de envio é muito mais curto que o do FinCEN nessas regiões."

A resposta operacional é manter uma única investigação e um único caso, registrando a jurisdição no caso e gerando o relatório específico para a autoridade correspondente. Um grupo de remessas com entidades reguladas em mais de um país também precisa manter os registros de cada operação separados, de modo que uma auditoria local visualize apenas os clientes e casos daquela entidade específica. As regras de envio para os EUA, incluindo limites e prazos, estão detalhadas em um guia dedicado sobre exigências de envio de SAR.

Uma fila unificada de analistas com a jurisdição vinculada

Uma fila unificada significa que todos os alertas de um mesmo cliente ou contraparte são destinados ao mesmo analista, independentemente do corredor que gerou a atividade. Um diretor de PLD de uma cooperativa de crédito dos EUA reforçou: alertas múltiplos de um mesmo associado não devem ser distribuídos de forma rotativa para profissionais diferentes. Um único analista avalia todo o cenário e o histórico do caso apresenta uma única linha de raciocínio.

O alerta precisa ser entregue com contexto. Um aviso genérico que aponta apenas uma atividade fora do comum não ajuda na tomada de decisão; o corredor, os parâmetros vigentes da jurisdição, as movimentações esperadas do cliente e as contrapartes vinculadas são os fatores que tornam a análise viável. Esse contexto deve vir de um perfil de risco de cliente unificado e compartilhado entre os corredores.

Os agentes que estruturam o caso e propõem recomendações conseguem reunir esse contexto de diferentes jurisdições, mas a decisão final permanece com o analista humano. A página da Oscilar destaca que "cada recomendação é revisada e confirmada por um analista humano antes de qualquer ação ser tomada." No gerenciamento de casos, cada decisão deve registrar a versão da configuração do corredor que gerou o alerta, permitindo sua reconstituição futura sob qualquer jurisdição.

Como a Oscilar resolve esse desafio

A Oscilar processa as operações de PLD transfronteiriço em uma plataforma unificada: estrutura de dados em tempo real, inteligência de dispositivos e comportamento, regras e gerenciamento de casos em um único ecossistema, com agentes integrados nativamente. Esse é o formato que o modelo de configuração precisa: decisões de fraude, integração de clientes e conformidade consultam o mesmo perfil de risco, garantindo que novos corredores apenas adicionem parâmetros, sem duplicar registros.

A página da Oscilar sobre PLD para fintechs com atuação em diversos produtos e regiões descreve a solução: "Adapte-se facilmente aos diferentes tipos de pagamento, clientes, produtos e regiões da sua fintech com os cenários, modelos e templates pré-configurados da Oscilar." A Oscilar mantém um histórico completo de auditoria para cada decisão com as justificativas salvas, mantendo a validação humana no centro do design.

A avaliação prévia de produção é estruturada como uma parceria de design de quatro semanas: configuração de dados na primeira semana, simulações com alertas históricos, modo de monitoramento em segundo plano e a validação com analistas humanos na quarta semana.

Perguntas frequentes

Qual é a diferença entre STR e SAR?

O STR (Relatório de Transação Suspeita) e o SAR (Relatório de Atividade Suspeita) cumprem a mesma função sob nomenclaturas distintas. O GAFI e o FINTRAC do Canadá utilizam STR; os EUA (enviado ao FinCEN) e o Reino Unido (enviado à UIF na National Crime Agency) utilizam SAR. O dever de reportar transações atípicas à UIF nacional é o mesmo, mas limites, prazos, formulários e gatilhos variam de acordo com a jurisdição.

Como o monitoramento de PLD deve mudar de acordo com o corredor de pagamento?

O monitoramento de PLD deve variar nos parâmetros, e não no processo em si. Cada corredor conta com seus próprios dados de risco de jurisdição, limites, regras de tipologia, campos de pagamento obrigatórios e destinos de relatório, tudo devidamente datado e versionado. O processo de investigação, os registros do cliente e os padrões de comprovação continuam unificados em todos os corredores.

Como uma mudança na lista cinza do GAFI deve ser integrada ao programa de PLD?

Uma alteração na lista cinza do GAFI deve ser incluída no programa como uma nova versão datada do parâmetro de risco de jurisdição, em vez de uma alteração nas regras ativas. A última declaração do GAFI, de 19 de junho de 2026, não exige diligência prévia aprimorada automática para países listados e esclarece que seus padrões não preveem a exclusão de riscos (de-risking). Calibre o dado de risco, registre a data de início da vigência e guarde a versão anterior para auditorias de decisões passadas.

Por que a correspondência bancária é classificada como de alto risco?

A correspondência bancária apresenta alto risco porque o banco correspondente processa pagamentos para clientes que não conhece diretamente. Em relações aninhadas, clientes do banco respondente ou outros bancos utilizam os serviços do correspondente. Este visualiza a movimentação, mas não o cliente final, tornando seu monitoramento dependente da diligência do respondente e das informações que acompanham a transferência.

Os agentes de IA podem auxiliar analistas em alertas de várias jurisdições mantendo a validação humana?

Sim. Os agentes de IA conseguem estruturar o contexto de corredores e jurisdições para um alerta, reunindo parâmetros ativos, a atividade típica do cliente e os dados ausentes, sugerindo uma resolução. O analista revisa e aprova cada recomendação antes que qualquer ação ocorra, e o caso registra a justificativa técnica e a versão das regras utilizadas.

Um único programa, múltiplos corredores

Um programa de PLD transfronteiriço ganha escala real quando cada novo corredor adiciona parâmetros, em vez de criar um novo processo. Mantenha os dados de risco de jurisdição com data de vigência definida, configure as exigências de dados de pagamento e destinos de relatórios por parâmetro e direcione os alertas de cada cliente para um analista único com o devido contexto. Se a sua equipe está avaliando a melhor estrutura de PLD para múltiplos corredores, consulte nossas páginas de soluções para fintechs e bancos, ou solicite uma simulação personalizada para os seus corredores.