A payments-format deadline on 14 November 2026 is approaching for financial institutions using Swift's cross-border ISO 20022 messaging framework. Under CBPR+, messages must include structured or hybrid postal address information, with town and country supplied in designated fields at minimum for the relevant agents and parties. Swift says fully unstructured addresses will no longer be accepted under the applicable rules. The effect reaches FX, securities, funds and corporate payments—not just ordinary bank transfers.[1]
The change is about payment information, not the message by which a broker places a trade on an exchange or foreign-exchange venue. A forex dealer can execute an order correctly yet still encounter a separate settlement or payout problem if its downstream bank sends a cross-border payment instruction with an unacceptable address structure. Similarly, a broker's withdrawal process can depend on beneficiary details that were collected long before the newer messaging requirements were adopted.[1]
Swift's published guidance explains that payment instructions failing the validation rules may be rejected before submission by the sending institution's own interface. Invalid CBPR+ messages that reach the network are subject to a negative acknowledgement, commonly termed a NAK. The distinction matters for troubleshooting: a rejected payment may never have entered the beneficiary bank's processing queue, so tracing it as a settlement delay at the destination can waste time.[1]
The trading instruction and the payment instruction follow different rules
The specific requirement is not that every bank must provide a complete street address in every case. For relevant agents identified by BIC, Swift says the BIC can still be a valid alternative to providing name and postal address. The guidance also lists certain reporting and administrative message types as exceptions to the town-and-country rule. Firms should check actual message categories and validation rules rather than indiscriminately inserting invented addresses into every field.[1]
Swift reports uneven readiness across the wider payments ecosystem. It notes that a substantial portion of existing messages still contain unstructured addresses and says approximately 65 payment market infrastructures do not yet have aligned implementation plans. Those are warnings about interoperability rather than a prediction that 65 markets will cease operating. A domestic payment rail that permits legacy address formats can still create a problem when the instruction moves into a cross-border CBPR+ leg.[1]
Swift SR2026: practical broker-payments distinctions
| Area | Affected by 14 November change? | Control |
|---|---|---|
| CBPR+ FX and securities payments | Yes, where applicable | Structured/hybrid address validation |
| Broker trade order to trading venue | Not by this address-specific rule | Separate order and venue protocols |
| Agent identified by BIC only | BIC remains a permitted option | Apply correct field and message rules |
| Unsupported unstructured CBPR+ address | May be rejected or NAKed | Remediate source address data |
For broker funding teams, the operational work is to review how account-opening forms, withdrawal instructions, corporate treasury systems and banking partners capture and transmit creditor and debtor address components. Swift says the required address information originates with the relevant parties and cannot be created through a general network contingency solution. The present story is a reminder of an already published November implementation date, not an announcement of a new rule issued on 31 October.[1]
Sources & further reading
- ISO 20022: The removal of unstructured address, frequently asked questions Swift · Accessed 31 Oct 2026