Before the AML System Vote, Name the Tuning Owner

A practical weekly article for community bank and credit union boards and senior leaders on governing AML monitoring technology, focused on tuning ownership, backlog escalation,...

The AML system demo is not where the risk lives.

The risk lives six months later, when the alert queue is too noisy, investigators are tired, operations wants fewer false positives, compliance wants cleaner coverage, and somebody quietly changes a rule because the system is making everyone miserable.

That is the moment boards and senior leaders should care about before they approve the next AML monitoring platform, model refresh, rules-tuning project, case management upgrade, or managed-services add-on.

Not because directors need to become BSA analysts. Please do not make them sit through every scenario rule unless you want to watch intelligent people age in real time.

But because tuning is not just a technical setting. It is where risk appetite, staffing capacity, customer friction, regulatory exposure, and technology governance collide.

If a community bank or credit union is approving an AML system change, the board packet should answer one plain question:

Who owns the tuning decisions after go-live?

The system vote is really an operating model vote

Most AML technology proposals are framed around capability.

Better monitoring. Better case management. Better workflows. Better analytics. Better investigator productivity.

All useful.

But the approval decision is bigger than the tool. The institution is also approving a future operating model for how suspicious activity is detected, triaged, escalated, documented, and reported.

Rules generate alerts. Alerts create investigations. Investigations consume staff time. Staff capacity affects backlog. Backlog pressure creates tuning pressure. Tuning changes what the institution sees.

That loop is governance. A rule threshold is not just a setting. It is a decision about what activity deserves attention, what noise the institution will tolerate, what risk may be missed, and who has authority to accept that tradeoff.

TD Bank showed what happens when growth outruns controls

The TD Bank case is a blunt reminder that BSA/AML weakness is not a paperwork problem.

In October 2024, the Office of the Comptroller of the Currency announced a cease and desist order, a $450 million civil money penalty, and a growth restriction against TD Bank, N.A. and TD Bank USA, N.A. for BSA/AML deficiencies. The OCC said the bank failed to develop and maintain a BSA/AML program reasonably designed to assure and monitor compliance. The agency cited deficiencies related to internal controls, risk management practices, risk assessments, customer due diligence, customer risk ratings, suspicious activity identification, evaluation and reporting, governance, staffing, independent testing, and training. The OCC also said the bank had significant, systemic breakdowns in its transaction monitoring program and processed hundreds of millions of dollars of transactions with clear indicia of highly suspicious activity. Source: OCC, “OCC Issues Cease and Desist Order, Assesses $450 Million Civil Money Penalty, and Imposes Growth Restriction Upon TD Bank, N.A. for BSA/AML Deficiencies,” Oct. 10, 2024: https://www.occ.gov/news-issuances/news-releases/2024/nr-occ-2024-116.html

Community institutions are not TD Bank. The scale, complexity, and supervisory posture are different.

But the governance pattern travels. When business growth, digital channels, staffing reality, and monitoring technology are not governed together, the control environment starts making promises the operating model cannot keep.

That is why an AML technology packet should explain how management will keep the control model aligned with the institution's actual risk profile after the system is live.

Who reviews tuning proposals? Who approves material rule changes? Who validates that fewer alerts really means less noise, not less visibility? Who tells the board when staffing capacity and system coverage no longer match the risk?

USAA showed that backlog and reporting are board-level symptoms

USAA Federal Savings Bank is another useful example because it connects growth, monitoring, staffing, and suspicious activity reporting.

In March 2022, the Financial Crimes Enforcement Network announced a $140 million civil money penalty against USAA FSB for willful violations of the Bank Secrecy Act. FinCEN said USAA FSB admitted it failed to implement and maintain an AML program that met minimum BSA requirements from at least January 2016 through April 2021. FinCEN also said the bank admitted it failed to accurately and timely report thousands of suspicious transactions involving suspicious financial activity by customers, including customers using personal accounts for apparent criminal activity. FinCEN's release said USAA FSB's customer base and revenue grew while its compliance program did not keep pace. Source: FinCEN, “FinCEN Announces $140 Million Civil Money Penalty against USAA Federal Savings Bank for Violations of the Bank Secrecy Act,” March 17, 2022: https://www.fincen.gov/news/news-releases/fincen-announces-140-million-civil-money-penalty-against-usaa-federal-savings

Again, not a community-bank scale example. But it is a clean warning.

A growing institution can buy better technology and still have a governance problem if monitoring logic, investigator capacity, escalation discipline, and reporting timelines are not managed as one system.

Backlog is not just a workload issue. It is a risk signal. False positives are not just annoyance. They are capacity tax. Tuning is not just optimization. It is a change to the institution's line of sight.

That is why senior leaders should be careful when an AML proposal promises fewer alerts. Fewer bad alerts can be wonderful. But the board packet should explain what was reduced, why it was reduced, how the decision was validated, and what independent review will confirm the institution did not tune away something important.

What I would want in the packet before the vote

If I were sitting in the boardroom or risk committee before an AML system approval, I would want four things in plain English.

1. The alert logic change map

Not every scenario rule. Not a dump of thresholds.

A simple map of what monitoring coverage is changing. Which products, channels, customer segments, geographies, transaction types, and digital workflows are affected? Which rules are new? Which rules are being retired? Which thresholds are changing enough to matter?

If the packet cannot explain that at a business level, the institution is asking leaders to approve a control change they cannot see.

2. The tuning owner

Someone has to own the tradeoff between noise and visibility.

That owner should not be a vague committee label. Name the accountable executive or business owner. BSA/AML leadership will have a central role. Compliance, risk, operations, and technology all need seats at the table. But accountability still needs a name.

When the queue gets ugly, that person should be able to explain what changed, why it changed, what evidence supports the change, and what residual risk was accepted.

3. The backlog threshold that forces escalation

Every institution has busy periods. That is normal.

What is not normal is allowing alert queues, investigation aging, SAR decision delays, or quality-review findings to deteriorate until the exam team becomes the first audience to hear the truth.

Before approval, leaders should define the trigger that turns backlog from management noise into an executive and board issue.

Maybe it is alert aging. Maybe it is case volume per investigator. Maybe it is late SAR filings. Maybe it is quality-review exceptions. The exact metric matters less than the discipline of naming it before stress arrives.

4. The validation plan after go-live

A tuning decision should not be considered successful just because the queue got smaller.

The validation plan should ask whether coverage still matches the risk assessment, whether expected alert volumes make sense, whether sample testing found missed activity, whether investigators understand the new workflow, and whether independent testing will review material changes.

That sounds basic. Basic is good. A lot of governance failures start because nobody wanted to write down the obvious thing and check it later.

The board's job is not to tune the rules

Directors should not approve individual AML thresholds. That would be governance theater with extra spreadsheets.

Their job is to make sure management has a disciplined way to govern the technology decisions that shape BSA/AML visibility.

That means treating the AML system vote as more than a software purchase. It is a decision about control coverage, staff capacity, accountability, validation, and escalation.

A strong packet should make the tradeoff visible before the contract is signed and before the first tuning fight shows up after go-live.

Because the dangerous question is not whether the system can generate alerts.

Of course it can.

The dangerous question is whether the institution will still know what it stopped seeing after everyone celebrates that the queue finally got smaller.

Discussion questions

1. Who owns material AML tuning decisions after go-live, and can that person explain the tradeoff between fewer false positives and reduced visibility in business language? 2. What backlog, alert-aging, SAR-timeliness, or quality-review threshold would force escalation to senior leadership or the board risk committee? 3. How will the institution validate that post-implementation tuning improved monitoring quality rather than simply making the queue easier to manage?