Article 17/12/09

Canada driving to ISO 20022


Payments infrastructures worldwide are facing intense pressure as the pace of change in the payments ecosystem continues to accelerate. End users demand faster payments and service providers want to be able to offer new services that differentiate them, while at the same time regulatory demands are increasing.

In Canada, as in many other jurisdictions, plans are accordingly being implemented that build up to a complete technology refresh of their core payments infrastructure systems. In line with other projects around the world, the messaging component of the proposed new architecture is based on the ISO 20022 standard.

ISO 20022 allows significantly more information, such as remittance data, to travel with electronic payments. The standard enables solutions and technologies for business automation, including end-to-end straight-through processing, easier payment tracking and system reconciliation. It also has the potential to make cross-border payments much more efficient over time.

Major project elements

The first step for Canada focused on the country’s main retail payments pipeline, Automated Funds Transfer (AFT) batch payments. This uses a proprietary format called Standard 005. In April 2016 an ISO 20022 based message set was introduced in parallel with Standard 005, allowing for voluntary market-driven adoption of the ISO standard with a period of co-existence. Phase II of this part of the project will make the use of ISO 20022 mandatory.

Moving on to the central systems, the roadmap drawn up by Payments Canada involves the replacement of the two major core systems as well as the introduction of a new real-time payments capability:

The existing Large Value Transfer System (LVTS) will be replaced with a new real-time gross settlement system named Lynx. Lynx will initially support SWIFT MT messages, moving to ISO 20022 message standards in a second phase, and will also feature an API-based services layer. At the time of writing Payments Canada is engaged in a procurement process for Lynx. It is intended that Lynx phase I will go live in 2020.

The Automated Clearing Settlement System (ACSS) – which among other things clears the AFT batch payments noted above – will be replaced with SOE, a batch payment, deferred net settlement system for the clearing of lower valued, less time-sensitive electronic and paper-based payments. This functionality was originally envisaged as a module of Lynx, but it was later decided to make SOE a completely separate system. SOE is scheduled to go live in early 2021.

The Real-time Payments Rail (RTR) will be a completely new service to provide ‘instant payments’, using ISO 20022 messaging, and will support overlay services using ISO 20022 based APIs.  In common with other real-time payments systems the RTR will support such features as Request to Pay messages, and aliasing, e.g. using an email address to identify a target payee. The first release of the new system will occur in mid-2019.

Why ISO 20022?

An overriding aim for ISO 20022 adoption is to use common messages across all these systems (Lynx, RTR, and relevant SOE payments streams, including AFT). The intention is also to align with global market practice for message usage (i.e. consistent with the SWIFT ISO 20022 Harmonization Charter), and use the ISO 20022 element names and usage definitions across all payment types (whether batch or single credits/debits). Payments Canada also intends to maintain the most recent version of the ISO 20022 messages, updating them in accordance with the SWIFT annual Standards Release cycle.

Transformer and ISO 20022

Trace Financial’s Transformer is well-placed to help Canadian financial institutions and payment service providers who need to manage the migration from legacy message formats, such as Standard 005 and SWIFT MT, to ISO 20022.

Firstly, Transformer offers high quality libraries of ISO 20022 message definitions, including every version of every message type.

These libraries offer a far better base for projects than, say, a downloaded XML Schema. Transformer libraries provide business-meaningful names and full descriptions at every level from individual fields through higher-level components right up to the whole message itself, and contain complete validation rules – including cross-field validations (which cannot be captured in an XML Schema). The libraries also maximise re-use, providing just one definition for each unique field or other component, which is then be referenced in many messages.

Transformer’s rich, business-meaningful definitions make every aspect of the ISO 20022 standard messages far easier to work with, cutting project timescales and greatly reducing the risk of message rejections.

Secondly, Trace Financial has created a set of bi-directional mappings between SWIFT MT and MX (ISO 20022) formats. These ready-built mappings include a range of special mapping functions created by Trace Financial to handle the conversion of the most complex message components. Transformer’s MT-MX mappings are easy to customise and maintain. The analyst can design and build changes to the mappings directly, with no error-prone hand-off to a separate coding team.

Transformer and the Canadian ACH File Format

Trace Financial also supplies a ready-built library for the ACH File Format used by several of the current Canadian payment streams, including the Automated Funds Transfer (AFT). Our library includes all the messages supported with Standard 005 (including both 1464 Byte and 80 Byte messages) and allows users to quickly build solutions for processing payments using the standard.

Creating mappings

Transformer dramatically shortens the time taken to build mapping and validation solutions involving complex standards. The analyst using Transformer creates solutions directly in the intuitive Design-Time GUI. There is no coding stage, even when the required data transformation is highly complex. In this way projects remain clearly articulated and easy to maintain, and removing the old-fashioned ‘spec handover’ from analyst to developer eliminates a major source of risk and delay. Testing is fully integrated at all stages.

Once solutions are complete and tested they are deployed into any of a wide range of technical infrastructures including Java, .NET, RESTful services, etc.

Working with JSON and APIs

Organisations which will be interfacing via APIs face the challenge of encapsulating the richness of ISO 20022 message formats within a JSON structure.  Transformer addresses this with a range of features that accelerate the creation, deployment and ongoing maintenance of JSON and API-based projects.

Transformer users can now import and export JSON Schemas and use them as Transformer message definitions. Transformer users can also work with OpenAPI (Swagger) specifications.

The use of JSON is evolving rapidly and the format is used in diverse ways by different project teams. Transformer offers a correspondingly wide variety of ways of managing JSON messages. These include importing schemas, importing example messages, authoring structures through Transformer’s own design tool, automatically supporting JSON representations of other messaging standards, layering XSD-style validation constructs over JSON message definitions, and allowing a mapping designer to manipulate and interrogate JSON structures that are only loosely defined.

Users can create outputs in JSON format from any message standard. For example, Transformer’s ISO 20022 library allows the user to create ISO 20022 compliant messages in either XML or JSON.


Payments Canada is orchestrating an ambitious multi-year project involving multiple new systems and migrations between several message standards, with periods of co-existence.

System participants using Transformer can rise to the multiple challenges of ISO 20022 adoption, SWIFT MT and Standard 005 coexistence, and API-based interfaces.