ISO 20022 is adopted. The structured address that would cut sanctions false alerts is not.
ISO 20022 ist eingeführt. Die strukturierte Anschrift, die Fehlalarme senken würde, nicht.
Swift reported a 97% adoption rate for ISO 20022 payment instructions after the cross-border coexistence period ended in November 2025. Four months later, the same organisation reported that roughly 65% of payment messages still carry an unstructured postal address. Those two numbers describe the same migration. The first is the part that was counted; the second is the part that was supposed to do the work. The structured address is the single element in ISO 20022 that bears directly on sanctions false alerts — it is what stops a filter from reading a street name as a country — and it is the element the industry has not delivered.
What the field is actually for
In the legacy message format, the parties to a payment were described in free-text lines. Field 50 of an MT 103 held the ordering customer: a name and up to four lines of whatever the originating bank’s system happened to hold. Field 59 held the beneficiary the same way. There were no tags inside those lines. A name, a street, a town, a postcode and a country all arrived as one undifferentiated block of characters.
A sanctions filter reading that block has no way to know which token is which. It tokenises the whole thing and compares every fragment against every list it has been given. That is why the classic false alert is not a near-miss on a designated person’s name. It is a town called Havana in Florida, a street named after Cuba in a European capital, a company whose trading name contains the word Crimea, a shipping address in a district that shares a name with a designated port. The list has a country on it; the message has that country’s name in it, in a position that has nothing to do with the payment’s destination; the filter cannot tell the difference because the message never told it.
ISO 20022 gives each of those elements its own tag. The debtor and creditor blocks carry Name, and separately StreetName, BuildingNumber, PostCode, TownName and Country, along with identifiers such as a BIC, a Legal Entity Identifier and, for natural persons, a date and place of birth. Once the message says which characters are a town and which are a name, the filter can screen the name against the name list, the country code against the country list, and decline to screen a street name against anything at all. Swift’s own framing, in its announcement of 25 March 2026, is that structured data “supports more precise filtering, improved monitoring and higher levels of automation in payments processing”.
That is the mechanism. Not a matching algorithm, not a model, not a data product: the message telling the filter what it is looking at.
The two numbers, and who published them
Both figures come from Swift, and it is worth being explicit about that. Swift operates the network, writes the CBPR+ usage guidelines that define what a compliant message looks like, and sells both a data-quality analytics service and an address-structuring tool. It has an interest in the migration succeeding and an interest in institutions buying help with it. It is also the only party in a position to count, because it carries the traffic. Nobody with an interest in a lower number is able to produce one.
With that stated: Swift reported that the community reached a 97% adoption rate for CBPR+ ISO 20022 payment instructions after the coexistence period ended on 22 November 2025. In the same period it introduced a hybrid postal address option in the 2025 usage guidelines — town name and country code in their designated fields, the rest of the address permitted to remain as free text — with a one-year grace period. On 25 March 2026 it announced that from 14 November 2026 fully unstructured addresses will no longer be accepted, that town and country must appear in designated fields for all agents and parties, and that non-compliant messages will be rejected on the network. In the same announcement: “Today, approximately 65% of payment messages still contain unstructured addresses.” Thomas Delaet, Swift’s chief product officer, is quoted saying that removing unstructured addresses is “a critical step”.
Swift also states that it cannot build a fallback, because address information “must be sourced at origin”. That sentence is the whole problem in seven words, and we will come back to it.
The arithmetic nobody does
Two figures circulate about sanctions screening, and they are usually treated as rival claims. They are not. They measure different things, and both are approximately right.
The first is the familiar trade-press headline that upwards of 99% of sanctions screening alerts are false positives. That figure is quoted by vendors and by the outlets that cover them; it is not, as far as this research found, a supervisory measurement. It describes precision — the share of alerts raised that turn out to involve nobody on a list.
The second comes from a regulator that ran an actual test. In November 2024 Finansinspektionen, the Swedish financial supervisor, published FI Supervision no. 30, an in-depth analysis of the automated screening systems used by 19 banks active in Sweden. Each bank ran a file of 5,000 names from the UN and EU sanctions lists through its own system, in its own test environment, with its own thresholds. Separately, FI ran a control file of 200 individuals and firms that are on no sanctions list at all. On that control file, the banks’ systems raised a false alert on 4.9% of the names in customer screening and 6.0% in transaction screening. FI also reported a global comparator drawn from equivalent tests at 75 institutions elsewhere: 6.8% and 9.3%.
So one source says 99% and a supervisor’s test says 5%. Both are true, because the first is a share of alerts and the second is a share of clean names. Converting between them requires the base rate — how often a genuinely listed party actually appears — and that is where the arithmetic gets uncomfortable.
Take an illustrative base rate of one listed counterparty in every 20,000 screened. That number is an assumption, not a measurement; no supervisor publishes it, and it will differ enormously by corridor. On that assumption, 20,000 names produce one true hit and, at a 4.9% per-name false-alert rate, roughly 980 false ones. The share of alerts that are false is 980 of 981, or 99.90%. The two figures are not in conflict; the second generates the first.
Now apply the improvement. The most concrete published estimate of what ISO 20022 does to false positives is a range of 25 to 30%, attributed to EY in December 2025 — a firm that sells ISO 20022 migration programmes, and which did not publish a method. Take the optimistic end. A 30% cut moves the per-name rate from 4.9% to 3.4%, which turns 980 false alerts into 686. The share of alerts that are false moves from 99.90% to 99.85%. The alert queue shrinks by three-tenths. The headline does not move at all.
To get the headline from 99.9% to 90% — nine false alerts per true hit rather than nine hundred and eighty — the per-name rate would have to fall from 4.9% to about 0.045%. That is a factor of roughly one hundred and ten. No structured address does that, and nothing else on the table does either.
This is worth stating plainly, because both numbers are routinely used to sell the same thing. The structured address attacks the per-name rate, which determines how much labour an alert queue consumes. It cannot attack the base rate, which determines what proportion of that labour is wasted. A control that removes a third of the work is worth having; a control marketed as fixing the “99% problem” is being sold against the wrong denominator.
The case for the standard, made properly
The argument for structured data is not weak, and it deserves its strongest form before the objection lands.
Every other lever available to a screening team is a trade. Raise the fuzzy-matching threshold and you cut false alerts and miss more real names. Lower it and you catch more and drown. Finansinspektionen’s data shows exactly how expensive that trade is. Against names spelled precisely as they appear on the lists, the 19 banks’ customer screening systems identified 86.3% on average, with a median of 99.3%. Against deliberately manipulated spellings — a hyphen removed, an accent dropped, a compound name split — the average fell to 63.9%, a drop of 22.5 percentage points, with the best system at 96.1% and the worst at 5.0%. Transaction screening did better: 96.1% correctly spelled, 88.4% manipulated. Not one of the 19 banks reached 100% on any test. The banks with the lowest customer-screening effectiveness shared a single vendor system, and banks running the same system produced different results, which FI reads as evidence that configuration, not software, is doing much of the work.
Field separation is the only lever that does not sit on that trade-off. If the filter knows which characters are the debtor’s name, it can be more aggressive on that field — catching more manipulated spellings — while screening the street line against nothing. Both error rates improve at once. There is no second control on the table with that property, and that is the honest case for the November 2026 deadline.
There is supporting evidence in FI’s own numbers, and FI found it surprising: transaction screening outperformed customer screening across the board, which the supervisor did not expect, since a customer record is examined at leisure and a payment is examined in flight. One plausible reading is that a payment message carries corroborating identifiers a customer record does not. FI does not draw that conclusion, and neither should this piece; but FI does state that “specific risks arise from using systems where the screening is limited due to the customer data being structured in the bank’s customer systems in a way that differs with how the data is structured in the UN’s and the EU’s official sanctions lists”. That is a supervisor saying that data structure determines screening outcomes.
The official machinery agrees. The Committee on Payments and Market Infrastructures at the BIS, jointly with the Payments Market Practice Group, published harmonised ISO 20022 data requirements in October 2023 and an updated report on 26 February 2026, setting a minimum data set for cross-border payments with adoption flexibility until the end of 2027 — and is careful to say these are not regulatory requirements. The Financial Action Task Force went further: on 18 June 2025 it announced that its plenary had adopted a revised Recommendation 16, standardising the originator and beneficiary information that must accompany cross-border payments above USD/EUR 1,000 — name, address, date of birth — with compliance required by the end of 2030.
What the European Union did instead
While the standards bodies were building a better field, the EU legislature took a different route to the same problem, and its reasoning is on the record.
Recital 25 of the Instant Payments Regulation states that when transaction-based screening is undertaken, “the large majority of… flagged transactions turn out, after verification, not to involve any of the persons or entities subject to targeted financial restrictive measures”, and that this creates operational challenges for providers trying to offer instant transfers reliably. Note what is absent: a number. The legislature asserts a large majority and does not say how large, because nobody measured it. Under the editorial rule this outlet applies to very wide ranges, an unquantified “large majority” is the same kind of admission — the quantity is inferred, not observed, and it is being used to justify a rule.
The rule is Article 5d, inserted into Regulation (EU) No 260/2012 by Regulation (EU) 2024/886. From 9 January 2025, providers offering euro instant credit transfers must screen their own payment service users against EU targeted financial restrictive measures at least once every calendar day, and immediately after any new designation or amendment enters into force. Article 5d(2) then prohibits transaction-based EU restricted-party screening for in-scope payments. Member states had until 9 April 2025 to introduce penalties, which must reach at least 10% of annual net turnover for a legal person and at least EUR 5,000,000 for a natural person.
That is the largest single reduction in transaction-level sanctions false alerts in European payments, and it contains no data-format component whatsoever. The EU did not wait for the structured address to make the check cheaper. It removed the check and moved the obligation to the customer base, where the population is small, stable and screened overnight rather than in the ten seconds a payment has to clear.
The relief is narrower than it looks, and the qualification comes from practitioners rather than from the text. Hogan Lovells, writing for bank clients in February 2025, points out that the prohibition covers EU restricted-party screening only. A provider with dollar exposure still faces OFAC’s Specially Designated Nationals list, and one with UK exposure still faces the UK Sanctions List, neither of which is displaced by an EU regulation. Those filters keep running on the transaction. In practice, the instrument that abolished transaction screening abolished one list’s worth of it.
Why the field stays empty
The interesting question is not whether structured addresses help. It is why, five years into a migration everyone agreed to, two-thirds of messages still do not carry them.
Swift’s own sentence answers it: address information must be sourced at origin. The structured address cannot be manufactured in the middle of the chain. It has to be captured by the originating institution, from the customer, through a channel — an online banking form, a corporate file upload, a branch terminal, a treasury system — and every one of those channels was built to accept a text box. Restructuring them means changing customer-facing forms, revalidating stored address data for the entire client base, and telling corporate clients that a file format they have used for a decade will start being rejected.
That work sits with the debtor’s bank. The saving sits somewhere else. In a correspondent chain, it is the intermediary and the beneficiary’s institution whose filters raise the alert and whose analysts clear it. The bank that pays for the data quality is not the bank whose alert queue shortens. This is the same asymmetry that makes the headline margin the smallest component of what an acquirer actually earns: the visible price and the actual economics attach to different parties.
Worse, the benefit is unattributable even where it lands. No alert queue has a field recording that this alert exists because a street name arrived unlabelled. Analysts clear alerts; they do not classify their causes. A saving that cannot be counted cannot be budgeted, and a compliance data project competing against one with a regulatory deadline loses every time.
Which is precisely why the deadline exists. Swift has not persuaded the originating banks that structuring addresses is worth it; it has arranged for unstructured messages to be rejected at the network edge from 14 November 2026. When a benefit cannot be made to land on the party who bears the cost, the remaining instrument is a penalty at the boundary. Finansinspektionen’s finding that screening effectiveness rises with bank size points at the same economics from the other end: compliance data work is largely a fixed cost, so it is done properly where there is a big enough base to spread it over.
Degrees of confidence
Firmly held: Swift’s two adoption figures, the November 2026 rejection rule, Finansinspektionen’s test results, and the text and dates of Article 5d. These are published by the bodies that made or measured them.
With reasonable confidence: that the “99% of alerts” figure and the supervisor’s 4.9% measure different quantities and are jointly consistent, and that the structured address acts on the second and not the first. The reasoning is arithmetic; the base rate that connects them is not.
Cautiously: the 25–30% improvement estimate. One consultancy, no published method, and a commercial interest in the programmes that deliver the change. It is the only quantified estimate this research found, which is itself a finding.
What this does not tell you
Finansinspektionen’s test was run in test environments against a synthetic 5,000-name file, using each bank’s own parameters. FI states explicitly that it did not review actual customers or transactions and draws no conclusion about real breaches. The 4.9% is a property of the systems as configured, not a count of alerts anyone had to clear. Four banks disputed their own results, arguing that the test data was not structured in a way their system could ingest — an objection that is itself a small illustration of the article’s subject.
Swift’s 65% is a share of messages, not of value, of alerts or of screening effort. An unstructured address on a low-risk domestic-adjacent corridor costs almost nothing; one on a corridor with heavy designation exposure costs a great deal. The distribution of the remaining 65% across corridors is not published, and without it the operational significance of the number cannot be calculated.
And nobody has published the measurement that would settle the mechanism: a bank reporting its own alert volume across the November 2025 cutover, with thresholds, list versions and business mix held constant. Until an institution or a supervisor does that, the case for structured data remains a mechanism rather than a result — a good mechanism, argued from first principles, with no before-and-after behind it. There is also a direction of harm worth naming, and it follows from the mechanism rather than from any published finding: a filter that screens only the Name field will not see a designated name deliberately typed into the street line. Precision cuts both ways.
The pattern this belongs to
Strip out the acronyms and this is a familiar shape. A rule creates a capability. Adoption of the capability is measured, because adoption is countable. Use of the capability is not measured, because use would require someone to define an outcome and own it. The programme reports success against the number it can produce.
The same shape produced a payee-name check that is displayed to the payer without shifting who bears the loss, and it produced the interface problem that made an access right worth less than the law that granted it until quality standards arrived eight years late. In each case the mandated artefact was delivered on time and the thing the artefact was for was left to emerge on its own.
The practical test, when the next data standard is announced, is three questions. Who has to populate the new field? Whose costs fall when it is populated? And will anyone, ever, be in a position to say whether it worked? Where the first two answers name different institutions and the third is no, the field will stay empty until something at the edge of the network refuses the message. That is not a failure of the standard. It is what a standard is for, and it is the reason a rejection rule dated 14 November 2026 is likely to do more for sanctions screening than the argument that structured data is better ever did.
Swift meldete für Zahlungsaufträge im grenzüberschreitenden Verkehr eine Einführungsquote von 97 Prozent, nachdem die Übergangsfrist im November 2025 endete. Vier Monate später meldete dieselbe Organisation, dass rund 65 Prozent der Zahlungsnachrichten weiterhin eine unstrukturierte Postanschrift tragen. Beide Zahlen beschreiben dieselbe Umstellung. Die erste betrifft den Teil, der gezählt wurde; die zweite den Teil, der die Arbeit leisten sollte. Die strukturierte Anschrift ist das einzige Element in ISO 20022, das unmittelbar auf Sanktions-Fehlalarme wirkt — sie verhindert, dass ein Filter einen Straßennamen für ein Land hält —, und sie ist genau das Element, das die Branche nicht geliefert hat.
Wofür das Feld eigentlich da ist
Im alten Nachrichtenformat wurden die Beteiligten einer Zahlung in Freitextzeilen beschrieben. Feld 50 einer MT 103 enthielt den Auftraggeber: einen Namen und bis zu vier Zeilen dessen, was im System der beauftragten Bank zufällig gespeichert war. Feld 59 enthielt den Empfänger auf dieselbe Weise. Innerhalb dieser Zeilen gab es keine Kennzeichnung. Name, Straße, Ort, Postleitzahl und Land kamen als ein einziger, ununterschiedener Zeichenblock an.
Ein Sanktionsfilter, der diesen Block liest, kann nicht wissen, welcher Bestandteil was ist. Er zerlegt alles in Wortteile und vergleicht jedes Bruchstück mit jeder Liste, die man ihm gegeben hat. Deshalb ist der typische Fehlalarm gerade keine Beinahe-Übereinstimmung mit dem Namen einer gelisteten Person. Es ist ein Ort namens Havanna in Florida, eine nach Kuba benannte Straße in einer europäischen Hauptstadt, ein Unternehmen, dessen Handelsname das Wort Krim enthält, eine Lieferanschrift in einem Stadtteil, der so heißt wie ein sanktionierter Hafen. Auf der Liste steht ein Land; in der Nachricht steht der Name dieses Landes, an einer Stelle, die mit dem Ziel der Zahlung nichts zu tun hat; der Filter kann den Unterschied nicht erkennen, weil die Nachricht ihn nie mitgeteilt hat.
ISO 20022 gibt jedem dieser Bestandteile eine eigene Kennzeichnung. Die Blöcke für Auftraggeber und Empfänger führen den Namen getrennt von Straße, Hausnummer, Postleitzahl, Ortsname und Land, dazu Kennungen wie BIC, Rechtsträgerkennung (LEI) und bei natürlichen Personen Geburtsdatum und Geburtsort. Sobald die Nachricht sagt, welche Zeichen ein Ort und welche ein Name sind, kann der Filter den Namen gegen die Namensliste prüfen, den Ländercode gegen die Länderliste — und den Straßennamen gegen gar nichts. Swift selbst schreibt in seiner Mitteilung vom 25. März 2026, strukturierte Daten unterstützten „präziseres Filtern, bessere Überwachung und einen höheren Automatisierungsgrad”.
Das ist der Wirkmechanismus. Er ist kein Vergleichsalgorithmus, kein Lernverfahren und kein Datenprodukt. Er besteht darin, dass die Nachricht dem Filter mitteilt, was er vor sich hat.
Die zwei Zahlen — und wer sie herausgibt
Beide Angaben stammen von Swift, und das gehört ausgesprochen. Swift betreibt das Netz, schreibt die Nutzungsrichtlinien, die festlegen, wie eine regelkonforme Nachricht aussieht, und verkauft sowohl einen Dienst zur Datenqualitätsanalyse als auch ein Werkzeug zur Strukturierung von Anschriften. Swift hat ein Interesse daran, dass die Umstellung gelingt, und eines daran, dass Institute Hilfe dabei einkaufen. Swift ist zugleich die einzige Stelle, die überhaupt zählen kann, weil dort der Verkehr durchläuft. Niemand mit einem Interesse an einer niedrigeren Zahl wäre in der Lage, eine auszurechnen.
Mit dieser Einschränkung: Swift berichtete, die Gemeinschaft habe nach dem Ende der Übergangsfrist am 22. November 2025 eine Einführungsquote von 97 Prozent für Zahlungsaufträge erreicht. Im selben Zeitraum führte Swift in den Nutzungsrichtlinien 2025 eine Zwischenform der Anschrift ein — Ortsname und Ländercode in ihren eigenen Feldern, der Rest darf Freitext bleiben — mit einer Übergangsfrist von einem Jahr. Am 25. März 2026 teilte Swift mit, ab dem 14. November 2026 würden vollständig unstrukturierte Anschriften nicht mehr angenommen, Ort und Land müssten für alle Beteiligten in den dafür vorgesehenen Feldern stehen, und nicht regelkonforme Nachrichten würden im Netz zurückgewiesen. In derselben Mitteilung: „Heute enthalten etwa 65 Prozent der Zahlungsnachrichten weiterhin unstrukturierte Anschriften.” Thomas Delaet, Chief Product Officer von Swift, wird mit dem Satz zitiert, die Beseitigung unstrukturierter Anschriften sei „ein entscheidender Schritt”.
Swift schreibt außerdem, eine Ausweichlösung sei nicht möglich, weil Anschriftsdaten „an der Quelle erhoben werden müssen”. Dieser Halbsatz enthält das ganze Problem; wir kommen darauf zurück.
Die Rechnung, die niemand aufmacht
Zur Sanktionsprüfung kursieren zwei Zahlen, die üblicherweise als konkurrierende Behauptungen behandelt werden. Das sind sie nicht. Sie messen Verschiedenes, und beide stimmen ungefähr.
Die erste ist die geläufige Schlagzeile der Fachpresse, wonach über 99 Prozent aller Sanktionsalarme Fehlalarme seien. Diese Zahl wird von Anbietern und den sie begleitenden Medien verbreitet; eine aufsichtliche Messung dahinter hat diese Recherche nicht gefunden. Sie beschreibt die Treffergüte — den Anteil der ausgelösten Alarme, hinter denen niemand von einer Liste steckt.
Die zweite stammt von einer Aufsicht, die tatsächlich getestet hat. Im November 2024 veröffentlichte Finansinspektionen, die schwedische Finanzaufsicht, den Aufsichtsbericht Nr. 30, eine Tiefenanalyse der automatisierten Prüfsysteme von 19 in Schweden tätigen Banken. Jede Bank ließ eine Datei mit 5.000 Namen von den Sanktionslisten der Vereinten Nationen und der EU durch ihr eigenes System laufen, in ihrer eigenen Testumgebung, mit ihren eigenen Schwellenwerten. Zusätzlich schickte die Aufsicht eine Kontrolldatei mit 200 Personen und Firmen durch, die auf keiner Liste stehen. Bei dieser Kontrolldatei lösten die Systeme in der Kundenprüfung bei 4,9 Prozent der Namen einen Fehlalarm aus, in der Transaktionsprüfung bei 6,0 Prozent. Als internationalen Vergleichswert aus gleichartigen Tests bei 75 Instituten anderswo nennt die Aufsicht 6,8 und 9,3 Prozent.
Eine Quelle sagt also 99 Prozent, der Test einer Aufsicht sagt 5 Prozent. Beides trifft zu, weil die erste Zahl ein Anteil an den Alarmen ist und die zweite ein Anteil an den unbelasteten Namen. Um die eine in die andere umzurechnen, braucht man die Grundhäufigkeit — wie oft eine tatsächlich gelistete Partei überhaupt vorkommt —, und an dieser Stelle wird die Rechnung unangenehm.
Nehmen wir zur Veranschaulichung eine gelistete Gegenpartei auf je 20.000 geprüfte an. Diese Zahl ist eine Annahme, keine Messung; keine Aufsicht veröffentlicht sie, und sie schwankt zwischen Korridoren erheblich. Unter dieser Annahme ergeben 20.000 Namen einen echten Treffer und bei einer Fehlalarmquote von 4,9 Prozent je Name rund 980 falsche. Der Anteil falscher Alarme beträgt 980 von 981, also 99,90 Prozent. Die beiden Zahlen widersprechen sich nicht — die zweite erzeugt die erste.
Nun die Verbesserung. Die konkreteste veröffentlichte Schätzung dessen, was ISO 20022 mit Fehlalarmen macht, ist eine Spanne von 25 bis 30 Prozent, zugeschrieben EY im Dezember 2025 — einem Haus, das Umstellungsprojekte zu ISO 20022 verkauft und keine Methode offengelegt hat. Nehmen wir das obere Ende. Ein Rückgang um 30 Prozent senkt die Quote je Name von 4,9 auf 3,4 Prozent, aus 980 Fehlalarmen werden 686. Der Anteil falscher Alarme geht von 99,90 auf 99,85 Prozent. Die Warteschlange schrumpft um knapp ein Drittel. Die Schlagzeile bewegt sich nicht.
Damit die Schlagzeile von 99,9 auf 90 Prozent fiele — neun Fehlalarme je echtem Treffer statt neunhundertachtzig —, müsste die Quote je Name von 4,9 auf etwa 0,045 Prozent sinken. Das ist der Faktor 110. Keine strukturierte Anschrift leistet das, und nichts anderes, was zur Debatte steht, leistet es auch.
Das gehört ausgesprochen, weil mit beiden Zahlen routinemäßig dieselbe Sache verkauft wird. Die strukturierte Anschrift greift die Quote je Name an — jene Zahl, die bestimmt, wie viel Arbeit eine Alarmwarteschlange verschlingt. Sie kann die Grundhäufigkeit nicht angreifen — jene Zahl, die bestimmt, welcher Anteil dieser Arbeit vergeblich ist. Eine Maßnahme, die ein Drittel der Arbeit beseitigt, ist ihr Geld wert. Eine Maßnahme, die als Lösung des „99-Prozent-Problems” beworben wird, wird gegen den falschen Nenner beworben.
Die Gegenseite, ordentlich vertreten
Das Argument für strukturierte Daten ist nicht schwach, und es hat seine stärkste Fassung verdient, bevor der Einwand kommt.
Jeder andere Hebel, den ein Prüfteam hat, ist ein Tauschgeschäft. Wer die Unschärfeschwelle anhebt, senkt die Fehlalarme und übersieht mehr echte Namen. Wer sie senkt, findet mehr und ertrinkt. Die Daten von Finansinspektionen zeigen, wie teuer dieser Tausch ist. Bei Namen in exakt der Schreibweise der Listen erkannten die Kundenprüfsysteme der 19 Banken im Mittel 86,3 Prozent, der Median lag bei 99,3 Prozent. Bei absichtlich veränderten Schreibweisen — ein Bindestrich entfernt, ein Akzent weggelassen, ein zusammengesetzter Name getrennt — fiel der Durchschnitt auf 63,9 Prozent, ein Rückgang um 22,5 Prozentpunkte, mit 96,1 Prozent beim besten und 5,0 Prozent beim schwächsten System. Die Transaktionsprüfung schnitt besser ab: 96,1 Prozent bei korrekter Schreibweise, 88,4 Prozent bei veränderter. Keine der 19 Banken erreichte in irgendeinem Test 100 Prozent. Die Banken mit der schwächsten Kundenprüfung nutzten dasselbe Anbietersystem, und Banken mit demselben System kamen zu unterschiedlichen Ergebnissen — für die Aufsicht ein Hinweis darauf, dass ein großer Teil der Wirkung von der Einstellung stammt, nicht von der Software.
Die Trennung der Felder ist der einzige Hebel, der nicht auf diesem Tauschgeschäft sitzt. Weiß der Filter, welche Zeichen der Name des Auftraggebers sind, kann er auf diesem Feld schärfer prüfen — und damit mehr veränderte Schreibweisen fangen —, während er die Straßenzeile gegen nichts prüft. Beide Fehlerarten verbessern sich gleichzeitig. Eine zweite Maßnahme mit dieser Eigenschaft steht nicht zur Verfügung, und das ist der ehrliche Fall für die Frist im November 2026.
In den Zahlen der Aufsicht steckt ein weiterer Hinweis, den sie selbst überraschend fand: Die Transaktionsprüfung schnitt durchweg besser ab als die Kundenprüfung, was die Aufsicht nicht erwartet hatte, denn ein Kundendatensatz lässt sich in Ruhe prüfen, eine Zahlung im Vorbeiflug. Eine mögliche Lesart ist, dass eine Zahlungsnachricht bestätigende Kennungen mitführt, die ein Kundendatensatz nicht hat. Die Aufsicht zieht diesen Schluss nicht, und dieser Beitrag zieht ihn auch nicht; sie stellt aber fest, dass „besondere Risiken entstehen, wenn die Prüfung dadurch eingeschränkt wird, dass die Kundendaten in den Systemen der Bank anders strukturiert sind als die Daten in den amtlichen Sanktionslisten der Vereinten Nationen und der EU”. Das ist eine Aufsicht, die sagt: Die Datenstruktur entscheidet über das Prüfergebnis.
Der amtliche Apparat sieht es genauso. Der Ausschuss für Zahlungsverkehr und Marktinfrastrukturen bei der Bank für Internationalen Zahlungsausgleich veröffentlichte gemeinsam mit der Payments Market Practice Group im Oktober 2023 harmonisierte Datenanforderungen für ISO 20022 und am 26. Februar 2026 eine überarbeitete Fassung: ein Mindestdatensatz für grenzüberschreitende Zahlungen, mit Spielraum bei der Einführung bis Ende 2027 — und mit dem ausdrücklichen Hinweis, dass es sich nicht um aufsichtsrechtliche Vorgaben handelt. Die Financial Action Task Force ging weiter: Am 18. Juni 2025 teilte sie mit, ihr Plenum habe eine überarbeitete Empfehlung 16 beschlossen, die die Angaben zu Auftraggeber und Empfänger bei grenzüberschreitenden Zahlungen über 1.000 US-Dollar beziehungsweise Euro vereinheitlicht — Name, Anschrift, Geburtsdatum — mit Umsetzungspflicht bis Ende 2030.
Was die Europäische Union stattdessen getan hat
Während die Normungsgremien ein besseres Feld bauten, wählte der europäische Gesetzgeber einen anderen Weg zum selben Problem, und seine Begründung steht im Amtsblatt.
Erwägungsgrund 25 der Echtzeitüberweisungsverordnung hält fest, dass sich bei transaktionsbezogener Prüfung „die große Mehrheit der… gekennzeichneten Transaktionen nach Überprüfung als solche erweist, an denen keine der Personen oder Einrichtungen beteiligt ist, gegen die gezielte finanzielle restriktive Maßnahmen verhängt wurden”, und dass daraus für Anbieter erhebliche betriebliche Schwierigkeiten entstehen. Bemerkenswert ist, was fehlt: eine Zahl. Der Gesetzgeber behauptet eine große Mehrheit und sagt nicht, wie groß, weil es niemand gemessen hat. Nach dem Maßstab, den dieses Haus an sehr weite Spannen anlegt, ist eine unbezifferte „große Mehrheit” dasselbe Eingeständnis: Die Größe wird erschlossen, nicht beobachtet — und sie begründet eine Regel.
Die Regel ist Artikel 5d, durch die Verordnung (EU) 2024/886 in die Verordnung (EU) Nr. 260/2012 eingefügt. Seit dem 9. Januar 2025 müssen Anbieter, die Echtzeitüberweisungen in Euro anbieten, ihre eigenen Zahlungsdienstnutzer mindestens einmal je Kalendertag gegen die gezielten finanziellen restriktiven Maßnahmen der EU abgleichen — und unverzüglich nach jeder neuen Listung oder Änderung. Artikel 5d Absatz 2 untersagt dann die transaktionsbezogene Prüfung gegen EU-Listen für die erfassten Zahlungen. Die Mitgliedstaaten mussten bis zum 9. April 2025 Sanktionen einführen, die bei juristischen Personen mindestens 10 Prozent des Jahresnettoumsatzes und bei natürlichen Personen mindestens 5.000.000 Euro erreichen.
Das ist die größte einzelne Verringerung transaktionsbezogener Sanktions-Fehlalarme im europäischen Zahlungsverkehr, und sie enthält keinerlei Datenformat-Bestandteil. Die EU hat nicht auf die strukturierte Anschrift gewartet, um die Prüfung billiger zu machen. Sie hat die Prüfung abgeschafft und die Pflicht auf den Kundenbestand verlagert, wo die Grundgesamtheit klein und stabil ist und über Nacht abgeglichen werden kann statt in den zehn Sekunden, die einer Zahlung bleiben.
Die Entlastung ist schmaler, als sie aussieht, und der Vorbehalt kommt von Praktikern, nicht aus dem Text. Die Kanzlei Hogan Lovells wies im Februar 2025 für ihre Bankmandanten darauf hin, dass das Verbot nur die Prüfung gegen EU-Listen erfasst. Wer Dollargeschäft hat, steht weiterhin vor der SDN-Liste des US-Finanzministeriums, wer Geschäft im Vereinigten Königreich hat, vor der britischen Sanktionsliste; keine von beiden wird durch eine EU-Verordnung verdrängt. Diese Filter laufen weiter auf der Transaktion. In der Praxis hat das Instrument, das die Transaktionsprüfung abgeschafft hat, sie um eine Liste erleichtert.
Warum das Feld leer bleibt
Die interessante Frage ist nicht, ob strukturierte Anschriften helfen. Sie lautet, warum nach Jahren einer von allen mitgetragenen Umstellung zwei Drittel der Nachrichten sie immer noch nicht führen.
Swifts eigener Satz beantwortet sie: Anschriftsdaten müssen an der Quelle erhoben werden. Die strukturierte Anschrift lässt sich nicht in der Mitte der Kette herstellen. Sie muss vom beauftragten Institut beim Kunden erfasst werden, über einen Kanal — ein Formular im Online-Banking, ein Sammelauftrag aus dem Firmenkundengeschäft, ein Terminal in der Filiale, ein Treasury-System —, und jeder dieser Kanäle wurde für ein Textfeld gebaut. Sie umzubauen heißt: kundenseitige Formulare ändern, gespeicherte Anschriftsdaten für den gesamten Bestand neu prüfen, und Firmenkunden mitteilen, dass ein Dateiformat, das sie seit zehn Jahren nutzen, künftig zurückgewiesen wird.
Diese Arbeit liegt bei der Bank des Auftraggebers. Die Ersparnis liegt woanders. In einer Korrespondenzkette sind es das zwischengeschaltete Institut und die Bank des Empfängers, deren Filter den Alarm auslösen und deren Mitarbeiter ihn abarbeiten. Die Bank, die für die Datenqualität zahlt, ist nicht die Bank, deren Warteschlange kürzer wird. Es ist dieselbe Schieflage, die dafür sorgt, dass die ausgewiesene Marge der kleinste Bestandteil dessen ist, was ein Acquirer tatsächlich verdient: sichtbarer Preis und tatsächliche Wirtschaftlichkeit hängen an verschiedenen Beteiligten.
Schlimmer noch: Der Nutzen ist selbst dort nicht zurechenbar, wo er anfällt. Keine Alarmwarteschlange führt ein Feld, in dem steht, dass dieser Alarm existiert, weil ein Straßenname unbeschriftet ankam. Sachbearbeiter erledigen Alarme; sie klassifizieren nicht deren Ursachen. Eine Ersparnis, die sich nicht zählen lässt, lässt sich nicht einplanen, und ein Datenprojekt der Regeleinhaltung verliert gegen ein Projekt mit aufsichtlicher Frist jedes Mal.
Genau deshalb gibt es die Frist. Swift hat die beauftragten Banken nicht davon überzeugt, dass sich das Strukturieren lohnt; Swift hat dafür gesorgt, dass unstrukturierte Nachrichten ab dem 14. November 2026 am Netzrand zurückgewiesen werden. Wenn sich der Nutzen nicht dorthin lenken lässt, wo die Kosten anfallen, bleibt als Instrument die Zurückweisung an der Grenze. Der Befund von Finansinspektionen, dass die Wirksamkeit mit der Größe der Bank steigt, zeigt dieselbe Ökonomie von der anderen Seite: Datenarbeit in der Regeleinhaltung ist weitgehend ein Fixkostenblock und wird dort ordentlich gemacht, wo es genug Grundgeschäft gibt, um ihn zu verteilen.
Sicherheitsgrade
Fest vertreten: die beiden Einführungszahlen von Swift, die Zurückweisungsregel ab November 2026, die Testergebnisse von Finansinspektionen sowie Wortlaut und Fristen des Artikels 5d. Sie stammen von den Stellen, die sie gesetzt oder gemessen haben.
Mit vernünftiger Sicherheit: dass die Zahl „99 Prozent der Alarme” und die 4,9 Prozent der Aufsicht Verschiedenes messen und miteinander vereinbar sind, und dass die strukturierte Anschrift auf die zweite Größe wirkt und nicht auf die erste. Die Herleitung ist eine Rechnung; die Grundhäufigkeit, die beide verbindet, ist es nicht.
Vorsichtig: die Schätzung von 25 bis 30 Prozent. Ein Beratungshaus, keine offengelegte Methode und ein geschäftliches Interesse an den Projekten, die diese Veränderung liefern. Es ist die einzige bezifferte Schätzung, die diese Recherche gefunden hat — was für sich genommen schon ein Befund ist.
Was daraus nicht folgt
Der Test von Finansinspektionen lief in Testumgebungen gegen eine künstliche Datei mit 5.000 Namen, mit den jeweils eigenen Einstellungen der Banken. Die Aufsicht schreibt ausdrücklich, dass sie keine echten Kunden und keine echten Transaktionen geprüft hat, und zieht keinen Schluss auf tatsächliche Verstöße. Die 4,9 Prozent sind eine Eigenschaft der Systeme in ihrer Einstellung, keine Zählung von Alarmen, die jemand abarbeiten musste. Vier Banken widersprachen ihrem eigenen Ergebnis mit dem Argument, die Testdaten seien nicht so strukturiert gewesen, dass ihr System sie aufnehmen konnte — ein Einwand, der selbst ein kleines Lehrstück zum Gegenstand dieses Beitrags ist.
Die 65 Prozent von Swift sind ein Anteil an Nachrichten, nicht an Beträgen, an Alarmen oder an Prüfaufwand. Eine unstrukturierte Anschrift auf einem Korridor mit geringem Risiko kostet fast nichts; dieselbe Anschrift auf einem Korridor mit starker Listungsbetroffenheit kostet sehr viel. Wie sich die verbleibenden 65 Prozent über die Korridore verteilen, ist nicht veröffentlicht, und ohne diese Verteilung lässt sich die betriebliche Bedeutung der Zahl nicht ausrechnen.
Und niemand hat die Messung veröffentlicht, die den Wirkmechanismus belegen würde: eine Bank, die ihr eigenes Alarmaufkommen über den Stichtag im November 2025 hinweg ausweist, bei unveränderten Schwellenwerten, Listenständen und Geschäftszusammensetzung. Solange kein Institut und keine Aufsicht das tut, bleibt der Fall für strukturierte Daten ein Mechanismus und kein Ergebnis — ein guter Mechanismus, aus ersten Prinzipien hergeleitet, ohne Vorher-Nachher dahinter. Es gibt zudem eine Schadensrichtung, die benannt gehört und die sich aus dem Mechanismus ergibt, nicht aus einem veröffentlichten Befund: Ein Filter, der nur das Namensfeld prüft, sieht einen gelisteten Namen nicht, den jemand absichtlich in die Straßenzeile schreibt. Präzision schneidet in beide Richtungen.
Wozu dieser Fall gehört
Nimmt man die Abkürzungen heraus, ist das eine vertraute Form. Eine Regel schafft eine Fähigkeit. Die Einführung der Fähigkeit wird gemessen, weil Einführung zählbar ist. Die Nutzung wird nicht gemessen, weil dafür jemand ein Ergebnis definieren und verantworten müsste. Das Vorhaben meldet Erfolg gegen die Zahl, die es erzeugen kann.
Dieselbe Form hat eine Empfängernamensprüfung hervorgebracht, die dem Zahler angezeigt wird, ohne zu verschieben, wer den Schaden trägt, und sie hat das Schnittstellenproblem hervorgebracht, das ein Zugangsrecht weniger wert sein ließ als das Gesetz, das es gewährte, bis nach acht Jahren Qualitätsmaßstäbe kamen. In beiden Fällen wurde das vorgeschriebene Artefakt pünktlich geliefert, und das, wofür es gedacht war, blieb sich selbst überlassen.
Der praktische Test lautet, wenn der nächste Datenstandard angekündigt wird, in drei Fragen. Wer muss das neue Feld füllen? Wessen Kosten sinken, wenn es gefüllt ist? Und wird irgendjemand jemals sagen können, ob es gewirkt hat? Nennen die ersten beiden Antworten verschiedene Institute und lautet die dritte nein, bleibt das Feld leer, bis etwas am Rand des Netzes die Nachricht verweigert. Das ist kein Versagen des Standards. Es ist, wozu ein Standard da ist — und der Grund, weshalb eine Zurückweisungsregel mit dem Datum 14. November 2026 für die Sanktionsprüfung vermutlich mehr bewirkt als das Argument, strukturierte Daten seien besser, es je bewirkt hat.
