Who set your monitoring threshold, and on what basis?

On 13 October 2026 FinCEN assessed Bank of America a $1.2 billion penalty for failing to mitigate and report priority national security risks. The same day the OCC imposed a $750 million civil money penalty, the largest in its history, for a “deficient and ineffective” anti-money-laundering programme. FinCEN credits the OCC amount against its own¹².

Buried in the detail is one small rule. Corporate INTL’s summary of the FinCEN order says alerts at the bank became a case only when a customer reached 20 points within 13 months. That threshold was “initially set by stakeholder judgment” and stayed until December 2023³.

What did the 20-point rule look like before anyone challenged it?

It was a number in a system. As summarised, the bank’s monitoring tool dated from 2010 and scored alerts with weighted risk factors³. One factor that produced suspicious activity reports 56.75% of the time in the bank’s own testing carried a weight of one point³. The threshold and the weights were each defensible on the day someone chose them. Nobody had to show the evidence again.

Before:

• Threshold: 20 points in 13 months.
• Basis: stakeholder judgment.
• Owner: not recorded in anything the regulator cites.
• Last tested against results: unclear. After one unfavourable internal test, a senior manager was reportedly told to repeat it, which produced a better result³.

What did it look like after December 2023?

The bank cut the threshold to 10 or 12 points and the window to four months³. A 2024 lookback then found nearly 8,900 unfiled reports covering nearly $4 billion in activity³. The OCC found that the bank’s audit function missed long-standing concerns that examiners later found, and that the bank knew for years that it was not escalating potentially suspicious activity¹.

After: a lower number and a shorter window. Whether anyone can now say who approved it, what data it rests on and when it is next reviewed is a separate question. A regulator will ask it.

What does an examiner want in place of “judgment”?

The same four things, for every rule that decides what gets looked at, paid, refused or escalated:

1. The number or condition itself, read from the system as it runs today.
2. The reason it is set there, in words a person approved.
3. The owner: a named person who stands behind it.
4. The evidence: the test, ticket or decision behind the reason, and the date it was last checked.

A threshold missing any of the four is a finding waiting for an examiner.

What can you do this week?

Pick five thresholds in your own controls: a fraud score cut-off, a refund approval limit, a credit limit, an alert trigger, an age-based eligibility rule. For each, write down who set it, when, and what result they tested it against. Count the blanks. The blanks are the audit.

How does AppThentic answer the examiner’s question?

om reads the threshold in the system, finds its source in the code, ticket or document, and shows it with its owner and status. Where nothing written down explains why the number is 20, om asks the person responsible, and the rule stays Unknown or Inferred until that person answers. Only a person’s approval makes it Approved. When the code later changes, the rule becomes Stale and its owner is asked again.

The result is the decision trail audit teams ask for: the reason, the owner, the approval date, every change since, and the evidence behind it. Rules without an owner or an approved reason are listed, not hidden. The trail itself is logged: who asked, who answered, who approved, and when. See Audit and compliance.

What is the lesson beyond banks?

Most thresholds in most companies were chosen once, by someone reasonable, and then left alone. The cost shows up when somebody outside asks why. At this bank the date was 13 October 2026 and the price was nine figures. Ask the question yourself first.

To see this on your own systems, book a walkthrough.

Sources