AML/Transaction: How Fintech Teams Orchestrate Suspicious Activity Reviews

Monday morning. 8:42 AM.

Your analyst opens their laptop. 200 new alerts in the queue. That’s before coffee.

The monitoring platform did its job. Thresholds fired. Velocity flags raised. Geographic anomalies surfaced. All perfectly correct. All perfectly useless until someone figures out which of those 200 alerts is a real threat, and which 195 are noise.

Here’s the dirty secret of AML in fintech: transaction monitoring is solved. Every serious team has a platform. Unit21, ComplyAdvantage, Sardine, Featurespace, take your pick. The tools exist. They work.

The bottleneck is what happens next.

Between “alert fired” and “SAR filed or case closed,” there’s a multi-step, multi-tool, multi-stakeholder investigation process. And at many fintechs, some part of it lives in Slack threads, shared spreadsheets, and the institutional memory of whoever has been on the team the longest.

That’s where the analyst hours go. Not into analysis. Into coordination.

The AML Alert Is Not the Investigation

When an alert fires, the clock starts. Not necessarily a regulatory clock (though sometimes it is) — but an operational one. Someone needs to:

→ Route the alert to the right analyst

→ Load the customer’s 90-day transaction history

→ Pull the adverse media check (Dow Jones, SEON)

→ Review related accounts

→ Apply the investigation checklist

→ Document every step with a timestamp

Most teams do this across 3-4 systems. Copy-paste between the monitoring tool, the KYC platform, the CRM, and an Excel sheet that lives somewhere on a shared drive nobody can find.

It’s not scalable. It’s not auditable. And it’s a nightmare when the regulator asks for the decision trail on a case from 14 months ago.

The investigation is the workflow. Every step (every search, every note, every decision) needs to live in a single, structured, traceable place. Because the regulator will not accept “we looked into it” as documentation. (They’ve heard that one before.)

What this requires isn’t another monitoring tool. It’s an orchestration layer — one that sits on top of your existing database and external tools, connects humans and AI agents, and produces a full audit trail in your own infrastructure.

Money Laundering: the Regulatory Reality Check

Let’s be direct about why this is non-negotiable.

SAR filing obligations.  In the US, FinCEN requires SARs to be filed within 30 days of detecting suspicious activity — 60 days if the subject can’t be identified. In the EU, national FIUs run on similar timelines. Miss the window, and you’re not just non-compliant. You’re on the radar.

Record-keeping requirements.  Every investigation, every decision, every piece of supporting documentation must be retained for 5+ years. Not in your analyst’s desktop folder. Somewhere structured, searchable, and retrievable on demand.

The tipping-off prohibition.  You cannot tell the customer you’re investigating them. Sounds obvious. That is, until your CRM and your AML workflow are loosely connected and someone accidentally triggers an automated email. It happens.

Enhanced Due Diligence triggers.  High-risk jurisdictions, PEPs, unusual transaction patterns. These require a separate, more intensive investigation track. EDD isn’t a checkbox. It’s a lifecycle.

There’s one more constraint most vendors gloss over: your data cannot leave your infrastructure. SAR data is legally sensitive. Data residency matters. Your investigation stack needs to run on your stack, not piped through someone else’s cloud.

Periodic Reviews: The Hidden Workload Nobody Talks About

Everyone talks about the alert queue. Nobody talks about periodic reviews.

Qonto explained on our podcast how they run Onboarding with Forest Workflows - Simplified Due Diligence (SDD) and Enhanced Due Diligence (EDD).

The same process applies to periodic reviews to run re-screening existing customers on a schedule. Not because something triggered an alert. Because regulation requires it. For each European market, this has its own dedicated lifecycle: different rules, different processes, different documentation requirements. That means a specific workflow per track.

This is ongoing work. Not a one-time onboarding task.

For teams managing hundreds of thousands of customers, the math gets ugly fast. Multiply customer base by review frequency by average investigation time. The result is a compliance team buried in routine work, which, by definition, can’t be cut without cutting compliance.

Unless you automate the routine parts.

What Scaling AML Compliance Actually Looks Like

In our podcast last year, Swan’s Chief Service Officer told us his  team grew 3x, while in the same period, transaction volume grew 8x.

Not a typo. 3x the people, 8x the work. The only explanation: automation absorbed the routine, so analysts could focus on the complex.

Their stated goal is to have AI to handle the routine so analysts focus on what matters.

“We're trying to find the right balance between using automation and keeping human in the loop, step by step. We want to automate checks at a high level, but our goal is not 100%. We would like to leverage AI to make these checks for analysts. But whenever there is a doubt, whenever there is a suspicious case, the idea would be to escalate it to a team of experts internally. So, it's not the 100% that we reach, but we want to, of course, assist with AI and automate all the easy ones with AI.” - Maxime de Juniac, CSO, Swan

That’s the model. AI agents handle triage, pattern detection, initial risk scoring. Analysts get pre-loaded cases: 90-day history already pulled, adverse media already checked, anomalies already flagged. They focus on the decision.

The teams winning at AML compliance aren’t the ones with the most analysts. They’re the ones where analysts aren’t doing analyst-level thinking on data-entry-level tasks.

Building the AML Investigation Workflow in Forest Admin

Forest Admin is the ops orchestration layer between your database, your external tools, and your team. In the context of AML investigations, it sits between the monitoring platform and the analyst — and handles everything in between.

Forest Workflows are built from two types of tasks:

Backoffice tasks connect directly to your own database and systems. Pull the 90-day transaction history. Create and update case records. Draft SAR entries into your own schema. Run internal risk rules. No data leaves your infrastructure. it stays in your stack, governed by your policies. Compliant by design.

MCP tasks and custom actions connect to external data sources within the same workflow. Trigger a Dow Jones adverse media check. Run a SEON risk profile. Call your sanctions screening API. Submit to the FinCEN portal at SAR filing time. Forest orchestrates the call, you control what goes where, and every external call is logged to the case record.

Humans and AI agents both have explicit roles in the flow. The AI handles the high-volume routine: triage, initial scoring, anomaly flagging, checklist pre-fill. The analyst picks up the pre-loaded case and makes the call. No context-switching. No copy-paste. No missing audit trail.

And because Forest runs on your infrastructure and with your own LLM/agent platform, the tipping-off prohibition isn’t a policy memo, but it’s a workflow initial-design constraint.

In this short demo, we show you how some of those key tasks are easily performed from Forest Workflows, as an analyst and senior reviewer.

AML Workflow Pattern: from Alert to Resolution

Here’s the step-by-step process; almost ready to run in Forest Workflows.

You can feed this to your favorite AI agent or LLM to build your own version with our skill.md file.
(still a bit experimental, we're taking feedback)

Step 1 — Alert fires. A monitoring platform triggers the process or adds to the batch/list. A basic task queries your DB to preload 90-day transaction history. Auto-routing assigns the case to the right analyst.

Step 2 — External context loaded. MCP tasks run in parallel or cascade: Dow Jones adverse media check, SEON risk score, sanctions screening. All results attached to the case record. All calls logged.

Step 3 — AI pre-screen. AI agent flags anomalies, suggests risk level, pre-populates the investigation checklist. The analyst opens a case that’s already 80% loaded.

Step 4 — Human investigation. Analyst works through the structured checklist. Each step timestamped. Notes captured in the case record, on your DB; not Slack, not a separate doc.

Step 5 — Decision point. Analyst reaches a verdict:

→ Close the case: rationale documented, evidence attached, case archived in your DB.

→ Escalate: full context forwarded to senior analyst or compliance officer.

→ File a SAR: SAR workflow triggered, pre-populated from the case record.

Step 6 — SAR filing. MCP task submits to appropriate entity (FinCEN, or national FIU). Confirmation logged to the case record. Customer not notified, by design.

Step 7 — Audit trail closed. Full case record retained in your own database: every action, every API call, every decision, every timestamp. Retrievable in minutes.

A flavor of this workflow exists at every serious fintech. The question is whether it lives in a structured, auditable system built on your own stack — or in the heads and spreadsheets of your compliance team.

One scales. The other, not so much

This is Article 2 in our series on fintech compliance workflows in Forest Admin. In this series:

• KYC onboarding.