AML compliance workflow that auditors love

AML compliance is one of those areas where the gap between what regulators expect and what actually happens inside institutions is genuinely alarming. Here is how we approach compliance management.

I’ll be blunt. Most AML compliance programs I’ve seen aren’t really programs. They’re binders. Big, thick binders full of policies that nobody reads, procedures that nobody follows, and checklists that get filled out retroactively when an examiner shows up.

In our conversations with compliance teams at mid-market financial institutions, the frustration is palpable. They know what they’re supposed to do. They know the Bank Secrecy Act requirements. They’ve read the FFIEC examination manual. But the gap between knowing and doing is where institutions get buried.

And when your AML workflow is a mess of disconnected spreadsheets, email approvals, and tribal knowledge about which alerts matter, automating any of that just means you’ll miss suspicious activity more efficiently.

Let me walk through what an AML compliance workflow should actually look like - not the textbook version, but the version that survives contact with real regulators.

Five pillars that regulators actually check

The BSA/AML compliance program framework sounds simple on paper. Five components. Every bank knows them:

1. Internal policies, procedures, and controls - written documentation of how you handle AML
2. A designated compliance officer - someone responsible for day-to-day execution
3. Ongoing employee training - not a once-a-year PowerPoint, but continuous education
4. Independent audit function - testing that the program actually works
5. Risk-based customer due diligence - the CDD Final Rule added this as a formal fifth pillar

Simple, right? Five things. Except each one is a living, breathing workflow that needs to execute consistently across every branch, every department, every day. That’s where things fall apart.

The institutions that get fined aren’t usually missing a pillar. They have all five documented. What they’re missing is execution. The compliance officer exists but is buried under 400 other responsibilities. The training happens but nobody tests comprehension. The policies exist but haven’t been updated since the last exam.

This drives me crazy. Having the documentation is maybe 20% of the battle. The other 80% is proving to examiners that people follow it.

Customer due diligence that doesn’t rot

CDD is the foundation of everything in AML. Mess this up, and nothing downstream works. If you want a deeper dive into how the KYC onboarding process feeds into CDD, that’s worth reading alongside this section. The FFIEC CDD examination procedures spell out four core elements:

• Customer identification and verification - confirm people are who they say they are, which isn’t as straightforward as it sounds
• Beneficial ownership identification - figure out who actually controls legal entities
• Understanding the nature and purpose of the relationship - build a risk profile
• Ongoing monitoring - keep watching, because risk changes

Here’s what a CDD workflow should look like when it’s working:

At account opening, you collect the basics - name, date of birth, address, identification number. You verify through documentation. You run the name against OFAC sanctions lists, PEP databases, and adverse media. You assign an initial risk rating. You document everything.

But that’s just day one.

The ongoing monitoring piece is where most institutions stumble badly. A customer who was low-risk three years ago might be high-risk today. Their business changed. They started receiving large international wire transfers. Their beneficial ownership structure shifted. If your CDD process doesn’t trigger re-evaluation when risk indicators change, you’ve got a static snapshot pretending to be a living assessment.

In discussions we’ve had with compliance officers at regional banks, the number one complaint is this: they can’t prove they did the ongoing monitoring. Not because they didn’t do it, but because the process wasn’t documented in a way that creates a clear trail. The work happened in someone’s head, or in an email thread that got deleted, or in a spreadsheet that got overwritten.

A workflow tool should force each step to be recorded. Every decision, every document collected, every risk rating change - with timestamps, with the person responsible, with the rationale. Not because you’re paranoid, but because when the examiner asks “how did you determine this customer was low risk?” you need an answer that doesn’t start with “well, I think it was…”

Transaction monitoring that catches real problems

Transaction monitoring is probably the most technically complex part of AML compliance, and it’s also where I see the biggest process failures. Not technology failures. Process failures.

Here’s what’s supposed to happen. Your monitoring system generates alerts based on rules and thresholds - unusual transaction volumes, structuring patterns, rapid movement of funds, transactions with high-risk jurisdictions. An analyst reviews each alert. They investigate. They either clear it with documentation or escalate it for SAR filing.

The FinCEN SAR statistics paint a stark picture. Filing volumes keep climbing year over year. That’s partly because criminals are getting more creative, but it’s also because institutions are filing defensively - when in doubt, file a SAR. That creates its own problems, because FinCEN then has to sort through mountains of low-quality filings to find the ones that matter.

The workflow challenge here isn’t the monitoring system itself. It’s everything that happens after an alert fires.

Alert triage - Someone needs to look at the alert within a defined timeframe. Not “when they get around to it.” Within hours or days, depending on risk level. Who’s responsible? What’s the SLA? What happens if they’re on vacation?

Investigation - The analyst pulls transaction records, reviews CDD files, checks for prior SARs on the same subject. This requires access to multiple systems. If they’re toggling between six different applications and copying data into a Word document, something will get missed.

Decision and documentation - Clear the alert or escalate. Either way, document the rationale. “I cleared this because the customer explained the transactions and it made sense” isn’t good enough. You need specifics. What did they explain? What supporting documents did you review? What was the timeline?

Escalation path - If it needs a SAR, who reviews next? Is there a quality check before filing? What’s the deadline? (FinCEN expects filing within 30 days of detection, with a possible 30-day extension.)

Each of these steps is a handoff, and handoffs are where things break. The alert sat in a queue for three weeks because the analyst was covering two roles. The investigation was done but the documentation was incomplete because the analyst didn’t have a template to follow. The SAR was drafted but nobody reviewed it before the deadline because the reviewer didn’t know it was waiting. Every one of those failures is a process gap, not a competence gap. The people aren’t the problem. The absence of a structured, trackable workflow is the problem. That’s not a technology issue - it’s a workflow issue, and it’s fixable.

SAR filing without the scramble

Suspicious Activity Reports deserve their own section because the consequences of getting them wrong are severe. File late, and regulators notice. File a bad one, and FinCEN notices. Don’t file when you should have, and you might end up in the same category as TD Bank’s $3.09 billion penalty.

The SAR workflow should look something like this:

Detection triggers the process. Could be a transaction monitoring alert, a referral from a branch employee, negative news about a customer, or a law enforcement inquiry. Whatever the trigger, it needs to be logged immediately.

Investigation happens next. Gather all relevant information - transaction history, CDD records, any prior SARs, open-source intelligence. This isn’t casual research. The FinCEN SAR narrative guidance expects a clear, complete narrative that answers who, what, when, where, why, and how.

Review and approval - a second set of eyes before filing. Ideally someone senior enough to catch gaps in the narrative but close enough to operations to understand the context.

Filing - submit through FinCEN’s BSA E-Filing system. Track the confirmation.

Follow-up - continuing SARs if the activity persists. Internal notifications if law enforcement makes contact. Record retention for five years after filing.

Every single one of those steps needs a timestamp, an owner, and a documented outcome. When examiners review your SAR process, they’re not just checking that you filed. They’re checking that your process for deciding when and how to file is consistent, timely, and defensible.

In our experience with workflow automation, the organizations that handle SARs well aren’t the ones with the fanciest technology. They’re the ones with a clear, repeatable process that everyone follows. Same steps, same documentation standards, same escalation paths. Every time.

Audit trails that make examiners smile

Here’s where it gets interesting for me, because this is fundamentally a workflow problem dressed up in compliance clothing.

The BSA record retention requirements say you need to keep most records for at least five years. But the real requirement isn’t just retention - it’s retrievability. Can you reconstruct what happened, who did what, and why, at any point in time?

An audit trail for AML compliance needs to capture:

• Who performed each action (not a shared login - an individual person)
• What they did (approved, rejected, escalated, modified, reviewed)
• When they did it (automatic timestamp, not manually entered)
• Why they did it (rationale, supporting evidence, risk assessment notes)
• What changed (before and after states for any modifications)

Most compliance teams cobble this together from email records, spreadsheet change logs, meeting notes, and memory. That’s fragile. One deleted email, one overwritten cell, and your audit trail has a gap.

A question that keeps coming up from compliance teams is whether audit trails are tamper-proof - the biggest pain point isn’t creating them, it’s proving nobody touched them after the fact. Regulators don’t want to hear “we think this is accurate.” They want system-generated evidence that nobody could have altered after the fact.

This is exactly why we built Tallyfy the way we did. Every step in a workflow gets an immutable timestamp. Every decision gets logged with the person who made it. Every document attachment, every comment, every status change - captured automatically. Not because someone remembered to write it down, but because the system doesn’t let you move forward without it.

Why spreadsheets and email will eventually sink you

I’m not convinced that most mid-market financial institutions understand how fragile their compliance processes really are. They work. Until they don’t. And that’s the terrifying part. And the trigger for failure is almost always scale.

When you’ve got 50 alerts a month, a spreadsheet tracker works fine. Someone owns it, updates it, and the compliance officer reviews it weekly. But when alert volumes hit 500 a month because you added a new product line or expanded into higher-risk markets, that spreadsheet becomes a liability.

Here’s what breaks:

Handoffs disappear. When analyst A escalates to reviewer B, the handoff is an email. If B is out sick, the email sits. Nobody else knows it’s pending. The 30-day SAR deadline passes.

Version control is fiction. Three people update the same spreadsheet. Someone overwrites someone else’s notes. The “final” version isn’t final. When the examiner asks for the investigation file, you’re piecing together fragments from multiple sources.

Training gaps compound. New analysts don’t know the informal rules - which alerts to prioritize, what the documentation standards are, where to find supporting information. The process lives in experienced people’s heads, not in a system.

Audit readiness takes weeks. When the exam letter arrives, compliance teams spend two to four weeks pulling together documentation that should have been organized all along. That’s two to four weeks of productive work lost to administrative scrambling.

Every vendor is shipping AI agents. Nobody’s building the workflows they need to follow. The financial institutions that will thrive in the next decade aren’t the ones buying the most sophisticated monitoring technology. They’re the ones turning their compliance programs into documented, repeatable, auditable workflows that run the same way every single time.

At Tallyfy, we’ve seen compliance teams cut their exam preparation time dramatically by simply running their processes through tracked workflows instead of email chains. Not because the tool is magic, but because it forces consistency. Every alert gets the same investigation steps. Every SAR follows the same review process. Every CDD refresh hits the same checkpoints.

Building an AML workflow that actually holds up

If I had to boil this down to what matters most, it’s this: regulators don’t care about your tools. They care about your process and your evidence. Can you show them, step by step, how a suspicious transaction went from detection to investigation to decision to filing? Can you prove that the same process runs for every alert, not just the ones that happened to get attention?

The ACAMS analysis of enforcement actions makes this painfully clear. The institutions that get hit with massive fines aren’t usually doing nothing. They’re doing something - just inconsistently, with gaps in documentation, and without the ability to prove to regulators that the program works as designed.

My suggestion? Stop thinking about AML compliance as a documentation exercise. It’s a workflow engineering problem. Understanding what compliance management actually means at a structural level helps reframe the whole approach. Every regulatory requirement maps to a process. Every process has steps, owners, deadlines, and evidence requirements. Get those right, and the compliance follows.

Get them wrong, and no amount of policy binders will save you when the examiners come knocking.