ISO 20022 Programme

Customer Adoption Guide

This document helps customers adopt to the ISO 20022 and CBPR+ standards. It provides timelines and a set of
checklists to help the customer plan and adopt the standard according to the customers' needs.

28 January 2022

Link to this document: https://www2.swift.com/go/book/book200789

ISO 20022 Programme Table of Contents
Customer Adoption Guide

Table of Contents

Overview............................................................................................................................................................ 4
Adoption of ISO 20022 for Cross-Border Payments.................................................................................................... 4
Documentation to Support your Readiness................................................................................................................. 4
Key Sources for Further Detailed Information..............................................................................................................5
Change Log..................................................................................................................................................................5

1 ISO 20022 and CBPR+.............................................................................................................................7

1.1 Your Checklist..........................................................................................................................................7

2 Technical Prerequisites.........................................................................................................................12
2.1 Your Checklist........................................................................................................................................12

3 FINplus and SWIFTNet Store-and-forward..........................................................................................17

3.1 Configure your Connection to SWIFTNet.............................................................................................. 17
3.2 FINplus Service Subscription.................................................................................................................18
3.3 Connectivity........................................................................................................................................... 18
3.4 Addressing.............................................................................................................................................26
3.5 Relationship Management.....................................................................................................................27
3.6 Environment Scaling..............................................................................................................................27

4 Communication Interfaces................................................................................................................... 32
4.1 SWIFTNet Link...................................................................................................................................... 32
4.2 Alliance Gateway...................................................................................................................................32
4.3 Alliance Remote Gateway..................................................................................................................... 32
4.4 Third-Party Products..............................................................................................................................32

5 Messaging Interfaces............................................................................................................................ 33

6 Translations........................................................................................................................................... 34
6.1 In-Flow Translation................................................................................................................................ 34
6.2 Local Translations..................................................................................................................................35
6.3 Third-Party Products..............................................................................................................................36

7 Testing.................................................................................................................................................... 37
7.1 SWIFT Standards Testing......................................................................................................................37
7.2 Loopback Testing...................................................................................................................................37
7.3 SWIFT Test Sparring Partner.................................................................................................................38

28 January 2022 2
ISO 20022 Programme Table of Contents
Customer Adoption Guide

7.4 Community Testing................................................................................................................................ 39

7.5 Non-functional Testing........................................................................................................................... 39
7.6 ISO 20022 Readiness Directory............................................................................................................ 39

8 Other SWIFT Initiatives......................................................................................................................... 40

8.1 SWIFT gpi and ISO 20022.....................................................................................................................40
8.2 ESMIG................................................................................................................................................... 41

Legal Notices................................................................................................................................................... 42

28 January 2022 3
 ISO 20022 Programme Overview
Customer Adoption Guide

Overview
This document helps support customers in their ISO 20022 CBPR+ adoption efforts. Each section
focuses on a specific topic and is structured as a checklist, with suggested steps and pointing to
available resources for more detailed information.
The Customer Adoption Guide will be updated as new information becomes available on a regular
basis.

Adoption of ISO 20022 for Cross-Border Payments

MT messages and FIN
For over 40 years, the MT messages transported over FIN have been a well-established financial
standard supporting cross-border payments and reporting (CBPR+). MTs global adoption and
continuous growth make it well embedded in core banking systems, including payment application/
hub, middleware, reconciliation, AML/KYC, archiving and reporting applications.

ISO 20022 MX messages and the new FINplus service

Based on a community decision, FIN retirement for cross-border payments and reporting
scheduled for November 2025, enabling 3 years for the industry to adopt new ISO 20022 (MX)
messages transported over FINplus, starting November 2022. ISO 20022 messages enable for a
richer content and are better structured. Payment actors must plan their back-office applications
and infrastructure readiness for the new FINplus service that will require technology and adoption
approach decisions, certainly influenced by the nature of your customers or your primary role in the
chain of cross-border payments.

Co-existence period
In-flow translation and the Transaction Manager will provide interoperability measures for the 3-
years coexistence period giving opportunity to each bank to send ISO 20022 messages at its own
pace.
By November 2022, you can choose one of the following options:
• (native) ISO 20022 messaging user
• remain (at least, partial) MT user
• digital native user, with a preference for integration through APIs
Whatever your profile and adoption approach, you must undertake a messaging interface upgrade
to be ready to receive multi-format messages (ISO 20022 MX with embedded translated MT from
November 2022.

Documentation to Support your Readiness

To help you prepare for the go live on ISO 20022 in November 2022, the start of the coexistence
period and the introduction of SWIFT’s enhanced platform, SWIFT has developed a suite of
supporting documents. These set out the steps to take in relation to implementation activities.
• The From FIN to FINplus Getting Started document is an entry-level reference guide, listing the
key project steps towards readiness for ISO 20022-based exchanges over the FINplus
messaging service. It highlights important considerations in moving from FIN to FINplus
messaging and points to more detailed information sources for readers who want to know more.

28 January 2022 4
 ISO 20022 Programme Overview
Customer Adoption Guide

• The ISO 20022 Customer Adoption Guide expands on the FIN to FINplus Getting Started guide.
It includes information on learning resources covering ISO 20022 and the Cross Border
Payments and Reporting+ (CBPR+) guidelines, and on how to configure and test messages
over the FINplus service.
• The ISO 20022 Market Infrastructure Adoption Guide is the equivalent of the Customer
Adoption Guide for market infrastructure (MI) operators. The content supports MIs and their
communities of participants in the process of adopting ISO 20022.
• The SWIFT Platform Evolution: Connectivity Guidance document sets out the vision shared by
SWIFT and its community for instant and frictionless payments, through connectivity to the
SWIFT platform as it evolves based on the concept of transaction management. The document
sets out the options available for connecting to the platform.
• The SWIFT Platform Getting Started Guide complements the Connectivity Guidance document
with information on the operational actions required to access the platform. It helps customers
to plan their implementation and get ready for transaction management capabilities.

Key Sources for Further Detailed Information

The documents listed in the previous section build on top of the detailed products and services
documentation that provide the most comprehensive level of published information.
That detailed documentation is available in one of the following three main area:
• MyStandards for everything you must read on Standards. It hosts amongst other information,
the CBPR+ User Handbook, CBPR+ Usage Guidelines and static testing portals, the Readiness
Portal and the Translation Portal
• The Knowledge Centre (User Handbook) for everything you must read on SWIFT services and
products, centralising all detailed documentation, such as service descriptions, release letters
and user guides. It also contains the Knowledge Base articles and how-to videos.
• The SWIFTSmart platform offering e-learning modules ranging from the basics of XML and ISO
20022, to messages specifications, and SWIFT services and products
Make sure to also bookmark our ISO 20022 Customer Adoption Support Page, your one-stop shop
for information related to adoption of ISO 20022 and CBPR+.
Note Remember to log in to see protected publications. You can also customise your view
of the Knowledge Centre, see the Knowledge Centre User Guide.

Change Log
This section describes the most recent changes made to this document.

Date Description Location

5 March 2020 Editorial fixes, additional sections Entire document

17 April 2020 Major date change, document taken Entire document

down

8 July 2020 Document republished, FINplus content FINplus and SWIFTNet Store-and-
added forward on page 17

9 September 2020 Editorial fixes, additional sections Entire document

28 January 2022 5
ISO 20022 Programme Overview
Customer Adoption Guide

Date Description Location

18 February 2021 Editorial fixes, additional sections Entire document

18 February 2021 AMH reference information added Connectivity on page 18

Relationship Management on page
27

21 May 2021 Editorial fixes, additional sections Entire document

30 November 2021 Editorial fixes Entire document

Removal of section Your Adoption
Journey
The messaging interfaces section is now
part of the SWIFT Platform Getting
Started

New sections in the Overview Overview on page 4

Addition of the in-flow translation service In-Flow Translation on page 34

Addition of the Testing section Testing on page 37

Addition of the ISO 20022 Readiness ISO 20022 Readiness Directory on

Directory section page 39

28 January 2022 Addition of MX messages Read the CBPR+ User Handbook

on page 8

New version of CBPR+ guidelines Read the CBPR+ Usage

Guidelines on page 9

New timeline for FINplus service FINplus Service Subscription on

subscription page 18

New testing guidelines document Community Testing on page 39

published

28 January 2022 6
ISO 20022 Programme ISO 20022 and CBPR+
Customer Adoption Guide

1 ISO 20022 and CBPR+

Purpose
This section provides guidance in building knowledge about ISO 20022 and the Cross-Border
Payments and Reporting Plus (CBPR+) group, starting from the basics to the details of message
flows and message specifications.

Intended Audience
This section is for anyone involved in an ISO 20022 adoption project at the customer side. The
reader can choose the level of details that they want to achieve depending on the needs of their
role on that adoption project.
Note SWIFT is working closely with its partner community to ensure they have access to
necessary documentation, tools and test services so they can be ready in time, and at
quality, to support our shared customers in adoption of ISO 20022 and CBPR+. For
more information, browse to our Vendor Readiness page.

1.1 Your Checklist

Your Timeline
0. Learn the Basics on page 8 Project Team
1. Read the Frequently Asked Project Team
Questions on page 8
2. Read the CBPR+ User Business Analyst
Handbook on page 8
Functional Analyst

3. Watch the ISO 20022 Adoption Project Team

Briefings on page 8
4. Read the CBPR+ User Business Analyst
Handbook on page 8
Functional Analyst

4. Read the CBPR+ Usage Business Analyst

Guidelines on page 9
Functional Analyst

5. Follow the SWIFTSmart Project Team

Learning Modules on page 10
6. Map Your Message Flows on Business Analyst
page 10
Functional Analyst

7. Perform your Impact Project Manager

Assessment and Define your
Implementation Project on page
10

28 January 2022 7
ISO 20022 Programme ISO 20022 and CBPR+
Customer Adoption Guide

1.1.1 Learn the Basics

The ISO 20022 Programme Hub on swift.com gathers the latest information including the ISO
20022 adoption timeline, what to expect during the coexistence period, upcoming events, and
more.
The Document Centre stores customer resources for public usage, such as videos, case studies,
whitepapers. Read the ISO 20022 For Dummies e-book which gives more information about why
ISO 20022 matters and its benefits.
The "ISO 20022 in Bytes" newsletter is published every two months. If you would like to receive it
then select "ISO 20022" (under the "Standards" category) as one of your interests in the SWIFT
Preference Centre.

1.1.2 Read the Frequently Asked Questions

The ISO 20022 Adoption FAQ provides answers to the questions you may have about ISO 20022.

1.1.3 Watch the ISO 20022 Adoption Briefings

The ISO 20022 Adoption Briefings are short videos (20 minutes or less) and feature SWIFT experts
walking you through the many facets of adopting ISO 20022 and CBPR+. They are available in
several languages and you can find them all on our SWIFTSmart platform, logically arranged as a
dedicated learning curriculum.
Adoption Briefings available at the time of publication:
• a recap of the scope, roadmap and resources of ISO 20022 adoption
• an introduction to CBPR+ usage guidelines and the features offered by the MyStandards
environment
• an introduction to FINplus, the messaging service for exchanging CBPR+ (and other ISO
20022) messages
• an explanation of the scope of the CBPR+ 2.0 collection of usage guidelines
• a walk-through to the various steps in testing CBPR+ messages and flows
• an introduction to the concepts of in-flow translation and multi-format MX messages
• a walk-through some considerations in moving from FIN to FINplus messaging

1.1.4 Read the CBPR+ User Handbook

The CBPR+ User Handbook is published on MyStandards and explains how the new ISO 20022
messages will be used. It captures the changes in payment flows between counterparties, new
terminology and concepts, and other details important to customer’s payment operations.
At the time of this publication, the CBPR+ User Handbook includes the following:
• Introduction to ISO 20022
- head.001 - Business Application Header
- pain.001 - Interbank Customer Credit Transfer Initiation
- pain.002 - Interbank Customer Credit Status Report
• Payment, Clearing and Settlement (pacs) messages

28 January 2022 8
ISO 20022 Programme ISO 20022 and CBPR+
Customer Adoption Guide

- pacs.008 - Financial Institution to Financial Institution Customer Credit Transfer

- pacs.009 (core) - Financial Institution Credit Transfer
- pacs.009 (cov) - Financial Institution Cover Credit Transfer
- pacs.009 (adv) - Financial Institution Advice Credit Transfer
- pacs.002 - Financial Institution to Financial Institution Payment Status Report
- pacs.004 - Payment Return
- pacs.010 - Financial Institution Direct Debit
• Cash Management (camt) messages
- camt.052 - Bank to Customer Account Report
- camt.053 - Bank to Customer Statement
- camt.054 - Bank to Customer Debit Credit Notification
- camt.057 - Notification to Receive
- camt.060 - Account Report Request
• Exceptions and Investigations messages
- camt.056 - Payment Cancellation Request
- camt.029 - Resolution of Investigation

The CBPR+ User Handbook is updated on a quarterly basis. It is accompanied by a library of

sample messages. For more information about various use cases, see CBPR+ Sample Messages.
Note A SWIFT certification on ISO 20022 and CBPR+ messages is also available. For more
information, see Certification Tracks on swift.com.

1.1.5 Read the CBPR+ Usage Guidelines

CBPR+ Usage Guidelines are available for download in multiple formats on MyStandards.

Important Based on change requests from the community, SWIFT has published an updated
v2.1 of the CBPR+ Usage Guidelines on MyStandards.

The Usage Guidelines cover the following list of messages:

• pacs.008 - Financial Institution to Financial Institution Customer Credit Transfer
• pacs.009 - Financial Institution Credit Transfer (core and cov cases)
• pacs.010 - Financial Institution Direct Debit
• pacs.002 - Financial Institution to Financial Institution Payment Status Report
• pacs.004 - Payment Return
• camt.053 - Bank to Customer Statement
• camt.054 - Bank to Customer Debit Credit Notification
• camt.052 - Bank to Customer Account Report
• camt.057 - Notification to Receive
• camt.060 - Account Report Request
• head.001 - Business Application Header
• pacs.009 - Financial Institution Credit Transfer (ADV case)

28 January 2022 9
ISO 20022 Programme ISO 20022 and CBPR+
Customer Adoption Guide

• pain.001 - Interbank Customer Credit Transfer Initiation

• pain.002 - Interbank Customer Payment Status Report
• camt.056 - Payment Cancellation Request
• camt.029 - Resolution of Investigation

In addition to dynamic translation rules and testing features already available on the CBPR+
Translation Portal, the first set of translation rules have been published in Excel and PDF formats
for offline reference.
This is only provided for customer convenience. You should always refer to the latest, up-to-date
translation rules in the CBPR+ Translation Portal.

1.1.6 Follow the SWIFTSmart Learning Modules

There are several e-learning modules available to support you. They are gathered in several
curricula that you can consult on our ISO 20022 adoption page on SWIFTSmart.
• Payments Industry - Get a view on the payments market and understand the standards for
payments
• CBPR+ - Understand how to interpret and populate an ISO 20022 message following the CBPR
+ guidelines
• SWIFT Messaging - Understand the basics of SWIFT messaging and solutions
• FINplus - Understand how you can use ISO 20022 format messages with FINplus
SWIFT will publish several SWIFTSmart modules over the next months to cover message details
and product changes. The complete SWIFTSmart catalogue can be consulted here.

1.1.7 Map Your Message Flows

You can begin to map your existing payments, reporting flows and message formats to the ISO
20022 and CBPR+ counterparts. This allows you to identify gaps and required changes.
SWIFT Services can provide necessary expertise in the execution of such mapping exercises, and
other ISO 20022 adoption activities like CBPR+ training. This will help save you time and effort,
allowing you to concentrate on your business. For more information, see the ISO 20022 Services
Info Sheet.
Customers can also consider SWIFT's product offering for further specifying and implementing a
mapping solution.
• SWIFT Translator can be used to design and perform message validation and translation from
any to any format.
• SWIFT Translator Validation and Translation Libraries for CBPR+, which can be customised
using SWIFT Translator to meet additional needs.
For more information, see Translations on page 34.

1.1.8 Perform your Impact Assessment and Define your

Implementation Project
Message flows and formats are only one dimension of adopting ISO 20022 for a financial
institution. Gaps and required changes that you identified in the previous step must be considered

28 January 2022 10
ISO 20022 Programme ISO 20022 and CBPR+
Customer Adoption Guide

from the broader perspective of your payment processing and reporting architecture (such as for
example, front end, back-office screening, reconciliation).
SWIFT Professional Services can also provide necessary expertise in the execution of such impact
assessments, the production of traffic analysis and reports, and other ISO 20022 adoption
activities. This will help save you time and effort, allowing you to concentrate on your business. For
more information, see the ISO 20022 Services Info Sheet.

28 January 2022 11
ISO 20022 Programme Technical Prerequisites
Customer Adoption Guide

2 Technical Prerequisites
Purpose
This section prepares you for the adoption to ISO 20022 and FINplus, make sure you have all
prerequisites in order.

Intended Audience
This section is for any team in contact with SWIFT services and products which may be impacted
by the ISO 20022 adoption.

2.1 Your Checklist

Topic Check Your Timeline
Role Management on
page 13
swift.com Who are my swift.com
administrators?
My swift.com
administrator can log in
on to swift.com.
SWIFTNet Offline Who are my offline
security officers security officers?
Do my offline security
officers have a valid
secure code card?
Can my offline security
officers log in into Secure
Channel?
SWIFTNet Online Who are my online
security officers security officers?
Do my online security
officers have a valid
certificate?
Can my online security
officers log in into the
SWIFT online operations
manager (O2M)?
Capacity Planning on
page 14
Bandwidth What bandwidth do I
have in place?
What is my current peak
bandwidth usage?
What is my current/future
business need
(transactions per
second)?

28 January 2022 12
ISO 20022 Programme Technical Prerequisites
Customer Adoption Guide

Topic Check Your Timeline

System What is the current
system load for all
systems in the SWIFT
stack (CPU and memory
usage)?
Relationship
Management Application
(RMA) on page 15
RMA service obligations A connection to your
BIC8 RMA queue is
configured.
A process is in place to
read and drain the RMA
queue at least once every
business day.
A process is in place to
accept or reject RMA
authorisations with 6
business days.
Support Channels on
page 15
Support channels Support channels are
known and accessible.
Assess your Technical Are my SWIFT operations
Readiness on page 16 ready to change?

2.1.1 Role Management

Defining the correct contact roles in your organisation is important to support your adoption efforts.
Every customer must make sure their Online security officers have access to the Online Operations
Manager (O2M).
As a SWIFT customer, you must have the following roles clearly defined within the institution:
• swift.com administrators
• SWIFTNet security officers
- online security officers (online operations manager)
- offline security officers (Secure Channel)
Additionally, it is a good opportunity to make sure the following interface security officers are also
identified:
• Alliance security officers (Alliance Access)
• customer security officers (Alliance Remote Gateway and Alliance Lite2)
For more information about the different roles, see the following:
• Security Officer Guide
• SWIFTNet Online Operations Manager User Guide
• Secure Channel User Guide

28 January 2022 13
ISO 20022 Programme Technical Prerequisites
Customer Adoption Guide

• Knowledge Base article 36671 - Frequently Asked Questions about Security Officers

2.1.2 Capacity Planning

SWIFT has been conducting internal performance benchmark exercises throughout 2021. The
results have been translated in an estimation of necessary resources for ISO 20022/CBPR+
messages on the FINplus service in the updated Connectivity Packs documentation.
When it comes to capacity planning, you need to consider that ISO 20022 messages contain
substantially more data than MT messages. To understand the impact on infrastructure and
capacity, you should proactively assess the business needs.
This first set of questions can help in analysing your existing setup:
• What lines do I have in place (type, Connectivity Pack and bandwidth)?
• What is my current peak bandwidth usage?
• What is my current business need for messages per second or per hour?
• What is the current load balancing setup and the configuration in place that aligns to the lines,
interfaces and back-office systems?
• What are the current interface validation settings in place for processing the messages? For
example, keyword extraction
• What is the average payload of MT messages?
• What is the current system load for all systems in the SWIFT stack (disk space, peak CPU
usage and peak memory usage)?
This second set of questions can in help in defining your future setup:
• What lines do I need in place (type, Connectivity Pack and bandwidth)?
• What are my future/projected peak bandwidth usage requirements?
• What are my future/projected needs for message per second or per hour?
• What will be my future load balancing setup and the configuration that aligns to the lines,
interfaces and the back office systems?
• What are the future Interface validation settings to be applied for the processing of the
messages?
• What is the ratio of the average payload of MT messages to the projected payload of the
equivalent ISO 20022/CBPR+ messages?
• What is the future/projected system load for all systems in the SWIFT stack (disk space, peak
CPU usage and peak memory usage)?
Changes to product installation requirements will become available in the respective release
letters.
For more information about the connectivity pack configurations, see Connectivity Packs -
Configurations for Multi-Vendor Secure IP Network Connectivity.
For more details on measuring transactions per second for Alliance Gateway, Alliance Access, and
a connected back-office application in the Knowledge Base article 5016802.

28 January 2022 14
ISO 20022 Programme Technical Prerequisites
Customer Adoption Guide

2.1.3 Relationship Management Application (RMA)

RMA is a mandatory prerequisite to exchange Live traffic with your counterparties. For Test and
Training traffic (pilot service) the use of RMA is optional. For more information, see Relationship
Management on page 27.
To ensure a transparent adoption of ISO 20022 and allow freedom in choice of technical channel
for each institution in the scope of the transaction manager (FIN, FINplus, API), institutions will be
required to keep RMA relationships synchronised across these services at all times. For more
information, see the KB article 5023348: SWIFT will assist the community in keeping authorisations
synchronised in the following ways:
1. Day-1 synchronisation – FINplus bootstrap
Remove the need for manual creation of FINplus authorisations for all FIN correspondents
(API's are validated against the authorized ISO request types) Bootstrap will happen in the
central RMA database, customers can get a fully synchronized starting point by downloading a
single distribution file. Aligned with In-flow translation mapping tables, for more information on
the FINplus bootstrap, see the KB article 5024914.
2. Continued synchronisation – local authorisation consistency check
Locally issued relationships after bootstrap will only be delivered and update the central filter if
consistency is maintained across FIN and FINplus. Failure to issue a consistent set of
authorizations will lead to an abort and will require the authorisation to be re-issued. For more
information on the local authorisation consistency check, see the KB article 5024915.
As a FIN or FINplus user, you must follow the mandatory obligations as set out in the RMA Service
Service Description:
• A connection to the BIC8 RMA queue is configured (bankbebb_rma for live and bankbebb_rma!
p for pilot).
• A process is in place to empty and read the Live RMA queue at least once every business day.
• A process is in place to accept or reject and distribute (if required)) RMA authorisations within
six business days.
For more information about the obligations and usage of the RMA service, see the following
documents:
• RMA Service Operations Guide
• RMA Service Service Description
• Knowledge Base article 5023348 - RMA Evolution
SWIFT Services can provide necessary expertise in reviewing and removing dormant or obsolete
RMA authorisations. This will help save you time and effort, allowing you to concentrate on your
business. For more information, see the RMA Usage Review and Removal Factsheet.

2.1.4 Support Channels

All ISO 20022 related queries can be addressed to the Support Centres. There are various
methods by which you can contact the Support Centre. All methods require that you are registered
on swift.com.
• Applicable to all regions
- Preferred method: Case Manager
- E-mail: [email protected]
• Europe, Middle East and Africa (EMEA) Customer Support Centre

28 January 2022 15
ISO 20022 Programme Technical Prerequisites
Customer Adoption Guide

- Phone: +31 71 582 2822

• Americas (AM) Customer Support Centre
- Phone: +1 540 825 6056
• Asia Pacific (AP) Customer Support Centre
- Phone: +852 2 852 8777

2.1.5 Assess your Technical Readiness

Based on the above, it is worth reviewing the state of your SWIFT operations before looking at
implementation.
SWIFT Services can provide necessary expertise in reviewing the technical readiness of your
SWIFT footprint for ISO 20022 and CBPR+. This will help save you time and effort, allowing you to
concentrate on your business. For more information, see the ISO 20022 Services Info Sheet.

2.1.6 Communicate with your Vendors

Contact your application vendors and Service Providers to ensure readiness for CBPR+. SWIFT
facilitates self-attestation and certification of application vendors to confirm readiness. For more
information, see the SWIFT Partner Programme page.

28 January 2022 16
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

3 FINplus and SWIFTNet Store-and-forward

To enable exchange of ISO 20022 formatted request types over SWIFTNet, SWIFT is deploying a
FINplus many-to-many InterAct service supporting ISO 20022 messages for payments and
beyond. It offers an equivalent level of features as FIN and include the validation of industry usage
guidelines such as CBPR+. For more information, see the FINplus Service Description and the
dedicated SWIFTSmart modules.
FINplus will also be one of the channels for interacting with Transaction Manager. The SWIFT
Platform Evolution: Connectivity Guidance document is published on swift.com and provides
information about the different implementation options available during the coexistence period,
starting November 2022.
SWIFT Services can provide training sessions on FINplus and general InterAct aspects. For more
information, see the ISO 20022 Services Info Sheet.

Purpose
This section explains the technical concepts needed to properly set up and configure your
infrastructure to support SWIFTNet store-and-forward. While the concepts are valid for FileAct or
InterAct in store-and-forward mode, we will drill down into some examples that are specific to
FINplus. On several occasions, parallels are drawn with the current FIN service that can help you
migrate any existing procedures to the new messaging service.
The first chapter of the section will provide a checklist with all the actions to send or receive traffic.
The rest of the document will go deeper into the different concepts to provide additional
information.
The final chapter talks about environment sizing and how to use these concepts to achieve high
availability and throughput set-up.
Make sure you consult the SWIFT Platform Evolution: Connectivity Guidance and the From FIN to
FINplus Getting Started (highlighting high-level considerations when moving from FIN to FINplus).

Intended audience
The intended audience for this section is all staff operating and configuring SWIFTNet interfaces
and focusses on the technical store-and-forward concepts. For all business-related topics, please
refer to the MyStandards page on swift.com. Where applicable, links are provided to SWIFT
messaging interface documentation, however the concepts described general to SWIFTNet and
valid for any Messaging interface software.

3.1 Configure your Connection to SWIFTNet

This chapter will provide a simple checklist that will cover all the steps that are required to properly
send and receive traffic on the FINplus InterAct in store-and-forward mode.
Note This section looks from a SWIFT messaging point of view. Any specific messaging
interface communication configuration is out of scope for this document.
Send traffic on FINplus InterAct store-and-forward
1. Complete the FINplus e-order form.
2. Choose a delivery notification queue (Any existing store-and-forward queue or create one in
the e-order form).
3. Prepare the certificate to sign your FINplus traffic.
4. Configure your store-and-forward input channels.

28 January 2022 17
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

5. Configure your SWIFTNet connection on the messaging interface.

6. Determine the use of optional features, like delivery notifications and non-delivery warnings.
7. Define your FINplus RMA relationships.
8. Configure your FINplus addressing rules.
Receive traffic on FINplus InterAct store-and-forward
1. Create and configure your store-and-forward queues (including delivery notification queues).
2. Define your message routing rules.
3. Configure your store-and-forward output channel.
4. Prepare the certificate to receive your FINplus traffic.
5. Configure your SWIFTNet connection on the messaging interface.

3.2 FINplus Service Subscription

FINplus consists of three separate services:

1 FINplus Pilot current (message validation based swift.finplus!pc

on the current Standards release (in sync with
the live service)

2 FINplus Pilot future (message validation based swift.finplus!pf

on the future Standards release)

3 FINplus Live swift.finplus

As from January 22, 2022, all BICs eligible for CBPR+ messaging are automatically provisioned to
the FINplus Pilot Future service. That is also the case for new BICs or existing BICs becoming
eligible. For more details, see the Knowledge Base article 5025106.
A similar automated provisioning will be organised for the FINplus Pilot Current and Live services in
November 2022.
Manual registration is still possible through the e-order form, for updates to existing provisioning or
registration for non CBPR+ messages (for example, Securities).
Live service subscription is based on a separate e-order form. You can only subscribe to the Live
service after you have subscribed to the Pilot services.
Information about filling out the e-form can be found in Knowledge Base article 5023958.
Note For an overview of message introduction dates on the FINplus services, see
Knowledge Base article 5024231.

3.3 Connectivity

3.3.1 Send Traffic on FINplus

After ordering your FINplus subscription, two configuration steps must be completed to send
FINplus traffic:
1. Definition of a delivery notification queue:

28 January 2022 18
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

• Even when no delivery notification is requested, every message sent over store-and-forward
must mention a delivery notification queue to store failed delivery notifications. This delivery
notification queue can be any existing queue (a dedicated queue can be defined directly
from the e-order form if wanted).
2. Role Base Access Control (RBAC):
• The FINplus service does not require a specific RBAC role, the only role that is checked at
message emission is the role that allows access to the delivery notification queue. This
RBAC role is defined as Swift.snf.control//SnFRequestor//queue//delnotqueue
(where delnotqueue is the queue you will use to store the delivery notifications). More
information about how to assign RBAC roles is available in the Online Operations Managers
User Guide.
• Institutions that want to control who in their institution can access FINplus, can use the
feature "Enhanced Access Control for Services Not Using RBAC. SWIFT will create and
validate an RBAC role for the FINplus services. This functionality is requested on BIC level
and is applied for all services not requiring RBAC.
After preparation, the messaging interface can be configured for message input.

Related information
Alliance Access Configuration Guide - Emission Profiles
Alliance Messaging Hub - Configuration Guide

3.3.1.1 Store-and-forward Input Channels

To send SWIFTNet traffic, you do not need to open a session with store-and-forward by default.
Traffic can be sent one-by-one and no technical relationship between messages exists. This also
means that the message sequencing principles do not apply to store-and-forward by default.
An input channel establishes a dedicated input session with SWIFT and acts as an access point for
(store-and-forward) interfaces. Typically, a sending interface only needs a single input channel for
live traffic and a single input channel for pilot traffic.
Because most customers only have one (active) messaging interface, SWIFT automatically creates
two input channels for each institution (BIC8) the moment they subscribe to FileAct or InterAct
(store-and-forward). The default input channels are also called the "generic input channels" and
can be used for any type of traffic (bankbebb_generic for live traffic and bankbebb_generic!p for
pilot traffic).
Users can optionally create additional input channels for the same BIC8 if required, for example,
when an institution has two messaging interfaces that operate at the same time and independently
of each other.
You may be able to create an input channel directly from your messaging interface. For more
information, see your respective interface's user guide.

Related information
Alliance Access Configuration Guide - Input Channels
Alliance Messaging Hub SWIFTNet Connectivity Guide - Input Channels

Input channel composition

An input channel name is up to 30 characters long and composed of three parts:
Inputchannel = BIC8 "_" name ["!p" for pilot services]

28 January 2022 19
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

Note In FIN, you always open an input session when logging in your logical terminal (LT) for
input. Messages will always receive a unique session and sequence number which
form the message input reference number (MIR).

3.3.1.2 Store-and-forward Input Channel Sessions

The main benefit of using input channels is that it greatly reduces the chance of possible duplicate
messages.
When opening an input channel and starting an input session, every message receives a sequence
number. SWIFT uses this number for the following tasks:
• Detect Messages out of sequence. SWIFT only delivers messages when all messages with a
lower sequence number in the input channel are accounted for.
• Detect duplicate messages. When a message is sent with a sequence number (ISN), the
FINplus service checks whether it is a possible duplicate sequence number. If so, the ACK is re-
sent (replay) to the sender. In case the same ISN is used with a different payload, an error
message is returned.
• Detect gaps. Messaging interfaces will automatically retry the missing message until the
technical acknowledgement is received. Thanks to the sequence number, SWIFT makes sure
every message will only be delivered once.
Without an input channel session, messages are sent to SWIFT one by one and no anomaly
detection is performed.
The use of input channels might decrease peak throughput due to the additional checks. To
achieve higher throughput when using input channels, see Environment Scaling on page 27.

3.3.1.3 Input Acknowledgement

In InterAct store-and-forward, the technical acknowledgement (ACK) is part of every InterAct
response of the message. This InterAct response will contain the message validation result and the
confirmation that store-and-forward has safestored the message.
The third important part of the acknowledgement is the SWIFTRef number. This is a unique
reference that is used in subsequent reporting of the status of the message like delivery
notifications or undelivered message reports.
Because the technical acknowledgement is not sent as a separate message and is always related
to InterAct request itself, your messaging interface may provide additional functionality to process
this acknowledgement.

Related information
Alliance Access Configuration Guide - Message Reconciliation Scenario
Alliance Messaging Hub SWIFTNet Connectivity Guide - SWIFTNet Store-and-forward

TIRACK
As a response to every message that it receives, FIN sends an acknowledgement service message
(TIRACK) back to the sending logical terminal in the form of an service message 21. The service
message 21 Acknowledgement contains the message validation result and confirms that FIN has
safely stored the message (More information is available in the FIN Operations Guide). The unique
reference number given to every ACKed FIN message is called the message input reference
(MIR).

28 January 2022 20
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

3.3.1.4 Delivery Notifications and Non-delivery Warnings

Both positive delivery notifications and non-delivery warnings are available as options in store-and-
forward.
For non-delivery warnings, store-and-forward allows a user to indicate a time-out period. The user
can set the period between 5 minutes and 24 hours. When the time-out period expires, SWIFT
sends a non-delivery warning in the form of a system message. For more information about
delivery notifications and non-delivery warnings, see the SWIFTNet Messaging Operations Guide .
When SWIFT cannot deliver a message, it will send to the original sender a failed delivery
notification (like the MT019 abort notification in FIN)
• For store-and-forward, you must always indicate the delivery notification queue where SWIFT
will store failed delivery notifications.
Note In FIN, when you send a message, you can opt to receive a non-delivery warning for
that message, a delivery notification, or both. A non-delivery warning (MT010) is sent
when a message cannot be delivered before the obsolescence period expires (15
minutes for urgent, and 100 minutes for normal priority messages). An MT011 delivery
notification is sent upon successfully reception of a message. For more information,
see the FIN Operations Guide.
The table below describes the mapping of system messages between FIN and store-and-forward:

Delivery notification FIN system message Store-and-forward system

message

Overdue warning MT010 xsys.010

Positive delivery notification MT011 xsys.011

Failed delivery notification MT019 xsys.012

Delayed NACK MT015 -

Sender notification MT012 xsys.002 (Y-Copy Authorisation)

xsys.003 (Y-Copy Refusal)

3.3.2 Receiving Traffic on FINplus

Similar to FIN, when a message has been sent and validated (ACK), SWIFT will safestore the
message and queue it for reception. In FIN, the storage happens in a destination’s delivery
subsets, in store-and-forward, messages are stored in "store-and-forward queues".

3.3.2.1 Store-and-forward Queues

Queues contain the messages and files that are sent by the sender to be delivered to the specified
receiver. Queues also contain the delivery notifications and system messages that are generated
by SWIFT.
The attributes of a queue are as follows:
• Queue Name
The queue name uniquely identifies a queue. It is used to access a queue when delivering
messages and files (access is defined with RBAC) and to set up the routing rules.

28 January 2022 21
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

• Queue Window Size

The window size controls the maximum number of messages SWIFT delivers from a queue to
the recipient without acknowledgement within each session. The receiver has to acknowledge
the message or messages before a new slot in the window is released and further messages
can be delivered. The default maximum window size is equal to 10. In case a higher window
size is required, customers must contact SWIFT (more information about window size in the
next chapters).
• Queue sharing mode
The queue sharing mode setting controls if a queue can have several simultaneous output
sessions. This is typically used by customers who run several interfaces in active-active mode
(like FIN shared subsets). If the queue sharing mode is equal to "Exclusive" then only one
session can be active at a time. If the queue sharing mode is "Shared" then it is possible to start
a new session on the queue even if another session is already active.
Starting multiple sessions on a queue is only possible using multiple output channels (more
information about output channels below). For more information about how to change the queue
sharing mode, see the SWIFTNet System Messages Guide.

3.3.2.2 Message Routing Rules

Store-and-forward queues and routing rules are managed directly from the FINplus e-order form in
the "Traffic Routing for Store-and-forward Service" section (not to be confused with the CUG
subscription section).
A store-and-forward routing rule has the following characteristics:

Characteristic Description

Rule order Order in which the rules are triggered from low to high

Queue name Unique name of the queue

Requestor DN DN of the Sender of the store-and-forward messages (your correspondent

DN)

Responder DN DN of the Receiver of the store-and-forward message (your DN)

Request type Request type of the message

When completing the order form to subscribe to the FINplus service, SWIFT proposes a default
queue with default routing rules:

Default configuration

28 January 2022 22
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

When this field is left untouched, the two following actions will be triggered:
1. Creation of the bankbebb_finpluscur!p queue
2. Creation of the routing rule to route traffic to this queue.
The routing rule will have the following characteristics:
• Rule order: 10
• Queue name: bankbebb_finpluscur!p
• Requestor DN: *
• Responder DN: *,o=bankbebb,o=swift
• Request type: *
This means that all traffic on the FINplus service sent to the receiver BIC bankbebb will be
routed to queue bankbebb_finpluscur!p.

Customised configuration
When accessing the "advanced" section, additional routing rules and queues can be defined and
the default proposal will no longer be taken into account.

Important notes when setting up your own routing rules:

1. Rule order: routing rules will be processed from low to high, once a routing rule is triggered, the
message is stored and put into the queue, all higher ordered rules will be ignored.
2. Full queue name: When a queue name is defined that does not exist yet, it will automatically be
created, queues must always be in the format bic8_name(!p).
3. Requestor and responder DN: Special care must be taken into account when defining a
specific DN. The below examples will explain on how to correctly define a specific DN

Defined DN Logic

Valid DNs for the FINplus service

*,o=bankbebb,o=swift A wildcard followed by a "," and the level 2 DN will trigger all level 3 DNs
and below.
The level 2 DN itself (o=bankbebb,o=swift) will not trigger the rule.
This should be the default DN used in routing rules for FINplus traffic.

28 January 2022 23
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

Defined DN Logic

cn=abc,o=bankbebb,o=s Without wildcard only the exact level 3 will trigger the routing rule. Note
wift that the 3rd level of the DN must be a valid 3-character branch code for
your institution.
cn=xxx,o=bankbebb,o=s
wift Message routing is typically handled by your messaging interface, this
set-up can be used in cases where you have dedicated business lines
with a dedicated messaging interface.
When the requestor/responder DN is either "o=bankbebb,o=swift" or
"cn=test,ou=abc,o=bankbebb,o=swift" it will NOT trigger the rule.

Non-Valid DNs for the FINplus service

o=bankbebb,o=swift Without wildcard "*", only the exact level 2 will trigger the routing rule so
when the requestor/responder DN is ou=abc,o=bankbebb,o=swift, it
will NOT trigger the rule.
A level 2 DN is not allowed in the swift.finplus service.

cn=test,cn=testabc,o= The first three levels of the DN are fixed for the FINplus service and the
bankbebb,o=swift third level must be a valid 3-character branch code for your institution (or
xxx. For more information, see Addressing on page 26). This will be
validated in the order form.

4. Request type: when not using wildcards, only the exact message type will trigger the rule.
5. When updating routing rules, they will be part of the weekly provisioning cycle and
implemented over the next provisioning cycle (2 weeks lead time).
For more information about how to specify routing rules, see the SWIFTNet Messaging Operations
Guide.

Important When configuring your routing rules, it is important that you foresee a rule for every
type of traffic. When no routing rules is found for a given message, it is automatically
stored in the generic queue of the receiving BIC8.

Note In FIN, the delivery subset definition and routing are defined by sending an MT047
system message. A change in routing and delivery subset definitions becomes active
at midnight (local time) after receiving the ACK of the MT047.

3.3.2.3 Output Channels and Queue Sharing

Store-and-forward messages are retrieved from a queue by opening an output channel and
establishing an output session for that specific queue.
An output channel is used to control the way and the order in which messages are to be delivered
to the receiver. During an output session, every message will receive a unique output sequence
number (OSN), this sequence number allows the system to identify missing messages at message
reception.
One of the main benefits for using output channels is that it allows for multiple sessions on a queue
simultaneously. Multiple sessions are required to be able to deliver messages from the same
queue in parallel to several endpoints. This achieves:
• High availability of output from a queue: Messages can still be delivered even when one of the
sessions fails for whatever reason (typically connectivity problems or a problem at the receiving
system

28 January 2022 24
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

• Higher performance: Incoming traffic from a queue can be handled by several messaging
interfaces and SWIFTNet Links in parallel
When you create a new store-and-forward queue from the e-order form, SWIFT automatically
creates a corresponding output channel with the same name, the default queue sharing mode is
"exclusive".
The default output channel is used when configuring your queue connection and you do not specify
an output channel. More information about how to configure your queue connection is available in
your messaging interface documentation.

Related information - queue connection configuration

Alliance Access – Reception Profiles
Alliance Messaging Hub SWIFTNet Connectivity Guide - SWIFTNet Store-and-forward
Note After a delivery subset is created and messages are stored in FIN, they can be
retrieved by logging into your logical terminal and opening an output session for that
delivery subset. While a single FIN logical terminal can be used to drain multiple
delivery subsets at the same time. In store-and-forward, the output channels are
strictly bound to a single queue and cannot be reused to drain other queues.

Queue sharing
To achieve a higher availability and throughput and acquire a queue with multiple output channels
at the same time a queue first must be set up in "shared" mode. More information about how to
activate queue sharing can be found in the SWIFTNet System Messages Guide. Additional output
channels can be created directly from the messaging interface.

Creating additional output channels

You do not need to specify the queue when creating an output channel. However, when an output
channel is used to acquire a specific queue, it is assigned and cannot be used to drain other
queues in the future.
When using multiple output channels to drain the same queue, every output channel will have their
own session and sequence numbers.

Related information - creating additional output channels

Alliance Access – Create an Output Channel on SWIFTNet
Alliance Messaging Hub SWIFTNet Connectivity Guide - SWIFTNet Store-and-forward

3.3.2.4 Access Control

Each user who wants to open a queue must first have access to that queue. Access to a queue is
based on RBAC information and defined through a single role: SnFRequestor, on the
swift.snf.control service. This role has to be assigned to the application certificate used to
acquire the store-and-forward queue.
For more information about how to assign roles for store-and-forward queues, see the SWIFTNet
Online Operations Manager User Guide.

3.3.2.5 Delivery Control

When using channels, the default delivery mode for store-and-forward messages is FIFO, this
means that messages will be delivered in the exact order they arrive in the store-and-forward
queue. When you open the output channel you can define additional delivery criteria. For example,
you can drain a specific subset only (urgent, normal messages or files) or assign different priorities

28 January 2022 25
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

to messages (drain "urgent" messages first, followed by "normal" messages). Messages are still
delivered in the correct order within their respective buckets.
For more information about delivery control options, see the SWIFTNet Messaging Operations
Guide. To configure the delivery control options, see your messaging interface user guide.

Related information
Alliance Access Configuration Guide – Reception Profiles
Alliance Messaging Hub SWIFTNet Connectivity Guide - SWIFTNet Store-and-forward

3.3.2.5.1 First-in-First-out Delivery

Like FIN, SWIFT cannot guarantee a sender to receive first-in-first-out delivery. This is because
during processing a lot can happen to a single message that can impact the flow (message copy,
MI authorisation, message cancellation, Sanctions Screening investigation).
Therefore a real sender to receiver First-in-First-out can only be achieved under very strict
conditions:
1. Sender uses a single input channel
2. No additional central processing is performed
3. All traffic routed to a single store-and-forward queue
4. Receiver only uses a single output channel (queue in exclusive mode)
In practice, this situation rarely occurs. It is therefore more useful to look at message ordering from
a sender and receiver perspective respectively.

Sender ordering
When a sender uses a single input channel, every message gets a unique sequence number. This
number defines the order in which SWIFT makes the messages available to the next processing
step. Any gap resolution for lower numbered messages will happen before a message is released.
This next processing step is not necessarily the receiver queue but can be Sanctions Screening
utility or a copy to an MI for example. This same reasoning applies to FIN traffic.

Receiver ordering
For any given queue, messages are delivered in the order they are ready in the queue (except if
the user explicitly asked for another delivery scheme, see Delivery Control on page 25). When a
message is flagged "ready" can depend on multiple factors, for example when it gets authorised by
an MI or released from the Sanctions Screening utility.

3.4 Addressing
Only institutions who have subscribed to FINplus can send or receive in the FINplus service
(Closed User Group).
FINplus addressing builds on two important concepts:
• DN CUG subscription
• FINplus specific addressing rules

28 January 2022 26
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

3.4.1 DN Closed User Group Subscription

As mentioned earlier, before a message can be sent on the FINplus service, your DNs must be
subscribed to the FINplus service. This is configured directly in the FINplus e-order form in the
section "SWIFTNet Closed User Group information".
Your institution will be automatically subscribed with a wildcarded level 3 DN. There is no
customisation allowed.

3.4.2 FINplus Specific Addressing Rules

Because the FINplus service is considered an extension of the current FIN service, SWIFT will
ensure that the addressing mechanism used in FIN and FINplus is consistent and transparent.
For more information, see the Requestor and Responder Distinguished Name (DN) section of the
FINplus Service Description, and the SWIFTNet Network Validation Rules for ISO 20022.

3.5 Relationship Management

Like in FIN, an RMA relationship is a mandatory prerequisite to exchange production traffic with
your counterparties. RMA relationships are set up and maintained separately for each service. This
means you will have to exchange a new RMA authorisation for the swift.finplus service. For
more information about RMA for FINplus, see the FINplus Service Description.
For Test and Training traffic the use of RMA is optional and RMA filtering will not be used by
default.
To enable the RMA check on your interface, you can activate the "trial filtering" option for the
swift.finplus!pc and swift.finplus!pf pilot services.

For more information about how to activate trial filtering, see your messaging interface
documentation.
For more information, see the RMA evolution Knowledge Base article 5023348.

Related information
Alliance Access Configuration Guide – Application Service Profiles
Alliance Messaging Hub - SWIFTNet Operations Guide - Relationship Management

3.6 Environment Scaling

Most users will have enough capacity when using the base set-up. This includes one input channel
and connectivity stack for their input traffic and, one output channel for their output traffic. When
scaling your environment for additional availability or throughput, the following notes should be
taken into account.
See section Capacity Planning on page 14 for initial guidance in analysing the impact of ISO 20022
on your infrastructure and capacity.

3.6.1 Message Input

Messages can be sent to the SWIFT network without input channel. While this case can give you
increased throughput by sending more traffic in parallel, SWIFT recommends using input channels

28 January 2022 27
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

for the reasons mentioned in earlier chapters. The next analysis will only cover the case when
using input channels.

3.6.1.1 Base Case

The base case uses one messaging interface and one connectivity stack. Most users will have
enough using the default input channel "bic8_generic". This input channel is created as soon as
you subscribe to an InterAct or FileAct (store-and-forward) and can be used for all your store-and-
forward traffic (it can be shared by multiple SWIFTNet connections on the same messaging
interface).

3.6.1.2 Increased Availability

In case additional connectivity stacks are available for sending messages. An input channel can be
opened by two different SWIFTNet connections on the same messaging interface over a different
connectivity stack at the same time. This set-up has multiple advantages.
1. Higher availability in case a connectivity stack goes down.
2. Higher throughput by parallelising your input traffic
3. Still have full benefit of input channel functionalities.
Note An input channel can only be used by one messaging interface at a time.

3.6.1.3 Increased Throughput

If the throughput that you want is not reached and it is determined that the input channel is the
bottleneck then the first step is to increase the window size of the input channel. The default
maximum window size for an input channel is 12. The default maximum window size can only be
increased by contacting SWIFT support.
Increasing the window size of a given input channel will not increase the throughput indefinitely. It
depends on many other components like interface performance, bandwidth, and HSM signing. The
impact of increased window size should be tested for your specific situation thoroughly.
If still not enough throughput is achieved then you can consider creating additional input channels.
For this, an important consideration has to be made. Every input channel will have its own session

28 January 2022 28
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

and message sequencing. When it is critical that business messages are sent in a specific order,
multiple input channels should not be used.

When you have multiple messaging interfaces working independently from each other at the same
time, each messaging interface will need a dedicated input channel. The same note as above
applies that if message ordering is important, traffic should not be split across multiple input
channels.

3.6.2 Message Output

As explained in earlier chapters, when traffic is sent to you, SWIFT will store it in the wanted queue
based on your routing rules (MRR). The following section will provide some guidelines that can
help you increase performance and availability of your incoming traffic.

3.6.2.1 Base Case

Like input channels, the base case for output will start with a single queue, output channel,
messaging and connectivity stack.

Based on your e-order from, SWIFT will create the requested queues and routing rules. For each
queue, an output channel will be created automatically with the same name as the queue.

28 January 2022 29
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

3.6.2.2 Increased Availability

In case additional connectivity stacks are available for your incoming traffic and to account for a
failing connectivity stack. This can be achieved by setting up your queue in shared mode and
create additional output channels on the queue (process is described above).

Messages will be distributed evenly between the different output channels. When one output
channel connection is disrupted, messages will automatically be delivered through the remaining
channel. When the failing connection is restored, traffic will be distributed automatically again.
While this set-up will increase the availability and provide you with a higher throughput, some
important considerations have to be made:
• Every output channel will have its own sessions and sequence numbering, for traffic where
messages ordering is important, multiple output channels should not be used. This traffic should
be routed to a dedicated queue with its dedicated output channel
• When an additional output channel is assigned to a queue (by acquiring the queue for the first
time) it cannot be used to acquire any other queues. Therefore, it is important to have a
sensible naming convention for additional output channels.

3.6.2.3 Increased Throughput

There are two main ways to increase output throughput:
1. Increase the output channel window size
2. Output channel load balancing

Increase the output channel windows size

The output channel window size consists of three concepts:
• Maximum window size: The maximum window size is defined on BIC8 level, this is the highest
window size that can be requested when opening an output channel. The default maximum
window size for a BIC is "10". A customer can request an increase to this window size by
contacting SWIFT.
• Requested window size: Maximum value to be used for a given output channel, this value is
defined when opening the output channel and cannot exceed the maximum window size.
• Effective window size: SWIFT will dynamically adapt the effective windows size up until its
requested window size value depending on the required throughput at a given time. When there
are no more messages in the queue, the effective window size is set to 1 again and follows the
same cycle of increasing. The advantage of a dynamically changing window size is that delivery
issues at the receiver side can be quickly detected, even at very low traffic periods.

28 January 2022 30
ISO 20022 Programme FINplus and SWIFTNet Store-and-forward
Customer Adoption Guide

Note The window size is mainly used to make up for connection latency. This means that an
increased window size can only increase the throughput up until a certain level (at
higher windows sizes, the window never gets full). After that other limitations will start
to play a bigger role (bandwidth, SNL throughput, messaging interface processing). A
very high window size can also become dangerous in case the receiving interface has
issues processing the traffic.
This also means that a direct comparison with the FIN window size is difficult to make
and will need to be customised and tested for every specific set-up.
To set the appropriate window size to account for the latency, you can follow the
instructions described in Knowledge Base article 5016802.
For example, for a latency (round trip time) of 2.5 seconds and we aim for 4 output
channels to reach the 70 TPS queue limit (20 TPS per output channel) we have:
20 TPS * 2.5 seconds = 50 window size per output channel

Output channel load balancing

When you get the maximum throughput for the window size, the next option is to create additional
output channels which drain the queue in parallel. They will all have their own window size and
could possibly be routed over a different connectivity stack (see picture below).
The below gives an example set-up with four output channels on the default FINplus store-and-
forward queue.

Traffic will be load-balanced across all four output channels. While you can increase the number of
output channels even further on the same queue, exceeding 4 will not provide much more benefit
as you will reach the maximum queue throughput (around 70 TPS with 4 output channels and
window size set correctly to account for latency). This should be sufficient however for any single
line of business. A dedicated queue can be created for every important business line.

28 January 2022 31
ISO 20022 Programme Communication Interfaces
Customer Adoption Guide

4 Communication Interfaces
Purpose
This section reviews the impacts of adopting ISO 20022 and FINplus on the communication
interface layer of your SWIFT stack.

Intended Audience
This section is for all staff operating and configuring SWIFTNet interfaces.

4.1 SWIFTNet Link

There is no specific impact on SWIFTNet Link for the exchange of CBPR+ messages over FINplus.
For more information about SWIFTNet Link, see the SWIFTNet Link 7.5 Service Description.

4.2 Alliance Gateway

There is no specific impact on Alliance Gateway for the exchange of CBPR+ messages over
FINplus.
For more information about Alliance Gateway, see the Alliance Gateway 7.5 Service Description.

4.3 Alliance Remote Gateway

There is no specific impact on Alliance Remote Gateway for the exchange of CBPR+ messages
over FINplus.
For more information about Alliance Remote Gateway, see the Alliance Remote Gateway Service
Description.

4.4 Third-Party Products

When using third-party products, make sure it is updated to correctly handle the new format. For
more information about guidance and rules related to the new format, see the MyStandards CBPR
+ Portal.

28 January 2022 32
ISO 20022 Programme Messaging Interfaces
Customer Adoption Guide

5 Messaging Interfaces
Purpose
For detailed information about the impacts of adopting ISO 20022 and FINplus on the messaging
interface layer of your SWIFT stack, see SWIFT Platform Getting Started.

28 January 2022 33
ISO 20022 Programme Translations
Customer Adoption Guide

6 Translations
Purpose
This section discusses translation options for coexistence between ISO 20022 CBPR+ and other
message formats, proprietary or not.

Intended Audience
This section is of interest to anyone involved in ISO 20022 and CBPR+ adoption projects.

6.1 In-Flow Translation

The in-flow translation service
During the coexistence period, from November 2022 to November 2025, SWIFT will provide
support for interoperability between ISO 20022 MX and MT users primarily with the following
features:
• a messaging-based in-flow translation service, for participants that are not ready for processing
of plain ISO 20022 messages
• a centrally-maintained transaction copy on Transaction Manager, for participants to access lost
or truncated data during the end-to-end transaction chain
The in-flow translation service is deployed on the FINplus service and creates an MT
representation derived from the initial ISO 20022 message. The translation operation takes place
during the message exchange at SWIFT and is based on the translation rules defined by the CBPR
+ workgroup.
The message is then delivered in a SWIFTNet message containing both the ISO 20022 MX and
the translated MT; it is therefore called a multi-format MX message. Not all messages exchanged
over FINplus are subject to in-flow translation: see the list of eligible request types in the FINplus
Service Description.
See also the ISO 20022 Programme In-flow Translation Service Overview.

Important In-flow translation always goes from ISO 20022 MX to MT, never in the opposite
direction.

The multi-format MX message

The multi-format MX message is an ISO 20022 message delivered through SWIFTNet InterAct
store-and-forward using the FINplus service. It carries the translated MT version within its
<RequestPayload> element.

The in-flow translation service adds three XML comments in that element:
• The first comment contains the translated MT itself.
• The second comment contains the overall result of the translation operation.
• The third comment contains further details about the translation operation, listing fields that
have been truncated and, if any, translation errors.
As ISO 20022 is a richer format than MT, there will be cases where some data is truncated. The in-
flow translation service replaces the last character of truncated fields in the MT by a + symbol for
easy identification. Unauthorised characters in MT are replaced by a . symbol.

28 January 2022 34
ISO 20022 Programme Translations
Customer Adoption Guide

Most customers will not have to worry about the multi-format MX message itself. When upgraded,
your messaging interface will manage the extraction and conversion of the multi-format MX
message to a usable output for your middle- and back-office applications. It will also verify the
integrity of the translated data based on the additional signature included by the in-flow translation
service.
What can be useful for example in case of routing or investigation of messages, are the translation
result and details included in the multi-format MX messages. For more information about how to
use the translation result and details in an Alliance/Access or AMH context, see SWIFT Platform
Getting Started.

Messages in scope of the in-flow translation service

See the list of the translation results in the FINplus Service Description.
See also the ISO 20022 Programme In-flow Translation Service Overview.
Note All translation rules from ISO 20022 MXs to FIN MTs approved by the CBPR+ working
group are published on MyStandards.

Timeline
The in-flow translation service is available for testing on FINplus Pilot Future since November 2021.
It is activated by default for all new or existing participants to the service and covers all eligible
messages.
In 2022 (date to be confirmed), SWIFT will provide a configuration screen (GUI) where financial
institutions can define the channel and format for the data they receive. Changes to those settings
take effect in real time.
This configuration is based on parameters consisting of the receiver's BIC8 or BIC11, optionally in
combination with message type and/or currency. Receivers who do not want to receive the
embedded MT format can use this capability to only receive the ISO 20022 message. Institutions
that want to continue to process messages in the MT format do not need to access the
configuration screen as the default will automatically apply.
As from August 2022, participants can start exchanging CBPR+ messages and use the in-flow
translation over the FINplus Live service. That will be on a voluntary basis, based on bilateral
agreements with counterparts of their choice.
As from November 2022, all participants are free to start sending part or all of their traffic as CBPR
+ messages and the in-flow translation service will become generally available.
In preparation for both Pilot and Live, participants must ensure they are running a version of their
messaging interface that supports multi-format MX messages (and transaction management
capabilities). For more information, see SWIFT Platform Getting Started.

6.2 Local Translations

6.2.1 SWIFT Translator

Customers may need a local translations solution to adopt CBPR+ or to ensure coexistence with
payment market infrastructures migrating to ISO 20022.
SWIFT Translator is a messaging format translation solution which allows customers to define,
validate, and translate messages from and to messaging formats. As the SWIFT Translator solution
is network and interface independent, it can be deployed and integrated in a flexible manner.

28 January 2022 35
ISO 20022 Programme Translations
Customer Adoption Guide

On top of format translation, SWIFT Translator complements MyStandards benefits in solving

standards format related issues.
Customers can:
• Re-use MyStandards usage guidelines as a source or target format, reducing time and effort
spent in format definition and validation,
• Define and document their proprietary/non-SWIFT formats on MyStandards
SWIFT Translator is composed of two components:
• a Designer, which is an offline software component offering a Graphical User Interface that
allows the customer to perform a number of actions (format, mapping, validation, etc.)
• a Runtime, which is a software component to be deployed within the customer's environment: at
the interface, middleware or back-office level, and performing message-format translation ,
validation and enrichment.
For more information, see the SWIFT Translator Service Description.

6.2.2 SWIFT Translator Libraries

SWIFT Translator libraries can be used together with the SWIFT Translator designer and greatly
accelerate the time that is needed to deliver a functional set of mappings or validations.
Such libraries can contain the following:
• A set of predefined mappings, for example, MT103 to pacs.008.001.08 containing CBPR+
restrictions and rules. This is used to speed up the process of mapping definition and
maintenance.
• A set of specific messages covering the initiative (called validation library). For example, CBPR
+ usage guidelines (base format ISO 20022, restrictions and rules for the specific initiative as
published on MyStandards). This is used to speed up the process of message validation.
For more information, see Libraries in the SWIFT Translator Service Description.

6.2.3 Alliance Access Custom Code Projects

Note This feature is not available on Alliance Entry.
Through the Integration Platform (IPLA) functionality of Alliance Access, the SWIFT Translator
Libraries and with the help of SWIFT Professional Services it is possible to have custom code
modules that take care of (bespoke) local translation, transformation and enrichment.

6.3 Third-Party Products

When using third-party products, make sure it is updated to correctly handle the new format. For
more information about guidance and rules related to the new format, see the MyStandards CBPR
+ Portal.

28 January 2022 36
ISO 20022 Programme Testing
Customer Adoption Guide

7 Testing
Purpose
Customers will test in many different ways along their journey to adopt ISO 20022 and CBPR+.
This section walks you through the various steps of testing CBPR+ messages and flows, and
explain what tools and support SWIFT make available to facilitate the testing efforts of the
community.
For more specific testing journeys based on customers' readiness status for November 2022, see
the SWIFT Platform Customer Testing Guidelines.

Intended audience
This section is any person involved in the planning, preparation or execution of ISO 20022 and
CBPR+ testing activities.

7.1 SWIFT Standards Testing

During implementation, customers will validate internal developments and changes through unit
testing, system testing, integration testing, and other testing types relevant to their project. Before
or in parallel to that, customers can also perform what we refer to as Standards testing; that is,
validating the structure of CBPR+ messages before any connectivity with FINplus is in place.
This is done using the testing applications available in MyStandards, by injecting messages that
have been manually created or generated by internal applications.
• The Readiness Portal (log in required) allows for testing messages against the CBPR+ Usage
Guidelines in a visual and user-friendly way. Errors are highlighted and explained, helping you
to learn, fix and re-test until messages are fully valid and compliant.
For more information see the MyStandards Readiness Portal User Guide.
• The Translation Portal offers a visual and user-friendly way of learning and testing the
translation rules from MT to ISO 20022 and vice-versa. Paste your message in the left-hand
panel and instantly see the translated version in the right-hand panel. You can then compare the
output with messages you had manually translated or generated from your applications.
For more information, see the Translation Portal Online Help.

7.2 Loopback Testing

The following testing steps require connectivity to the FINplus Pilot service. The principle of
loopback testing is to send messages to yourself over the network. By “yourself” we mean sending
to the same BIC or between several of your own BICs. That will enable you to validate your
outbound messages against CBPR+ Usage Guidelines using the service validation engine this
time, but also the correct reception, routing and further processing of inbound messages by your
messaging interface, middleware and back-office applications; both from a functional and technical
standpoint.
See the previous chapters for guidance on how to subscribe and get ready for FINplus messaging.

28 January 2022 37
ISO 20022 Programme Testing
Customer Adoption Guide

7.3 SWIFT Test Sparring Partner

Overview
With FINplus connectivity in place and end-to-end integration validated thanks to Loopback testing,
we then encourage you to test with SWIFT. For that purpose, the SWIFT Test Sparring Partner acts
as a fictitious counterparty on the FINplus Pilot service, without any other counterparty involved.
Like any “real” institution, the SWIFT Test Sparring Partner is physically connected to FINplus and
possesses its own set of BICs. It can be used to simulate the sending, receiving or relaying of
CBPR+ messages.
The SWIFT Test Sparring Partner comes with an easy-to-use web portal. It offers a wide catalogue
of pre-defined test cases covering the various CBPR+ messages. You can configure your test
cases and, taking the example of “receiving”, request the SWIFT Test Sparring Partner to generate
the CBPR+ message. The message is physically exchanged over the FINplus Pilot service and
delivered to your messaging interface, for end-to-end processing.
For more information, see the SWIFT Test Sparring Partner for CBPR+ User Guide and the
SWIFTSmart module Introduction to the SWIFT Test Sparring Partner for CBPR+.

Key features of SWIFT Test Sparring Partner

• Access to the portal is through the secured swift.com environment. Users will need a valid
swift.com account linked to your institution BIC.
• Within the application, you can define each user role (administrator, tester, viewer) and what
kind of testing they are authorised to do.
• The SWIFT Test Sparring Partner includes a catalogue of pre-defined test cases covering the
various CBPR+ messages, with accompanying pre-defined test data.
• The portal’s screens visually render the CBPR+ messages, allowing for a fluid test configuration
and execution. They also contain instructions, to provide guidance on what needs to be done,
and how.
• Finally, the application offers three types of reports, for consulting the status of test activities or
dive into execution details of a given test run.

Two options to access SWIFT Test Sparring Partner

You can choose one of the two following access options:
• Universal access
The Universal access is free-of-charge to all users subscribed to the FINplus environment. The
full catalogue of pre-defined test cases is available, along with pre-defined test data, covering
the various CBPR+ messages. The test cases cannot be modified and there is limited flexibility
in customising the test data: Universal users are typically allowed to modify the BIC, the amount
and the currency to be used. All reporting features are available too. The Universal access
comes in a pure self-service mode, with supporting documentation and regular Support
channels in case of queries.
• Premium access
The Premium access offers all of the above, plus the possibility to fully customise the test cases
and test data. If you want to configure more exotic cases, like adding 4 Intermediary Agents to a
flow or using beneficiary data that will trigger specific routing rules at your side, that is all
possible. The Premium access is payable and comes with mandatory SWIFT Professional
Services for supporting test preparation and execution. For more information, contact your
SWIFT Account Manager

28 January 2022 38
ISO 20022 Programme Testing
Customer Adoption Guide

7.4 Community Testing

Through the community testing, you will want to validate interoperability with selected
counterparties. That selection could be based on, for example, volumes or criticality of the flows to
be tested. You are, in principle, free to engage in such kind of activities whenever you like. SWIFT
recommends to first test extensively with the SWIFT Test Sparring Partner, to confirm your level of
CBPR+ readiness.
As for the other testing steps, the SWIFT Platform Customer Testing Guidelines provides guidance
for the preparation and execution of those activities.

7.5 Non-functional Testing

Finally, when it comes to non-functional testing, note the following items:
• Performance tests must be planned at least 4 weeks in advance and require approval from
SWIFT.
• The SWIFT Customer Testing Policy, available on the Knowledge Centre, sets out the
conditions for non-functional testing, like performance but also resilience and security testing.
For more information, see:
Knowledge Base article 2008531 - How can I plan my SWIFTNet throughput tests?
Knowledge Base article 5022293 - SWIFT Maintenance Schedule for core messaging services

7.6 ISO 20022 Readiness Directory

Until the end of the CBPR+ migration, an ISO 20022 readiness directory is made available on the
SWIFTRefdata portal to all swift.com users registered under a connected BIC. For each BIC11 and
related level-3 DN, it shows what request types have been exchanged over the FINplus services
(Live, Pilot Current, Pilot Future) based on observed traffic.
That informative directory can be used to look up other participants’ readiness and comes is a
complement to direct communication with your counterparties. It is updated on a monthly basis and
covers both payments and securities request types.
For more information, see the SWIFTRef ISO 20022 Technical Specifications.

28 January 2022 39
ISO 20022 Programme Other SWIFT Initiatives
Customer Adoption Guide

8 Other SWIFT Initiatives

Purpose
This section summarizes dependencies of ISO 20022 and CBPR+ adoption and other key
initiatives from SWIFT.

Intended Audience
This section is of interest to anyone involved in ISO 20022 and CBPR+ adoption projects.

8.1 SWIFT gpi and ISO 20022

The gpi ISO 20022 adoption timeline is aligned with the renewed CBPR+ adoption timeline and
with the ISO 20022 adoption timeline of key payment market infrastructures (PMIs). There are four
main deliverables for gpi ISO 20022 adoption:

• Tracking of domestic and cross-border payment messages (pacs)

• Introduction of ISO 20022-based messages for interactions with the Tracker, as equivalents to
MT and APIs
- trck.001 - Tracker Payment Status Update
- trck.002 - Tracker Payment Status Information
- trck.003 - Tracker Alert Notification
- trck.004 - Payment Status Customer Tracker Report (g4C)
• Upgrade to Tracker API services v5 to cater for ISO 20022 data model
• Keep supporting Tracker confirmations in the current format / channels

8.1.1 Specifications
The various Rulebooks have been or will be updated according to the following timeline:

Rulebook Published on the Knowledge Centre

gCCT and gCOV September 2021

gFIT November 2021

Summary of Impacts table November 2021

gpi ISO PMI readiness dashboard November 2021

Return flows (gCCT, gCOV, gFIT) 2022

Universal Confirmations 2022

The specifications of the Tracker API services v5 is available on SWIFT Developer Portal.
The final Usage Guidelines for the trck.confirmation messages are available on MyStandards.

28 January 2022 40
ISO 20022 Programme Other SWIFT Initiatives
Customer Adoption Guide

8.1.2 End-to-End Tracking of ISO 20022 Messages

SWIFT will release the SWIFT gpi ISO 20022 adoption features as follows:

Pilot Live
Tracking of pacs.008 and pacs. September 2021 November 2021
009 COV messages
Tracking of pacs.009 CORE, and September 2021 November 2021
pacs.002 messages
Exchange of ISO 20022 September 2021 November 2021
confirmation messages with the
Tracker
Tracker API services v5 September 2021 November 2021

Note The exchange of CBPR+ messages on the FINplus Live services will start end of
2022. Messages exchanged as part of a PMI making use of a SWIFTNet store-and-
forward many-to-many service will, however, be trackable in Live as from November
2021. All Live Tracker interactions based on ISO 20022 will also be possible as from
November 2021.

8.1.3 More Information

More information on SWIFT gpi ISO 20022 adoption features are available in the following
resources:
• SWIFT gpi on the Knowledge Centre
• gpi Support Page
• Universal Confirmations Support Page
• MyStandards
• SWIFT Developer Portal

8.2 ESMIG
As announced on 28 July 2020, the ECB’s Governing Council has approved a one-year extension
to the T2-T2S consolidation project timeline. The project is now scheduled to go live in November
2022.
For more information and future updates on the ESMIG/T2-T2S consolidation project, see the
dedicated ESMIG Support Page.

28 January 2022 41
ISO 20022 Programme Legal Notices
Customer Adoption Guide

Legal Notices
Copyright
SWIFT © 2022. All rights reserved.

Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order
expressly grants you that right, in which case ensure you comply with any other applicable
conditions.

Disclaimer
The information in this publication may change from time to time. You must always refer to the
latest available version.

Translations
The English version of SWIFT documentation is the only official and binding version.

Trademarks
SWIFT is the trade name of S.W.I.F.T. SC. The following are registered trademarks of SWIFT:
3SKey, Innotribe, MyStandards, Sibos, SWIFT, SWIFTNet, SWIFT Institute, the Standards Forum
logo, the SWIFT logo, SWIFT gpi with logo, the SWIFT gpi logo, and UETR. Other product, service,
or company names in this publication are trade names, trademarks, or registered trademarks of
their respective owners.

28 January 2022 42