The aim of a risk assessment is to be correct exactly once: the moment it's finished. From there it only accumulates drift. A product launches, a customer segment gets onboarded, a wire corridor opens to a country that wasn't in scope six months ago, a vendor gets added to the stack and never looked at again. Each changes the org's risk profile materially. The illusion is believing a static document can continue to accurately describe a subject that's in a perpetual state of change.
How the drift surfaces
In practice, the distance between the risk assessment on file and the institution's real risk profile generally gets discovered at one of three moments:
- An exam is scheduled. The assessment on file is over a year old, and nobody has pressure-tested it before the examiner does.
- A new officer inherits the program. They're handed someone else's document, built on someone else's read of the institution, and have to work out how much of it still holds before they can defend any of it.
- A peer institution takes a consent order. The findings - a thin risk assessment, gaps in CDD, monitoring that missed a typology - are rarely unique to that institution. Another with the same profile and the same stale-assessment habit has no real basis for assuming they won't be next.
Same failure, three different triggers: something forced someone to check whether the paper matched reality, and it hadn't been checked in a while.
Identifying and managing drift in risk systems was a top priority during my time at both eBay and PayPal. It turns out that the way to get optimal performance out of a detection system lies as much in your ability to iterate quickly as it does in simply 'making a better model or rule.' A new top-performing model is useless until it can get deployed, and there's no guarantee that today's performance will hold in the future (spoiler, it most often doesn't). Drift is inevitable. What's important is how rapidly you can identify and respond to it. This becomes even more important when the source data is stale. For example, a 90-day chargeback window means that the values represent the past three months. Not today, not last week, but months. Trying to tune for today's performance using observed patterns from three months ago is, at best, playing catch-up.
Risk assessment is exactly the same kind of system. An organization's ability to spot emerging risk and respond to it quickly is what separates mature risk programs from developing ones. Trying to make strategic decisions with analysis data from six, nine, or twelve months ago is playing catch-up on an even slower cycle.
Regulators are done pretending otherwise
FinCEN's proposed rule on AML/CFT program requirements uses a phrase worth sitting with: the risk assessment should be "dynamic and responsive." Examiners have expected programs to keep pace with the institution for years, informally. What's new is the NPRM trying to write that expectation into the rule itself - making the risk assessment the foundation the rest of the program stands on, instead of a document produced once a year to satisfy a checklist item.
The plain expectation: every material change to products, customers, geography, or transaction patterns is now the kind of event that should trigger a review and an updated posture. Almost no institution is built to work that way. An annual or biennial cadence fails that standard before it even starts - it's kicking the can down the road and calling it a methodology.
A checklist tells you a control exists. It doesn't tell you it works.
There's a version of "compliance" that looks complete and isn't: a binder of policies, a risk assessment that technically exists, a CDD procedure signed off by someone, all present, all filed, none of it connected to a current picture of risk. Examiners have a term for this: "technical compliance." It's not a compliment.
When an examiner or a board wants to see the risk assessment, they're not asking for proof that a document exists. They're testing whether someone can currently explain, with evidence, where the institution's exposure sits and what's being done about it.
"We have a policy" is not a program. "We have a policy, here's how it maps to our current customer risk, here's our monitoring coverage against that risk, here's what changed since the last time we looked" is a program. The difference was never the paperwork. It's whether the paperwork is still telling the truth.
What "dynamic and responsive" actually requires
Closing the gap isn't a writing problem, and a more thorough assessment doesn't fix it - a more thorough snapshot goes stale just as fast. It's the same discipline that mattered at eBay and PayPal: the gap between the document and the institution isn't a defect you fix once and move on from. It's a maintenance problem, and maintenance means re-running the assessment on a cadence that matches how fast the institution actually changes, not squinting at last year's version and hoping it still holds. Concretely, that's a process built around three things:
- Fast enough to re-run after every material change, not just at the next quarterly planning cycle.
- Comparable across runs, so a reviewer can see exactly what moved between one assessment and the next, and why.
- Legible to people who aren't compliance practitioners - a board, a CEO - without someone translating it first, because the point of an assessment is to drive a decision, not simply to exist for their own sake.
Almost no institution has this today, and it isn't because compliance teams are careless. A lean team producing an assessment the traditional way - internally, through workshops and interviews, or through an outside engagement - physically cannot re-run it every time something changes. The traditional model was built for annual. The standard isn't annual anymore.
An exam, an inherited program, a peer's enforcement action - none of these create the gap. They just force someone to go looking for one that was already there. Better to find it on a cadence you chose than one an examiner chose for you.