Fedwire’s ISO 20022 switch gave banks rich payment data their core systems still truncate

The week

Every business day, the Fedwire Funds Service moves enormous sums between American banks. It is the Federal Reserve’s own wire system, the pipe banks use when money has to arrive in full, right now, and cannot be called back. On July 14, 2026, that pipe marked an anniversary most people outside banking never noticed.

One year earlier, the Federal Reserve had switched Fedwire to a new message format called ISO 20022, and it did so in a single-day cutover. That meant changing the language every bank uses to describe a payment, all at once, overnight. The old format was proprietary, used for decades and built for a time when a payment message needed little more than an amount, an account and a name. ISO 20022 is an international standard that works more like a well-designed form: separate, labeled boxes for who is paying, who is being paid, where each of them lives, why the money is moving and what invoice it settles.

Fedwire was not alone. The Clearing House, which runs CHIPS, the other major US system for large-value payments, had already moved CHIPS to ISO 20022 in April 2024. Internationally, banks send cross-border payment instructions over Swift, the global messaging network that connects banks around the world. In November 2025, the period in which banks could still send those instructions in Swift’s legacy format, known as MT, came to an end.

And more was on the calendar. Swift’s cross-border payment standards were due, in November 2026, to stop accepting fully unstructured postal addresses. A bank could no longer send an address as one long line of text; at the very least, the town and the country would have to sit in their own labeled boxes. The Federal Reserve had planned a Fedwire release for the same month.

So in mid-July 2026, US banks were a year into running the new format at home and bracing for the next tightening of data requirements. The messages were flowing. The open question, and the subject of this piece, was whether banks were actually getting anything out of the richer data those messages could now carry, or whether much of it was being thrown away somewhere between the customer and the systems that were supposed to use it.

When banks asked their boards to fund the move to ISO 20022, the pitch was mostly about data. The new messages carry structured fields for the parties to a payment, their addresses, the purpose of the payment and the remittance information that tells a company which invoice is being paid. The old formats either lacked those fields or crammed the information into free text, the way a note scrawled on the back of a check might say “for March rent, unit 4B.” Better data, the argument went, would mean sharper sanctions screening, better fraud detection, more payments processed without a human touching them, and better reporting for customers.

A year after the Fedwire cutover, that case still holds. But the benefit depends on a chain of systems, and most banks have fixed only one link. A payment travels in three stages: data in, from the customer and the channel where the payment starts; data through, across the bank’s own internal systems; and data out, in the tools that are supposed to put the data to work. First, what changed and what did not.

From free text to labeled boxes

A payment message is the instruction one bank sends another: move this amount, from this account, to that account, for this person. For decades, many of these messages used compact, bank-specific formats designed when computer storage was expensive and every character counted. Information that did not have its own field went into a free-text line, and different banks filled that line in different ways.

ISO 20022 is a global standard for financial messages. Its main idea is structure. Instead of one line that says “Acme Supply Ltd, 12 Harbour Road, Leeds, UK, payment of invoice 5531,” the message has a field for the name, separate fields for street, town, postcode and country, a field for the purpose of the payment, and room for detailed remittance information. A useful comparison is the difference between a handwritten letter and a tax form. Both can carry the same facts, but only the form lets a computer reliably find “country” without guessing.

Two more terms matter for what follows. A cutover is the moment a system stops using the old way and starts using the new one. Fedwire’s was a single-day cutover: one day, every participant switched together. And a core banking system is the bank’s central ledger, the system of record that holds accounts and balances and posts every transaction. In many banks it is decades old, deeply customized and the hardest thing in the building to change.

Switching the format on the wire between banks does not, by itself, change what happens inside any bank. The message can arrive perfectly structured and then be squeezed back into an old shape the moment it lands. That is what makes this a leadership issue rather than a finished project.

Data in: what the customer and channel actually supply

A structured message is only as rich as what goes into it. Many payments still begin in places that capture names and addresses as free text: a corporate customer’s accounting system, an online banking form with a single “address” box, a branch process where a staff member types what the customer says. When that information is 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 the remittance information is cut short.

Suppose a regional bank’s business customers upload payment files from their own finance software, and one large client, a distributor, sends hundreds of payments a week, each with the supplier’s address typed in one line, because that is how its system has stored addresses for fifteen years. The bank can transmit those payments in ISO 20022, and they will pass. But the structured boxes for town and country will be empty or guessed at, and every downstream benefit shrinks accordingly.

The cross-border address rule was meant to force part of this issue. To meet it, banks need either better capture at the point where the payment starts, or reliable parsing of legacy address data, meaning software that reads a line of text and tries to split it into street, town and country. Parsing is faster to deploy and never fully reliable, especially for international addresses, where formats vary enormously and a town name can also be a street name somewhere else.

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, not the bank’s. A relationship manager may need to explain to a treasurer why the bank is asking for work that brings the client no obvious benefit this quarter.

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. A board that sees a specific percentage of corporate payments fully structured, an owner such as the head of transaction banking, and a target date has something to follow up on. A board that hears “we are improving data quality” does not.

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 was a reasonable choice under time pressure. It spared the core banking system, the payment hub and every downstream system from having to change all at once. A payment hub is the software that sits between the outside payment networks and the bank’s internal systems, routing and checking payments as they come and go.

The trouble is what translation does. It preserves the transaction, the amount and the accounts, but it often discards what does not fit the old shape: structured addresses, details of the ultimate debtor and creditor (the real parties behind a payment made on someone else’s behalf) 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. A data warehouse is the central store that analysts, risk teams and regulators’ reports draw on, so whatever disappears before it reaches the warehouse is invisible to most of the bank.

There are two ways to fix this. One is to change internal data models to carry the full message, which is thorough and often slow and expensive, because it touches the core. The other is to store the original message in a governed repository and make it available by reference, so any system that needs a field can look it up. The second is usually faster, and it lets downstream teams adopt fields as they are ready rather than waiting for one large program. “Governed” matters here: the repository needs clear rules on who can see what, how long messages are kept and how they are protected.

Community banks and credit unions face a constrained version of this. Many depend on a core processor or a correspondent bank 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. A credit union negotiating a renewal has bargaining power it may not have again for years, which is why these questions belong on the procurement checklist now.

Data out: where the value is realized

The benefits arrive only in specific systems that consume the data. Three matter most.

Sanctions screening. Banks must check payments against government lists of people, companies and countries they are not allowed to deal with. Screening against free text is crude: a name that happens to contain a sanctioned word can trigger an alert, and every alert has to be reviewed by a person. Screening against structured names, addresses and countries can produce more precise matches. That happens only if the screening engine is configured to read the structured fields, and if match rules are retuned and tested. Without that work, the engine keeps reading the old free-text version and the new fields sit unused.

Fraud detection. Fraud models are software that scores each payment for risk based on patterns. They can gain new inputs, such as consistent party identifiers and purpose information. That matters as authorized push payment scams grow. In those scams, criminals trick a real customer into sending money themselves, so the payment looks legitimate on every technical check. Better information about who is being paid and why gives the model more to notice.

Reconciliation. When a company receives a payment, its finance team has to match it to an invoice. If the remittance data arrives intact, software can do that automatically. If it is cut short, someone in accounts receivable does it by hand, phoning customers and digging through emails. For a bank’s corporate clients, intact remittance data is one of the most tangible benefits of the whole migration.

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, because a message with a full name, address and purpose is exactly the kind of information privacy rules care about.

A program budget committees can fund

The three stages 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. A program that works has a few recognizable features:

• A short list of target fields, such as structured address, purpose code, ultimate parties and remittance data, each mapped to the systems that should receive it.
• A dated milestone for each field and each system, with a named owner.
• Before-and-after measures for every consuming system, so the benefit is shown rather than assumed.
• A governed store of original messages, so nothing is lost while internal systems catch up.
• A client outreach plan for corporate customers whose files are the source of poor data.

The failures are just as recognizable. The biggest is treating the migration as finished because messages flow. Compliance with the network’s format is the floor, not the payoff. A second is relying entirely on parsing to fix addresses, which works most of the time and fails silently the rest. A third is leaving screening and fraud tools on their old settings, so the new data never reaches the decisions it was meant to improve. A fourth is ignoring the privacy side, collecting richer personal data without deciding how long to keep it or who may use it.

Consider a mid-sized bank that did the format work on time and then stopped. Its compliance team still reviews roughly the same volume of screening alerts as before. Its corporate clients still call about unmatched payments. Its fraud team has never been told new fields exist. Nothing is broken, which is exactly why nobody is asking. 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.

What the board paid for

The money was already spent. Banks funded the migration on the promise of better data, and a board is entitled to ask whether its core systems are keeping that promise or truncating the data the bank paid to receive. Regulators care about sanctions screening and fraud controls, and those are precisely the areas where unused data is a missed improvement. Customers notice when their payments reconcile automatically, and when they do not. And the next deadline, whenever it lands, will be easier for banks that have already fixed their data at the source.

There is also a less visible risk. A bank that discards rich data inside its own walls may find, during an investigation or an audit, that information it received was not available when it mattered. Being able to show what a payment message said, and how it was used, is a simple form of protection.

Where the payment data is still being lost

1. What share of our outgoing payments carry a fully structured address, a purpose code and complete remittance data, broken down by channel and client segment? Who owns improving that number?
2. If we trace one richly populated inbound message through our systems, which fields survive into the core, the data warehouse, screening and fraud tools?
3. Has our sanctions screening engine been configured and retuned to use structured fields? What happened to alert volume and true-match rate when it was?
4. If we rely on a core processor or correspondent, what exactly have they told us about the fields they retain and when their tools will use them, and is that written into our contract?
5. What is the dated plan for the remaining work, and how will we know when the benefits we promised the board have actually arrived?

With hindsight

The deadline that was meant to force the next step 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.

For banks that had invested in address capture and parsing in the first half of the year, this is not wasted effort. The requirement was deferred, not withdrawn. Every corporate client persuaded to send structured addresses, every online banking form redesigned and every parsing rule tested is still work the bank will need. It simply has more time to finish it properly.

The risk now is that the extra time is used to pause. Deadlines are what move work up the queue in most banks. When a deadline slips, budgets and people are often moved to whatever is due next, and half-finished data projects lose momentum. Corporate clients who were reluctant to change their files will be even less eager now that the date is further away.

There is also a subtler trap. The Fedwire cutover itself went ahead on schedule and has run without drama, which has made it easy to forget that the internal data work is unfinished. From the outside, everything looks done. Payments move. The format is the new one. The gaps are inside: in the payment that arrives with a blank purpose code, in the core system that never received the structured address, in the screening engine still reading free text.

A regulatory deadline is a forcing device, not the goal. The goal was better data in the systems that make decisions about risk and customers, and that goal has no deadline attached. A bank that uses the extra year to finish origination fixes with corporate clients, store full messages and retune screening will be ahead whenever the new date arrives. A bank that waits will face the same work later, under more pressure.

Institutions should follow Swift’s and the Federal Reserve’s published timelines as they are confirmed.