Fedwire and ISO 20022, one year on: what changed — and what breaks on 16 November 2026
The Fedwire Funds Service switched to ISO 20022 in a single day, with no coexistence and no fallback. A year later the migration is done, and a second mandatory cutover is already scheduled. Here is what the Federal Reserve itself reports breaking in production, and what to fix before November.
Where does Fedwire ISO 20022 stand, one year after the migration?
The Fedwire Funds Service adopted the ISO 20022 message format on a single day: 14 July 2025. There was no coexistence period — the legacy FAIM 3.0.7 format stopped being supported on Friday 11 July 2025, and messages still sent in it were not accepted. One year on, the migration is complete: Fedwire originated 217.3 million transfers in 2025, averaging about $4.59 trillion a day. A second mandatory release is already fixed for 16 November 2026, and it removes the fully unstructured postal address for every party and every agent, in every message, in favour of a single hybrid format that always requires a town name and a country.
Validate your file right now
Free, instant and 100% in your browser - no file is ever uploaded.
The big bang of 14 July 2025 — and the date everyone still gets wrong
The Federal Reserve did not phase this in. It adopted ISO 20022 for the Fedwire Funds Service on a single day, and it said so in those words. Friday 11 July 2025 was the last day the legacy format was supported; once the service closed at 7 p.m. ET, FAIM-formatted messages were no longer accepted, and any still in flight were deleted over the migration weekend. There was no dual run, no translation layer, no grace period.
The date you will still find in vendor documentation — and in the answers of more than one AI assistant — is 10 March 2025. That was the original date, and it was postponed. The migration happened on 14 July 2025. If a supplier's page still says March, it has not been touched in over a year, which tells you something about the rest of the page.
What disappeared was FAIM, the Fedwire Application Interface Manual: a proprietary, tag-based format where a payment was a series of numbered braces — {1520} for the IMAD, {2000} for the amount, {6000} for the information to the beneficiary. The only legacy left is read-only: past messages stay retrievable for fifteen months, each in the format it was created in.
What actually changed inside the message
The interesting part is not that XML replaced tags. It is the four structural obligations that came with it, each of which breaks a naive integration.
Every message now travels in an envelope: the Business Application Header
head.001 is mandatory, both when you send and when you receive. The header is a separate document from the business message, and the routing number it carries has to be the right one — see the T125 error below. If your integration treats the payment as a single XML document, it is already wrong.
The UETR became mandatory — but Fedwire does not check that it is unique
The Unique End-to-End Transaction Reference is required on the value messages (pacs.008, pacs.009, pacs.004). The Federal Reserve validates its format and states plainly that it does not verify uniqueness. A duplicated UETR will go straight through, and the reconciliation problem lands on you, not on the operator.
The message set is narrower than most people assume
Value: pacs.008, pacs.009, pacs.004. Status: pacs.002. Return request: camt.056, answered by camt.029. Drawdowns: pain.013 and pain.014. Technical rejects: admi.002. Reporting: camt.052, and only camt.052 — there is no camt.053 on the Fedwire Funds Service. Writing one is a category error, not a variant.
Dates, times and amounts are restricted beyond what the schema allows
Fedwire accepts UTC or a UTC offset, and rejects plain local time. The interbank settlement date must be a bare local date (YYYY-MM-DD), because it means a Fedwire business day in Eastern time. Amounts carry no leading plus or minus sign: they are assumed positive. A message can be schema-valid and still be refused on any of these.
What the Federal Reserve itself reports breaking
After the go-live, the Fed published a post-implementation FAQ. It is an unusual and valuable document: the operator's own list of what actually goes wrong in production. Four items are worth memorising, because none of them are schema errors — the file is valid, and it still fails.
Carriage returns inside free-text elements
The Fed explicitly recommends against putting CRLF in free-format text. It is legal XML, it passes validation, and it delays processing or breaks the receiving institution's handling. Strip line breaks out of anything a human typed.
Text elements that contain nothing but spaces
Same family, same outcome. An element padded with spaces is not an empty element, and the Fed advises against sending it. Trim, and omit the element rather than send whitespace.
T125 — the header does not match the connection
The routing number in the From Member ID of the Business Application Header must belong to the owner of the FedLine Direct connection sending the message. This is a wiring error, not a data error, and it is the first thing to check when everything looks correct and nothing goes through.
Using the wrong message to fix a payment
A payment that has already settled is returned with a pacs.004 — never with a new pacs.008 or pacs.009. A request to return one is a camt.056, never a camt.110 investigation. And T134 fires when the Charge Bearer is set to CRED with no charges information attached: use SHAR, or state zero.
The second big bang: Monday 16 November 2026
A year of stability, and then another mandatory cutover — with a cutover weekend on 14-15 November and the last normal day on Friday the 13th. It is not gradual, and it is not optional. Five things to have on the wall.
- 1The fully unstructured postal address disappears. Every party and every agent, in every message, moves to a single hybrid format: town name and country always present, plus at most two free-text lines of 70 characters. The three lines of 35 characters are gone.
- 2The investigation messages camt.110 and camt.111 are redesigned — if you built anything on the 2023 version, it needs revisiting.
- 3An XSD pattern is introduced on text elements. Until now the accepted character set was a matter of recommendation; from November it is enforced by the schema.
- 4The test calendar is already published: two production test Saturdays, 19 September and 31 October 2026, with registration ten business days ahead. A test group is mandatory if you average 100 or more outbound messages a day via import or upload.
- 5Look at the calendar twice. SEPA's structured-address rule bites on 15 November 2026 — the day before. If you send payments on both sides of the Atlantic, this is one address project, not two.
The Fed gives its reason openly: interoperability with the changes Swift and CHIPS are making. This is the same hybrid end-state that the CBPR+ group introduced in November 2025, arriving on Fedwire a year later — which is why the two deadlines land in the same fortnight. It is not a coincidence, and it is not a coordination you can ignore.
Validate a Fedwire message before you send it
Drop a pacs.008, pacs.009, pacs.004 or camt.056 into the validator and see what the Fed would see. It runs entirely in your browser — the file never leaves your machine, which is the only realistic way anyone tests a production wire.
Open the Fedwire validatorOfficial sources
Every fact above comes from the Federal Reserve's own publications: the ISO 20022 Implementation Center, the post-implementation FAQ, the November 2026 release FAQ and the published volume statistics. Where the Fed does not publish something — the exact message version identifiers and the remittance field lengths live in the Implementation Guide on MyStandards, behind a login — this article says nothing rather than guessing.
Frequently Asked Questions
When did Fedwire migrate to ISO 20022?
On 14 July 2025, in a single-day cutover. Friday 11 July 2025 was the last day the legacy FAIM 3.0.7 format was supported. The date 10 March 2025, which still circulates widely, was the original plan and was postponed — it is not the migration date.
Was there a coexistence period between FAIM and ISO 20022?
No. The Federal Reserve adopted ISO 20022 on a single day, with no dual running. FAIM-formatted messages sent after the cutoff were not accepted and were deleted during the migration weekend. The only legacy access left is read-only: past messages remain retrievable for fifteen months, each in the format it was created in.
Which ISO 20022 messages does the Fedwire Funds Service use?
Value messages: pacs.008 (customer credit transfer), pacs.009 (financial institution transfer, including cover) and pacs.004 (payment return). Status: pacs.002. Return request: camt.056, answered by camt.029. Drawdowns: pain.013 and pain.014. Technical rejection: admi.002. Reporting: camt.052. Every one of them is wrapped in a head.001 Business Application Header. There is no camt.053 on Fedwire.
Is the UETR mandatory on Fedwire, and is it checked?
It is mandatory on the value messages — pacs.008, pacs.009 and pacs.004. The Federal Reserve validates the format of the UETR but does not check that it is unique. A duplicate will be accepted, so uniqueness is your responsibility, not the operator's.
What happens on 16 November 2026?
A second mandatory release, with a cutover weekend on 14-15 November. The fully unstructured postal address is removed in favour of a single hybrid format for every party and every agent, in every message; the camt.110 and camt.111 investigation messages are redesigned; and an XSD pattern is applied to text elements, tightening the character set you may send.
Are structured addresses already mandatory on Fedwire?
Not for everyone, and this is the most common misunderstanding. Since July 2025 the hybrid end-state applies only to the Ultimate Debtor, Initiating Party, Ultimate Creditor and Originator. The Debtor, the Creditor and the agents are still on the interim regime: a structured address or up to three free lines of 35 characters, but never both at once. That interim regime ends on 16 November 2026.
How does Fedwire tell me a message was rejected?
With an admi.002. It carries the IMAD of the rejected message in the related reference — or NOTAVAILABLE when the message could not be read far enough to find one. A technical or schema error and a business error are distinguishable by the shape of the identifier the reject carries.
Does this affect CHIPS, FedNow and SWIFT?
CHIPS migrated to ISO 20022 on 8 April 2024, and FedNow has been ISO 20022 native from the start. On SWIFT, the MT/ISO 20022 coexistence for cross-border payment instructions (CBPR+) ended on 22 November 2025 — but that applies to payment instructions: the MT 9xx reporting messages are deprecated, not withdrawn. Fedwire's November 2026 release is explicitly aligned with what Swift and CHIPS are doing.