Reduce AML False Positives and Keep Coverage

Last updated: September 2026

The defensible way to reduce AML false positives is to give each alert the context that separates expected behavior from unexpected behavior, rather than raising thresholds until the alert count looks acceptable. A higher threshold lowers alert volume and coverage together. Context lowers alert volume while typology coverage holds. Every tuning change is then tested below the line, documented, and signed off by a person, so the institution can show an examiner that nothing suspicious fell out of scope.

TL;DR

• A higher threshold cuts alerts and coverage at the same time. Adding context (segment, customer history, counterparties, linked accounts, typology) cuts alerts while coverage holds.

• Segment customers so each one is compared with real peers, not with every customer of the same broad type.

• Test every tuning change above and below the line. The below-the-line sample is the evidence that typology coverage held.

• Record each change: what changed, why, the population tested, the results, who approved it and when it took effect.

• The revised model risk guidance (SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026, all dated 17 April 2026) replaced SR 11-7 and SR 21-8. Testing, validation and monitoring, and governance remain the frame.

• AI agents can prepare alert reviews and point at the rules that need tuning. Analysts still decide, and the institution still owns every threshold.

How do you reduce AML false positives without missing suspicious activity?

You reduce AML false positives without missing suspicious activity by giving each alert more information about the customer and leaving thresholds in place until testing supports a change. Four practices do most of the work:

1. Add context to alerts. Compare activity with the customer's own history, its peer segment, its counterparties and its linked accounts, and tie each alert to the typology it is meant to catch.

2. Segment customers. Set thresholds and scenarios per segment, so a large retailer and a sole trader are not judged against the same line.

3. Test every change above and below the line. Check that the alerts that remain are productive and that the activity that no longer alerts is not suspicious.

4. Keep a human sign-off. A person decides each disposition, and a person approves each tuning change, with the record kept for examiners.

The motive is rarely a smaller number for its own sake. A chief compliance and AML officer at a bank described it this way: "I want to actually catch the bad guys and I don't want my team to waste time clearing false positives. I want them to be using their brain, not like working on stuff the machine could clear."

Why AML monitoring produces so many false positives

AML transaction monitoring produces many false positives because most programs apply static thresholds to very different customers and send alerts to analysts with little context attached. Three causes recur across banks and fintechs.

One-size thresholds. A single cash or velocity threshold applied across personal, small-business and corporate customers fires constantly on the customers whose normal activity sits near it. The threshold may suit one segment and misfire on the segments it was never calibrated for. At a sponsor bank the same problem repeats across every fintech program, which a separate guide on sponsor bank AML oversight covers.

Alerts without context. An alert that reports only that a transaction looked unusual is not actionable. What makes an alert actionable is the context attached to it: what the account normally does, how its peers behave, who the counterparties are and what else is linked to it. Without that context, an analyst rebuilds it by hand for every alert, and most of the rebuilding ends in a clearance. The same logic applies whether alerts are generated in batch or through real-time transaction monitoring.

Rules that accumulate. Scenarios get added after an exam finding or a new typology and are rarely retired. Each one adds its own stream of alerts, and nobody owns the question of whether the stream still catches anything.

The false negative is the real risk

A false positive costs analyst time. A false negative is suspicious activity that never reaches an analyst, and potentially a suspicious activity report (SAR) that is never filed. Any effort to reduce AML false positives has to show it did not create false negatives, which is why experienced teams stay cautious.

A global head of compliance operations at a crypto firm said: "We were very careful about overly tuning it to make sure that we weren't missing anything. We would be happy to see more alerts than too few."

Volume still matters to supervisors. A chief compliance officer at a bank subsidiary said its regulator had pointed out that the bank generated more alerts than similar banks of its size and volume. Examiners notice alert volume that is out of line with peers, and an unexplained drop draws the same question as an unexplained surge.

Two neighboring problems are out of scope here. Name-match false positives in sanctions and PEP screening come from matching logic, not from monitoring thresholds, and are tuned differently. False declines in fraud prevention carry a different cost, customer friction and lost revenue, and are covered in a separate guide on reducing fraud false positives.

Raising thresholds versus adding context

Raising a threshold and adding context both lower the AML false positive rate, but only context does it while typology coverage holds. A higher threshold removes alerts at the margin regardless of whether they were suspicious, so the alerts it removes include some that mattered. Context removes the alerts that are explained by who the customer is and what the customer normally does, and it keeps the alerts that are not.

The two levers look alike on an alert-volume chart. Only one of them can answer the examiner's follow-up question.

Context takes several concrete forms: the customer's segment and expected activity, its transaction history, its counterparties, the accounts linked to it, and the typology the alert is meant to catch. An FIU manager at a sponsor bank described rules that evaluated activity at the instrument level when they needed to look at the entity level. Rewriting those rules to look at the entity materially cut one category of alerts, without raising a single threshold.

The context also has to reach the analyst working the alert. The operational test of explainability is whether each alert carries its reasons, so the person in the queue can see why it fired and what separates it from the customer's normal behavior. Rules stay part of the answer: as a chief risk officer at a digital bank put it, "There are analysts who are going to tune rules all the time because not everything can be in a model." Whether rules or machine learning models should do the detecting is a separate question, covered in a guide on rules versus models in transaction monitoring.

Segmentation: compare customers with their real peers

Customer segmentation reduces AML false positives by comparing each customer with peers whose normal activity looks like theirs. Most programs underuse segmentation. A BSA/AML executive at a bank with a digital banking arm named missing segmentation as a common deficiency: many systems split customers only into business and personal, when a national chain and a corner restaurant are not the same kind of business customer.

Segment on the attributes that drive expected activity:

• Customer type, such as individual, sole trader, small business, corporate, or money services business.

• Product, such as deposit account, card program, payments, or lending.

• Expected activity, including declared volumes and transaction types captured at onboarding and refreshed over time.

• Geography, including where the customer operates and where its counterparties sit.

Set thresholds and scenarios per segment, and write down the rationale for each one. Segmentation is also a supervisory expectation. A chief compliance and AML officer at a bank said regulators expected the bank to risk-segment its rules, so that high-risk clients were looked at more often, and that the incumbent system could not do it. Fintech programs feel this sharply, because products and customer bases change quickly; Oscilar's page on AML for fintechs covers that setting.

Revisit segments as products and customers change. A segment defined when a program launched stops describing its customers once a new product or customer base arrives, and false positives creep back in. Tuning by payment corridor and jurisdiction is its own discipline, covered in a separate guide on cross-border AML workflows.

What makes a tuning change defensible to examiners

A tuning change is defensible to examiners when the institution can show, in writing, what changed, why it changed, how it was tested, that typology coverage held, and who approved it. A director of compliance and BSA at a community bank described the question every change has to survive: "I get an examiner will ask me like, how did you determine? Like how did the system determine this? And if I don't have it in writing, I won't be able to defend it."

Above-the-line and below-the-line testing

Above-the-line (ATL) and below-the-line (BTL) testing is how a team shows that a threshold change kept coverage. When a threshold changes, the team samples activity just above the new line to confirm the alerts that remain are productive. The team also samples activity just below the line to confirm that the activity that no longer alerts does not include suspicious activity the old threshold would have caught. The below-the-line sample is the evidence an examiner looks for.

A VP and AML risk officer at a community bank summarized the practice: "When we do scenario adjustments, you have to do above the line below the line testing and then save it for the regulators." The gap shows up when it is skipped. A BSA/AML systems manager at a sponsor bank, reviewing a rule change, found that the above-the-line and below-the-line testing that should have been done months earlier for that change had never been done.

Map typology coverage before and after

List the typologies each scenario is meant to detect, then check that every typology is still covered after the change, by the changed scenario or by another one. A tuning change that quietly retires the only scenario covering a typology is a coverage gap, even if every remaining alert is productive.

Test before production

Test the change on historical data before it goes live. A compliance director at a community bank recalled a rule change made directly in production that produced a flood of alerts, and the first question afterwards was whether a test environment existed. A chief compliance officer at a payments fintech framed the same concern from the other side: "My primary concern would be somebody turns off a rule... I'd rather catch that problem at the beginning rather than after the alerts generate."

Many systems still make this hard. A BSA/AML executive at a bank with a digital banking arm said, "If you want to make some changes to your thresholds to existing rules, that's not something you can test before you turn it on within the system."

The revised model risk guidance

On 17 April 2026 the Federal Reserve, the OCC and the FDIC issued revised model risk management guidance: SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026. The revision superseded SR 11-7 and SR 21-8, the 2021 interagency statement on model risk management for BSA/AML compliance. The revised guidance is organized around model testing, model validation and monitoring (including conceptual soundness and outcomes analysis), and governance and controls. Those three headings are a practical structure for the record of any tuning change to a scoring or segmentation model.

Whether a given AML rule set falls inside the revised model definition is a question of reading the definition, not a blanket answer. The guidance defines a model as a complex quantitative method that applies statistical, economic or financial theories to produce quantitative estimates, and it excludes simple arithmetic and deterministic rule-based processes that lack an underlying statistical or economic theory. A scoring or segmentation model is more likely to fall inside that definition than a single fixed rule, and the institution's own model risk function should make that call.

SR 26-2 also states that it is expected to be most relevant to banking organizations with over $30 billion in total assets regulated by the Federal Reserve. Smaller institutions still face the same examiner question about how a threshold was set.

Effective challenge

SR 26-2 keeps the principle of effective challenge: critical analysis by objective experts who have the expertise, independence and organizational standing to effect change. For a tuning change, that means someone other than the person who proposed the change reviews the testing and can stop the change.

A BSA/AML and OFAC officer at a regional bank described how many functions a threshold change touches: "It's not as simple as just me flipping switches. We got to run it through our enterprise risk management group, our data group, our IT and infosec group... model risk management."

Vendor-built models do not transfer that responsibility. A compliance director at a community bank said: "The third party part of it because that's where they get you... Did you do due diligence, like did you validate to understand how it's how it operates?" How a monitoring model is validated end to end is covered in a separate guide on AML model validation.

What a tuning change record contains

A record like this is what turns a threshold change into something an examiner can follow.

Write the record so a non-specialist can read it. An AML compliance manager at an online gaming operator asked of any risk factor: "Was that documented very clearly and, very readable for regulators or auditors?"

Where AI agents fit, and where humans stay

AI agents fit in AML alert review as preparers and recommenders, and humans stay as the decision-makers. An agent gathers the evidence an analyst would otherwise collect by hand, sets out its reasoning, and recommends a disposition. The analyst reviews the reasoning and decides. Oscilar's risk agents work on that rule: "Agents never autonomously close or escalate alerts — every recommendation is reviewed and confirmed by a human analyst before any action is taken."

Four design choices keep that arrangement defensible:

• Every alert, not a sample. An agent runs against every alert that enters a configured queue, so there is no population it silently skips, and every action by an agent or an analyst is logged with its reasoning.

• Missing data goes to a person. When key attributes such as a date of birth or an address are missing, the agent flags the gap and recommends manual review rather than forcing a disposition. Auto-dismissing an alert without corroborating evidence increases regulatory risk.

• Per-queue configuration. Which alert types a high-confidence recommendation can be confirmed quickly for, and which always need a full read of the reasoning, is set per queue according to the institution's risk appetite.

• A documented path to sampling. Trust builds from full analyst review of every recommendation toward periodic sample QC, the way second-line quality assurance already works, and each step is validated against known outcomes and recorded.

The revised model risk guidance does not settle how to govern agents. OCC Bulletin 2026-13 states that generative and agentic AI models are not within its scope, and the agencies plan a request for information on banks' use of AI. Governance still applies: the institution owns the threshold, the disposition and the record, whoever prepared the review.

Buyers set the boundary themselves. A chief BSA officer at a sponsor bank said: "Even if we could automate all the way through SAR submission, just because we can, doesn't mean we should, from a regulatory posture, they're going to want to see us having very tight guardrails on how we QC this." The same officer described the order of work: "If we can clean that up, let's start by making a smaller pile and then we'll figure out how we work the pile faster."

Agent dispositions also feed tuning. A director of AML compliance at an online gaming operator described using them as evidence: "How many are the agents recommending are a non issue my investigators are agreeing with and they're isolated to like certain rules that then I'm saying, all right, we need to tune this rule because it's giving us a bunch of non issues." Agreed non-issues clustered on one rule point at the rule to change, and the change still goes through testing and sign-off. Reviews, dispositions and the reasoning behind them sit together in case management, so the record for any alert can be pulled up on demand.

Measuring the result after the change

Measuring the result after a tuning change means watching whether alerts became more productive without coverage slipping. Track three things over time.

• Conversion by segment and scenario. Watch alert-to-case and case-to-SAR rates for each segment and scenario the change touched. A rising conversion rate with stable SAR filing suggests the change removed noise. A falling SAR count in a segment is a prompt to re-check the below-the-line population, not a result to celebrate.

• Drift in any model involved. Monitor data drift, feature drift and concept drift, alongside outcome measures by segment, so a model that is degrading is caught before the next exam rather than during it.

• Periodic below-the-line re-testing. Customers and typologies change after the change goes live. Re-sample below the line on a schedule and record the result against the original change.

Record each of these against the change record, so the examiner sees one continuous story from proposal through monitoring.

How Oscilar approaches it

Oscilar approaches false-positive reduction as a tested, documented change rather than a threshold edit. Before anything goes live, a four-week design partnership runs a backtest against historical alerts, then shadow mode on the live queue, then a human-in-the-loop readout.

The platform keeps a full audit trail per decision with stored reasoning, human-in-the-loop by design, bias and drift monitoring, and is designed to fit the interagency model risk management guidance. Auto model monitoring covers data drift, feature drift and concept drift, plus outcome KPIs measured by segment.

Oscilar's AML solution pages describe a testing suite in these words: "Run backtests, A/B tests, and unit tests in one click to validate existing and new risk models." They also describe an alert prioritization model: "Prioritize alerts based on their significance and potential risk, facilitating response management." Prioritization, as described there, sets the order in which alerts are worked; it is not a way to suppress them.

Frequently asked questions

Why do AML transaction monitoring systems generate so many false positives?

AML transaction monitoring systems generate many false positives because they apply static thresholds to very different customers and send alerts with little context attached. Rules also accumulate over time and are rarely retired. Segmentation and context reduce the noise without lowering coverage.

What is below-the-line testing in AML?

Below-the-line testing in AML samples activity that falls just under a new or changed threshold, to confirm that nothing suspicious stopped alerting because of the change. It is paired with above-the-line testing, which checks that the alerts that remain are productive. Together they show an examiner that typology coverage held.

How do you defend an AML threshold change to examiners?

You defend an AML threshold change with a written record of what changed and why, the population and period tested, the above-the-line and below-the-line results, the typologies confirmed as still covered, and who challenged and approved the change. Post-change monitoring and periodic re-testing complete the record.

Does reducing false positives create model risk obligations?

Reducing false positives can create model risk obligations when the change touches a model, such as a scoring or segmentation model. The revised model risk guidance (SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026) expects testing, validation and monitoring, and governance for model changes. Whether a simple deterministic rule counts as a model is a reading of the guidance's definition that the institution's model risk function should make.

Can AI agents reduce AML alert workload while keeping human sign-off?

AI agents can reduce AML alert workload while keeping human sign-off by preparing each review, gathering evidence and recommending a disposition that an analyst confirms or overrides. The agent runs on every alert in a configured queue and routes missing data to manual review. Agentic AI is outside the scope of the revised model risk guidance, so the institution's own governance sets how agent recommendations are checked.

Fewer false positives come from better context and from changes that are tested and documented. A higher threshold removes coverage along with the noise. Every tuning change needs below-the-line evidence that typology coverage held, and a person who signs it off. To see how segment-level tuning, testing and a per-decision audit trail fit together, read about AML transaction monitoring for banks, or ask for a walkthrough on your own historical alerts.