Consultoria em Crime Financeiro

Trabalho com os problemas de compliance que são mais difíceis do que parecem no papel.

Atendo bancos, fintechs e empresas reguladas em AML, fraude, sanções, validação de modelos e ativos digitais. Minha experiência está tanto no compliance quanto na tecnologia que o sustenta — pipelines de monitoramento de transações, arquitetura de screening de sanções, gestão de risco de clientes e a integração de dados que determina se tudo isso realmente funciona quando é examinado de perto.

Áreas de atuação
  • AML & Monitoramento de Transações
  • Fraude & FRAML
  • Sanções & Screening
  • Validação de Modelos
  • Compliance em Ativos Digitais
  • IA em Crime Financeiro
Marcos regulatórios
  • OCC / BSA / FinCEN
  • NYDFS Part 504
  • OFAC / SDN
  • FATF Travel Rule
  • OCC 2011-12 (Risco de Modelo)
Como isso funciona na prática

Avaliações de programas, análise de lacunas de controle, revisão crítica de modelos, preparação para exames regulatórios — mas também revisões de arquitetura, design de pipelines, ajuste de alertas e ajuda para construir sistemas que possam ser explicados a um regulador, não apenas apresentados num processo de seleção de fornecedor.

Por que o lado técnico importa

Comecei como desenvolvedor e DBA antes de entrar na área de crime financeiro. Esse histórico muda como eu leio um programa de monitoramento. Quando algo gera alertas demais, um modelo não passa pela validação ou um sistema de screening deixa correspondências passarem, o problema costuma estar nos dados ou na arquitetura — não na política. Consigo encontrar porque já construí esse tipo de sistema.

Como cheguei até aqui.

Cresci em Caxias do Sul, no sul do Brasil, e comecei minha carreira como desenvolvedor — Oracle Forms, Reports, Designer, depois DBA, depois VB. Com o tempo, assumi funções de liderança de equipes. Crime financeiro veio depois, e ficou. Trabalho em FRAML desde então, e mais recentemente também com tecnologia de compliance mais ampla, incluindo sistemas de tesouraria e finanças.

Esse histórico como desenvolvedor não é coincidência. É por isso que abordo problemas de AML e fraude de forma diferente da maioria das pessoas que vêm pelo lado jurídico ou de auditoria. Já revisei lógica de segmentação com engenheiros de dados, reconstruí fluxos de geração de alertas, trabalhei em lacunas de rastreabilidade na validação de modelos com equipes quant, e estive em reuniões onde o profissional de compliance e o arquiteto de tecnologia simplesmente não chegam a um acordo sobre o que o sistema está fazendo. Conheço os dois lados dessa conversa.

Ao longo dos anos trabalhei em contextos nos EUA, Canadá, Europa, Oriente Médio, Ásia-Pacífico e América Latina — reguladores diferentes, perfis de risco diferentes, e níveis bem distintos de maturidade em como as instituições constroem e governam esses programas. Essa variação molda a forma como penso sobre o que de fato é um programa defensável, e o que apenas passa numa revisão interna.

Atualmente trabalho no Huron Consulting Group. Este site reflete meu próprio pensamento e experiência. Falo inglês, português e espanhol.

Fora do trabalho: dois filhos, quatro gatos, dois cachorros e minha esposa — também de Caxias do Sul. Moramos em Concord, na região de Charlotte, na Carolina do Norte.

Onde passo a maior parte do meu tempo.

01

AML & Monitoramento de Transações

Avaliação de programas, lógica e ajuste de alertas, gestão de casos, qualidade de SARs e estruturação de caminhos de escalação. Inclui trabalho direto com a arquitetura do pipeline de monitoramento e com a integração de dados que determina se o sistema gera alertas úteis ou apenas ruído.

02

Fraude & Convergência FRAML

Estruturação de programas de risco de fraude, cobertura de tipologias e a questão central de se AML e fraude devem compartilhar dados, processos e infraestrutura de investigação. A maioria das instituições os mantém separados de formas que criam lacunas de cobertura e trabalho duplicado.

03

Sanções & Screening

Arquitetura de screening, cobertura e atualização de listas de vigilância, configuração de correspondência de nomes, gestão de falsos positivos e controles para pagamentos internacionais e ativos digitais. OFAC SDN, ONU, UE, OFSI e listas específicas por jurisdição.

04

Validação de Modelos & IA

Avaliação independente de modelos de detecção, lógica de pontuação e definição de limites. Infraestrutura de modelos, explicabilidade, backtesting e documentação de rastreabilidade. Inclui estruturação de governança de IA para instituições que adotam aprendizado de máquina na detecção de crime financeiro — onde auditabilidade não é opcional.

05

Risco em Ativos Digitais

Arquitetura de compliance para instituições nativas em cripto e para bancos com exposição indireta. Integração de blockchain analytics, implementação de Travel Rule e TRISA, risco de contraparte VASP e screening de sanções para atividade on-chain. Estruturado a partir do que os examinadores estão de fato pedindo hoje.

06

KYC / CDD / EDD

Controles de onboarding, metodologia de pontuação de risco de clientes, beneficiário final, fluxos de due diligence aprimorada e a arquitetura de dados que sustenta tudo isso. Um modelo de classificação de risco que não consegue ser mantido nem explicado é um passivo. A maioria dos problemas aqui é de dados e processo, não de política.

Temas sobre os quais continuo escrevendo porque continuam aparecendo.

IA tem um problema de dados. A maioria das pessoas está diagnosticando errado.

O problema não é o modelo. São os dados que entram nele — e as decisões institucionais que moldaram esses dados muito antes de qualquer treinamento ser executado.

LinkedIn →

Seu banco não opera com cripto. Isso não significa que cripto não está afetando seu banco.

A exposição a cripto chega por meio da atividade dos clientes, do comportamento de pagamentos e de relacionamentos com correspondentes — muitas vezes bem antes de qualquer decisão deliberada de entrar nesse mercado.

LinkedIn →

Validação de modelos é onde os programas de compliance costumam estar mais vulneráveis.

Não porque os modelos estejam errados. Porque as instituições não conseguem explicar as decisões, reproduzir os resultados ou mostrar o que mudou entre versões quando um examinador pergunta.

LinkedIn →

Adotar IA em crime financeiro não é, antes de tudo, uma decisão tecnológica.

As perguntas mais difíceis são de governança: quem aprova uma mudança de limiar, como isso é documentado, e o que acontece quando um investigador discorda da pontuação do modelo.

LinkedIn →

Manda uma mensagem curta.

Se você está lidando com um problema de AML, sanções, risco de modelo, fraude ou ativos digitais e quer uma segunda opinião ou ajuda para decidir o que fazer — algumas linhas sobre a situação já são suficientes para começar.

Chega direto pra mim. Nenhum e-mail exposto nesta página.