The Challenge
Bank of America developed a transaction monitoring system that appeared advanced but had a major flaw: it treated risk as static instead of adaptive. The Event Processor, launched in 2010 and touted as "first of its kind for the industry," assigned risk scores to suspicious activity alerts at the group level rather than the individual transaction level. This meant a customer could trigger multiple high-risk alerts, but the system would assign the entire cluster a single, low-weight score.
The real issue wasn't just the initial design choice. Bank of America's compliance program allowed these flawed risk weights to persist for years, even after internal testing revealed a disconnect between alert types and actual suspicious activity reporting. FinCEN's settlement order highlighted that 76 percent of risk factors carried identical weights from 2018 through 2023, despite evidence that the scoring model didn't reflect real-world money laundering patterns.
System Constraints
Event Processor operated on a 13-month rolling window. Individual alerts accumulated into an Event Group, and only when that group's combined score reached 20 points would a human investigator open a case. If the threshold wasn't met within 13 months, the oldest alert aged out and the window reset based on the next alert in the queue.
This setup created a loophole: ongoing suspicious activity could evade detection indefinitely, as older events dropped off before the cumulative score triggered review. The system prioritized efficiency over adaptability.
Bank of America, like all U.S. financial institutions, was required to file Suspicious Activity Reports (SARs) when transactions met certain thresholds or patterns. However, the bank's internal testing and governance failed to address Event Processor's shortcomings promptly.
Where the Approach Failed
Bank of America conducted SAR yield testing in 2020, measuring how often a particular alert type resulted in an actual SAR filing. This testing revealed significant mismatches. One alert type had a SAR yield of 30 percent but carried an Event Processor score of only 6 points, far below the 20-point investigation threshold. Another showed a 27.7 percent yield but scored just 2 points.
The data was available, and the testing methodology was sound. However, the remediation was slow. Those risk weights weren't adjusted until 2022, two years after the testing revealed the problem.
This isn't about missing controls. It's about controls that existed but weren't integrated into decision-making with urgency. Bank of America had internal audit functions, compliance testing programs, and management oversight. What it lacked was a governance model that treated risk scoring as a dynamic system needing continuous recalibration.
Results and Metrics
The result was a $1.2 billion penalty from federal regulators and a settlement order detailing systemic failures in transaction monitoring, customer due diligence, and sanctions screening. The core issue: failure to file SARs in a timely manner because Event Processor's design allowed suspicious activity to accumulate undetected.
FinCEN's order didn't just cite the dollar figure. It documented how Event Processor's group-level scoring allowed "a large amount of potentially suspicious activity to accumulate within an Event Group before it would be subject to investigation." The system's architecture meant different types of suspicious behavior could combine within a single Event Group and still not trigger the threshold, even when individual components warranted immediate review.
The 76 percent figure is particularly damning: three-quarters of Event Processor's risk factors remained unchanged for five years while the bank's own testing showed the weights didn't correlate with actual money laundering risk.
What Should Have Been Done Differently
First, Bank of America should have designed Event Processor to apply risk scores at the individual event level, not the group level. If a customer triggers ten high-risk alerts in rapid succession, each should contribute to the risk calculation, not one aggregated score that obscures the pattern.
Second, the bank needed a formal schedule for risk weight recalibration directly tied to SAR yield testing results. When 2020 testing shows a 30 percent SAR yield for an alert type scored at 6 points, you don't wait until 2022 to adjust the weight. Treat it as a priority deficiency and remediate within the next testing cycle.
Third, governance is more important than architecture. Bank of America's compliance, audit, and management teams allowed known deficiencies to persist because there was no process to translate testing findings into system updates. Your transaction monitoring system is only as good as the governance process that keeps it current.
Takeaways for Your Team
If you're evaluating third-party transaction monitoring systems or building your own, ask how risk weights are calculated and how often they're recalibrated. Static scoring models are a liability. Your vendor should show how frequently they update risk factors based on emerging typologies and regulatory guidance.
Implement SAR yield testing as a standard control, not a one-time exercise. Measure the conversion rate from alert type to SAR filing, and use that data to adjust your risk scoring model. If an alert type consistently generates SARs, it should carry a higher weight. If it generates noise, tune it down or eliminate it.
Build remediation timelines into your testing protocol. When you identify a deficiency through internal audit or compliance testing, document the expected fix date and escalation path if that date slips. Bank of America had the testing data in 2020 but didn't act until 2022. That two-year gap is where billion-dollar fines are born.
Finally, recognize that transaction monitoring isn't a set-it-and-forget-it system. Money laundering tactics evolve. Regulatory expectations shift. Your risk scoring model needs to evolve with them, or you're building technical debt that will eventually come due in the form of enforcement actions.
