On July 14, 2025, the Federal Reserve completed the Fedwire Funds Service migration to ISO 20022, retiring the legacy FAIM message format that had carried US high-value wires for decades. The change replaces free-text, semi-structured wire data with structured XML messaging. Banks are now rejecting wires that don't include the required address fields. For AP and treasury teams, this is no longer a back-office banking project. It's an operational compliance issue with immediate consequences for vendor master data, payment templates, and any wire that touches a US counterparty.
Why this matters now
The Fed's migration brings the United States into line with the more than 70 countries already operating on ISO 20022, including the Eurozone, the UK and the major SWIFT cross-border corridors. CHIPS migrated in April 2024. Fedwire migrated in July 2025. The SWIFT MT and MX coexistence period on cross-border payments ended November 22, 2025. Fully unstructured addresses will not be accepted after November 2026, adding further pressure on cross-border payments.
The Federal Reserve's implementation FAQ confirms the structured postal address format is now the standard for Fedwire messages, replacing legacy unstructured text. Banks across the network have communicated the same message to corporate customers: include full physical addresses on wire instructions, or expect rejections.
For finance teams, this is the regulatory shift arriving at the payment level. ISO 20022 enables better sanctions screening, sharper fraud detection, and cleaner straight-through processing. These are outcomes regulators and banks have been pursuing for years. The cost of that improvement is that every party in the payment chain now has to supply structured, complete data. Incomplete records that worked under FAIM no longer work under ISO 20022.
What is actually changing
Under the old FAIM format, a wire instruction could include a beneficiary bank reference as a single unstructured line. A typical entry might read simply:
BANK OF AMERICA NYUnder ISO 20022, the same information sits in structured fields within a <PstlAdr> (Postal Address) block:
<PstlAdr>
<StrtNm>Main Street</StrtNm>
<BldgNb>100</BldgNb>
<TwnNm>New York</TwnNm>
<Ctry>US</Ctry>
</PstlAdr>The shift from semi-structured text to structured, machine-readable fields is the entire point of the migration. Compliance engines, sanctions filters, and fraud-detection systems can validate structured data automatically. They can't reliably parse free-text address strings, which is why the legacy format has been a long-standing problem for AML, OFAC, and fraud screening.
For US Fedwire payments using ABA routing numbers, the beneficiary financial institution must now be identified with bank name, physical street address, city, state, and country. Where an intermediary financial institution is involved, the same level of address detail is required for the intermediary. Banks are also increasingly collecting structured address data for the originator, the beneficiary, and any ultimate debtor or creditor, aligning Fedwire practice with SWIFT CBPR+ and broader AML expectations.
Who is affected and how enforcement varies
Every organization that originates US dollar wires through Fedwire is affected, but the requirement is not uniform across every field. The Fed has structured the migration around mandatory fields, optional-but-strongly-recommended fields, and a hybrid end-state that aligns with SWIFT CBPR+. Enforcement varies by bank and corridor, payment type, whether an intermediary is used, and the sanctions risk profile of the payment.
In practice, a US-to-US domestic wire to a well-known beneficiary bank may process with less friction than a cross-border wire involving an intermediary in a high-risk corridor. But the operational reality for AP and treasury teams is what banks are now saying directly to customers: include full physical addresses, or wires may reject.
What compliance means in practice
For finance teams, the work falls into four areas. None of it is new in concept. Each is now non-optional.
Update wire templates. Any saved Fedwire template that pre-dates July 14, 2025 may be missing required structured address fields for the beneficiary bank or intermediary. Templates need to be rebuilt with full physical address data: bank name, street, city, state, country. The old shorthand bank references don't pass validation.
Clean bank master data. Vendor records and bank reference data held in ERP and treasury systems are the source of truth for what gets sent to the bank. If those records contain truncated address fields, non-standard abbreviations, or missing intermediary details, the resulting wire instructions will fail validation. Master data hygiene is now a payment processing prerequisite.
Structure beneficiary records. Beneficiary records need to capture the bank's physical address as structured fields, not free-text notes. Many ERP and AP systems were not designed to enforce this. The fix is at the data-entry and validation layer, not just the output template.
Tighten ERP-to-bank data integrity. The integration between ERP, treasury management system, and the bank's payment channel must preserve structured fields end to end. Converter middleware that flattens ISO 20022 back to legacy formats can truncate exactly the data the Fed now requires.
The common operational failures are predictable: old templates missing bank addresses, incomplete intermediary bank information, truncated address fields, and non-standard abbreviations that break automated validation. Each of these is a fixable data problem. The cost of leaving them unfixed is wire rejection and the manual rework that follows.
What this means for fraud prevention
The migration changes more than payment processing. It changes the data available for fraud detection, and that has direct implications for how AP and treasury teams verify the payments they send.
Under the old free-text format, a beneficiary bank reference like "BANK OF AMERICA NY" carried no validation handles. There was no structured way for a fraud system to check whether the bank existed at the address claimed, whether the entity name and address matched a known institution, or whether the combination of routing number and bank address was consistent. Mule accounts, fake bank references, and mismatched payment parties could slip through controls that were never designed to parse unstructured data.
Structured ISO 20022 data closes some of those gaps. Fake banks become easier to detect because the structured fields can be cross-referenced against authoritative bank registries. Mismatched addresses, where the bank name and the claimed physical location don't align, become a fraud signal rather than noise. Sanctions screening improves because structured party data can be checked against OFAC and other lists without the false positives that plague free-text matching. Mule accounts become easier to identify because the data trail is consistent and machine-readable across the payment chain.
This is the broader shift the migration enables. The bank-level controls that ISO 20022 makes possible only work if the payment data they consume is clean. That data starts inside the finance teams originating the payments.
Where payment assurance fits
The Fedwire migration formalizes something Eftsure has been building toward across the payment lifecycle: that structured, verified party data is the foundation of payment security, not an afterthought. Eftsure's verification approach matches vendor entities to their authoritative bank details using structured data, the same kind of structured matching that ISO 20022 now requires across the US wire system.
For finance teams, this means the work of cleaning vendor master data, validating bank details against authoritative sources, and detecting mismatches between party and bank is no longer a parallel exercise to wire compliance. It's the same exercise. The data quality required to pass Fedwire's new validation gates is the same data quality required to detect Business Email Compromise (BEC), vendor impersonation, and bank detail change fraud before a payment is released.
Eftsure provides end-to-end payment assurance across vendor onboarding, bank detail changes, and pre-payment verification, verifying entity-to-bank matches against authoritative sources so finance teams catch the mismatches before the wire is sent. Eftsure backs verified payments with a guarantee of up to US$1m, subject to Eftsure's standard terms and conditions.
Fix the data before the next wire rejects
The Fedwire migration is operationally real now. Wires are being rejected for incomplete address data, and the November 2026 deadline for fully unstructured addresses will add further pressure on cross-border payments. The finance teams getting this right are treating it as a master data problem first and a template problem second. The templates are only as clean as the records feeding them. The teams who use this migration to fix vendor and bank data structure get something more than wire-processing reliability. They get a payment data foundation that fraud detection, sanctions screening, and AML controls can actually use.
