ISO 20022 Migration for the Australian Payments System –
Responses and Options Paper – September 2019
4. Migration Approach

4.1 Summary of responses

4.1.1 Risks and challenges

Respondents identified the need to prioritise the domestic migration project against other initiatives as the most significant of the risks identified in the Issues Paper by likelihood and consequence (risks 1–4, Figure 7). Other issues identified by respondents include: industry capacity; migration challenges (risks 5 and 6, Figure 7); the capacity for vendors to keep up with an aggressive whole-of-industry domestic migration timeline; potential for compliance and screening failures during the coexistence phase; and technical challenges in supporting multiple formats during the coexistence phase. Some responses identified risks arising from a lack of clear regulatory and reporting expectations, particularly in respect of AML/CTF compliance and sanctions screening, during the migration project.

Figure 7: Risks and Challenges
Figure 7: Risks and Challenges

4.1.2 Migration strategy, timing and coexistence

Most respondents preferred a domestic coexistence phase to support the transition from existing MT messages to ISO 20022 messages. Many in the industry agreed with the view that the domestic coexistence phase should be aligned with the beginning of SWIFT's coexistence phase for cross-border payments migration. Some options to manage industry coexistence are discussed in Box C.

Around 55 per cent of respondents support a like-for-like migration followed by adoption of enhanced message content (Figure 8). Support for an initial like-for-like phase was influenced by a general desire to reduce overall project risk by allowing for a phased approach to project delivery. In contrast, other respondents indicated a desire to complete their build as part of a single project. These participants are in favour of a delivery model that provides flexibility by allowing a like-for-like migration with an option to adopt enhanced content. This would allow them to populate messages immediately after implementing their internal build but would not impose any requirements on recipients to process the enhanced content. The requirement to populate and absorb enhanced content would be made mandatory later in the coexistence phase, meaning that participants who choose to migrate later in the coexistence phase would need to migrate straight to enhanced content, without any like-for-like period. These respondents stressed this will allow a participant to commence using enhanced content early if it is ready to do so.

Figure 8
Figure 8: Migration Approach

Some respondents identified potential impediments to migrating domestic payments messaging by the end of 2024, ahead of SWIFT's cut-off for MT cross-border flows. The key theme coming from these responses was the challenge of ensuring internal project investment prioritisation of this initiative against other competing initiatives, e.g. ASX-led CHESS migration and ongoing NPP initiatives, as well as payments-related developments in other jurisdictions. Some respondents have a preference to undertake system builds for both domestic and cross-border migrations simultaneously, while others noted that staging the domestic migration behind the SWIFT cross-border migration could reduce their project delivery risk.

Box C: Options to manage domestic message coexistence

The industry indicated a strong preference for including a coexistence phase in the project approach. This box presents three options for how a domestic coexistence phase might work (Figures 9, 10, and 11).

Option 1: Coexistence of separate MT and ISO 20022 Closed User Groups (CUGs)

Under the first option, two separate CUGs could be managed. These are an ‘MT’ CUG using the SWIFT FIN service (as now), and an ‘ISO’ CUG using the SWIFT InterAct service. Participants would be added to the ‘ISO’ CUG when they are able to both send and receive ISO 20022 messages. Those in the ISO CUG would agree bilaterally to exchange ISO 20022 messages over InterAct with others that have already migrated, and would continue to exchange MT messages over FIN with those not yet migrated. The downside of this approach is that participants are required to continue sending and receiving MT messages until the last participant has migrated. This option removes the need to translate domestic messages between MT and ISO 20022 as MT flows will continue to be part of a separate CUG.

Figure 9: Option 1
Figure 9: Option 1

Option 2: Coexistence of MT and ISO 20022 CUGs and mandatory to receive ISO 20022

A second option could mandate that all participants are able to receive ISO 20022 messages at the beginning of the coexistence phase, which is the option being adopted by SWIFT for the cross-border migration. Under this option, participants that have not yet updated their back office systems to receive and process ISO 20022 messages would need to use a translation service to translate inbound ISO 20022 messages for processing. This would result in some truncation of ISO 20022 message content, with the onus on the receiving institution to manage compliance risks, including passing on the full message content (i.e. including truncated data) where the instruction was received in the ISO 20022 format. This option allows sending institutions to migrate to sending ISO 20022 messages at any time within the coexistence phase that meets their project preferences.

In this option, sending participants that have not yet migrated could continue to send outgoing MT messages through FIN and maintain support for MT/FIN traffic until the end of the coexistence phase. This would require receiving institutions to also maintain their connectivity for inbound MT/FIN traffic until the last FIN CUG member has migrated.

Figure 10: Option 2
Figure 10: Option 2

Option 3: Mandatory capability to send and receive ISO 20022

A third option could rely on the ability of some translation services to translate outbound SWIFT MT messages into ISO 20022. Using translation services, institutions that are not yet ready to send native ISO 20022 messages would send their translated MT messages over the InterAct service. Similar to Option 2, participants would be required to be able to receive ISO 20022 messages from the beginning of the coexistence phase. This approach would immediately implement clearing and settlement of ISO 20022 messaging between participants and would allow institutions to retire back office MT support once they have completed their internal system changes. It is expected that this type of translation service may come at an additional cost. A drawback in this approach is that it requires all participants to be ready to send and receive ISO 20022 messages at the start of the migration period.

Figure 11: Option 3
Figure 11: Option 3

The RBA will support processing of both formats for the duration of the coexistence phase (i.e. it will process and respond in the format the message was received). The RBA will not perform translation of any messages in RITS.

Consultation Questions
  1. Of the options canvassed in Box C, which domestic coexistence option(s) does your organisation support? Please explain your view.

4.1.3 RITS AIF migration

Coexistence will affect some participants' use of the RBA's AIF service, which currently uses the existing MT standards. For the HVCS and batch migrations to ISO 20022, the main potential impact is to the reporting that RITS provides to ESA holders, as these may contain details of settlements that were submitted to RITS by both MT and ISO 20022 instructions.

Some planning is required as certain ISO 20022 fields may be both richer in data and longer in character length and these may not align to the equivalent fields used in current MT AIF messages (such as ESA statements). The RBA will look to consult with industry to help ensure that current MT AIF reporting can continue without impact to ESA holders from the commencement of the coexistence phase. This will occur as part of the industry discussions to determine the ISO 20022 message usage guidelines.

The RBA intends to introduce a new ‘ISO 20022 AIF’ CUG during the coexistence phase and this will run alongside the existing MT AIF CUG. The various services offered by the existing MT AIF CUG will be gradually introduced in ISO 20022 format, subject to equivalent ISO 20022 messaging being available. The intention is for AIF members to have the option of selecting the AIF message(s) they will use from either (or both) the MT AIF CUG or the ISO 20022 AIF CUG until the end of the coexistence phase.

Consultation Questions
  1. For organisations that use the RBA's AIF service, does your organisation have any initial views on the proposed high-level approach for the use of the RBA's AIF service during the coexistence phase?

4.2 Proposed migration approach

The RBA and APC propose a migration approach that comprises a coexistence phase of three years, consistent with the industry's preference. Given responses to the Issues Paper had mixed views on the timing of the introduction of enhanced content, it is proposed that the industry initially adopts a like-for-like migration that allows for enhanced content to be optionally included in messaging. The enhanced content would become mandatory to include in messages at a later stage within the coexistence phase. This approach would allow participants flexibility with their project delivery to include enhanced content at a time that suits their organisation. Some participants may choose to build enhanced content capability up front, while others may prefer to deliver like-for-like message content in the first delivery phase and enhanced content at a later stage of their project. A phased approach should reduce the risk of managing widespread changes across multiple participants and systems across the industry.

The proposed approach, mapped out in Figure 12, entails the following phases:

  1. Consultation, planning and design, and build and test phases are completed over 2019 to 2021.
  2. From November 2021 to November 2023, existing MT messages or new ISO 20022 messages would coexist according to the chosen coexistence option. The ISO 20022 messages would comprise existing fields mapped from MT messages as well as new fields reflecting the enhanced content. Senders would have the option of whether or not to populate the additional fields.
  3. From the beginning of the third year (i.e. from November 2023) enhanced content items (as agreed by the industry) would become mandatory for ISO 20022 messages. MT messages could continue to be generated by those participants that had not yet migrated to ISO 20022. Any participant that chooses to migrate during this year would need to immediately support mandatory enhanced content.

After November 2024, all participants must have migrated to ISO 20022. The RBA intends to no longer support MT messages in RITS.

Figure 12: Proposed Timeline
Figure 12: Proposed Timeline

The timeframe supports organisations that are aiming to align their ISO 20022 adoption with the start of the SWIFT cross-border migration in November 2021. It also enables organisations to choose to introduce support for enhanced ISO 20022 content for domestic messaging any time between November 2021 and November 2023. It should also support organisations that wish to defer their internal migration projects until after November 2023, however, it requires them to move immediately to enhanced content when they do migrate.

Participants that remain on MT messaging after November 2021 will need to manage data truncation resulting from cross-border and domestic payments received in ISO format during the coexistence phase. Participants may also need to manage differences between domestic ISO 20022 message usage guidelines and other international jurisdictions on an ongoing basis. Notably, compliance obligations would still apply to the original message received.

Consultation Questions
  1. Does your organisation agree with the proposed migration approach (like-for-like with optional enhanced content, followed by mandatory enhanced content)? Please explain your view.
  2. Does your organisation support the proposed timeline for the migration project? Please explain your view.