Here's a question worth asking before your next audit, not during it: if your compliance lead got hit by a bus tomorrow, could someone else run the AML program from what's written down, not from what's in their head?
Most founders say yes. Most are wrong. The gap between "the process works" and "the process is documented" is where regulators, auditors, and eventually your own growth plans quietly run out of road.
What examiners actually test for
The FFIEC IT Examination Handbook treats reliance on a single person's undocumented knowledge as a management deficiency in its own right, independent of whether that person's process actually works. Examiners don't evaluate whether your AML screening or incident response is effective in isolation. They evaluate whether it is written down clearly enough that it would survive that person leaving on short notice. A process that works perfectly in someone's head and nowhere else is not a passing answer. It escalates into a Matter Requiring Attention, and MRAs that go unaddressed compound into formal enforcement action.
This is not a US-only concern dressed up in acronyms. Every major regulatory framework that touches financial services operations converges on the same requirement: effectiveness is necessary but not sufficient. It has to be documented, current, and testable by someone who was not in the room when it was built.
The written-program requirement, concretely
Under 31 CFR 1020.210, a bank or money services business needs a written AML program: documented policies and procedures, a named compliance officer, ongoing training, and independent testing. Each of those four elements has to exist on paper, not just in practice. A program that runs flawlessly but exists only as tribal knowledge among two or three people is, on its face, a violation, regardless of how well it performs day to day.
In the EU, DORA has required a documented, board-approved ICT risk management framework since it took effect on 17 January 2025, along with a maintained register of third-party ICT arrangements under Article 28. The emphasis is identical: a working system that isn't documented is not a compliant system, because "working" cannot be verified, audited, or handed off without a record of how and why it works.
Why this keeps surfacing as a finding
The pattern shows up the same way across institutions of very different sizes. A process starts clean and gets refined over time by the two or three people closest to it. Each refinement makes sense in context and never gets written down, because writing it down was never the thing standing between the team and the next deadline. Eventually the documented version and the lived version diverge, and only the people doing the work know which one is current.
That gap is invisible until someone outside the team needs to rely on the documentation: a new hire, an auditor, an examiner, or a replacement after the key person leaves. At that point the undocumented version isn't an efficiency shortcut anymore. It's the only version that exists, and it just left the building.
What a defensible answer looks like
Passing the key-person test does not require a binder nobody reads. It requires three things that examiners and auditors can actually check:
- A written version of every critical process, AML screening, onboarding, incident response, vendor management, that a new hire could follow without calling the person who built it.
- A named owner and a review date for each of those documents, so "current" is verifiable rather than assumed.
- A record of testing or independent review, because a document that was accurate once and never checked again fails the same way tribal knowledge does.
None of this replaces having a good process. It is the layer that proves the process exists independently of the people currently running it, which is exactly what an examiner, an auditor, and a new hire are each separately trying to verify.
Where this intersects with automation
Teams often want to automate their way out of this problem before fixing the underlying gap, and it doesn't work in that order. An automation built on top of an undocumented, inconsistently applied process just encodes the inconsistency faster. The sequence that actually holds up under review is: document the process as it actually runs, assign ownership and a review cadence, then automate the parts that are now stable enough to automate. Skipping the first two steps is how teams end up with a fast system nobody can explain to an examiner.
If you're not confident your documentation would survive your own key-person test, that's worth finding out before an exam date forces the question.