Why FinCEN's 2026 NPRM Rewrites AML Transaction Monitoring

Almost every bank and most regulated firms under FATF-aligned supervision run a transaction monitoring system, score hundreds of thousands of transactions against threshold controls, file suspicious activity reports on the statutory clock, and pass their AML examinations with the controls marked "in place". And yet Europol's own figures put the proportion of those reports that law enforcement actually acts on at roughly ten percent, while the industry's accepted false-positive rate on the alerts generated by those transaction monitoring systems hovers around ninety-five percent (10)(12)(13). The comfort on offer is procedural: the engine ran, alerts fired, transactions were flagged, SARs were filed. The failure is substantive: the intelligence product is thin.

That gap — process followed versus outcomes achieved — is the gap FinCEN's 7 April 2026 Notice of Proposed Rulemaking was built to close (1). It is also the gap this article examines: how rule-driven AML transaction monitoring got here, why the 95 percent figure is a data-model problem rather than a vendor-selection problem, and what changes about the supervisory question when the regulator formally shifts the test from "did you run the controls" to "did the controls identify the right transactions". The UK Money Laundering Regulations 2017, the US Bank Secrecy Act and the EU's AMLR Article 26 are converging on the same answer, and the NPRM is the clearest regulator-issued articulation of it so far. We come at the problem from the architectural side. Transaction monitoring is only as good as the evidence base it operates on; if that evidence base is built from redundant copies of raw identity documents that the monitoring system then scores transactions against, specificity does not rise with throughput. That is the ground a Zero-Knowledge KYC identity layer occupies upstream of the monitoring stack, and it is the ground we have built Verifyo around.

What AML transaction monitoring is, and why definitions matter for the argument

Transaction monitoring is the control that sits between customer due diligence, which happens at onboarding, and suspicious activity reporting, which happens when a pattern triggers. Its job is continuous. A compliant programme does not check the customer once at onboarding and then leave the relationship unobserved; the transaction monitoring system watches the stream of transactions over the life of the relationship and flags the transactions that look inconsistent with what the institution already knows about that customer. This is why monitoring is always framed in the statutes as "ongoing" — the word carries weight, and the rest of the architectural argument depends on it.

We use a compact, non-glossary framing because the SERP is already saturated with "what is transaction monitoring" explainers and because the mechanism, not the definition, is what produces the rest of this analysis. AML transaction monitoring is the mechanism by which a financial institution continuously scores the transactions of an existing customer against the institution's compliance view of that customer, and escalates exceptions to a reportable threshold under the applicable suspicious-transactions regime.

The statutory frame: FATF Rec 10, EU AMLR Article 26, 31 CFR 1020.320

Ongoing monitoring is not an optional piece of architecture. Firms operating under the UK Money Laundering Regulations 2017, the US Bank Secrecy Act and the EU's AMLR Article 26 share the same statutory frame: the regulatory requirements converging across those jurisdictions all anchor to ongoing monitoring of the business relationship, and FATF Recommendation 10 is required in every FATF-aligned jurisdiction where obliged entities file suspicious activity reports. The statutory frame includes an explicit SAR obligation at 31 CFR § 1020.320, an ongoing-monitoring obligation at FATF Recommendation 10, and a codified equivalent at EU AMLR Article 26. FATF Recommendation 10 requires "ongoing due diligence on the business relationship and scrutiny of transactions undertaken throughout the course of that relationship to ensure that the transactions being conducted are consistent with the institution's knowledge of the customer, their business and risk profile, including, where necessary, the source of funds" (4). The EU's AMLR codifies the same obligation at Article 26(1): "Obliged entities shall conduct ongoing monitoring of business relationships, including transactions undertaken by the customer throughout the course of a business relationship, to ensure that those transactions are consistent with the obliged entity's knowledge of the customer, the customer's business activity and risk profile" (8).

In the United States, 31 CFR § 1020.320 — the BSA implementing regulation on reports by banks of suspicious transactions — fixes the downstream obligation: "A bank is required to file a SAR no later than 30 calendar days after the date of initial detection by the bank of facts that may constitute a basis for filing a SAR" (9). Three jurisdictions, one obligation: watch the relationship, scrutinise the transactions, file the report when the pattern warrants. That is the legal baseline on which every operational choice sits.

The operational frame: ingest, score, alert, investigate

Operationally the transaction monitoring process runs as a real-time transaction monitoring pipeline in four types of step — ingest, score, alert, investigate — and the engine must provide an auditable output at each step. The transaction monitoring process the FinCEN NPRM tests for effectiveness begins with the transactional data the engine ingests — identity attributes of the parties, counterparty details, geography, device and channel signals. The rules the engine applies encode the institution's risk appetite in executable form, and the transactional data feeding the scoring step carries the evidence those rules test against. The engine then scores each transaction against a library of monitoring rules that encode amount thresholds, velocity signatures, structuring typologies, layering patterns, and watchlist-proximity flags; the scoring step identifies transactions whose signatures deviate from the established profile and flags them for investigator review. When a rule fires, the system generates an alert on the flagged transactions and routes it to an investigator who either closes the alert as non-suspicious or escalates to a SAR. Anti money laundering controls higher up the stack — CDD, sanctions screening, adverse-media screening — feed the reference data that the scoring step relies on. Every later claim about alert yield in this article refers back to this pipeline, which is what makes the definitional detour worth the paragraph it takes: each of the architectural failures we examine lives at a specific step of the process, and naming the steps lets us name the failure exactly.

The failure mode: why rule-driven monitoring generates 95 percent false positives

This is the diagnostic spine. The AML transaction monitoring systems most banks run today combine rule based logic on amount and velocity with behavioural scoring on transaction activity, and structurally produce alert populations of millions of transactions per month that outpace investigative capacity. The 95 percent false-positive figure that the transaction monitoring industry argues about is not a vendor-selection problem but a data-model problem. The more raw records the engine ingests, the more thresholds it can fire transactions against; specificity does not rise with volume. Criminals know the velocity thresholds; the methods they use shift faster than the rules library can update. A transaction monitoring system that holds the customer's entire document file across multiple ingestions cannot distinguish between meaningful signal and duplicated document metadata — the engine has no way to tell the two apart from inside the scoring step, and laundered transactions and legitimate transactions arrive at the investigator queue carrying the same weight. Money laundering intelligence therefore plateaus not because the engine is wrong but because the evidence it operates on is dense, inconsistent, and under-specified. Funds moving through correspondent relationships trigger the same types of alerts as ordinary commerce, and complex layering typologies produce signatures indistinguishable from routine activity once the reference row is thick with document copies. Criminals who know the velocity thresholds are creating alert populations the second line cannot clear.

The 95 percent false positives figure and the suspicious activity reports gap

The headline number — that 90 to 95 percent of alerts generated by AML transaction monitoring systems resolve as false positives on the transactions flagged by the engine — is widely attributed to a PwC industry report and reprinted consistently across trade press covering transaction monitoring (12). It is a useful directional figure but a shaky sole citation, which is why we always pair it with the Wolfsberg Group's 2024 statement on effective monitoring for suspicious activity: "The Group does not believe that the value being derived from the constantly increasing volume of SARs/STRs is contributing proportionately to effective outcomes in the fight against financial crime" (10). An increase in alert population does not produce a proportionate increase in useful intelligence, and the red flags the scoring step surfaces are only as specific as the reference row allows. Europol's figures on the output end of the pipeline corroborate the mechanism: only around ten percent of suspicious activity reports and suspicious transaction reports filed across the EU financial intelligence regime are further investigated by competent authorities (10)(13). The Europol report is explicit that volume is not the bottleneck — utility is. Making the evidence base thicker does not produce better signal — the engine is still scoring structured deposits against a velocity rule it cannot re-calibrate without richer identity context. Cash transactions below the reporting threshold, layered transfers across accounts to evade CTR filing, and deposits that form the SAR pattern all surface as undifferentiated alerts on the same thin reference row. The number the industry argues about is not the real problem. The data model producing it is, and the transactions the engine can actually identify as suspicious are the ones where the upstream evidence carried discriminating signal.

Parameters, thresholds, and the evidential basis for HSBC £63.9m

The Financial Conduct Authority's £63.9 million fine on HSBC in December 2021 is the cleanest supervisory articulation of where this data-model problem lives in practice. The operative sentence from the Final Notice is precise: "HSBC failed to appropriately test and update the parameters within the systems that were used to determine whether a transaction was indicative of potentially suspicious activity" (6). For instance, the red flags the HSBC engine surfaced did not tie back to the typologies the institution's own assessment had identified, and the parameter-testing finding showed the engine firing on simple amount thresholds while complex layering signatures went undetected. The mechanism insight is not that HSBC's engine was wrong in the abstract; it is that HSBC could not evidence that its transaction monitoring system continued to identify the transactions the risk assessment actually cared about over the eight-year review window. When a bank cannot evidence its parameter-testing discipline, it cannot evidence that its scoring step addresses the types of money laundering typologies the institution identified — and that is the supervisory failure the FCA priced at £63.9m.

Starling Bank's £29m fine in October 2024 is the second tell. The FCA's press release pulls no punches: "Starling's financial sanction screening controls were shockingly lax. It left the financial system wide open to criminals and those subject to sanctions" (7). The architectural point is slightly different from HSBC: the hole was in the upstream screening control rather than in the scoring step itself, but the consequence landed in the same place. Neobank-scale screening had collapsed across a population of 54,000 high risk accounts flagged by the screening controls, and the activity consistent with laundered-proceeds patterns went undetected despite automated systems being in place. Transactions the engine should have flagged were not flagged; transactions that should have surfaced as the relevant activity were not detected; money routed through high-exposure corridors moved cleanly because the reference file the engine scored transactions against was not fit for purpose. More relationships, more records, more transactions scored — same financial crime enforcement logic applied.

AI and machine-learning approaches do not escape this data-model ceiling. The Bank of England and FCA's Machine Learning in UK Financial Services report — a joint regulator survey of AI adoption across the sector — finds that anomaly-detection models, graph-analytics tools and entity-resolution solutions are being layered onto rule-driven monitoring systems across the sector (11). The report is explicit that data quality, not algorithm choice, is the governance frontier. The AI layer is asked to identify unusual patterns the threshold controls miss, and surfaces anomalies that rule-driven logic cannot encode. The anomaly-detection and graph-analytics technologies the sector now layers on top of rule-driven engines consume the same upstream identity evidence the legacy engine does. Fraud models face the same data-model ceiling as AML models — both consume the same upstream identity evidence. Artificial intelligence cannot manufacture specificity that was never in the reference row; it can only surface transactions — laundered or legitimate — that the engine already had visibility into. Each component of the stack ingests the same reference layer. AI-assisted monitoring raises the ceiling marginally. It does not remove it. The failure mode is upstream of the algorithm, in the evidence layer the algorithm ingests, and the transactions AI can identify as anomalies are the transactions the underlying evidence was already able to distinguish.

Threshold-driven monitoring is not broken because the engine is wrong. It is capped because the evidence base it operates on is built out of copies of raw documents moving between systems, not out of attestations that carry discriminating signal natively. More data, worse signal.

Why the FinCEN 2026 NPRM is the regulator catching up

Regulators across the FATF-aligned jurisdictions are converging on the effectiveness question, and FinCEN's 7 April 2026 Notice of Proposed Rulemaking on AML/CFT programmes is the clearest articulation of that shift on the US side. It is the topical anchor for everything in this article, and it is the document compliance leaders evaluating transaction monitoring posture in 2026 have to read first. The operative sentence in the Federal Register publication is unambiguous: "FinCEN is proposing a rule to fundamentally reform the requirements for financial institutions' AML/CFT programs … to ensure that financial institutions establish and maintain effective AML/CFT programs that better achieve the purposes of the BSA and lead to more effective outcomes for financial institutions as well as law enforcement and national security agencies" (1). The comment window closes on 9 June 2026. The accompanying Fact Sheet (2) and the regulator's Key Changes memo (3) frame the reform as a new programmatic framework — language that formalises what Wolfsberg already said in 2024, which is that the effectiveness gap is the product, not a bug in individual deployments.

The proposed rule, verbatim

We take the Federal Register text at face value because the choice of verb in the Key Changes memo matters: the NPRM "define[s] a new framework for 'effective' AML/CFT programs and implement[s] certain other reforms to core programmatic requirements" (3). The word sits inside quotation marks in the regulator's own language — the drafters are telling supervised institutions that it is doing work in the rule. The NPRM replaces the legacy AML programme regulatory requirements with a principles-grounded effectiveness standard; a programme that produces well-documented alerts at a high throughput but thin investigative yield is no longer the thing the regulator wants to see. A programme that produces fewer, better-calibrated alerts on transactions that actually move to SAR, and then to investigation by law enforcement, is.

What effectiveness replaces, and why the timing matters

The NPRM does not retire specific anti money laundering rules. It changes the supervisory question. Under the old regime a bank examiner asked whether the institution had documented its controls, deployed them, and evidenced their operation — the compliance-as-documentation frame organisations have operated under for twenty years. The effectiveness evidence required by the NPRM shifts supervisory focus from "did you run the rules" to "did your programme produce useful intelligence", and the new regulatory requirements are outcome-shaped rather than process-shaped. Under the new regime the examiner asks whether the programme produced useful intelligence — whether the monitoring engine's output reached law enforcement in a form law enforcement could act on, whether the parameter-testing loop actually tightened the signal over time, whether the risk based approach at the top of the programme meaningfully shaped the transaction monitoring at the bottom. The firms subject to the NPRM will see the same shift, making outcome quality, not throughput, the standard the laws are enforcing. That reframes every line of the supervisory playbook, from parameter testing through SAR quality through the operating model of the three lines of defence.

FinCEN is not moving alone. The EU AMLR (Regulation (EU) 2024/1624) codifies ongoing monitoring at Article 26 with general application from 10 July 2027 (8), and AMLA takes up its direct supervisory mandate from the same date. The FCA's Financial Crime Guide already treats parameter testing as a supervisory expectation inside the UK handbook. FinCEN's NPRM is the third leg of a simultaneous, cross-jurisdiction pivot on aml compliance architecture — EU money laundering regulations converging on effectiveness, UK supervisors already testing parameter-testing evidence, and the US now codifying the same shift. Compliance leaders planning 2026–27 controls investment are planning against three converging expectation sets, not one — and the converging element is the effectiveness question, not a specific change of rule.

The risk-based approach: how FATF already asked for effectiveness

The effectiveness test is not new thinking. Regulators and standards bodies have been calibrating the same expectation for over a decade — the Financial Action Task Force (FATF) has asked banks to interrogate whether their rules identify money laundering and terrorist financing typologies across the full transaction monitoring population since the 2014 Risk-Based Approach Banking Sector guidance, and Recommendation 10 has required ongoing due diligence anchored to the customer risk profile for longer still (4)(5). The risk based approach is the frame inside which every monitoring rule sits, and the standards body has asked firms to interrogate whether their controls actually identify the typologies their assessment flagged. What changes in 2026 is supervisory appetite to enforce it. The US, the EU and the UK are collectively moving from "the rules exist, the standards expect you to interrogate them, we trust you have" to "show the working". That is a change of supervisory posture rather than a change of substantive standard, and it is why the NPRM reads like codification rather than reinvention.

FATF Rec 10 and the customer risk profile

Recommendation 10 puts the customer risk profile at the centre of the ongoing monitoring obligation: transactions must be "consistent with the institution's knowledge of the customer, their business and risk profile, including, where necessary, the source of funds" (4). FATF Recommendation 10 is mirrored in every FATF-aligned jurisdiction's AML regulations. The profile is the reference frame. If the profile is thin — built from stored document copies rather than structured attestations — every downstream monitoring decision inherits that thinness, and every alert the engine surfaces inherits the same under-specification. A rules engine cannot do better than the reference file permits, and a reference file built by copying documents across platforms does not improve the engine. Readers interested in how the framework composes on-chain will find the architectural walkthrough in risk-based AML framework.

FATF 2014 RBA guidance on automated systems

The 2014 Banking Sector guidance is even more direct on automated systems: "Where automated systems are used, banks should understand their operating rules, verify their integrity on a regular basis and check that they address the identified ML/TF risks" (5). Enhanced due diligence measures at the high risk tier are where the rule based approach composes with risk appetite — FATF asks firms to tighten the engine where the assessment says the exposure is concentrated, and enhanced monitoring obligations under FATF Recommendation 10 kick in at precisely that tier. Read alongside the HSBC Final Notice, the 2014 guidance is a regulator-issued instruction to do precisely what HSBC was fined for not doing — understand the monitoring rules, test them against the identified laundered-proceeds typologies (money laundering and terrorist financing, in the FATF's shorthand), and keep the check current. The failure mode is not news to the standards body. It is news to many deployments. And where those deployments touch jurisdictions or cohorts that carry concentrated exposure, the gap between process and outcome compounds every time the scoring step ingests another copy of the same under-specified reference row.

The identity-evidence layer: what monitoring actually operates on

Now the architectural pivot. Threshold-driven transaction monitoring is only as good as its evidence base, and today that evidence base is built from redundant copies of raw identity documents that the transaction monitoring system then scores transactions against — laundered activity and clean activity flowing through the same reference row. The document transfers every traditional KYC vendor performs produce evidence that is redundant across receiving systems and complex in scale but thin in signal. Every system the account holder touches stores its own full dossier. The monitoring system ingests feeds from that dossier. The "more records" framing that dominates industry marketing hides a specificity problem: the documents are substantially the same across ingestions, the metadata is inconsistent, and no two services' versions of the customer profile reconcile cleanly. This is the privacy-by-redundancy anti-pattern that every mainstream document-heavy vendor produces as a side-effect of its architecture, and it is why "more data, worse signal" is not a rhetorical claim but a direct data-model consequence — one that cuts across monitoring systems built around legacy rule libraries and monitoring systems built around newer anomaly-detection layers alike.

Privacy by redundancy: what every document-heavy identity vendor architecturally produces today

Sumsub, Onfido, Jumio, Veriff, Persona, Socure and Trulioo are the visible faces of the document-heavy KYC solutions class. Each of them, as a function of how its architecture is designed, transfers raw PII to each client platform that integrates them. That is a factual statement about architecture rather than an attack — the vendors do exactly what their integration contracts with receiving organisations promise. The receiving institution stores a copy. The monitoring system ingests from that copy. The next service onboarding the same individual repeats the process with a fresh document capture. The methods the monitoring engine scores against are the same methods the vendor's document-copy trail makes indistinguishable across entities. Fraud teams and AML teams both screen against the same evidence layer; criminals who know which document packs the vendor accepts are creating reusable evidence that the monitoring engine later scores, and every vendor transfer creates a new copy of the same reference row.

The account holder's identity is present in the wider financial system six or ten or fifty times, each copy slightly different, none canonical. For AML transaction monitoring at a specific institution, the ingested reference row carries whatever the vendor transferred, which is the full document file rather than a verified attestation. The monitoring engine then has to rebuild specificity inside the scoring step, and transactions it should identify as suspicious and transactions it should leave alone produce the same evidential trail — which is exactly where it cannot add specificity that was missing upstream.

Why more data is worse signal

The failure is informational, not computational. A rules engine cannot distinguish useful signal from duplicated document metadata; transactions moving illicit funds through layered relationships and transactions consistent with ordinary commerce produce the same evidential trail once the reference row is dense with document copies, and the duplicated metadata is structurally indistinguishable from a new observation. High risk relationships and lower-exposure holders both produce identical document-copy trails once the documents have moved through the vendor-to-platform pipeline. Funds laundered through layered structures trigger the same types of alerts as legitimate commercial deposits, and the types of evidence the monitoring system consumes cannot discriminate between them. In one instance the reference row carried five copies of the same passport, and the unusual structuring across deposits produced red flags that the investigator queue could not triage without re-interpreting the transactional data from scratch. Alerts on suspicious-activity signatures triggered at the scoring step therefore carry the same evidential weight whether the underlying holder is actually higher-exposure or not; the monitoring engine cannot identify transactions as suspicious without some way to distinguish them from activity the customer conducts legitimately, which is why the investigator queue clears the bulk of the flagged transactions as false positives. The aml transaction monitoring reference data is dense but under-specified, and the activity signatures it carries cannot tell illicit funds apart from ordinary commerce — the anomalies it surfaces are anomalies of document metadata, not anomalies of economic behaviour. Unusual transactional data should expose laundered flows; instead it is absorbed into the same undifferentiated reference row. It tells you what documents the account holder uploaded. It does not tell you what attestation the onboarding institution issued about them. That is the distinction the FinCEN NPRM is implicitly asking supervised financial institutions to make explicit: not more records, but evidence that the reference layer the programme relied on was fit to produce the outcome the programme claims.

A better evidence base does not mean more fields in the onboarding record. It means fewer fields that each carry a verified signal. The architectural question is whether the evidence layer feeding the monitoring system produces attestations or document copies — whether the reference row includes a verified position or a document dump. That is the ground a Zero-Knowledge KYC layer occupies — and it is the ground we have built Verifyo around.

Three lines of defence under an effectiveness regime

The three-lines-of-defence model was built around "the engine ran correctly". Under the FinCEN effectiveness frame, each line's scope shifts, and organisations operating mature transaction monitoring programmes have to rebuild each line's operating question against the new test. This section walks the first, second and third lines and names what changes, not as a checklist but as a reframing of the existing checklist. The transaction monitoring process keeps its four-step shape — ingest, score, alert, investigate — but the evidential question each line answers moves up a level. What the first line has to absorb, what the second line has to test, and what the third line has to audit all depend more explicitly on the quality of the evidence base than they did under the prior compliance-as-documentation frame. Each line's operating model now includes explicit evidence about the transactions the engine processed and the patterns it identified, about the transactions flagged and the transactions detected as part of a laundered-proceeds trail.

First line: front-office detection and the customer risk profile

First-line controls absorb the upstream customer risk profile from the onboarding system and translate it into transaction-level vigilance across the real-time transaction monitoring stream. The entities whose transactions the first line absorbs are the entities the effectiveness regime asks the front office to produce evidence about. Firms whose first-line controls were built for fraud-prevention workflows face a making-the-case problem — the first line must make each decision traceable rather than tick a box. Under an effectiveness regime, first-line teams need attestations they can act on, not document dumps they have to re-interpret at the point of use. Anchoring the first-line posture to FATF Recommendation 10's "consistency with the customer's risk profile" language (4) changes the operating question from "did we store the right documents" to "did the view we built from those documents actually reach the analyst". That is a data-flow question, and the answer depends on whether the evidence that moved downstream was a compact, signed position or a thick, ambiguous document bundle — and whether the first-line tools in front of the analyst surface the transactions worth investigating or bury them.

Second line: compliance, parameter testing, and the HSBC lesson

Second-line compliance owns the evidence that transaction monitoring actually addresses the institution's assessment. This is the ground the HSBC Final Notice fell on: parameter-testing was the missing control, not the firing rules (6). Parameter-testing is a continuous risk management discipline under the effectiveness regime — the second line tightening the rules the engine runs against emerging typologies, not a one-time process that can be ticked and forgotten. It evidences continuously that the transactions the engine flagged and the transactions it detected as part of a laundered-proceeds trail actually mapped to the money laundering typologies the assessment identified. Enhanced parameter testing across the funds-flow sample is the screen against the effectiveness standard. For example, the HSBC evidence bundle showed parameter changes tied to specific risk assessment decisions, and the Wolfsberg effectiveness framing asks each firm to document precisely that linkage. Under the new regime it is the structural evidence the supervisor will want to see — a live, empirical loop that ties each monitoring rule back to the typologies it was deployed against, re-runs when those typologies change, and documents the decisions to tighten or relax thresholds against the outcome data from actual laundered-funds investigations. The supervisor's question flips from "do you have parameter-testing procedures" to "does your parameter-testing evidence show the engine tightening the signal over time".

Third line: internal audit, suspicious activity, and the effectiveness dossier

Third-line internal audit will increasingly be asked to assess not only whether the controls operated as designed but whether the controls produced useful intelligence on suspicious activity. "Lead to more effective outcomes for financial institutions as well as law enforcement and national security agencies" is the FinCEN text (1), and audit is the function that has to evidence the outcome side. Any increase in alert volume raises the burden on the third line; the audit trail must tie flagged transactions back to suspected illicit funds and the typologies the assessment identified. Expect audit plans to run end-to-end: transactions ingested, alerts generated on flagged transactions, investigator dispositions, SARs filed under the 31 CFR 1020.320 "Reports by banks of suspicious transactions" regime (9), and the law-enforcement feedback loop where one exists — the through-line from flagged activity to reported case of illicit funds to downstream investigation. Criminals the effectiveness dossier is supposed to help catch are the ones whose patterns the first two lines missed; the third line must provide the audit trail that proves the gap was either closed or disclosed. Audit has to screen the alert population for escalation patterns that the parameter-testing loop should have surfaced but did not. The effectiveness dossier includes the transaction monitoring evidence that ties alerts to the money laundering typologies identified at the risk-assessment step and detected at the scoring step — a through-line from identified typology to detected activity to reported SAR. The dossier is the artefact that will carry a supervised institution through a BSA examination under the new frame — and aml compliance teams that start building it now will be better placed in 2027 than teams that wait for the final rule.

A Zero-Knowledge KYC evidence layer, upstream of monitoring

This is the earned architectural move. The positioning is explicit: we do not perform transaction monitoring, and Verifyo is not a transaction monitoring product. Verifyo builds the identity-evidence layer that monitoring systems and transaction monitoring solutions consume. The Zero-Knowledge KYC attestation gives the bank's or platform's transaction monitoring system a compact, verified signal — sanctions cleared, PEP cleared, criminal-record cleared, adverse-media cleared, identity bound to a specific wallet — without the raw document file that creates the privacy-by-redundancy problem at the upstream step. The engine then scores transactions against a thinner, higher-specificity evidence base than it does when every integrating system holds its own copy of the same documents, and transactions the engine flagged can be traced to a canonical reference row rather than a document dump.

Attestation, not document transfer

The mechanism is the attestation. A Verifyo attestation screens against PEP, sanctions, adverse-media, criminal-record and barred-persons sources, creates a wallet-binding attestation cryptographically tied to the onboarding event, and transfers only that verification status to the receiving platform — never the source documents. Attestation transfers, not document transfers: systems integrating Verifyo's API receive a verification status check, creating a verified position rather than a document dump. The proof is cryptographic, the reference row is canonical, and the onboarding event is bound to the wallet the customer will transact from. Attestations provide proof of status, not raw PII. Readers who want the deeper mechanism on how watchlist clearance composes inside a zero-knowledge envelope can follow the architectural walkthrough in sanctions screening in zero-knowledge, and the Travel Rule piece on counterparty identification is a neighbouring primitive in the same architectural family.

What the monitoring system sees, and why signal improves

When a receiving service's transaction monitoring engine ingests reference data from an attestation layer, the reference row is short, canonical, and cryptographically bound to the onboarding event. The technologies the receiving service runs — whether the transaction monitoring process is a rule-driven engine or an AI-layered stack — still score transactions against a reference row. Monitoring controls that previously had to adjudicate across inconsistent document copies now operate against a single, signed position. The false-positive yield improves not because the engine changed but because the reference data did — the scoring step is no longer being asked to reconstruct specificity that was missing upstream, and the transactions the engine can identify as suspicious are finally the transactions the evidence was built to discriminate. Attestations provide a through-line from assessment to alert to report that a stack of document copies cannot. That is the mechanism behind the architectural claim that better inputs produce better outcomes: the inputs are carrying more signal per byte, so the engine has more to work with at the same volume.

We do not run ongoing transaction monitoring. That is the job of the bank's or platform's own monitoring stack, or of specialist providers like ComplyAdvantage, Chainalysis, Unit21, Quantexa and Napier — the class of transaction monitoring solutions built for financial institutions that need engines, rulesets and alert-triage tools to process transactions at scale. The monitoring software the receiving service runs — whether it is a rule based engine or an AI-layered stack — still scores transactions against a reference row, and AML transaction monitoring systems built for the effectiveness regime benefit when that reference row carries signal rather than noise. Criminals whose document packs pass the vendor check but whose behaviour patterns fail the monitoring engine are exactly the cohort cleaner inputs help surface. The AML transaction monitoring systems the sector runs today are not short of rules; they are short of discriminating evidence, and legacy rule engines cannot manufacture specificity the reference row never carried. Our contribution is upstream of theirs — an identity attestation layer that gives those transaction monitoring solutions a cleaner input. FinCEN's effectiveness pivot is about outcomes; cleaner inputs are a precondition rather than the whole answer. The mechanism is narrow and worth stating plainly: if the evidence base is the bottleneck, the architectural answer is a thinner evidence base with more signal per field, not a thicker one — so that the transactions the engine identifies, the transactions it flags, and the transactions the investigator queue processes are the transactions actually worth processing.

What compliance leaders can do before the FinCEN comment window closes

The comment window closes on 9 June 2026. The challenges compliance leaders face between now and that date are not abstract. This closing section is not a checklist in the SERP-template sense — it is two directional recommendations for compliance leaders planning 2026–27 controls investment against the FinCEN NPRM, EU AMLR Article 26 (general application 10 July 2027), and the FCA Financial Crime Guide expectations already in force, plus a word on engaging with the NPRM itself. The connecting thread across them is the same connecting thread across the diagnosis: the control point has moved up the stack, from "did the rule fire" to "did the evidence the rule operated on carry the signal the rule needed".

The first move is to treat parameter testing as effectiveness evidence rather than as a compliance chore. Compliance teams have to learn to read parameter-testing as a risk management output, not a compliance chore — the HSBC lesson is that parameter testing has to document the rationale, not just the runtime. Link each parameter test to the specific risk assessment decision that drove the threshold choice, keep the loop live so the evidence bundle reads as effectiveness rather than as process activity, and document the transactions the testing identified as edge cases and the transactions it flagged and then detected through the investigation cycle — both the laundered and the legitimate. For instance, the deposits sample the HSBC Final Notice cited is the cleanest worked example of how parameter-testing evidence reads under the effectiveness regime: trace each flagged deposit back to the onboarding artefact that produced the reference row. Under the new regime, the supervisor's question is not "did you test the parameters" — it is "can you show that your testing tightened the signal". Investing in the dossier that answers the second question is investing against the regime you will be supervised under from 2027 onwards, not the regime you were supervised under through 2025.

Audit the identity-evidence layer, not only the monitoring engine

The monitoring engine is only as good as the reference file it scores transactions against. The question internal audit has to learn to ask is the question the engine cannot ask itself — whether the reference data is canonical, signed, and scoped to the positions the engine actually uses. Auditing the identity-evidence layer means tracing a representative sample of alerts back to the exact onboarding artefact that fed the reference row, and checking whether that artefact was a verified position or a copy of a document. The audit population is the transaction sample; the audit question is whether the reference row that drove each flagged transaction was a verified position or a document dump, and whether the transactions the engine detected as part of a laundered-proceeds pattern mapped back to the typologies the assessment identified. This is the question a Zero-Knowledge KYC attestation layer is designed to answer from the outside — and we have built Verifyo around it. Teams that want to see how the audit trail composes when the identity layer is cryptographically signed can read our walkthrough on auditing ZK compliance evidence.

Engage with the NPRM

FinCEN is accepting comments through 9 June 2026 (1)(2). Effectiveness as a supervisory test is not yet settled; the early trade-press memos from Covington, Sullivan & Cromwell and Gibson Dunn show the industry already shaping how the new test will be assessed in practice. Compliance leaders whose programme management treats AML transaction monitoring systems as outputs of an upstream identity architecture will have less to rebuild in 2027 — the challenges they face between now and 9 June are architectural, not procedural, and the effectiveness evidence of teams that treat monitoring as a standalone control will read thinly. Compliance leaders evaluating the software vendors in the transaction monitoring class for 2027 have a narrow window to shape the record that will drive implementation. Financial institutions that engage materially during the comment window — not ritually, but with evidenced positions on how the proposed effectiveness metrics will interact with existing parameter-testing practice, SAR-quality measurement, and AMLR Article 26 alignment — will be better positioned at implementation, and the organisations whose parameter-testing programmes and transaction monitoring evidence are already structured against effectiveness will have less to rebuild in 2027. The laws the NPRM rewrites will shape AML programme design in every FATF-aligned jurisdiction; domestic laws implementing the FATF standards will follow the same effectiveness shape, and firms that engage materially in the comment window will be better positioned at implementation. The period between now and 9 June 2026 is short. The NPRM's reach, measured in supervisory consequence, is not.

Threshold-driven AML transaction monitoring is not ending. It is being asked to produce evidence of outcomes rather than evidence of process — evidence that the transactions the engine identified, flagged and detected were the transactions the money laundering risk assessment actually cared about. The rules the engine ran and the rules it missed are both part of the effectiveness record 2027 will audit, and teams that learn the architectural frame now will be better placed to answer. The financial institutions that adjust fastest are the ones whose identity-evidence layer was already built for specificity rather than volume, whose monitoring systems consume a reference row that includes a signed attestation rather than a stack of document copies, and whose anti money laundering programmes treat the effectiveness test as an architectural question rather than a documentation exercise. That is the shift 2027 will reward.

Sources

(1) Financial Crimes Enforcement Network (FinCEN). Anti-Money Laundering and Countering the Financing of Terrorism Programs — Notice of Proposed Rulemaking. Federal Register, 10 April 2026 (issued 7 April 2026). https://www.federalregister.gov/documents/2026/04/10/2026-07033/anti-money-laundering-and-countering-the-financing-of-terrorism-programs

(2) Financial Crimes Enforcement Network (FinCEN). Fact Sheet: Proposed Rule to Fundamentally Reform Financial Institution Programs Designed to Fight Illicit Finance. 7 April 2026. https://www.fincen.gov/system/files/2026-04/Program-NPRM-FactSheet.pdf

(3) Financial Crimes Enforcement Network (FinCEN). Key Changes in FinCEN's Proposed Rule to Refocus AML/CFT Programs on Effectiveness. 7 April 2026. https://www.fincen.gov/system/files/2026-04/Key-Changes-Program-NPRM.pdf

(4) Financial Action Task Force (FATF). International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation — The FATF Recommendations (adopted 2012, updated October 2025), Recommendation 10. https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/FATF%20Recommendations%202012.pdf.coredownload.inline.pdf

(5) Financial Action Task Force (FATF). Guidance for a Risk-Based Approach — The Banking Sector. October 2014. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Risk-based-approach-banking-sector.html

(6) Financial Conduct Authority (FCA). FCA fines HSBC Bank plc £63.9 million for deficient transaction monitoring controls. 17 December 2021. https://www.fca.org.uk/news/press-releases/fca-fines-hsbc-bank-plc-deficient-transaction-monitoring-controls

(7) Financial Conduct Authority (FCA). FCA fines Starling Bank £29m for failings in their financial crime systems and controls. 2 October 2024. https://www.fca.org.uk/news/press-releases/fca-fines-starling-bank-failings-financial-crime-systems-and-controls

(8) European Parliament and Council. Regulation (EU) 2024/1624 of 31 May 2024 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing (AMLR), Article 26. EUR-Lex, 19 June 2024. https://eur-lex.europa.eu/eli/reg/2024/1624/oj/eng

(9) Financial Crimes Enforcement Network (FinCEN). 31 CFR § 1020.320 — Reports by banks of suspicious transactions. eCFR. https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1020/subpart-C/section-1020.320

(10) Wolfsberg Group. Statement on Effective Monitoring for Suspicious Activity, Part I: Moving Beyond Automated Transaction Monitoring. 2024. https://wolfsberg-group.org/resources/168/

(11) Bank of England and Financial Conduct Authority. Artificial intelligence in UK financial services — 2024. 21 November 2024. https://www.bankofengland.co.uk/report/2024/artificial-intelligence-in-uk-financial-services-2024

(12) PwC (cited via industry reprints — Retail Banker International). Industry benchmark: 90–95% of AML transaction-monitoring alerts are false positives. https://www.retailbankerinternational.com/comment/hidden-cost-of-aml-how-false-positives-hurt-banks-fintechs-customers/

(13) Europol. From Suspicion to Action — Converting financial intelligence into greater operational impact. 2017. https://www.europol.europa.eu/cms/sites/default/files/documents/ql-01-17-932-en-c_pf_final.pdf