What BSA Alert Triage Actually Costs a Small Team

A BSA analyst opens an alert. Before forming any view about whether the activity is suspicious, they open the core to pull ninety days of account history. They check whether this customer has generated alerts before, and what happened with them. They look at related accounts, a business and its owner, or several family members. They open the customer file to see what the expected activity was supposed to look like when the account was opened. They check whether anything changed recently. Then they write down what they found.

Only after all of that does the actual question get asked: is this suspicious?

At a community institution, that question is frequently answered quickly, because the analyst knows the customer, or can walk down the hall to someone who does. The contractor's deposits spiked because it is roofing season. The retiree wired money to a grandchild buying a house. The restaurant's cash deposits changed because it started doing catering. The judgment takes a moment. The assembly took most of the time. And the assembly is the part nobody was hired for.

The Regulator Is Saying This Too

This is not just an internal complaint from an overworked department. It is now an explicit part of how the FDIC describes the problem. In an April 2026 statement on the proposed BSA Program Rule, FDIC Chairman Travis Hill said plainly that banks currently devote enormous resources to BSA compliance while it remains unclear how much of that effort actually advances law enforcement or national security goals. That is a striking thing for a banking regulator to state on the record, and it is the premise behind the reform.

The proposal takes a risk-based approach and would actively encourage banks to shift resources away from lower-risk activity and toward higher-risk activity, with each program built around that institution's own risk assessment and profile. Hill also noted that community banks in particular receive little direct feedback from law enforcement about what is useful, and that they would be able to lean on the Treasury Department's National Priorities in building their risk assessments. The proposal is explicitly designed to stop penalizing institutions for "foot faults" and to move exams away from box-checking.

There is one more piece worth noting, because it directly concerns the subject of this post. When Congress passed the AML Act in 2021, it directed the agencies not only to modernize the BSA and focus programs on high-risk areas, but to encourage technological innovation in countering money laundering. Using tools to handle the mechanical parts of alert review is not in tension with the regulatory direction. It is part of what the statute asked for.

Assembly Versus Judgment

The useful split inside any alert is between gathering and deciding. Gathering is retrieval and formatting. Pull the transaction history for a date range. Retrieve the customer profile and the expected activity documented at onboarding. Check the prior alert history on this customer and its outcomes. Identify related accounts by tax ID or address. Note anything that changed. Put all of it in one place, in the same order, every time.

Deciding is everything that follows. Does this pattern fit what this customer does? Is the explanation plausible? Does it warrant escalation? Should this become a SAR? Would a reasonable examiner agree with how this was handled?

Gathering has no discretion in it at all. The same steps happen on every alert, in the same order, and doing them well means doing them identically each time. That is the definition of work an automation tool handles better than a person, because a person gets tired, gets interrupted, and on a heavy queue day starts taking shortcuts that never appear in the file.

Deciding is the opposite. It requires knowing the institution's risk appetite, the customer base, the local economy, and the examiner's expectations. It is judgment, and at a community institution the quality of that judgment is genuinely higher than at a large bank, because the analyst has context no model can reconstruct.

What Gets Automated, and What Does Not?

Being specific about the boundary matters more here than in most operational areas, because the consequences of getting it wrong are regulatory.

What a tool can reasonably do is assemble the case file. Given an alert, it retrieves the account history for the relevant window, pulls the customer profile and documented expected activity, surfaces prior alerts and how each was resolved, identifies related accounts, and presents all of it in one consistent layout with every source noted. The analyst opens one prepared file instead of five systems.

What stays with a person is every part that involves a conclusion. Whether the activity is consistent with the customer. Whether to escalate. Whether to file. What the SAR narrative says. A tool should not score alerts as suspicious or clear them automatically, and nothing here suggests it should. Our automation and micro-apps page describes the general shape of this kind of contained tool.

The line is clean: a tool can gather facts and present them, and a person decides what they mean. If a proposed tool crosses that line, whatever efficiency it promises is not worth the examination risk, and the institution's own model risk obligations will make that a longer conversation than it is worth.

What This Looks Like in Practice

On each alert, the analyst works through the same sequence across the core, the monitoring system, the customer file and a shared drive of prior SAR documentation. On a good day the sequence is thorough. On a day with forty alerts, the third system sometimes gets a quicker look than the first.

With assembly handled in advance, the analyst opens an alert and finds the ninety-day history, the onboarding profile, the prior alert outcomes, and the related accounts already compiled in a consistent format. Their first act is to read rather than to retrieve. The judgment gets the full attention, and it gets the same complete picture on the fortieth alert as on the first.

Nothing about the decision changed. The same person applies the same standard. They are simply not spending most of the alert retrieving things a system already knows.

Why This Helps in an Exam

The instinct is that automating any part of BSA work creates examination risk. For the assembly step, the opposite is usually closer to the truth. Consider how consistency actually looks today. An analyst reviewing forty alerts in a day does not gather identical information on each one. They cannot. Attention varies, interruptions happen, and the file reflects what was checked rather than what should have been checked. Some alerts get five systems reviewed and some get three, and nothing in the record distinguishes them.

Automated assembly produces the same inputs on every alert, with each source and retrieval time logged. When an examiner asks what the analyst looked at before dispositioning a case, the answer is documented and identical across the sample rather than dependent on recollection. That is a stronger position, not a weaker one.

It also fits the direction the FDIC proposal is pointing. A program meant to concentrate resources on higher-risk activity is easier to demonstrate when the lower-risk work is handled consistently and the record shows where analyst attention actually went.

Have a Problem To Solve?

If your team has a review routine everyone has quietly learned to live with, that's usually the clearest sign it's worth a second look. The most effective approach is to start small, one problem at a time, rather than looking for a single platform to fix everything at once. Our community financial institutions consulting page covers how we work through questions like this with compliance and operations teams. If you'd like to talk through what a first project could look like, schedule a discovery call with one of our operations experts.