A practical tool for anyone dealing with structured address formatting in financial messaging.

It started with a simple need to transform an unstructured address (as required under the November 2026 payment initiation and execution requirements) into a fully structured format, or at least to indicate the country code and town name as a minimum set of structured data points for the payment party address. 

This may sound like a simple task, but it is not, we can assure you. There are many country-specific practices in address formatting, and even local characters can create issues in the final use of structured or hybrid addresses.

For corporates, the November 2026 deadline is not just a bank-side compliance milestone but a material change in how master data must be collected, governed, and expressed across ERP, vendor master, and payment initiation systems. Existing vendor and customer records that only hold free-text address lines will need to be reviewed, enriched, and in many cases structurally remodelled so that country, town, postal code and other key components can be reliably populated into ISO 20022 elements in payment files. 

If this upstream work is not done in time, the risk of rejected or delayed payments will increase significantly when banks and payment market infrastructures tighten their sanctions and AML screening rules on structured address content.

If you’ve ever worked with ISO 20022 payment messages, you know the pain: taking a perfectly normal postal address (say, “350 Fifth Avenue, Suite 3300, New York, NY 10118, United States”) and breaking it down into a dozen structured XML or further to JSON fields. By hand. Repeatedly. ugh. And we know that sometimes the source systems where the payment counterparty data is stored do not have the capacity to store all the address fields in a structured output.

So, we at Standardised Trust built a tool to do it automatically (with the ability to test it manually first, of course).

Our address converter and its inner workings

The Address Converter (which is available at https://address.standardisedtrust.com/) takes unstructured postal addresses – the kind you’d write on a commercial invoice or other documents – and converts them into the standardised PostalAddress format used in ISO 20022 payment initiation messages (pain.001 V9, if you will). Paste in an address, click Transform, and you get properly structured fields with XML or JSON output ready to use. In manual mode, multiple unstructured addresses can also be fed into the Transformer in a file to get the structured address results in an output file.

You can also run the service with a REST API call and get the response in a JSON payload. There are options to use AI in the address parsing, and if you already subscribe to the Google Address Validation API and have an API key, you can validate address correctness through Google’s service. The output can also be transliterated into ASCII ISO Latin if required. All sensitive credentials are securely stored within the service login, and manual use does not require account creation or login at all.

The tool offers two parsing modes:

• AI-powered parsing, which handles international addresses, unusual formats, and edge cases with high accuracy
• Heuristic (rule-based) parsing, which uses pattern matching for postal codes, country names, and street numbers for more straightforward cases

Every result comes with a confidence indicator (high, medium, or low) so you know when to double-check.

Why ISO 20022 structure as the foundation?

The global financial industry is migrating to ISO 20022 for SWIFT-delivered international payment messaging. The SWIFT deadline for banks has passed, but the grace period for unstructured address usage runs until November 2026. In addition, the EU’s SEPA payment schemes (Instant and Credit Transfers) require structured or hybrid addresses where address data is used, and banks worldwide are updating their systems in line with the November 2026 timeline. Structured address data is no longer optional as it becomes a compliance requirement across many jurisdictions and payment infrastructures.

For corporates, this means that unstructured “free text” address lines can no longer be treated as harmless legacy baggage in payment files, and they must become scrutinised data points in banks’ sanctions and name-screening engines aligned with FATF Recommendation 16 on wire transfers and the travel rule. 

As SWIFT, SEPA, and local ISO 20022-based infrastructures tighten validation of ordering and beneficiary party address elements, incomplete or unstructured addresses can trigger repair workflows, returns, or outright rejections. In a turbulent geopolitical environment where sanctions lists change frequently and regional restrictions evolve quickly, the quality and structure of address data suddenly play a direct role in whether cross-border and even domestic payments can be executed smoothly.

The impact extends beyond SWIFT cross-border payments into SEPA and domestic clearing. Where ISO 20022 XML payment messages carry structured debtor and creditor information, corporates that have not modernised their master data and file formats will face increased friction, at a time when regulators expect greater transparency in payer and payee identification. This creates an urgent but also strategic opportunity to clean up vendor and customer address data, harmonise it across business units, and embed structured addressing as a standard in all payment initiation flows.

This tool won’t solve every compliance challenge, but it removes one of the most tedious parts of the transition, which, as many of us know all too well, is manually reformatting addresses. ​

Beyond compliance: MX as an enabler for better B2B international payments

The change to ISO 20022 MX in international payments is not only about satisfying compliance officers and regulators. By making payment purpose codes, ultimate debtor, and creditor information structurally available (and by introducing structured remittance information in November 2026), corporates gain access to much richer data for automated reconciliation and analytics. 

When address and party data are consistently structured, and the remittance and purpose fields are standardised instead of free-text, payment and reconciliation process harmonisation between banks, corporates, and their trading partners can finally move to the next level.

For B2B flows, this can lead to fewer manual postings, clearer identification of the underlying commercial transaction, and better matching between invoices, payments, and contractual flows in trade and supply-chain finance. 

It is the same line of thinking that has been there since the early ISO 20022 work in the mid-2000s: use structured, reusable data building blocks so that one well-formed payment message can support both regulatory transparency and high-quality automation in corporate back offices. 

The November 2026 deadline is therefore both a challenge and a chance for corporates to close the gap between compliance-driven requirements and the long-term vision of straight-through, data-rich B2B payments.

Try it yourself

The tool is currently free to use at https://address.standardisedtrust.com/. A full online end-user manual and API documentation are available for developers, along with sample addresses to help users get started quickly.

The service has been built as a collaboration between payments domain experts, human guidance, and AI development by Lovable. Because sometimes the best tools come from knowing what’s needed, not just how to code it.