Fedwire Drops Free-Text Addresses From Wires on 16 November

On 16 November 2026 the Fedwire Funds Service stops accepting the address format most wire instructions have used for decades.

The Federal Reserve's implementation page sets out the change directly. The service intends to "remove the fully unstructured postal address option in favor of a single hybrid postal address format for all parties and agents across all message types."

Read the parenthetical that follows and the operational consequence becomes concrete: the change will "remove three free-text lines of 35 characters each, require town name and country, and allow the option to include other structured address elements such as two free-text lines of up to 70 characters each."

What Is Actually Being Removed

Until now, a payment instruction could carry a counterparty's address as three lines of free text — the digital equivalent of writing an address on an envelope and letting the receiving bank work it out.

After 16 November there is one format, and two of its fields are compulsory: town name and country. Free text does not disappear, but it shrinks to an optional two lines and is no longer the whole address.

The distinction matters because it changes what a payment message must know before it is sent, rather than what a human can interpret after it arrives. A field that a system currently populates with whatever the customer typed now has to resolve into a named town and a country code.

The Rest of the November Release

Two other changes ship on the same date.

The Fed will "make enhancements to the investigation messages (camt.110/camt.111) to enable better structuring of frequently used investigation use cases" — the message types used when a payment has to be traced, queried or corrected after the fact.

It will also add features to the FedPayments Manager – Funds application, including a Create Payment Return capability for past messages.

This Is Not Only a Fedwire Deadline

The Federal Reserve states one of the release's purposes plainly: to "ensure interoperability with modifications that the Swift® service and CHIPS® network (peer operator) will make."

That sentence is the reason this is a cross-border problem rather than a domestic one. Fedwire is aligning its address rules to a change happening across the correspondent banking network at the same time. A firm that fixes its Fedwire messages and nothing else has solved one leg of a payment that usually has more than one.

The precise Swift requirements and their effective date sit on Swift's own documentation, and should be read there rather than inferred from the Fed's alignment statement.

Why Payment Businesses Should Care Before November

Address data is usually the least governed field in a payments stack. It is collected once at onboarding, rarely validated, frequently copied between systems, and almost never revisited.

A requirement that town and country be present, in their own fields, turns that dormant data into a delivery dependency. The work is not in the payment rails. It is upstream: in onboarding forms that accept a single free-text address block, in customer records migrated from older systems, in API schemas that expose one address string, and in every integration where a merchant or platform passes counterparty details through.

None of that is difficult individually. It is slow collectively, because it touches the parts of a system that were built to be permissive.

What the Fed Has Not Said

The implementation page describes what the service will do. It does not state what happens to a message that arrives without a town name or country after 16 November, and it does not publish an enforcement or rejection policy alongside the format change.

Firms planning remediation should therefore treat the format requirement as fixed and the failure mode as unspecified, and should confirm handling with their own correspondent or service provider rather than assume a grace period exists.

The date is not in question. What sits behind it is worth asking about now, while there is still time to change a form field rather than reprocess a payment.