An automated compliance system can operate exactly as configured and still fail to perform the function the organization needs.

That distinction is central to FinCEN’s findings concerning Bank of America’s proprietary transaction monitoring system, Event Processor. The FinCEN Consent Order attributes missed and delayed reporting of more than $5 billion in suspicious activity to deficiencies in internal controls and other parts of the bank’s anti-money laundering program. That figure describes suspicious activity that was not timely reported, not a determination that every dollar represented criminal proceeds.

In Part 1, we examined management decisions about known risks. This installment examines how those decisions were embedded in technology, testing, and investigative processes. In this Part 2, we review the natural follow up from that statement; the lesson is not that automation is inherently unreliable. It is that automating a decision does not remove the obligation to establish that the decision is supportable.

Inside Event Processor

Bank of America developed Event Processor to manage transaction monitoring alerts. The bank’s records described an interconnected model system intended to support the identification, investigation, and reporting of suspicious activity. Its development also addressed a practical problem: there were not enough investigators to review all the alerts being generated.

The diagram on page 10 of the Consent Order illustrates the basic process. Individual alerts received weighted risk scores and were generally consolidated at the customer level into Event Groups. Unless an automatic promotion applied, the group ordinarily did not become an investigative case until its combined score reached 20 points. That threshold, initially established through stakeholder judgment, remained in place until December 2023.

The timing rules were equally important. An Event Group generally needed to reach the threshold within 13 months of its oldest active alert. Older alerts could remain in the group but no longer contribute to its score. Consequently, retirement of an alert did not establish that the underlying concern had been investigated or resolved. For compliance leaders, the distinction is consequential. A system that generates an alert is not necessarily a system that ensures the alert receives meaningful review.

The Testing Challenged the Design

The Consent Order describes repeated evidence that the system’s risk weights did not adequately reflect the risks being identified. One internal report found that an ATM large-cash-deposit risk factor carried only one point in Event Processor even though the bank’s testing associated it with a SAR yield of 56.75%. FinCEN also notes that SAR yield can be useful but is not the only metric for evaluating a control. The issue was the bank’s failure to respond appropriately to evidence that its design was not addressing its risks.

The chart on page 21 makes the threshold problem particularly clear. In tested samples, Event Groups scoring 19 points, just below the investigative threshold, had SAR yields of 45.49% in the first quarter of 2022 and 45.03% in the second quarter. Earlier testing of groups scoring 20 to 24 points, which qualified for investigation, had produced yields of approximately 34%. FINCEN consent order

These results did not establish the precise performance of every unreviewed transaction. They did, however, challenge the justification for leaving the threshold unchanged. The management question should have been: What does this evidence tell us about the activity we are not investigating?

When Efficiency Becomes the Wrong Objective

FinCEN found that the bank’s testing often focused on whether yields above and below the threshold were statistically different, without adequately considering the implications of missed suspicious activity. The bank also lacked an objective benchmark to help assess the appropriateness of the threshold.

In another example, a calibration model reduced the number of cases requiring investigation by more than 8,200. An accompanying report described the associated loss of SARs as permissible without explaining how that conclusion had been reached.

This is an important distinction for any automated compliance process. Reducing unnecessary reviews can be a legitimate improvement. Reducing reviews is not, by itself, evidence of improvement. Consider an expense-monitoring tool. Eliminating repetitive, demonstrably irrelevant alerts may improve performance. Raising thresholds until the review team can handle the remaining volume does not establish that the excluded transactions present acceptable risk.

That is an application of the case, not a finding about an expense system at Bank of America. The transferable principle is that the performance objective must remain tied to the compliance purpose.

Exceptions Can Defeat the Primary Control

The Event Processor also used rules that rescored certain risk factors to zero. The Consent Order describes those rules as developed through an ad hoc and subjective process without adequate testing. When the bank discontinued the logic in December 2023, approximately 150,000 active Event Groups had triggered one or more aspects of it.

One particularly useful example involved customers exempted from certain currency transaction reporting requirements. Event Processor used that status to suppress some alerts, even though the applicable exemption did not remove the obligation to report suspicious activity. The broader control lesson is to examine the legal and factual basis for every exception.

An exception for one purpose should not silently become an exemption from a different control. A previously approved customer should not automatically become exempt from future review. A false-positive determination based on yesterday’s information should not permanently determine tomorrow’s result.

Data Gaps Limit What Technology Can Detect

FinCEN found that the bank’s systems did not distinguish adequately among types of negotiable instruments, such as checks and money orders. That limited targeted monitoring. The Consent Order also describes insufficient monitoring and data quality issues involving credit card activity. The lesson for compliance technology governance begins before model selection.

What information does the control need? Is that information captured consistently? Does it reach the monitoring system? Can investigators retrieve and use it? Who is responsible when a required field is incomplete or a relevant product is missing from coverage? A sophisticated analytical tool cannot compensate for an unidentified gap in the information supplied to it.

Recalibration Revealed the Scale of the Problem

Following regulatory engagement, Bank of America lowered the investigative threshold in December 2023 to 10 or 12 points, depending on the Event Group. A limited lookback identified nearly 8,900 SARs involving approximately $4 billion in activity that the bank had failed to identify and report under the prior parameters.

The bank estimated that the revised thresholds would double ongoing monthly investigative volume and require approximately 750 additional personnel, with another 800 consultants needed for the one-time lookback. These were the bank’s estimates of staffing requirements, not evidence that every position had already been filled. For a CCO, those numbers make the resource question concrete. Technology configuration and staffing cannot be governed as unrelated decisions when one determines the workload of the other.

The Application to AI Governance

The Consent Order describes Event Processor as a proprietary interconnected model system. It does not establish that it was a generative AI system. Nevertheless, its governance failures provide useful comparison points for organizations deploying AI in compliance. FINCEN consent order

NIST’s AI Risk Management Framework organizes risk management around Govern, Map, Measure, and Manage. Applied here as an analytical framework, those functions suggest a practical sequence: assign accountable ownership, define the intended use and relevant risks, test actual performance, and act when the evidence identifies deficiencies.

ISO/IEC 42001 provides a complementary management-system approach for establishing, maintaining, and continually improving the governance of AI. Neither framework is presented here as a standard that FinCEN found Bank of America had violated. The objective is not to prohibit innovation. It is to ensure that innovation remains explainable, testable, and subject to effective challenge.

Three Key Takeaways

First, validate the decision rules, not merely system availability. Establish why thresholds, weights, prioritization rules, and exceptions address the intended risk.

Second, test what the control misses. Include below-threshold activity, incomplete product coverage, data gaps, and delayed escalation.

Third, connect technology governance to resources and remediation. A finding that requires additional review must lead to a supportable operational response.

The CCO question: Can you demonstrate that your compliance technology addresses the intended risk, or only that it operates according to its configuration?

In Part 2, we examined how BOA’s Event Processor transaction monitoring system failed to translate automated alerts into effective detection and investigation. FinCEN identified unsupported design choices, inadequately calibrated risk weights, poorly governed suppression rules, and monitoring gaps that persisted despite testing that challenged the system’s effectiveness.

After the bank lowered its investigative thresholds, a limited lookback identified nearly $4 billion in suspicious activity that it had failed to identify and report under the previous parameters. The central lesson for CCOs is that reducing alert volumes or investigative workloads does not, by itself, demonstrate improved compliance. Effective technology governance requires reliable data, supportable decision rules, independent testing, attention to missed activity, and resources sufficient to address the findings. These principles also provide practical guidance for AI oversight. The measure of an automated control is whether it addresses the intended risk, not simply whether it operates as configured.

Join us Tomorrow

Tomorrow in Part 3 broadens the analysis from transaction monitoring to sanctions compliance, examining OFAC’s findings involving blocked-bank payment routing, improperly prioritized alerts, delayed watchlist updates, and mishandled accounts associated with blocked persons. These incidents raise a larger management question: when several controls fail in different ways, does the organization investigate each error separately, or examine whether they reveal shared weaknesses in oversight, resources, and operational execution?

We will explore the importance of vendor oversight, controlled technology changes, appropriately scoped investigations, and coordinated disclosure and cooperation. We will also examine the distinction between completing a corrective action and demonstrating that it works, including the role of interim safeguards and independent validation. The question for boards and compliance leaders is whether management has corrected individual incidents or verified that the underlying controls work across the enterprise.