Can You Show Your Work? 6 Questions to Test Your AML Transaction Monitoring

One BSA officer told us recently that his CEO called him twice the day the latest AML enforcement news broke. Across the industry, compliance teams and executives were undoubtedly questioning “Could that be us?”

Within a single week, two massive AML enforcement actions underscored a key industry challenge. Both institutions had technology installed, yet the systems fell short. The problem was monitoring logic that nobody could fully explain, test, or defend.

That matches a shift I've been watching for a while. Policies and procedures still matter, but examiners are going well past them. These fines highlight that checkbox compliance isn’t defensible. 

What are your thresholds? Are they good enough? What was behind them? 

The emphasis on a risk-based approach is to ensure each program fits its institution, and examiners are checking, with a fine-tooth comb, whether it does, because a checkbox isn’t a decision. Risk is unique to the institution, and the AML program should be too.

Whether it’s your direct transactions, a BaaS partner's volume, or logic from a third party, it’s your banking rail, your charter, and your responsibility.

I've been saying some version of the above quote for years. If you use a vendor, run a BaaS program, or outsource part of your compliance work, you still have to be able to look a regulator in the eye and explain exactly what's happening. 

"Someone else handles that" won't cut it, and neither will a murky answer. 

That’s why I put together six questions I'd want any AML leader to be able to answer about their own program.

TL;DR: What do recent AML enforcement actions mean for your transaction monitoring program?

Recent enforcement actions point to the same gap: monitoring logic the institution couldn't explain or defend. Examiners expect you to justify every threshold, rule, and AI-assisted decision, not just show that controls exist. That responsibility stays with your institution even when a vendor or partner is involved.

• Explain every threshold and rule, including the ones you didn't write. Out-of-the-box or vendor logic built for someone else's program is still yours to defend.

• Let your data drive tuning, not your staffing. Customized rules and backtesting cut noise for reasons you can document.

• Close the loop when testing finds a problem, with a tested fix and an approval trail.

• Match coverage to your risk assessment across products, geographies and customers.

• Find suspicious activity yourself. Law enforcement outreach should confirm your monitoring, not replace it.

• Hold AI to the same standard. If you can't see how it reached a conclusion, you can't defend it.

1. Can you explain every transaction monitoring threshold and rule, including the ones you didn’t write?

The findings describe thresholds set by judgment with no evidence behind them, left in place for years, and rules that suppressed alerts without real governance. Nobody could point to why the numbers were what they were. This is the danger of a static program. 

I see the same gap from another direction: institutions running rules that were never curated for them. Sometimes it's an out-of-the-box template that got switched on and never tuned. Sometimes it's a black-box provider whose logic was built for someone else's program. One of our customers described a past provider this way: "You can only change the threshold, that's all you got. You can't change a rule."

Out-of-the-box rules are a fine starting point. We have them too. But they should be a baseline, never the final answer. Every rule should be curated to your segment limits, customers, and products.

In practice, a glass box program gives you:

• Rule logic your BSA officer can read without calling a vendor or a data scientist

• A documented rationale for every threshold

• Backtesting before any change goes live

• A version history that shows exactly what was running on any given date
  
  

"An examiner will ask me… how did the system determine this? And if I don't have it in writing, I won't be able to defend it." - BSA leader, community bank

2. Is your AML monitoring driven by your data, or by your staffing?

One finding that stuck with me describes monitoring designed around how many investigators were available, with compliance resources kept to a minimum. I understand the pressure. Every team I've worked with has had more alerts than people at some point. But when staffing sets the thresholds, coverage becomes whatever is left over.

Tuning to cut noise is good. Why you're tuning is what matters. Customized rules for your portfolio, plus backtesting against your own historical data, show you which rules find real risk and which just create work. Rule effectiveness data, like SAR conversion by rule, tells you where to look. That's a decision to strengthen your BSA program, not a volume-control play based on headcount, and it's one you can document.

Then there's the first pass. An AML alert review agent can pre-read each alert, pull the context together, and suggest a disposition with its reasoning, while your analyst makes the call. Curated rules plus an agent on the first pass is two birds, one stone: the rules that remain carry more weight, and your team spends its time on real risk instead of noise.

"With quantitative data [it] is not something that can be refuted… it creates defensibility." - Compliance leader, global payments company

3. When AML model testing finds a problem, what happens next?

The recent findings describe testing that flagged significant problems, followed by no meaningful action. Documenting a concern isn't the same as fixing it.

If you haven't worked inside a bank, let me give you an insider scoop. An issue often starts as an observation. If it isn't fixed, it becomes a finding. At that point you commit to a remediation plan, including what you'll change, how, and by when. Making the commitment is the easy part. Following through is where programs often break down.

In one past role, I couldn't test rule changes at all. Everything had to go straight into production. 

If you’re trying to fix something, and do so carefully, that's not where you want to be.

Let’s say a rule is flooding your queue with false positives and building a backlog. A glass box approach:

• Uses your data to decide what the fix should be

• Shadow-tests the change alongside production before it touches live decisions

• Deploys with an approval trail, without waiting weeks on a change request

• Hands the documentation to internal audit or your examiner

What you want to avoid is "we turned it off because it was too much."

Transparency helps after the fix, too. If you committed to clearing a backlog in six months, a dashboard with aging buckets lets you, your auditors, and your board watch the queue shrink in real time. AI analytics let you ask plain-language questions about the program and see the query behind each answer.

4. Does your coverage match every product in your AML risk assessment?

Coverage gaps showed up across the recent actions: limited monitoring of money orders and other negotiable instruments, weak credit card monitoring, and a focus on smaller deposit products at the expense of a much larger card business.

Program coverage starts with your risk assessment. It needs to encompass your full product landscape, typologies, services, geographic risks, and client portfolio. Your transaction monitoring must directly map back to these findings. For instance, a bank in southern Texas might weigh its money order activity differently than other offerings due to regulatory shifts demanding heightened scrutiny. However, the remaining product suite still requires thorough assessment and curated monitoring. Compliance cannot just react to the week's hot topic. Maintaining visibility across all typologies and products ensures your risk assessment evaluates every area to deliver dynamic, holistic coverage.

A glass box program organizes rules by typology and maps them to your risk assessment, so you can show your coverage in one view instead of rebuilding it across systems when the examiner asks.

5. Who's finding your suspicious activity, transaction monitoring or law enforcement?

In one recent case, more than a third of investigations started from outside events like subpoenas, law enforcement requests, and requests from other financial institutions, rather than from the institution's own monitoring.

To be clear, hearing from law enforcement is normal. In past roles I've worked with the SEC, IRS, DOJ, and local police departments, and I was always glad when they reached out, especially on activity I'd already filed on. That outreach should confirm what your monitoring found. It shouldn't be your primary mechanism for finding suspicious activity. 

Having automated transaction monitoring isn't the same as having effective transaction monitoring. If it isn't catching activity, it's busy work. Measure detection effectiveness rule by rule, know where your cases come from, and track trends over time so you're proactive, not reactive.

6. Can you explain the AI in your AML program?

AI governance is a key topic for compliance teams right now, and for good reason. Compliance teams know they have to defend every decision. They can't defend what they can't see. Some large banks are blocking AI agents outright because they can't explain the logic behind them.

"Our MRM wants to peek inside the black box." - Head of BSA Program Governance, regional bank

The answer isn't to avoid AI. It's to hold AI to the same standard as your rules. The model I see working, and the one most of our customers ask for, is human in the loop: the agent recommends with a written rationale, a person decides, and every override is logged. 

Automation can grow as trust does. When an examiner asks how a decision was made, you can show the evidence the agent used, what it suggested, and who made the final call.

Glass box AML monitoring is how you answer an examiner

None of these questions are new. What's changed is how hard examiners are pushing on them, and how little room there is for "the system just does that."

Glass box monitoring is how you answer an examiner who asks how the system determined something. It’s not just a product feature or a one-size-fits-all checkbox, but rather how you show your work instead of hoping someone else got it right. 

At the end of the day, it's your charter and your responsibility, so every threshold, rule, and AI-assisted decision should be something you can explain, and defend, yourself.

If you want to see what that looks like in practice, see how Oscilar approaches AML transaction monitoring.

FAQs

What does glass box AML transaction monitoring mean?

Glass box monitoring means the people accountable for the AML program can see and explain how it works: the logic of every rule, why each threshold is set where it is, what changed and when, and how any AI-assisted decision was reached. The opposite is a black box, where alerts come out but the institution can't show how they were generated.

Why are regulators focused on explainability in AML programs?

A risk-based program is supposed to fit the institution's own risks. Examiners test that by asking how thresholds were set, how rules were tuned and how outcomes are measured. If an institution can't explain those choices with documentation, it can't show the program is working as its policies say it does.

Is a bank responsible for AML controls run by a vendor or BaaS partner?

Yes. A bank can use vendors and partners, but the BSA/AML program, and the accountability for it, stays with the institution that holds the charter. That's why the bank needs to understand and be able to defend any logic it relies on, including logic a third party built.

How can banks reduce AML false positives without adding risk?

Tune with data, not headcount. Customize rules to your products and customers, backtest changes against historical data before deploying them, track rule effectiveness such as SAR conversion by rule, and document why each change was made. That reduces noise for reasons you can defend.

Can banks use AI in AML compliance if examiners expect explainability?

Yes, if the AI is explainable and governed. A common approach is human in the loop: the AI agent recommends a disposition with its rationale, an analyst makes the decision, and every output and override is logged for audit and examination.