The work is usually some combination of platform architecture, system consolidation, detection model governance, and exam preparation. On the technical side, that means the framework and data architecture a compliance program actually runs on — across systems like Actimize, Oracle FCCM, and adjacent enterprise infrastructure. On the regulatory side, it means making sure the controls hold up when auditors and examiners look closely, not just when things are running smoothly.
Financial Crime Advisory
I design and run financial crime technology platforms. The compliance problems come with the territory.
I work with financial institutions on the architecture of financial crime technology programs — how transaction monitoring, sanctions screening, case management, and financial data infrastructure fit together, and whether they hold up when regulators and internal audit take a close look. I came up through development and DBA work before moving into compliance, which means I can own the systems layer, not just advise on it.
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 history changes what I can do at the table. When a monitoring program 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 get to it because I have built and run these kinds of systems. I know what the inside looks like.
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.
My current focus is platform architecture — how financial crime systems are designed, connected, and governed across the full stack. That tends to mean working on the parts that are hardest to fix later: data integration between detection and financial systems, vendor ecosystem decisions that accumulate technical debt, and the governance layer that makes model validation and exam response actually workable rather than scrambled. This site reflects my own thinking. 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 tend to be most useful.
01
AML & Transaction Monitoring
Designing and stabilizing transaction monitoring and case management platforms. Alert logic, segmentation, and tuning. SAR quality and escalation path design. A lot of this work involves consolidating overlapping systems and fixing the data integration problems that cause alert generation to be unreliable at scale — the kind of issues that look like tuning problems but are actually architecture problems.
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
Model risk governance framework design, independent challenge of detection models, scoring logic, and threshold setting. Building the infrastructure and documentation that makes validation traceable, reproducible, and defensible — not just compliant on paper. Includes AI governance design for institutions where explainability and auditability are exam requirements, not aspirations.
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.
Finance transformation fails at regulated firms for a specific reason.
The issue is not the technology or the ambition. It is that transformation programs are designed without accounting for how compliance, risk, and regulatory constraints interact with the systems being replaced.
Stablecoins will not wait for your compliance program to catch up.
Stablecoins are already moving through payment flows and customer activity at regulated institutions — whether those institutions have a policy on them or not.
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.