ISO 20022: The Swift AI address structuring model

What does the AI-based address structuring model do?

To assist the community with this transition, Swift has developed a software solution based on Natural Language Processing (NLP)-based AI system to infer structured data (Town and Country) from unstructured legacy address content that can still be found in corporate and client databases, or in payments files received through corporate channels. 

The Town and Country outputs are provided with confidence scores and resolution options to support both automation and expert review. The model also provides diagnostic data to ensure transparency, auditability, and effective decision-making.

Our aim is to enhance data quality, ensure compliance with CBPR+ ISO 20022 standards, address formatting standards and improve operational efficiency in address standardization processes.

Download model

Who is the target audience? Where can the address structuring model be used? 

It can be used by Financial Institutions for cleaning and structuring their client databases, or to fix incoming corporate originated payment files. So, the target audience includes operations and technology teams at financial institutions, service bureaus and Swift partners. 

Many corporate enterprise resource planning (ERP) systems use free text or semi structured fields when storing address information. This means corporates and their payment system providers have databases filled with customer and counterparty addresses in an unstructured format. All of these source systems must be updated to comply with the November 2026 milestone. The data structuring model can help ensure compatibility with these legacy systems and databases.

What is the applicability of the address structuring model (countries, regions) – what data sources does it rely on? 

The address structuring model is calibrated and trained using data from multiple sources, including address templates derived from network data spanning more than 200 countries and territories, open repositories like GeoNames, OpenStreetMap, postal code registries, and custom-generated addresses designed to capture unusual or edge-case formats. It reflects actual statistic user data on the Swift network from all geographies. The model therefore has universal applicability, which enables seamless and consistent global interoperability. 

Does the address structuring model have known limitations? 

The model is not designed for extracting full postal addresses or for purposes beyond Country/Town resolution, to be included in debtor/creditor fields for the MT 103 or pacs.008, where this is the biggest pain point today based on Swift’s study.

Agent fields are mostly identified by BIC8s (~ 97%) for which structured addresses are available (e.g. in the SwiftRef portfolio). Hence the model is not designed to handle free format Agent fields, such as the field 57D for example that identifies where the beneficiary’s account is held. 

There may be limitations when processing addresses in non-standard formats or when encountering new address patterns not covered in training datasets. Additional validation is recommended for low-confidence predictions or critical workflows. 

The model is also designed to extract towns and countries using inputs encoded in Swift character set X. The model performs optimally with inputs in English or transliterated formats. Inputs in non-Latin scripts such as Arabic, Chinese, Cyrillic, or Japanese (CJK) may yield unreliable or unexpected results. 

A full user guide is included with the model distribution package, detailing:

• Sample output formats
• Schema definitions
• Examples of correct and incorrect predictions

Is the address structuring model adaptable? Can it be tuned?

For financial institutions operating across multiple jurisdictions with unique requirements, the address structuring model can be adjusted by incorporating proprietary or additional registries and repositories tailored to specific regions.

The model can also be tuned to switch on inferences or not.

How will the address structuring model be made available? (when, how, how much, for whom) 

To help the community meet ISO 20022 postal address migration deadlines, Swift is - for the first time - delivering the address structuring model as an open-source AI solution, made available free of charge. This reflects our commitment to collaboration, innovation, and the long-term success of the ecosystem in its ISO 20022 migration efforts. It can be integrated into internal systems, standalone tools, or used as a batch-processing engine to pre-process and clean unstructured address fields in legacy message formats. Availability is planned for November 2025.

The model is accessible to the Swift community (e.g. Swift users, service bureaus, vendors, and Swift partners) for everyone to use and build on. It will be made available via the Swift download center on Swift.com, accompanied by a user guide and installation instructions.

Legal terms

The solution is provided to the community as open-source software according to its license terms and the licenses applicable to its components. For comprehensive legal terms, please consult the license agreement.

The license will also be published on Swift.com, outlining the scope of permissible use, modification and redistribution rights granted to the community and other legal terms and conditions. 

The solution is provided “as is”, without warranty of any kind, express or implied. Users accept full responsibility and risk in utilising the solution.

What is the difference between the Swift Translator and the address structuring model? 

The Swift Translator is an easy-to-use, standalone solution that enables you to define, validate, and translate messages to and from any format. It modifies messages to fit the target format, e.g. from MT/MX to MX/MT format. The Swift Translator does not try to resolve Towns and Countries from information available in the message. It maps the Towns and Countries when available to the appropriate destination format. More details about Swift Translator can be found here.

The scope of the address structuring model is more targeted. As input, it only takes in free text containing address information to be included in the debtor/creditor fields of the MT 103 or pacs.008 message and as output infers (predicts) the Town and Country components from the available unstructured data, with confidence scores. It specifically addresses the November 2026 ISO 20022 migration deadline when only fully structured or hybrid addresses will be allowed, with mandatory presence for Town and Country fields. 

Using both tools together could yield more accurate and reliable results.

Does the Swift Translator use the address structuring model?

The address structuring model is not integrated in any Swift products. 

Swift has developed a set of translation rules applicable only to fields 50F and 59F that convert properly formatted ‘F’ fields to the equivalent ISO 20022 hybrid address and vice-versa. These rules are documented in MyStandards and are available in the Standards Release 2025 translation libraries.

How is the address structuring model designed?

The model is a lightweight NLP-based AI system to infer structured address data (Town and Country) from unstructured fields (MT 103 fields 50 and 59). The output is limited to Town and Country predictions. Customers may configure thresholds for regional tuning.

For data scientists: the model is designed around a Conditional Random Field (CRF), a probabilistic graphical model well-suited for structured prediction tasks, particularly where outputs are interdependent. Its primary objective is to extract Town and Country entities from unstructured address strings located in fields 50 and 59 of MT 103 financial messages. The input to the model consists of tokenised components of these address strings, potentially enriched with linguistic and contextual features. 

Training is conducted using a supervised learning approach on synthetic data sets with ground truth labels, that reflect diverse international address formats. 
To support accurate extraction, the model leverages external data sources such as global address datasets, postal code registries, and open-source geolocation databases. The implementation is built using Python and PyTorch, providing a flexible and scalable foundation for model development. This design takes advantage of the CRF’s ability to capture dependencies between adjacent tokens, leading to more accurate identification of location entities in complex or ambiguous address data.

Personal data

The model was trained on synthetic data, generated from templates that reflect the diversity of address structures found in real Swift payments data across all geographies.  No personal data was used for the solution development. 

The model runs fully offline and isolated within the user’s systems.   Users are solely responsible for using the solution and complying with all relevant regulations, including personal data protection.

Will the address structuring model be supported and maintained?

The model is supplied with user documentation and installation notices. Please note that user support and maintenance services are not provided.