TL;DR
95–99% of sanctions screening alerts are false positives — compliance teams spend most of their time clearing innocent payments, not catching bad actors.
Most guides blame the matching algorithm. The bigger, neglected cause is upstream: dirty, unstructured address data being matched against precisely structured sanctions-list entries.Legacy MT103 messages cram addresses into a 35-character free-text field; ISO 20022 splits them into parsed fields (StreetNm, BldgNb, TwnNm, Ctry, PstCd) the engine can match precisely.Validated structured addresses cut geographic false positives by 25–30% — for a mid-tier bank that's $90K–$185K in review costs eliminated every month, with no algorithm change.It's not a cure-all: structured addresses don't fix name-matching or watchlist-ambiguity false positives. They remove one large, addressable category of noise so analysts focus on alerts worth investigating.The November 2026 SWIFT/EPC structured-address deadline forces the fix anyway — adopting early solves the payment STP problem and the sanctions screening problem at once. kg-card-end: html
I've sat in more compliance operations rooms than I can count. And the ritual is always the same: the morning queue lands, analysts scroll through hundreds of flagged alerts, and the question on everyone's mind is never "did we catch a bad actor?" It's almost always "how fast can we clear this queue before noon?"
That experience — the daily urgency of managing thousands of alerts that almost none of them will survive — is the lived reality behind a number that should embarrass an entire industry: 95–99% of sanctions screening alerts are false positives.
Industry research from LexisNexis, Dow Jones Risk & Compliance, and SWIFT's own operational data consistently supports this range. For every genuine sanctions match, compliance teams wade through 99 to 199 false alarms. The system was designed to catch everything — and it does. Including nearly everything that isn't a problem.
Most guides treat this as an algorithm problem. Tune the fuzzy matching thresholds. Improve the phonetic scoring. Add machine learning. These are real levers — but they're not the only ones, and they're certainly not the most neglected. The upstream problem — the one that generates alerts before the algorithm even runs — is address data quality. And that's what almost no one is talking about.
kg-card-begin: html
The core argument: Sanctions screening false positives reach 95–99% partly because screening engines are matching dirty, unstructured address data against precisely structured sanctions list entries. The mismatch isn't only in the algorithm — it's in the input. Structured addresses reduce false positives by 25–30%. That's the lever this post is about.
kg-card-end: html kg-card-begin: html99%of sanctions alerts are false positives (industry average)5–10%of cross-border transactions trigger a screening alert$10–100direct cost per alert review per incident25–30%false positive reduction from structured address validationkg-card-end: html
The Mathematics of a $370,000 Monthly Problem
Let's make this operational, not theoretical. Take a mid-tier bank processing 500,000 cross-border payments monthly. At a 5% alert rate — conservative by industry standards — that generates 25,000 flagged transactions each month. At a 99% false positive rate, 24,750 of those are legitimate payments that need to be manually cleared.
At a direct review cost of $15–25 per alert — covering analyst time at $30–50/hour for 15–30 minutes of investigation — that's $370,000 to $620,000 per month in compliance overhead, applied almost entirely to proving innocence rather than finding guilt. Annually: $4.4M to $7.4M. From one institution.
Scale that across the industry and you begin to understand why the $8–12 billion annual cost of payment address data problems is not an exaggeration — it's a conservative floor.
kg-card-begin: html⚠️ The Regulatory ParadoxRegulators expect zero misses. Systems respond by alerting on everything. The result is compliance teams spending 95%+ of their time proving that flagged payments are innocent, rather than investigating payments that genuinely require scrutiny. This isn't a bug in the system. It's the predictable output of an architecture that never solved the data quality problem at the source.kg-card-end: html
What the Conventional Wisdom Gets Wrong
Ask any sanctions screening software vendor why false positive rates are so high and you'll get a version of the same answer: name matching ambiguity, phonetic algorithm sensitivity, and the inherent breadth of sanctions watchlists. These explanations are accurate. They're also incomplete.
The standard narrative identifies the filter problem while ignoring the data problem. It diagnoses the screening engine without examining what the engine is being asked to work with.
Here's what most compliance guides miss: sanctions watchlists contain structured, precisely formatted address data. The OFAC Specially Designated Nationals list, the EU Consolidated List, the UN Security Council Consolidated List — all of these maintain address entries with parsed fields: street name, city, country, postal code. These are clean, machine-readable records.
Cross-border payment messages — until very recently — do not. SWIFT messages carry address data in a single free-text field: 35 characters, sometimes two lines, with mandatory abbreviations and zero standardisation requirements. That's the raw material your screening engine is working with on the counterparty side.
You're asking an engine to precisely match a structured, fully-parsed record against an unstructured text blob. The engine has to guess. And it guesses broadly, because guessing narrowly creates regulatory risk.
The Before/After That Makes This Concrete
Consider the same counterparty represented in both formats:
kg-card-begin: html❌ Legacy MT103 (Unstructured)Creditor Address (35-char free text):
ACME TRDG CO
12 W CORNICHE RD UAE
// Country ambiguous
// City missing entirely
// Abbreviations unmapped
// Engine must guess broadly✅ ISO 20022 (Structured)StreetNm: West Corniche Road
BldgNb: 12
TwnNm: Abu Dhabi
Ctry: AE
PstCd: 12345
// Unambiguous geographic match
// Engine makes binary decisionkg-card-end: html
In the legacy format, "12 W CORNICHE RD UAE" could be Abu Dhabi, Sharjah, Dubai, or Ras Al Khaimah — the Corniche is a common address element throughout the UAE. The engine cannot distinguish between them without additional data. It alerts broadly. Most of those alerts are false positives generated not by a matching problem, but by a data quality problem.
In the ISO 20022 structured format, the TwnNm field makes this a binary fact. Abu Dhabi is Abu Dhabi. The engine doesn't need to guess. False positives from this category of geographic ambiguity disappear.
I've seen this pattern consistently across data quality engagements in financial services: what looks like an algorithm problem, on closer examination, turns out to be an input data problem wearing algorithm clothing. Fix the input, and a significant portion of the "algorithm problem" resolves itself. This is what the 'Which Paris?' problem illustrates at a global scale — the screening engine isn't broken, it's operating on fundamentally ambiguous inputs.
Why ISO 20022 Changes the Sanctions Screening Equation
The November 2026 SWIFT and EPC deadline for structured address compliance is discussed almost entirely as a payment processing story. Banks that don't adopt structured addresses face increased payment rejection rates, higher exception costs, and regulatory exposure under EPC guidelines. That framing is accurate — but it undersells the downstream compliance benefits by a wide margin.
Structured address adoption under ISO 20022 is also a sanctions screening story.
The mandatory structured address fields — StreetNm, BldgNb, TwnNm, Ctry, PstCd — aren't just formatting requirements. They are the building blocks of precise geographic matching. When those fields are populated with validated, accurate data — not just present, but correct — screening engines gain the granularity to make precise matches rather than broad approximations.
For a deeper look at what these fields actually contain and how they work, see our technical explainer: ISO 20022 Address Fields Explained: TwnNm, Ctry, AdrLine.
The Mechanism Behind the 25–30% Reduction
The false positive reduction from structured addresses is not uniform across all alert types. It's concentrated in a specific category: geographic false positives — alerts triggered because the screening engine couldn't disambiguate between different locations with similar names, partial address data, or incomplete country identification.
This category of false positive is eliminated by structured data, because structured data resolves the ambiguity at source. "Mohammed Al Rashid at 14 Corniche Road, Abu Dhabi" is a different record than "Mohammed Al Rashid at 14 Corniche Road, Beirut." In unstructured legacy data, that distinction may be invisible to the screening engine. In ISO 20022 structured data, it's a binary difference in the TwnNm and Ctry fields.
Banks implementing validated structured address pipelines — where the address is not just formatted to ISO 20022 standards, but verified accurate across 195 countries — report false positive rate reductions of 25–30% from this category alone.
kg-card-begin: html✅ The Savings CalculationAt our earlier example — 24,750 false positive reviews monthly at $15–25 per alert — a 25–30% reduction represents 6,000–7,400 fewer reviews each month. That's $90,000–$185,000 in monthly review cost eliminated, without changing a single algorithm threshold or hiring an additional analyst. The mechanism isn't better screening. It's better inputs. The difference matters strategically: algorithm tuning is a recurring cost. Data quality improvement is a structural fix.kg-card-end: html
What "Fixing This" Actually Looks Like Operationally
Compliance operations teams that implement structured address validation consistently report three operational shifts — and one important caveat.
The first shift is categorisation. False positive reductions don't happen uniformly across your alert queue. Geographic false positives — the largest single category in most institutions — decline sharply. Alerts that remain tend to be name-matching and entity ambiguity issues, which are genuinely harder to resolve and genuinely worth investigating. The signal-to-noise ratio of your remaining alerts improves significantly.
The second shift is analyst behaviour. When the alert queue shrinks by 25–30%, analysts aren't just doing less work — they're doing different work. The time previously spent clearing geographic false positives reallocates to genuine investigations. Risk decisions become better. The quality of compliance coverage improves even as the volume of work decreases.
The third shift is the audit trail. Regulators increasingly accept that validated structured address data, properly documented, provides stronger compliance evidence than a manual review record for a cleared false positive. The audit trail improves in quality alongside the improvement in alert accuracy. This matters especially under the new regulatory frameworks that accompany the November 2026 deadline.
The relationship between AML compliance and address data quality extends well beyond sanctions screening specifically — for a broader look at how address data affects the full AML compliance picture, see our companion post: Address Data Quality for AML Compliance.
What This Doesn't Fix (The Credibility Moment)
I want to be precise about the scope of what structured addresses resolve — because overstating it would undermine trust in what's a genuinely significant improvement.
Structured address validation eliminates the category of false positives caused by geographic ambiguity in payment data. It does not resolve name-matching false positives (the "Mohammed Al Rashid" problem is a name problem, not an address problem). It does not resolve watchlist ambiguity caused by incomplete sanctions list entries. And it does not replace the need for tuned matching algorithms and experienced analyst judgement.
What it does is remove a large, addressable category of noise — the noise that comes from asking a screening engine to make precise matches against ambiguous geographic data. Removing that noise makes everything else work better.
There's also a more nuanced problem that structured addresses alone cannot solve: the context-dependent nature of address screening. A street called "Cuba Street" in Wellington, New Zealand, is not a Cuba-related sanctions risk — but unstructured or context-naive screening can't tell the difference. We've written about this specific problem in detail: The 'Cuba Street' Problem: Context-Aware Screening.
The 99% False Positive Rate Isn't a Law of Nature
Every technology cycle I've observed in financial services follows a similar arc. A structural problem becomes accepted as inevitable because it's been present long enough that practitioners stop questioning whether it has to be this way. Address data quality in sanctions screening is at that inflection point.
The 95–99% false positive rate is not a regulatory requirement. It's not a technical inevitability. It's the output of a system built on address data that was never designed for precision matching — and maintained on that architecture because, until now, there was no regulatory mandate forcing a change.
The November 2026 ISO 20022 structured address deadline provides that mandate. Banks implementing structured address pipelines are simultaneously solving their payment STP problem and their sanctions screening problem. The purpose-built address intelligence platforms that deliver ISO 20022 compliance with validated accuracy across 195 countries aren't just compliance tools — they're operational tools that change the economics of financial crime compliance.
The question isn't whether to fix the data. It's whether you fix it now, ahead of the deadline, and capture the compliance dividend — or fix it reactively, under pressure, in late 2026, and pay the cost of the delay.
kg-card-begin: html💡 Tweetable Insight"Banks aren't bad at catching sanctions evaders. They're excellent at flagging innocent payments. The problem is that both categories cost exactly the same amount to investigate."kg-card-end: html kg-card-begin: html
Key Takeaways
195–99% of sanctions alerts are false positives — compliance teams spend most of their time clearing innocent payments, not investigating genuine risk.2Address data quality is an upstream driver — screening engines match structured watchlist entries against unstructured payment address blobs, forcing broad fuzzy matches.3ISO 20022 structured addresses reduce geographic false positives by 25–30% — validated TwnNm, Ctry, and related fields enable binary geographic decisions instead of guesswork.4The savings are operational, not theoretical — a mid-tier bank can eliminate $90K–$185K in monthly review costs from geographic false positives alone.5Structured addresses do not fix name-matching false positives — they remove a large, addressable category of noise so analysts focus on alerts worth investigating. kg-card-end: html
Frequently Asked Questions
kg-card-begin: htmlWhat percentage of sanctions screening alerts are false positives? ▾
Industry research consistently shows that 95–99% of sanctions screening alerts are false positives — meaning only 1–5% of flagged alerts represent genuine matches requiring escalation. The root causes include name-matching ambiguity, algorithm sensitivity settings, and — critically — poor address data quality that forces screening engines into broad, imprecise matching. This false positive rate is not a regulatory requirement; it's the output of a data quality problem that has been accepted as structural rather than addressed at source.
Why does address data quality affect sanctions screening accuracy? ▾
Sanctions watchlists contain structured, precisely formatted address data. Cross-border payment messages — using legacy formats — carry address data as unstructured free-text, often abbreviated into 35-character fields with no standard format. Screening engines must match a precise sanctions entry against an ambiguous text blob, resulting in broad fuzzy matches and high false positive rates. Structured, parsed address data allows engines to make binary geographic distinctions — Abu Dhabi versus Beirut — that are invisible in unstructured legacy data.
How does ISO 20022 reduce sanctions screening false positives? ▾
ISO 20022's mandatory structured address fields (StreetNm, BldgNb, TwnNm, PstCd, Ctry) replace the legacy free-text address blob with parsed, machine-readable data. This gives screening engines the granularity to make precise geographic matches rather than broad approximations. The false positive reduction is concentrated in geographic false positives — alerts triggered by location ambiguity — which disappear when location data is structured and validated. Banks implementing structured address validation report 25–30% reductions in false positive rates from this category.
What does a sanctions screening false positive cost a bank? ▾
Direct cost per alert review ranges from $10 to $100, depending on institution size, tooling, and review complexity. Labor costs alone run $7.50–$25 per alert at typical compliance analyst rates ($30–50/hour for 15–30 minutes of investigation). For a mid-tier bank generating 25,000 alerts monthly at a 99% false positive rate, that represents 24,750 manual reviews of legitimate payments — a monthly compliance cost of $370,000–$620,000 in review time, not including technology licensing or operational overhead. Annually: $4.4M–$7.4M from one institution.
Can structured addresses reduce sanctions false positive rates by 25–30%? ▾
Yes, with an important qualification: the 25–30% reduction applies specifically to the category of false positives caused by geographic ambiguity — cases where unstructured address data prevents the screening engine from distinguishing between different locations. Structured addresses do not resolve name-matching false positives or watchlist ambiguity. Banks should implement structured address validation as one component of a comprehensive false positive reduction programme, alongside algorithm tuning and enhanced entity data management.
kg-card-end: html kg-card-begin: html
Continue Reading
Compliance The Compliance Dividend: How ISO 20022 Structured Addresses Transform Financial Crime Compliance Sanctions, AML, KYC, Travel Rule — how structured addresses cut false positives 25–30% and transform audit evidence across four FATF domains simultaneously.Read article →Technology November 2026: The ISO 20022 Deadline That Changes Everything The SWIFT CBPR+ enforcement date, what it requires, and why institutions that treat it as a compliance project will miss the bigger opportunity.Read article →Regulation What Regulators Actually Require: EPC, SWIFT, and CPMI Decoded The specific field requirements behind the mandates — and what "compliant" actually means for each standards body.Read article →Implementation Structured vs. Hybrid Addresses: Why It's Not Either/Or Structured is the superset. Hybrid is the subset. Here's the mathematical relationship between the two formats — and why it settles the debate.Read article →Economics Same Effort, Better Outcome: The Case for Structured Addresses by Default Structured and hybrid ISO 20022 addresses require identical implementation effort — but only one delivers 30–50× better outcomes.Read article →Data Quality The ISO 20022 Paradox: Why Message Migration Is the Easy Part Format compliance without data readiness is a pattern that's repeated for 30 years — and it always ends the same way.Read article →Data Quality ISO 20022: This Time, Let's Get Payments Data Right The ISO 20022 migration is the payments industry's best chance in thirty years to fix cross-border data quality. The question is whether we seize it.Read article →kg-card-end: html