Reducing AML false positives

Plain language meaning

Reducing AML false positives explains how AI can help banks prioritise suspicious activity alerts, suppress weak noise, group related behaviour and support investigators without weakening risk-based monitoring, SAR judgment, independent testing or audit evidence.

This topic is about AML alert quality and investigator effectiveness. It is not about using AI to avoid regulatory obligations or automatically decide that activity is not suspicious.

In a real bank, this topic cannot be handled as a loose data-science or technology idea. It affects customer outcomes, fraud and AML control, operational queues, service continuity, privacy, security, model governance, audit replay, management reporting and regulatory confidence. AI should improve speed and quality, but the bank must still prove source data, permitted use, approved logic, human accountability, fallback handling and retained evidence.

Where it sits in the banking AI journey

This card belongs to Business Impact and Controls. The working flow is Monitoring alert, AI prioritisation, Investigator review, Disposition decision, and SAR and feedback evidence.

Read the flow as a bank operating model. Each stage needs a source system, a data owner, a timing rule, a quality gate, a model or rule boundary, an exception path, a customer-impact view, a fallback option, a monitoring requirement and a retained record. That is what separates useful AI adoption from uncontrolled automation.

Banking data and evidence

The important data points are alert scenario, customer risk rating, transaction pattern, counterparty, historical alerts, investigator note, SAR decision, and false-positive label. These items matter because they can influence risk scoring, operational repair, fraud action, AML triage, customer treatment, reporting, model monitoring and management decisions.

The evidence pack should include alert queue, priority score, case narrative, disposition code, SAR support, tuning paper, and independent test report. A strong bank can replay the journey from source data to transformed input, AI output, rule result, human action, system outcome and monitoring result. A weak bank only knows that a process ran and hopes the process was right.

Controls that make AI adoption safe

The core controls are scenario governance, risk-based tuning, case sampling, SAR escalation rule, independent testing, model validation, and management reporting. These controls keep the topic anchored to banking purpose, approved policy, data governance, model-risk expectations, operational resilience, customer fairness, privacy, security and auditability.

The practical design should define what AI may recommend, what it must never decide alone, which deterministic rule remains authoritative, who owns thresholds and overrides, how degraded service is handled, how customer harm is detected and what evidence is retained. Without that control design, faster AI can simply make weak processes fail faster.

Architecture and data-operation lens

Banking AI depends on the architecture around it. Storage, streams, feature definitions, training sets, model versions, thresholds, feedback labels and rollback paths must be governed before the bank relies on AI output. The model is only one part of the control chain.

A bank-grade design connects channels, source systems, core records, payment hubs where relevant, fraud systems, AML platforms, case tools, data platforms, feature stores, model-serving endpoints, policy engines, audit logs and management dashboards. It also records degraded operation, recovery actions and lessons learned.

Regulatory and governance lens

Federal Reserve SR 26-2, dated 17 April 2026, gives revised model-risk guidance for traditional models and non-generative AI models used by banking organisations, including development, validation, monitoring, change control and governance.

The Federal Reserve's 2026 model-risk guidance states that generative and agentic AI are outside that guidance, while broader bank risk-management and governance practices still need to control tools and processes not covered by the guidance.

NIST AI RMF 1.0 uses Govern, Map, Measure and Manage functions for AI risk management, and NIST AI 600-1 adds generative-AI risk actions for source grounding, content provenance, data protection, cybersecurity and human oversight.

FFIEC Architecture, Infrastructure and Operations guidance expects financial-institution technology environments to be governed, resilient, secure, monitored, documented and aligned to business risk, including emerging technologies such as artificial intelligence and machine learning.

BCBS 239 remains current for effective risk data aggregation and risk reporting, and the Basel Committee's January 2026 newsletter reiterates the importance of accurate, comprehensive and timely data capabilities in banks.

FFIEC BSA/AML examination guidance expects suspicious activity monitoring systems and supporting technology to be risk-based, explainable by management, independently tested where appropriate and aligned to the bank's risk profile.

FinCEN's 12 June 2026 Section 314(b) materials clarify information sharing for possible terrorist activity, money laundering and fraud-related specified unlawful activity within the statutory safe-harbor framework for participating financial institutions.

OFAC's Framework for Compliance Commitments describes sanctions compliance programme components including management commitment, risk assessment, internal controls, testing and auditing, and training.

Diagram walkthrough

Read the diagram from left to right as Monitoring alert, AI prioritisation, Investigator review, Disposition decision, and SAR and feedback evidence. It is a banking control map. The point is to show how data, AI or ML output, rules, human action, operational routing and audit evidence should connect.

Use it as a 30-minute study method. For each box, ask which system creates the data, which definition is used, which model or rule acts, what can go wrong, who can override it, how a fallback works, which customer or regulatory impact exists and what record proves the final state.

Most important mistake to avoid

The common failure is reducing AML false positives by suppressing alerts without proving risk coverage. The correct goal is better prioritisation and better evidence, not weaker monitoring.

The correction is disciplined scope. Keep the chapter anchored to banking purpose, prove the data path, make ownership visible, test failure behaviour, record the evidence and make the final outcome explainable without relying on memory, assumptions or developer-only knowledge.

A smaller queue is not the goal by itself

An AML monitoring system may produce many alerts that investigators close without escalation. A model can help prioritize or group them, but simply suppressing alerts lowers the false-positive count without showing that suspicious activity is better detected. The bank needs a defined alert population, investigation outcome and time horizon. Closed alerts are not automatically proven innocent, and an unreviewed suppressed event lacks a label. Evaluation should compare workload, typology coverage, quality of case evidence and missed-risk indicators, not only closure rate.

Imagine a bank uses an AI ranking layer on existing transaction-monitoring alerts. The ranking proposes a review order but does not erase the underlying rule trigger. Analysts can record why a case was escalated, closed or re-opened, with linked transactions and relevant customer context. The pilot compares investigator time, backlog age, high-quality escalations and review samples across the score range. A low-priority stratum should be independently sampled under an approved testing plan to look for blind spots. Sampling cannot prove zero misses, but it can reveal whether the ranking hides patterns.

A strong control design keeps the rule version, model version, score, reason inputs, queue position, assigned reviewer, disposition and later correction. New typologies or a changed customer mix may require fresh validation. A low false-positive percentage in one period may reflect a narrow population or a policy change rather than a better model. Threshold changes need approval, versioning and a rollback path if quality indicators worsen.

Test duplicate transactions, a missing customer link, delayed external data and an investigator overriding priority. Confirm that every case remains traceable and that mandatory escalation or reporting requirements are decided by responsible staff under applicable law. The FATF Recommendations provide international AML standards, but local implementation and institutional obligations differ. A ranking model is decision support, not a substitute for the bank's risk assessment or legal responsibilities.

Define a false positive in the workflow

An anti-money-laundering alert is a signal for review, not a finding that a customer committed a crime. A case closed without escalation is not necessarily a confirmed false positive: the investigator may lack evidence, the pattern may be low priority or the disposition taxonomy may be inconsistent. Before claiming that AI reduces false positives, define the alert population, outcome categories, review standard and observation period. Measure whether the bank improves useful detection and timeliness while reducing unnecessary work.

Machine learning can rank transaction-monitoring alerts, cluster related cases, improve entity resolution and assist analysts with source-linked summaries. These uses have different control boundaries. A ranking model can move cases within a governed queue; it should not silently suppress required alerts. A name-matching model can help prioritize possible matches, but mandatory screening and final dispositions follow their own rules. An assistant draft requires human verification of source evidence.

FATF has described both opportunities and challenges of new AML/CFT technology, including potential efficiency and false-positive reduction. BIS work on network analysis illustrates research potential, but a proof of concept is not a guaranteed outcome for a particular bank. A bank needs its own validation, privacy controls and operating evidence.

Map the alert lifecycle

Start with source transactions and customer data, monitoring rules, generated alerts, deduplication, model ranking, assignment, investigation, escalation or closure, and later intelligence. Record IDs and timestamps at each stage. One customer episode can trigger several rules and alerts. Counting each as an independent false positive may exaggerate workload; collapsing all into one case can conceal missed patterns. Define the case unit and linkage method.

Separate transaction monitoring from sanctions screening and fraud detection. They can share data and analytical techniques, but their legal, timing and disposition rules differ. A possible name match is not a confirmed sanctioned party. A fraud score is not an AML case outcome. A low statistical risk score must not override a mandatory hold or required investigation.

Review queue age matters. A model that reduces analyst touches by deferring low-ranked alerts can make the false-positive rate look better while leaving cases unresolved. Measure alerts created, assigned, reviewed, closed, escalated and still pending, with age and severity. Include cases outside model coverage and those handled under fallback.

Data and features

Transaction-monitoring features can describe value, frequency, direction, counterparties, product use, cash activity or deviations from customer history. Network features can identify links among accounts, entities and beneficiaries. Each requires point-in-time source records, typed relationships and a defined lookback. A weak customer merge can create a suspicious network that does not exist; a missed link can hide one.

Know which facts were available when the alert was generated. A later investigation note, confirmed relationship or case disposition cannot be used in the original ranking feature. Preserve event and availability times, source versions and feature validity. A label created by an analyst after reviewing the model score can be influenced by the model and should not be treated as independent truth without qualification.

Reference data changes too. Customer risk categories, product codes, country classifications and screening lists have effective and recorded dates. A current mapping backfilled into historic alerts can produce leakage. For live ranking, stale source or reference data should trigger an approved limited path rather than a fabricated low score.

Label limitations

Historical case closures are useful but imperfect labels. Analysts have different workloads and experience, rules change and investigations can end without external confirmation. A suspicious-activity report or escalation is a process outcome, not proof that the underlying activity was illicit. A model trained to predict escalation may learn past operational patterns, including inconsistent review or resource constraints.

Define a taxonomy: generated alert, duplicate, reviewed benign explanation, unresolved, escalated, reported, reopened and confirmed external outcome where available. Version definitions and preserve source evidence. Sample cases to check disposition quality and agreement among reviewers. If a workflow change adds a new closure code, a model-performance chart should not interpret the shift as changed customer risk.

Low-ranked cases may receive less review, creating selective labels. If the model is used to prioritize cases, confirmed useful outcomes become concentrated in the high-ranked group. Periodic governed sampling of lower-ranked alerts can challenge blind spots. Report sampling method and uncertainty. Do not assign unreviewed alerts a benign label.

Define useful metrics

Precision among reviewed alerts can show analyst yield, but it is sensitive to which cases were selected for review. False-positive rate requires a credible definition of the negative population, which may be unavailable. Report case volume, proportion closed with a documented benign explanation, escalation yield, time to disposition, oldest case, high-severity coverage and outcomes from sampled lower-priority cases. Give denominators.

Measure workload in analyst hours, not only alert count. A model can reduce duplicate cases or help prepare evidence, saving time even if the number of alerts stays constant. A summarizer may make cases faster to review but should not be credited with fewer false positives unless the classification or disposition quality actually changes. Monitor reviewer corrections and unsupported generated claims.

Effectiveness is a guardrail. A sharp reduction in alerts is not success if serious activity is missed. Evaluate known typologies, red-team or synthetic scenarios where suitable, investigator challenge and sampling of unreviewed populations. Historical labels are incomplete, so disclose what the tests can and cannot prove. The objective is timely, well-supported detection with manageable noise.

Ranking model

A ranking model can order alerts by predicted investigative value. Define the target and capacity: does it prioritize likely escalations, severe potential harm or cases needing urgent action? These can diverge. A fixed top-N queue will behave differently when total alert volume changes. A score threshold can overload analysts during a new pattern. The policy should define aging, escalation and review of low-ranked cases.

Validate on later periods and separate related customers or networks across training and test where appropriate. A random row split can leak near-duplicate alerts. Check performance by product, channel, geography and customer type under privacy and legal governance. Inspect false negatives and source coverage, not merely a global ranking metric.

Record model score, feature state, rank, policy version, assignment and final case action. A human investigator needs source evidence and uncertainty, not an unsupported accusation. An override can reflect new information or policy. Do not feed every override directly into retraining as ground truth.

Entity resolution

Duplicate alerts can arise because the same customer or counterparty appears under several identifiers. ML-assisted entity resolution may combine aliases, accounts and legal entities. False merges can implicate an innocent customer; false splits can hide a network. Use typed relationships, source provenance, confidence and effective dates. High-impact ambiguous matches should receive review.

Measure match precision and recall on a representative, hand-checked sample, including non-Latin names, transliteration, joint accounts and acquired portfolios where relevant. Check downstream alert and case effects. A model that reduces duplicate alerts by aggressively merging entities can lower workload while missing distinct parties. Validate the intended use and provide a correction route.

When a mapping error is found, reverse lineage should identify alerts ranked or grouped using it. Correct source relationships, recompute analytical views and review actual case dispositions. Do not rewrite the historical record as though the corrected identity was known at the time.

Network analysis

Network features can reveal activity spread across accounts and institutions, but their edges have different meaning. An observed transfer is not the same as a suspected beneficial-ownership link. Use edge type, direction, time and confidence. A graph model trained on investigation outcomes can inherit the bias of which networks were investigated. Test sensitivity to uncertain links.

Privacy and data-sharing rules constrain collaborative analysis. BIS Project Aurora explored network and privacy-enhancing approaches in a proof of concept; a bank considering similar ideas must assess its own permissions, data quality and operational design. Do not assume that pooling data or using a graph automatically reduces false positives in production.

A graph snapshot can be stale. A real-time alert rank based on yesterday's graph should carry that timestamp. A source migration that changes entity keys can alter centrality and neighborhood features. Monitor and validate around such changes. A technically successful graph computation is not proof of correct relationships.

Analyst assistance

A retrieval or generative assistant can summarize transaction history and cite policy or case evidence. It may reduce reading time, but it can omit a contradictory transaction or invent a rationale. Preserve source links and require review for consequential case dispositions. A generated draft should be distinguishable from the analyst's final narrative.

Measure time saved, citation accuracy, correction frequency and case quality. Do not infer AML false-positive reduction from faster drafting alone. If an assistant makes closures easier than escalations, it could bias dispositions. Sample both closed and escalated cases for evidence quality.

Restrict sensitive case data in prompts, logs and vendor flows. An AML case can contain confidential investigative information and third-party relationships. Apply purpose-based access and retention; a general engineering dashboard should not expose full narratives. Test prompt injection in untrusted payment references or retrieved documents.

Sanctions-screening distinction

Name screening often produces possible matches requiring disposition. ML may help prioritize or explain match features, but the bank's screening obligations and approved controls determine action. A low model score cannot automatically clear a true mandatory match. Evaluate name variation, transliteration, dates, aliases and source-list versions on governed test cases.

Measure possible-match volume, analyst workload, disposition time and independently reviewed misses. A "false positive" in screening has a different definition from a transaction-monitoring alert closed without escalation. Keep metrics separate. If a list update causes a spike, first examine reference version and matching rules before retraining a model.

An external screening vendor may change its matching algorithm or list feed. Version response and list state, test against known examples and preserve audit evidence. A technical timeout needs an approved hold or limited path. The model's availability is not a substitute for compliance continuity.

Controlled pilot

Choose a bounded alert class with consistent source data and enough historical cases. Build point-in-time features and document label uncertainty. Compare current prioritization with a candidate in shadow, including the full alert population and low-ranked sampling. Review cases where rankings diverge. Establish analyst capacity and high-severity coverage before a live pilot.

During a bounded rollout, monitor alert creation, model coverage, invalid inputs, queue age, reviewer hours, closure reasons, escalations and sampled misses. Keep mandatory rules and case-retention controls. Predeclare stop conditions such as lost alerts, unacceptable backlog, source staleness or serious missed cases. A pilot should not report a false-positive reduction by excluding cases from its denominator.

After outcomes mature, compare like-for-like cohorts and disclose changes in alert rules, customer mix and staffing. Report both efficiency and effectiveness. If the model helps reviewers find useful cases sooner without reducing total alerts, that may still be valuable; call it prioritization rather than false-positive elimination.

Incident and fallback

Suppose a customer-master update falsely merges two businesses. Network features and alert ranks change, while the model endpoint is healthy. A mapping-quality alert or analyst report should trigger investigation. The bank can route affected alerts through an approved conventional queue, correct the mapping and identify cases whose rank or disposition was affected. Preserve original evidence and review actual outcomes.

If the ranking service is unavailable, underlying alert generation should continue. Operations use an approved queue order, track age and escalate capacity limits. When the service recovers, do not drop or duplicate cases. Reconcile the alert population across generation, model, case assignment and disposition. A late score should not silently close an already reviewed case.

Independent review

Sample a high-ranked escalation, a low-ranked closed case, an unreviewed alert, an entity-resolution correction and a model fallback. Reconstruct source facts available at ranking time, feature and model versions, policy and human action. Ask whether the later disposition is a reliable label and whether any required alert was suppressed. Query the full affected population for a simulated mapping defect.

Reducing AML false positives responsibly means analysts spend less time on weak or duplicate signals while serious cases remain visible and are investigated in time. The bank must show both sides with traceable decisions, representative review and honest limits on ground truth.

Primary reading: FATF digital transformation of AML/CFT, BIS Project Aurora and Basel AML/CFT guidance.

A numeric queue example

Suppose monitoring rules generate 20,000 alerts in a month. Investigators can fully review 12,000 within the required operating window. The current workflow deduplicates 2,000 alerts into related cases, leaving 18,000 case items. A model ranks them, and operations assigns 10,000 for immediate review while 8,000 follow a governed lower-priority path. Reporting "10,000 fewer false positives" would be wrong: the 8,000 lower-priority cases have not been proven false. The bank should report alerts, duplicates, reviewed cases, pending cases, age and dispositions separately.

Among the 10,000 reviewed, 600 are escalated and 9,400 closed under documented reasons. Some escalations later prove unsubstantiated; some closures may be revised. A precision calculation using 600 divided by 10,000 is an investigative yield under that workflow, not the true prevalence of illicit activity. If the model changes who gets reviewed, comparing that yield with the prior month's raw figure can mislead.

A random or risk-stratified sample of lower-ranked cases can help estimate missed useful cases. The sampling scheme must be recorded: probability, selection criteria, review depth and follow-up. If 20 of 400 sampled cases merit escalation, do not simply multiply 5 percent by all unreviewed cases without considering strata and uncertainty. The result should prompt investigation of model blind spots and queue policy, not a fabricated exact count of undetected crime.

Duplicate reduction versus suppression

Grouping alerts from the same underlying episode can reduce redundant analyst work. For example, a series of transfers may trigger value, frequency and geography rules. A case graph can link them while retaining every original alert and rule hit. An analyst sees the episode once with all source events. This is different from deleting the alerts. The bank should be able to unpack the group and show why each alert belonged there.

False merges can be serious. Two businesses with similar names may be grouped incorrectly, concealing distinct behavior or exposing one customer's information to a reviewer of another case. Validate entity and episode matching on hand-reviewed samples, including rare naming patterns and acquired portfolios. Record confidence and human correction. A change in grouping algorithm can alter workload metrics without changing actual risk.

If a duplicate rule is deterministic and reliable, use that simpler control. ML may add value for ambiguous relationships or complex patterns, but it must show incremental benefit and manageable error. Compare group-level review time, missed independent cases and analyst corrections. A lower raw alert count from aggressive grouping is not itself proof of higher effectiveness.

Human capacity and case quality

An AI rank can improve allocation of scarce analyst time if high-value cases rise early. Define what "high value" means: urgency, potential severity, likelihood of a useful investigation or a mandated deadline. A case with low predicted escalation probability can still be urgent under a mandatory rule. Policy constraints should govern assignment before statistical ranking.

Reviewers need evidence and a route to challenge the rank. Show source transactions, entity links, feature validity and uncertainty. A case worker should not be forced to accept a generated narrative that omits contradictory facts. Capture overrides with reasons and sample them for quality. An override may reflect new information, not model error.

Track analyst hours per case, time to first action and time to disposition. A model can lower apparent false-positive count by making closure faster but less thorough. Quality assurance should inspect sampled closures and escalations against source evidence. Monitor reopened cases, corrections and supervisory findings. A workload gain is valuable only when the control remains effective.

Training-data selection

Historical alerts are generated by old rules. A model trained only on them may not detect suspicious patterns outside those rule boundaries. It may still be useful for prioritizing the governed alert population; do not claim it replaces detection of unseen activity. Candidate typologies require separate development and evaluation. Compare to current rules and keep scope explicit.

Training labels reflect which alerts were investigated, how deeply and under what policies. Use time-aware splits and group related entities to avoid near-duplicate leakage. Inspect changes in rule sets and reviewer taxonomy. A model that predicts historical escalations might reproduce inconsistent analyst practice. Independent domain review and low-ranked sampling are needed to challenge that feedback loop.

Validate source coverage. If one product's transactions are delayed or a customer mapping fails, the model can rank cases with incomplete evidence. A low score under missing network features should not be treated as safe. Use validity flags and an approved fallback. Report model coverage and invalid-input cases by product and source.

Measuring improvement fairly

Construct a baseline period with alert rule versions, product mix, staffing, case taxonomy and maturity. Compare a candidate on the same eligible cases in shadow, then a bounded live use with documented changes. Report analyst hours, queue age, escalation yield, sampled low-ranked misses and case quality. A rise in escalation yield can reflect better ranking or a changed review population; state the distinction.

Where possible, use matched cohorts or a governed controlled rollout. But mandatory controls and high-severity cases should not be withheld for experimentation. Shadow scoring avoids changing actions but cannot measure all behavioral effects of a new queue. A live pilot needs stop conditions for lost alerts, serious misses, backlog and data validity.

Avoid a single savings figure based on multiplying "fewer alerts" by average review minutes. If alerts are grouped, remaining cases may be more complex. If AI summarizes evidence, review time may fall without case count changing. If low-ranked cases are deferred, workload is postponed, not eliminated. Measure actual completed work and the risk of the pending population.

Source and model change

A new payment product or customer segment changes alert distribution. A reference-table update can change country or entity-risk features. A screening-list update can increase possible matches independently of transaction-monitoring models. Monitor source and rule versions beside model scores. Diagnose shifts before lowering thresholds or retraining.

When a model is updated, test the full workflow: alert generation, deduplication, ranking, assignment, review and final case state. A candidate may rank well offline but overload one specialist team. Compare tail queue age and mandatory coverage, not only mean precision. Record which cases used each model and policy version. A rollback should preserve every case and its action history.

An assistant or extraction model has separate versions for prompts, retrieval corpus and source documents. A new prompt can change analyst summaries without changing alert scores. Audit citation and factual quality after updates. A model's fluent output should not be counted as a confirmed case conclusion.

Privacy and collaboration

AML investigations can involve sensitive transaction networks and third parties. Limit model and analyst access by purpose, log retrieval and protect training extracts. A cross-institution analytics project requires its own legal, contractual and technical assessment. Research demonstrations do not establish permission to pool identifiable customer data.

Privacy-enhancing methods can reduce exposure in some collaborative designs, but they have limitations and need validation. A federated model or encrypted computation does not fix poor source labels or ambiguous entity matches. Evaluate the actual system's information leakage, detection performance and operational controls. Keep customer and institution boundaries visible in lineage.

Generated case summaries should not copy full narratives into broad telemetry. Use protected references and authorized drill-down. If a source record is corrected, identify affected rankings and cases while preserving the original decision context under applicable retention rules.

Case review drill

Create a test set with a duplicate pair, two similar but distinct entities, a high-severity low-score alert, a model timeout, a late source transaction and a case reopened after closure. Trace each from rule hit to final disposition. The duplicate pair should remain visible as two original alerts in one case; the distinct entities should not merge. The high-severity case should follow mandatory escalation regardless of rank. The timeout should invoke the approved queue policy.

After a customer-mapping correction, reverse lineage should enumerate alerts and rankings that consumed it. Compare original and corrected features, then review actual case decisions. A later analytic change should not erase the prior evidence. Reconcile alert, case and disposition counts before declaring the incident closed.

Reporting to management

Present a table with total source transactions, rule-generated alerts, duplicates grouped, unique cases, model coverage, reviewed cases, pending cases by age, escalations, sampled lower-priority findings and analyst hours. Include rule and model versions and source-quality exceptions. Define every denominator. Trend the measures over equal maturity windows and explain changes in staffing or policy.

State the conclusion narrowly. If ranking reduced median review time and raised escalation yield without increasing sampled misses, say so with the study's limits. If a model suppressed alerts, describe the authorization and evidence for that change separately. If labels are too weak to estimate missed cases, report the uncertainty rather than calling every closure a false positive. This preserves the purpose of AML AI: more effective, timely investigation with accountable use of scarce attention.

Final acceptance record

Before release, have compliance define mandatory coverage, acceptable backlog and escalation. Have analysts review representative high, middle and low-ranked cases with source evidence. Have model validation challenge labels, time leakage, entity resolution and segment effects. Have operations demonstrate fallback with a failed ranker and a delayed source feed. The case system should reconcile every generated alert to a grouped case, pending item or documented disposition.

After a bounded pilot, repeat the same sample review and measure actual hours and queue age. Identify any alert that disappeared between rules and cases, any mandatory case delayed by ranking and any unsupported assistant narrative. Investigate rather than average them away. A handful of serious misses can matter more than a large aggregate reduction in routine closures.

Record the approved model, feature, rule and policy versions with an affected-case query. If a customer mapping is corrected later, the bank should locate every rank and case it influenced, preserve the original review and determine whether a new investigation is needed. This traceable correction path is part of the outcome, not an optional audit extra. Include cases still pending at the reporting cutoff and revisit them at a stated date, rather than counting them as false positives. Document the review depth and selection method for sampled low-priority alerts. Without those details, a sample cannot establish whether serious cases were missed.

Queue denominator exercise

Monitoring rules generate 10,000 alerts. A grouping process links 1,000 duplicates to existing cases, a ranker prioritizes the remaining population, and analysts review 6,000 within the period. The 3,000 lower-priority pending cases are not proven false positives. Report generated alerts, grouped cases, reviewed and pending cases, queue age, dispositions and sampled low-ranked outcomes with clear denominators.

Hand-check one high-ranked escalation, one low-ranked case and a false customer merge. Preserve rule hits and source evidence after grouping. A mapping correction should trigger reverse lineage to affected ranks and case decisions. If ranking fails, alert generation continues and an approved queue order applies. This demonstrates workload improvement without suppressing mandatory monitoring or treating an unreviewed alert as harmless. Sample the pending group under a documented selection method and review depth. Report uncertainty around missed useful cases, not a fabricated exact false-positive count. Verify that high-severity rules retain precedence over the model rank and that an alert is never lost during grouping or fallback.