Fedwire’s ISO 20022 switch gave banks rich payment data their core systems still truncate
A year after Fedwire moved to ISO 20022, the structured message reached most US banks intact. Its value did not, because data was lost at origination, inside banks’ own systems, or in screening and fraud tools never set up to use it.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
July 14, 2026 marked one year since the Federal Reserve moved the Fedwire Funds Service to the ISO 20022 message format in a single-day cutover, replacing a proprietary format used for decades. The change followed the Clearing House’s move of CHIPS to ISO 20022 in April 2024. In November 2025, the period in which banks could still send cross-border payment instructions over Swift in the legacy MT format ended. More was scheduled. Swift’s cross-border payment standards were due, in November 2026, to stop accepting fully unstructured postal addresses, requiring at least a structured town and country. The Federal Reserve had planned a Fedwire release for the same month. In mid-July 2026, US banks were a year into running the new format domestically and preparing for that next tightening of data requirements.
The migration was sold to boards largely on data. ISO 20022 messages carry structured fields for parties, addresses, purpose and remittance information that the old formats either lacked or crammed into free text. Better data was supposed to improve sanctions screening, fraud detection, straight-through processing and customer reporting. A year after the Fedwire cutover, that case still holds, but the benefit depends on a chain of systems, and most banks have only fixed one link. We break the chain into three parts, in the order a payment travels: data in, from the customer and channel that originate it; data through, across the bank’s own systems; and data out, in the tools that are supposed to use it.
Data in: what the originating customer and channel supply
A structured message is only as rich as what goes into it. Many payments still start in corporate customers’ systems, online banking forms and branch processes that capture names and addresses as free text. Mapped into ISO 20022, the result is a message that is technically valid and structurally poor. The address sits in a single line field, the purpose code is blank and remittance information is cut short.
The cross-border address rule was meant to force part of this issue. To meet it, banks need either better capture at origination or reliable parsing of legacy address data. Parsing is faster to deploy and never fully reliable, especially for international addresses. Better capture means changing online banking forms, corporate file specifications and onboarding records, and asking corporate clients to change their own systems. That is a client-communication project as much as a technical one, and it runs on the clients’ timelines.
A practical way to start is to measure. Banks can report, by channel and by client segment, the share of outgoing payments with fully structured addresses, populated purpose codes and complete remittance data. The numbers show where to focus outreach, and they turn a vague data-quality goal into a target someone owns.
Data through: what survives the bank’s own systems
This is where most institutions fell short. To meet migration deadlines, many banks translated incoming ISO 20022 messages back into legacy internal formats. That spared core banking, payment hubs and downstream systems from changing all at once. Translation preserved the transaction but often discarded what did not fit, such as structured addresses, ultimate debtor and creditor details and extended remittance data.
The test is simple to describe. Take a richly populated inbound message and trace which of its fields are still available in each downstream system that might need them. In many banks the payment hub has them, the core does not, and the data warehouse holds whatever the core kept. There are two ways to fix this. One is to change internal data models to carry the full message. The other is to store the original message in a governed repository and make it available by reference. The second is usually faster, and it lets downstream teams adopt fields as they are ready.
Community banks and credit unions face a constrained version of this. Many depend on a core processor or correspondent for payment processing and have little control over internal data models. Their questions belong in vendor conversations: which ISO 20022 fields the provider retains, how the institution can query them, and when the provider’s screening and fraud tools will use them. Those questions carry more weight before a contract renewal than after it.
Data out: where the value is realized
The benefits arrive only in specific consuming systems. Sanctions screening against structured names, addresses and countries can produce more precise matches than screening free text. That happens only if the screening engine is configured to read the structured fields, and if match rules are retuned and tested. Fraud models can gain features such as consistent party identifiers and purpose information, which matter as authorized push payment scams grow. Reconciliation improves when remittance data reaches the receiving customer intact.
Each gain needs its own change, test and measure. For screening, the measure is alert volume and true-match rate before and after structured fields are used. For fraud, it is model performance with the new features. For corporate clients, it is the share of incoming payments that auto-reconcile. Payment messages are now one of the richest structured data sources a bank receives every day. Using them for analytics also requires clear retention rules and access controls suited to the personal data they contain.
The three parts depend on one another, but they need not be done in order. A bank can store full messages now, retune screening next and improve origination capture over a longer period with clients. The mistake is treating the migration as finished because messages flow. A short list of target fields, each mapped to the systems that should receive it and to a dated milestone, gives the remaining work a shape that budget committees can fund and auditors can follow.
With hindsight
From October 2026, the deadline that was meant to force the next step has moved. In late August 2026, after the industry asked for more time, Swift deferred the payments changes in its 2026 standards release, including the removal of unstructured postal addresses. A new timeline is expected around the end of the year. On August 27 the Federal Reserve rescheduled its November 2026 Fedwire Funds release, which carried the same address change, to November 2027. Banks that had invested in address capture and parsing in the first half of the year have not wasted the effort, since the requirement was deferred, not withdrawn. The risk now is that the extra time is used to pause. The Fedwire cutover itself went ahead on schedule, which has made it easy to forget that the internal data work is unfinished. Institutions should follow Swift’s and the Federal Reserve’s published timelines as they are confirmed.