Arquitetura de relatórios regulatórios AML em escala

Por que os relatórios AML são o problema de dados mais difícil de um banco

À primeira vista, os relatórios regulatórios AML parecem um problema de dados. Um regulador — FINTRAC no Canadá, FinCEN nos EUA — quer que você reporte determinados padrões de transação: transferências eletrônicas de fundos acima de um limite (EFTR), transações em dinheiro acima de um limite (CTR), comportamento suspeito (STR) e transações incomuns (UTR). Pegar os dados, formatar e enviar.

Na prática, a dificuldade é que o regulador quer a história interligada : quem originou os fundos, quem os recebeu, quem controla a conta, qual o nível KYC das partes, qual etapa de câmbio passou por qual intermediário e quais sinais de cibersegurança foram acionados durante a sessão. Esse contexto está espalhado por centenas de sistemas de origem — core bancário de varejo, mercados de capitais, crédito comercial, transferências, câmbio, tesouraria, hubs de clientes e sistemas de identidade — cada um com seu próprio esquema, frequência de atualização e responsáveis.

O 2º pacote regulatório da FINTRAC tornou isso explícito: aproximadamente 30 casos de uso distintos, cada um vinculando a transação financeira a dados de câmbio, clientes/contas e cibersegurança, nas áreas de banco privado, varejo, mercados de capitais e negócios comerciais. Do ponto de vista arquitetural, isso não é um projeto de relatórios. É uma plataforma de integração corporativa.

A arquitetura de referência, de ponta a ponta

As plataformas que projetamos para bancos de primeira linha compartilham uma estrutura comum — cinco camadas lógicas, cada uma escalável e auditável de forma independente:

• Ingestão das fontes. Captura de alterações de dados do core bancário, Workday HR, hubs de clientes, mecanismos de câmbio e sinais de cibersegurança. Alguns sistemas publicam eventos; sistemas legados expõem extrações em lote que encapsulamos em um carregador com validação de esquema.
• Espinha dorsal de streaming. Fluxos de eventos no estilo Kafka transportando transações financeiras, atualizações KYC, correspondências em sanções e eventos do ciclo de vida das contas. Os tópicos são particionados por cliente ou conta para preservar a ordenação por entidade.
• Vinculação e enriquecimento. Tarefas de processamento de fluxos vinculam o evento de transação a dados mestres de clientes, hierarquias de contas, etapas de câmbio, perfis KYC e comportamento histórico. A saída é um registro reportável totalmente interligado e estruturado conforme o regulador.
• Detecção e regras. Actimize hospeda os cenários de detecção AML para STR/UTR; regras determinísticas de limites e dados de referência orientam EFTR/CTR. A saída é um fluxo de possíveis envios com suas evidências.
• Envio e linhagem. Um serviço de envio formata os payloads EFTR/STR/CTR/UTR conforme os esquemas da FINTRAC, assina e transmite pelo canal seguro. Cada registro carrega um ID de linhagem que permite chegar aos eventos de origem.

A plataforma roda no Azure — AKS para serviços em contêineres, PostgreSQL para o repositório de envios regulatórios, Azure Storage para eventos brutos e Azure Monitor / Sentinel para segurança e observabilidade. Em implantações nos cinco grandes bancos canadenses, aprimoramos o Actimize no AKS com PostgreSQL especificamente para capacidades CTR em escala.

Por que streaming de eventos, e não lotes noturnos

Historicamente, os relatórios AML eram um processo noturno em lote. Isso funcionava quando os prazos das obrigações de reporte eram medidos em dias. Hoje, a expectativa da FINTRAC — e, francamente, o próprio apetite de risco do banco — está muito mais próxima de operar quase em tempo real. Os EFTR precisam ser acionados de forma confiável, independentemente de quando a transferência subjacente é liquidada. Os STR se beneficiam da associação de sinais comportamentais ao vivo à transação.

O streaming de eventos oferece três coisas que o processamento em lote não oferece. Primeiro, ingestão que considera a contrapressão: uma origem lenta não derruba o fluxo regulatório. Segundo, reprocessamento: quando uma regra muda, podemos reprocessar a janela afetada sem tocar nos sistemas de origem. Terceiro, ordenação por entidade: ao particionar por cliente ou conta, garantimos que a alteração de uma transação seja processada após a original, mesmo com dez mil eventos por segundo em circulação.

Em termos de custo, o AKS oferece computação elástica que acompanha o volume — picos de fechamento de mês, de ano e de volatilidade cambial não exigem capacidade permanentemente provisionada.

Modelagem de ameaças como artefato essencial de arquitetura

O reporte AML é um ambiente hostil. Agentes mal-intencionados tentam ativamente ficar abaixo dos limites, fracionar transações ou contaminar dados KYC. Uma boa plataforma AML não é apenas compatível com as normas — ela leva os adversários em conta.

Toda arquitetura que entregamos nesse espaço inclui um modelo explícito de ameaças: STRIDE em cada fronteira de componente, classificação de dados em cada repositório e identidades com privilégio mínimo nas chamadas entre serviços. Os segredos ficam no Azure Key Vault; as identidades de serviço usam identidades gerenciadas, não credenciais estáticas. Payloads sensíveis — documentos KYC e dados pessoais de clientes — são criptografados com chaves de envelope vinculadas à área de negócio.

No envio regulatório, cada payload é assinado e a chave de assinatura é protegida por hardware. Isso permite detectar um envio adulterado ou reproduzido tanto do lado da FINTRAC quanto no nosso próprio fluxo de auditoria.

KYC e integração de empresas de serviços monetários

Os relatórios AML dependem de KYC. Se o KYC estiver errado, os relatórios estarão errados. Uma das partes táticas mais interessantes em que trabalhamos é o fluxo de integração de empresas de serviços monetários (MSBs) — uma categoria de clientes legitimamente de alto risco, com exigências relevantes de diligência devida KYC.

O padrão arquitetural: um fluxo de verificação que reúne registros de MSBs, listas de sanções e dados de beneficiários finais em um grafo de enriquecimento de clientes; uma interface tática de gestão de casos para a equipe de investigações AML; e uma trilha de auditoria que vincula cada decisão de integração à evidência que a sustentou. A solução tática ganha tempo enquanto o hub estratégico de clientes avança — mas suas saídas têm o mesmo formato, então a plataforma estratégica herda os dados sem retrabalho.

Lições da entrega em dois bancos de primeira linha

• Trate o esquema do regulador como um contrato. Desenvolva de acordo com ele desde o primeiro dia. Não deixe estruturas internas de dados vazarem para a camada de envio.
• A vinculação é o trabalho. As regras EFTR/STR são a parte fácil. Vincular corretamente 30 casos de uso de dados de clientes, contas, câmbio e cibersegurança é onde se concentram 80% da engenharia.
• Linhagem não é opcional. Quando um regulador questiona um envio, você precisa mostrar cada evento que contribuiu para ele em minutos — não em dias.
• A aprovação do comitê de revisão de arquitetura não é mera formalidade. Use-a para promover rigor. As revisões pelas quais passamos detectaram problemas de residência de dados e gestão de chaves que seriam muito caros de corrigir depois.
• Nativo da nuvem ≠ exclusivo da nuvem. Alguns sistemas de origem continuarão locais por anos. A arquitetura precisa ser realista sobre a integração híbrida.

Seu banco ou fintech precisa disso?

A SEYSO projetou plataformas AML e de relatórios regulatórios em vários bancos de primeira linha do Canadá e dos EUA — cobrindo obrigações LCTR, EFTR, STR, UTR, CTR, KYC e CFT. Se você está modernizando a tecnologia de combate a crimes financeiros, migrando o Actimize de plataforma ou definindo um novo programa regulatório, adoraríamos conversar. Traga as obrigações regulatórias e a complexidade dos sistemas de origem; nós trazemos a arquitetura.