When Rules Become Risk: Treating BSA/AML Systems as Models

But it's not a model!! 

This might sound obvious to most of us as BSA/AML transaction monitoring systems have been treated as models for years. But every so often, I still run into pushback questioning whether SR 11-7 really applies to these models.

✋ The common pushback sounds familiar: “It’s not really a model”, "there aren't really any calculations", or “back-testing doesn’t apply here.”

But the reality is, based on regulatory guidance, it DOES meet the definition of a model. A model, per SR 11-7, includes:

✅ Inputs (like customer risk scores, transaction types, geographies),

✅ Processing logic (rules, scenarios, thresholds), and

✅ Outputs (alerts and case queues).

It also includes assumptions such as how thresholds are set, how typologies are prioritized, and how the system is tuned to your institution’s risk profile.

So yes, it is a model. And because it plays a critical role in BSA/AML compliance, it’s generally considered high risk.

While I agree that traditional back-testing doesn’t always fit, that doesn’t mean validation isn’t necessary or feasible.

The real issues are around false positives (too much noise) and false negatives (missed risk). A thoughtful validation can include:

✔️ Analyzing alert effectiveness and relevance

✔️ Reviewing tuning and thresholds

✔️ Performing sensitivity testing to see how changes in inputs or assumptions affect results

✔️ Challenging logic, overrides, and documentation

💡 Just like with any other model, the validation scope can and should be tailored to the size and complexity of the institution. It doesn’t always have to be a heavy lift, but it does need to be risk-based and defensible.

👉 And while model logic and alert performance get most of the attention, don’t sleep on the data. If the inputs are wrong, everything else falls apart. I’ll share more thoughts on that in a follow-up post soon.