In banking compliance operations, up to 99% of sanctions screening alerts in cross-border payments are false positives. This means that compliance teams spend most of their time clearing legitimate payments, not catching bad actors.
Most blame the matching algorithm, and focus on tuning fuzzy matching thresholds, improving phonetic scoring, and deploying machine learning tools. However, the mismatch isn’t solely in the algorithm – it’s in the inputs.
Go deeper with GlobalData
Access deeper industry intelligence
Experience unmatched clarity with a single platform that combines unique data, AI, and human expertise.
Data quality is the bigger – and often neglected – root of the problem. Screening engines are matching dirty, unstructured entities and address data against structured sanctions list entries again with unstructured address data. Similar problem exists with embargoed/sanctioned ships, aircrafts, countries and their cities. All these are falsely detected in free format addresses.
An expensive problem
False positives aren’t just a drain on compliance resources; they’re also costly. Take, for example, a mid-tier bank processing 500,000 cross-border payments monthly. A 5% alert rate (conservative by industry standards) will generate 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.
Each direct review costs approximately $15–25 per alert, including analyst time at $30-50/hour for 15-30 minutes of investigation and verification. This means that the bank is spending between $370,000 to $620,000 per month in compliance overhead, applied almost entirely to proving innocence rather than finding guilt. On an annual basis, this comes to $4.4m to $7.4m for just one institution.
Scaled across the industry, an $8-12bn annual cost of false positives isn’t a wild exaggeration, but a conservative estimate.
What the status quo gets wrong
When asked why false positive rates are so high, sanctions screening software vendors often point to name matching ambiguity, phonetic algorithm sensitivity and the inherent breadth of sanctions watchlists. While these explanations are accurate, they’re also incomplete.
In order to make sure we do not miss any sanctioned entities, all software tools try to match the whole set of fuzzy matches without having a context to validating/verifying all potential hits. Structured addresses provide the real context for verifying all sanctioned entities by providing context and related information to enable intelligent tools to detect false(ly) detected fuzzy matches and reject false hits – just like humans do. Structured and verified addresses also invalidate ships, cities, countries, names that appear in street and building address components. Once the entity and its address is fully understood and structured, it can then be easily matched and verified with previously structured sanctioned entities and their addresses in various watchlists. [Note: Structuring in a way is/means “understanding”]
The typical narrative focuses on the filter problem, while ignoring the data problem. It diagnoses the screening engine without examining the data it is being asked to work with.
Sanctions watchlists contain SDNs (Specially Designated National – Blacklisted entity) and address data. For example, there are over 150 such lists including the OFAC Specially Designated Nationals List, the EU Consolidated List and the UN Security Council Consolidated List which maintain the blacklist entities and their unstructured address entries [Note: The lists also contain unstructured address data].
The cross-border payment messages historically also do not. Before the advent of messaging standard ISO 20022, SWIFT messages carried address data in up to four free-text fields: 35 characters each. The screening engine is being asked to precisely match a name and unstructured address, SDN record against an unstructured text blob. As a result, the engine has to guess, and it guesses broadly, because guessing narrowly creates regulatory risk.
For example, “12 W Corniche Rd UAE” could be in Abu Dhabi, Sharjah or Dubai, as Corniche is a common road name in the UAE. In the legacy format, the screening engine wouldn’t be able to distinguish between them without additional data. Also take an example of Cuba Street, Wellington, New Zealand – a fuzzy unstructured address match would identify Cuba as the blacklisted country and create a false hit – even if Cuba Street is a valid street address in Wellington city in New Zealand. Similarly, “Muhammad Ali Road, Mumbai” or “Atlas Street” would generate false hits on the name “Muhammad Ali” and “Atlas Street, Stoke-on-Trent” as blacklisted individual in Iran or a blacklisted ship in Barbados. The compliance team cannot ignore this and look at it manually.
In the ISO 20022 structured format, with mandatory structured address fields (StreetNm, BldgNb, TwnNm, PstCd, Ctry) replacing the legacy free-text address box, the ‘TwnNm’ field provides assured clarity: Structured “Santa Clara” as a street name in San Jose, would remove ambiguity of Santa Clara, as a city in California or Santa Clara – a city in blacklisted Cuba. Abu Dhabi is Abu Dhabi. False positives from this category of geographic ambiguity disappear.
This is a consistent issue across data quality engagements in financial services: what looks like an algorithm problem, turns out to be a data quality problem on closer examination. Fix the data and a significant portion of the “algorithm problem” resolves itself.
ISO 20022 changes the equation
The global roll-out of ISO 20022 is adding pressure on banks to clean up their data. SWIFT and European Payments Council (EPC) have set a deadline of 15 November 2026, after which unstructured addresses in ISO 20022 payment messages will no longer be allowed. Banks that don’t adopt structured addresses face increased payment rejection rates, higher exception costs and regulatory risk.
But while structured address compliance is discussed almost entirely as a payment processing story, it’s also primarily a sanctions screening story. Global organisations and the G20 are focusing on problems because mandatory financial crime compliance is a major bottleneck for efficient and transparent payment processing.
The false positive sanction screening reduction from structured addresses is concentrated in a specific category: geographic false positives. These are alerts triggered because the screening engine couldn’t distinguish between different types of entities (names, cities, countries, vessels) with similar names, partial address data or incomplete country identification.
This category of false positive is eliminated by structured address fields because it resolves the ambiguity in free format address text with grounded context in a trusted and explainable manner. These are the building blocks of precise geographic matching. When those fields are populated with validated, accurate data, screening engines gain the granularity to make precise matches and apply validations rather than make broad approximations.
Banks implementing validated structured address pipelines, where the address is not just ISO 20022 formatted but verified across 246 countries, report false positive rate reductions of 25-30% from this category alone.
Revisiting the previous example of a mid-tier bank, with 24,750 false positive reviews monthly at $15–25 per alert, a 25-30% reduction represents 6,000-7,400 fewer reviews each month. This eliminates to between $90,000 and $185,000 in monthly review cost, without changing a single algorithm threshold or hiring an additional analyst. This is in addition to payments operations savings.
The solution isn’t better screening; it’s better inputs. The difference matters as algorithm tuning is a recurring cost, while data quality improvement is a structural fix.
Operational shifts
Compliance operations teams that implement structured address validation consistently report three operational shifts – and one caveat.
The first shift is categorisation. False positive reductions don’t happen uniformly across an 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 harder to resolve and worth investigating. However, the signal-to-noise ratio of remaining alerts improves significantly.
The second shift is analyst behaviour. When the alert queue shrinks by 25–30%, analysts can do different work. The time previously spent monotonously clearing geographic false positives can be reallocated to genuine investigations and risk decisions improve.
The third shift is the audit trail. Regulators increasingly accept that validated structured address data, properly documented, provides stronger explainable compliance evidence than a manual review record for cleared false positives. The audit trail improves in quality alongside the improvement in alert accuracy.
The contextual knowledge and understanding provided by fully structured entity information further enables additional false positive reduction techniques that increase false positive reductions up to 75%.
The caveat is that while structured address validation eliminates several categories of false positives caused by geographic ambiguity in payment and sanctions data, it doesn’t replace the need for tuned matching algorithms and experienced analyst judgement.
There are similar benefits of structured addresses in AML, KYC and Travel Rule related checks and false positive reductions.
What it does is remove a large, addressable category of 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.
Parth Desai, founder of ioNova AI
