Program assessments, control gap analysis, model challenge, exam preparation — but also architecture reviews, pipeline design, alert tuning, and helping teams build systems that can be explained clearly to a regulator, not just demonstrated to a vendor selection committee.
Financial Crime Advisory
I work on compliance problems that are harder than they look on paper.
I work with banks, fintechs, and regulated businesses on AML, fraud, sanctions, model validation, and digital asset risk. My background is in both the compliance side and the technology underneath it — transaction monitoring pipelines, sanctions screening architecture, customer risk workflows, and the data integration that determines whether any of it actually works under examination.
Work covers
- AML & Transaction Monitoring
- Fraud & FRAML
- Sanctions & Screening
- Model Validation
- Digital Asset Compliance
- AI in Financial Crime
Regulatory frameworks
- OCC / BSA / FinCEN
- NYDFS Part 504
- OFAC / SDN
- FATF Travel Rule
- OCC 2011-12 (Model Risk)
I started as a developer and DBA before moving into financial crime. That background changes how I read a monitoring program. When something is producing too many false positives, or a model cannot be validated, or a screening system is missing matches, the problem is usually in the data or the architecture — not the policy. I can find it because I have built these kinds of systems.
About
How I ended up here.
I grew up in Caxias do Sul, in southern Brazil, and started my career as a developer — Oracle Forms, Reports, Designer, then DBA work, then VB. Eventually team lead roles. Financial crime came later, and it stuck. I have been working in FRAML ever since, and more recently across broader compliance technology including treasury and finance systems.
That developer background is not incidental. It is why I approach AML and fraud problems differently from most people who come at them from the legal or audit side. I have reviewed segmentation logic with data engineers, rebuilt alert generation workflows, worked through model validation traceability gaps with quant teams, and sat in rooms where a compliance officer and a technology architect cannot agree on what the system is actually doing. I know both sides of that conversation.
Over the years I have worked across US, Canadian, European, Middle Eastern, Asia-Pacific, and Latin American operating environments — different regulators, different risk profiles, different levels of maturity in how institutions build and govern these programs. That range shapes how I think about what a defensible program actually looks like versus what just passes an internal review.
I currently work for Huron Consulting Group. This site reflects my own thinking and experience. I speak English, Portuguese, and Spanish.
Outside of work: two kids, four cats, two dogs, and my wife — also from Caxias do Sul. We live in the Charlotte area, in North Carolina.
Work
Where I spend most of my time.
01
AML & Transaction Monitoring
Program assessment, alert logic and tuning, case management workflows, SAR quality, escalation path design. Includes work with monitoring pipeline architecture and the data integration that determines whether alert generation is reliable or just noisy.
02
Fraud & FRAML Convergence
Fraud risk program design, typology coverage, and the structural question of whether AML and fraud detection should share data, workflows, and investigation infrastructure. Most institutions have them separated in ways that create coverage gaps and operational overhead.
03
Sanctions & Screening
Screening architecture, watch list coverage and ingestion, name matching configuration, false positive management, and controls for correspondent banking and digital asset payment flows. OFAC SDN, UN, EU, OFSI, and jurisdiction-specific list management.
04
Model Validation & AI
Independent challenge of detection models, scoring logic, and threshold setting. Model infrastructure, explainability, backtesting, and validation traceability documentation. Includes AI governance design for institutions deploying machine learning in financial crime detection where auditability is non-negotiable.
05
Digital Asset Risk
Compliance architecture for institutions that are crypto-native and for banks with indirect exposure. Blockchain analytics integration, Travel Rule and TRISA implementation, VASP counterparty risk, and sanctions screening for on-chain activity. Built around what examiners are actually asking for now.
06
KYC / CDD / EDD
Onboarding controls, customer risk scoring methodology, beneficial ownership, enhanced due diligence workflows, and the underlying data architecture. A risk rating model that cannot be maintained or explained is a liability. Most of the problems here are data and workflow problems, not policy problems.
From the field
Things I keep writing about because they keep coming up.
AI has a data problem. Most people are diagnosing it wrong.
The failure is not the model. It is the data going into it — and the institutional decisions that shaped that data long before anyone ran a training job.
Your bank does not touch crypto. That does not mean crypto is not touching your bank.
Crypto exposure arrives through customer activity, payment behavior, and correspondent relationships — often well before any deliberate decision to enter the space.
Model validation is where compliance programs tend to be most exposed.
Not because the models are wrong. Because institutions cannot explain the decisions, reproduce the outputs, or show what changed between versions when an examiner asks.
Deploying AI in financial crime is not primarily a technology decision.
The harder questions are governance: who signs off on a threshold change, how do you document it, and what happens when an investigator disagrees with a model score.
Contact
Send a short message.
If you are dealing with an AML, sanctions, model risk, fraud, or digital asset problem and want a second opinion or some help figuring out what to do — a few lines on the situation is enough to get started.
This goes directly to me. No email address on this page.