Alliance Access 7.

Release Letter

This document contains release information for Alliance Access 7.2.

20 April 2018
Alliance Access 7.2 Table of Contents
Release Letter

Table of Contents

Impact of Using FileAct with Release 7.2........................................................................................................4

Practical Information.........................................................................................................................................5

1 Overview...................................................................................................................................................7
1.1 Why Release 7.2 and How Does It Impact Me?...................................................................................... 7
1.2 Enhancements and Features...................................................................................................................7
1.3 Resolved Problems................................................................................................................................19
1.4 Software Distribution..............................................................................................................................19
1.5 Support Duration................................................................................................................................... 19
1.6 System Requirements........................................................................................................................... 20
1.7 Documentation...................................................................................................................................... 23
1.8 Warnings and Known Issues................................................................................................................. 24
1.9 Obsolete Functionality........................................................................................................................... 27

2 Installation and Migration..................................................................................................................... 29

2.1 Fallback Activities.................................................................................................................................. 29

3 Support...................................................................................................................................................30

A Routing Keyword Extraction and Verifiable Fields.............................................................................31

B Switch-over Planning for Standards MT..............................................................................................44

B.1 Actions to be Taken Now....................................................................................................................... 44
B.2 Actions to be Taken as Soon as Possible.............................................................................................. 44
B.3 Actions to be Taken Before 18th November 2017................................................................................. 44
B.4 Actions to be Taken on 15th, 16th, or 17th November 2017 (Last Business Day of the Week).............44
B.5 Actions to be Taken Before Your First Log In on 19th or 20th November 2017..................................... 45
B.6 Actions to be Taken after the First Login............................................................................................... 45

C Standards Switch-over Planning for InterAct Services..................................................................... 46

C.1 Actions to be Taken When You Are Notified of a Service Change.........................................................46
C.2 Get Ready for Testing............................................................................................................................ 46
C.3 Migrate to the New Standards............................................................................................................... 47
C.4 Wind Down Use of the Old Standards................................................................................................... 47
C.5 Stop Using the Old Standard.................................................................................................................48

20 April 2018 2
Alliance Access 7.2 Table of Contents
Release Letter

Legal Notices................................................................................................................................................... 49

20 April 2018 3
Alliance Access 7.2 Impact of Using FileAct with Release 7.2
Release Letter

Impact of Using FileAct with Release 7.2

An important impact of this release relates to the exchange of files using the FileAct service.
FileAct customers migrating to Release 7.2 cannot exchange files with counterparties that
are not running the minimum supported version of Remote File Handler 7.0.50 or higher.

Testing FileAct with counterparties

If you are not sure whether your counterparty is running on SWIFTNet Link and Remote File
Handler 7.0.50 at a minimum, then only complete the testing using FileAct in loopback mode or
store-and-forward mode.
Note To benefit fully from the FileAct Enhancements, your counterparties must also be on
Release 7.2. For more information, see Knowledge Base tip 5021829.
Customers that start a new FileAct service after Release 7.2 must confirm that their
counterparty(s) are running on the minimum Remote File Handler 7.0.50 baseline
version, in order to limit any possible compatibility issues.

Frequently asked questions

See Knowledge Base tip FileAct Enhancements with Release 7.2 - Frequently Asked Questions
(5021829), which outlines details about compatibility of the software versions for FileAct transfers.

20 April 2018 4
Alliance Access 7.2 Practical Information
Release Letter

Practical Information
Installation type Mandatory release
Install by November 2018
You must either install Release 7.2 from scratch, or install Release
7.2 using a prepared backup file. You cannot upgrade to Release 7.2
using your current environment.
Release 7.2 contains several enhanced security features including
additional detection capabilities of compromises as observed in the
modus operandi where attackers deploy malware to obtain operator
access (as described in SWIFT ISAC Bulletin 10060).
In some situations the detection mechanism of Alliance Access
7.2.00 reports false memory integrity errors. The behaviour is hard to
reproduce but has occurred at least once with most of the customers
that have not installed Alliance Access 7.2.10. When an integrity
alarm occurs SWIFT always ask you to provide data to investigate
the case.
Therefore, to avoid getting false alerts and having a support case
opened for investigation, install update 7.2.10 before proceeding with
any operations.
Please see Knowledge Base tip 5022433 for more information
regarding the reasons why 7.2.10 must be installed as soon as
possible.

Operating system requirements One of the following:

• AIX 7.2
• Red Hat Enterprise Linux 7.2
• Red Hat Enterprise Linux 6.7 (until 2020)
• Oracle Solaris 11.3
• Microsoft Windows Server 2016
See Operating System Requirements for Release 7.2 on page 20.

Customer installation path For Alliance Access:

Release 7.2
For Alliance Web Platform Server-Embedded GUI packages:
Release 7.2

Customer migration path For Alliance Access:

Release 7.1.23 or higher - 7.2
For Alliance Web Platform Server-Embedded GUI packages:
Release 7.1.23 or higher - 7.2

20 April 2018 5
Alliance Access 7.2 Practical Information
Release Letter

Product dependencies This release has dependencies on other products:

• Alliance Web Platform Server-Embedded 7.2
• Alliance Gateway 7.2 with SWIFTNet Link 7.2
See also SWIFTNet Requirements on page 21 and Other
Requirements on page 22.

Software support lifetime This base release of Alliance Access 7.2 will be supported until 16
November 2018, when the annual Standards update becomes
mandatory.

Significant changes since previous Updated information regarding the need to install Alliance Access
version: 7.2.10 (this section).

Purpose of this Document

This document contains release information for Alliance Access 7.2, which is a mandatory release.
This document is intended for the system administrators of the Alliance Access systems. It clarifies
the changes, the product dependencies, and last minute information.
First read this Release Letter, and then use the other documentation provided for more detailed
information.
For a complete list of documents, see section Documentation on page 23.
New and changed functionality can be found in Enhancements and Features on page 7.
The problems resolved in this update can be found in Resolved Problems on page 19.

20 April 2018 6
Alliance Access 7.2 Overview
Release Letter

1 Overview
Alliance Access 7.2 includes all changes introduced since update 7.1.23. It also contains the
following enhancements with no new features or functionalities:
• Updates for Standards MT November 2017
This update resolves the issue mentioned below.

Significant fixes

CR number Description

50009348 MQHA XMLv2 flow using the XML-Dsig LAU fails.

1.1 Why Release 7.2 and How Does It Impact Me?

Release 7.2 of the SWIFTNet/Alliance product portfolio is a mandatory upgrade to the underlying
technology behind SWIFT's Interface products. The aim of the release is to continue to provide a
highly secure and efficient SWIFT service for our customers in the years ahead.
All software updates will be numbered in the 7.2.xx series.
The Alliance Access Service Description has been updated with this release.
Note Join us on LinkedIn to exchange experiences with your peers in the SWIFT Alliance
User Community.

1.2 Enhancements and Features

1.2.1 Overview
This update contains the following enhancements and new features:
• Standards 2017 support
• Technology renewal
• Oracle Database is distributed in a different way
• Four-eyes security for configuration changes
• Security by default
• Enhanced local password policies
• Event distribution to monitoring systems in CEF format
• Improved information in events
• Support for process whitelisting tools
• Support for SWIFTNet FileAct enhancements
• CREST over SWIFTNet enhancements
• Message/Instance search enhancement
• Identification of messages touched by human
• Security Best Practice Check tool enhancement

20 April 2018 7
Alliance Access 7.2 Overview
Release Letter

• Changes in Operator behaviour

• New security parameter to control the JVM options.
• Alliance Access operator required to launch Integration Platform (IPLA) command line tools
• Unique identifier per installed instance
See also Knowledge Base tip 5021833 for a detailed list of other functional enhancements that are
implemented in 7.2.

1.2.2 Standards 2017 Support

Alliance Access 7.2 introduces the Standards MT November 2017 and implements all required
changes to support the new Standards. For more information, see the Standards page on
www.swift.com.

SWIFT gpi: on the Standards Release 2017 cut-over date, all banks must be capable of receiving
gpi fields in Block3
The February 2017 updates of the Standards Release Guide on SWIFT gpi mentions:
MT 103, MT 103 STP, and MT 103 REMIT: Two additional fields may be present in header block 3
to indicate a service type identifier (field 111) or a Unique End-to-end Transaction Reference
(UETR, field 121). Use of these fields has previously been restricted to members of the SWIFT
Global Payment Innovation (SWIFT gpi) Initiative. This service allows banks in the SWIFT gpi
Closed User Group (CUG) to track payments based on the UETR. SWIFT gpi participants will be
allowed to include these header fields in all MTs 103, MTs 103 STP, and MTs 103 REMIT that they
send, including to banks that are not in the CUG, allowing the service to track a payment up to
the first bank outside of the SWIFT gpi CUG. Banks that are not in the CUG must be able to
receive these header fields but will not be allowed to send or forward messages containing fields
111 or 121.
Alliance Access is already capable of receiving the fields and forwards them to your back-office.
Make sure that your payment systems are able to receive messages with block 3 field 111 and 121.
Alliance interfaces will not remove the gpi fields on incoming MT103 when passing them on to
back-office systems. If needed, SWIFT Consulting Services can propose custom solutions.
The FIN tank file contains test messages with field 111 and field 121 in block 3 as part of the test
messages for future standard.

SWIFT gpi: Unique End-to-end Transaction Reference format enforced

As of the activation of the Standards 2017, the Unique End-to-end Transaction Reference (UETR)
used in the framework of SWIFT gpi will have to comply with Version 4 of Standard RFC4122.
Instead of being a 36X field, it will now have to be formatted as xxxxxxxx-xxxx-4xxx-yxxx-
xxxxxxxxxxxx where x is a lower case hexadecimal character (0-9,a-f) and y is 8,9,a or b). This will
be validated during manual entry.

1.2.3 Technology Renewal

Release 7.2 has been built on a completely refreshed technology platform. Next to a refreshed
operating system baseline with the latest releases, all internal third-party components have been
renewed and, in some cases, replaced. At the same time, we now deliver a 64-bit version only,
which allows you to get greater benefit from the power your server provides.

20 April 2018 8
Alliance Access 7.2 Overview
Release Letter

Restrictions:
• All customers who use third-party ADK components must request new versions of these
components from their providers.
• All customers using IPLA modules must validate with their provider if their module is compatible
with Release 7.2.
Note The base Release 7.2 is aligned with the August 2017 Alliance Security Update with
regards to the Oracle Java critical updates implemented. November 2017 will be the
first slot where a potential Security Update will be available for Release 7.2.

1.2.4 Oracle Database is Distributed in a Different Way

We have changed the packaging of the embedded database and the way it is deployed. This will
provide very important benefits compared to previous releases:
• the database footprint can be downloaded once and re-used for all Alliance Products on the
same platform
• The implementation is in line with Oracle's standard set-up, and as such better support is
available
• implementing security updates that impact the Oracle database can be done without exporting/
importing data
This will have the following impact:
• the download of the software is no longer a single package
• the total size of the packages to download from swift.com has increased significantly
• additional temporary disk space is required to perform the installation (see Hardware
Requirements for Release 7.2 on page 20)
• additional disk space is required by the installed software (see Hardware Requirements for
Release 7.2 on page 20)
• due to these changes the installation takes longer
• on AIX, Red Hat Enterprise Linux, and Oracle Solaris, some additional packages need to be
present as prerequisites (see the section Prepare for Alliance Access 7.2 Installation in the
appropriate version of the Installation Guide (AIX, Linux, Oracle Solaris).
To achieve a smooth installation, make sure that all required components are downloaded, and that
you reviewed the installation instructions and requirements before you start the installation process.
For more information, see Software Distribution on page 19.

1.2.5 Four-eyes Security for Configuration Changes

Now more than ever your security auditors will be strong on LSO/RSO assigning the right roles to
the right people and make sure that the configuration of Alliance Access is well controlled.
With Release 7.2, a new security parameter System - 4 Eyes mechanism is set to enabled by
default. Having this security parameter set enforces that more than one person is required to
change and enable Operators, Message Partners, and Routing Schemas.
Using this feature avoids the need to set up two operator profiles with mutually exclusive
permissions to implement an explicit segregation of duties. With this feature you need actions from
two different people to create/modify and enable the changes while they have the same role.

20 April 2018 9
Alliance Access 7.2 Overview
Release Letter

Thanks to this feature, a customer can assign a single profile to multiple employees and let Alliance
Access take care of the segregation of duties (for specific entities). Previously, the same customer
had to create multiple complex operator profiles to be assigned to each employee to ensure the
segregation of duties.
At the same time, Alliance Access tracks who created and who made the last modification to
Operators, Message Partners and Routing Schemas. The last modifier cannot enable the Message
Partner. If this is attempted, an error will be displayed. Additionally, keeping the last modifier tracked
allows changes to be better monitored.
For more information, see the section Four-Eyes Mechanism in the Alliance Access Configuration
Guide.

1.2.6 Security by Default

To help you to get your systems secure and to reduce the effort to keep them secure, a number of
changes have been implemented where the secure option is the default.

Local Authentication for Message Partners and Alliance Gateway connections

• For new Message Partners, the Local Authentication (LAU) will now be selected by default.
It will still be possible to deactivate the LAU. When a Message Partner (new or changed) is
saved without LAU, a warning message will be displayed and a security event will be logged in
such case.
• The use of LAU with Alliance Gateway is mandatory in Alliance Access 7.2.
Gateway connection definitions migrated from a previous release without LAU will be marked as
'Unreliable'. You will not be able to assign it to any connections. Alliance Access will block all
message flows assigned to a 'Unreliable' Gateway connection. Once LAU is configured, you can
use the connection again.
For Alliance Gateway connections, the usage of TLS will be enforced by Alliance Access.
For more information, see the section Gateway Connection Details Window in the Alliance Access
Configuration Guide.

Local Transfer Agent (LTA) – new security parameter and permission

Alliance Access Message Partners can be configured with a Local Transfer Agent to call a script
upon completion of the session.
To prevent unintended execution of malicious scripts a new permission (Applic. Interface -
Configure LTA) has been introduced to control whether an operator is allowed to edit the LTA
configuration fields or not.
During installation, even if installing from a backup file, this new entitlement is not given to any
operator profile.
In addition to this permission, it will also be possible to completely disable the usage of the LTA
feature for all Message Partners. This will be controlled by the new security parameter LTA
Enabling.

If there are Message Partners configured with the LTA option and the security parameter is updated
to 'No', the Message Partner will continue to run. However the script will not be executed and the
corresponding configuration fields will not be visible in the edit screens anymore.
When migrating from earlier versions, the default value for that parameter will be set to 'No'. If there
is at least one Message Partner configured with the LTA option then the security parameter will be
set to 'Yes', to make sure the configuration continues to work.

20 April 2018 10
Alliance Access 7.2 Overview
Release Letter

For more information, see the section Batch Output in the Alliance Access Configuration Guide.

Configurable restriction on the authentication types allowed

Alliance Access provides four different ways to authenticate users: Password, RADIUS One-time
password, LDAP, Password and TOTP.
A new security parameter (Auth. type available) enables security officers to configure the
authentication types allowed when creating a new operator.
Once the security parameter Auth. type available is configured, it will be applied when a new
operator is created.
As an example, an operator defined with ‘password’ will continue to function and be able to login on
the system even if the authentication list has been restricted to not allow passwords. However,
whenever the operator gets updated and the option gets changed to something else than
'password' it will not be possible to set it back to 'password' until the authorised list gets updated.
For more information, see the section User Management in the Alliance Access Configuration
Guide.

Default authentication type for operators

When creating new operators you will see that the default authentication type has been changed to
Password and TOTP, which is more secure than the old default Password.
The new security configuration parameter System - Auth type available, allows you to further
restrict what authentication models can be assigned to operators in your institution.
For more information, see the section System in the Alliance Access Configuration Guide.

Time zone associated with operators

Customers having end-users connecting to Alliance Access from different time zones were
previously troubled to define operator profiles that could only access the system during specific
hours. It was the time zone of the Alliance Access server that drove the features.
As of Release 7.2, a time zone is associated to the operator (through the operator definition).
During migration the time-zone of the server will be assigned. The selected time-zone is tracked in
the successful log-on event 3000.
For more information, see the section Sign-on Time Limits in the Alliance Access Security Guide.

1.2.7 Enhanced Local Password Policies

Building on the password policy enhancements introduced in 2016, further enhancements have
been made to meet industry best practices.

Two groups of users

The operators/users defined on Alliance Access are separated into two groups:
• normal users
• privileged users (users having the rights to change the system configuration)
The normal users will have the "Normal users" password policy applied, and administrators will
have the "Privileged users" password policy applied. These policies are controlled by security
parameters.
The following tables show the password policy changes for both groups:

20 April 2018 11
Alliance Access 7.2 Overview
Release Letter

Normal users

Security parameter 7.2 status Description Default value

Password – User Min Pwd new Minimum length of the user password 8
Length TOTP when TOTP is configured as
authentication type.

Allowed values: from 8 to 64.

Password - User Min Pwd updated Allowed values: from 12 to 64. 12

Length

Password - User Max Bad updated Maximum number of incorrectly 5

Pwd entered user passwords tolerated
before sign on is refused.

Allowed values: from 1 to 10.

Password - User Period updated Number of days after which the user 90
password has to be changed.

Allowed values: from 8 to 120.

Password - User Strong updated Defines the number of character types 4

Validation (Upper, Lower, Number, Symbol) a
user password must contain

Allowed values: 3 or 4.

System - Disable Period updated The number of calendar days after 120
which a user is disabled if there was no
successful sign-on. The check is done
at server start-up and every hour.

Allowed values: from 30 to 180

Privileged users

Security parameter 7.2 status Description Default value

Password - Admin Min Pwd new Minimum length of the administrator 17

Length password.

Allowed values: from 17 to 64

Password - Admin Min Pwd new Minimum length of the administrator 12

Length TOTP password when TOTP is configured as
authentication type.

Allowed values: from 12 to system

limits.

Password - Admin Max Bad new Maximum number of incorrectly 5

Pwd entered administrator passwords
tolerated before sign on is refused.

Allowed values: from 1 to 10.

20 April 2018 12
Alliance Access 7.2 Overview
Release Letter

Security parameter 7.2 status Description Default value

Password - Admin Period new Number of days after which the 365
administrator password has to be
changed.

Allowed values: from 8 to 1460.

System - Admin Disable new The number of calendar days after 120
Period which an administrator is disabled if
there was no successful sign-on. The
check is done at server start-up and
every hour.

Allowed values: from 30 to 180.

Note • Migrated end-users who have passwords that are shorter than the specified
minimum will be asked to select a new password at the first password change
following the installation of Release 7.2.
• When a normal user profile is changed (for example, new permissions are added)
and becomes a privileged user; the user will automatically inherit the new
password policy, applied as from the next login, if the length constraints change
and the used password is too short.
• The generated initial password complies with the password policy with respect to
the length, and may contain a mixture of uppercase/lowercase/numerics. The
password must however be changed at first use.
• The new character type used for Strong validation (Symbol), can be any character
out of (! # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~). Non-ASCII characters
are not supported in passwords.
• Some additional rules are enforced on the passwords:
- The password must not be the same as the user name.
- Successive passwords must not follow a sequence.
- The number of occurrences of the same character used in the password must
be less than or equal to (L-1)/2 (where L is the length of the password).
For more information, see the section Password in the Alliance Access Configuration Guide.

Default list of strings that cannot be used in passwords

To give passwords a higher chance to survive brute-force attacks when using local passwords and
local passwords and TOTP, every new password will be checked against a list of blacklisted
substrings. During installation, an initial list of 800 blacklisted substrings will be activated. The list of
blacklisted substrings can be modified by the operators with the Security Definition -
Password Blacklist permission.

When an operator selects a new password, a check will be performed to make sure that none of
the blacklisted substrings are present in the password. If a blacklisted substring is detected, the
user will be informed about the substring that he cannot use and will be asked to select a different
password.
For more information, see the section Password Blacklist in the Alliance Access Security Guide,
and saa_blacklist in the Alliance Access Configuration Guide.

20 April 2018 13
Alliance Access 7.2 Overview
Release Letter

Enhancements to Security Operator profile

To further strengthen audit ability of actions executed by LSO/RSO, it is now possible to define
additional security operators by assigning the users the user type "Left Security Officer" or "Right
Security officer" instead of defining them as a human user. Operations executed before by LSO or
RSO, can now be executed by any of the operators with user type Left Security Officer or Right
Security Officer. To enable this feature, set the new security parameter System - Extra sec
officer to Yes.

Where LSO and RSO were required, action by one operator with the Left Security Officer user type
and one with the Right Security Officer user type will be required.
At the same time, security officers (including LSO/RSO) passwords will now also get locked upon
too many failed log on attempts or if the last log on is too long in the past. To prevent situations
where no valid security officers are available, a “breaking glass” procedure has been implemented.
This procedure requires a registered security officer to call SWIFT Support.
The security Officer Reset password action is only available on LSO/RSO if the security parameter
Reset Peer Officer Pwd is set to value Yes. This feature did not change.

For more information, see the Alliance Access Configuration Guide.

Superkey Operator profiles removed

To strengthen security setup, Release 7.2 will no longer have default operator profiles with full
permissions. There will be no R7.2_Superkey profile and during data import all Superkey profiles
from previous releases will not be migrated.

1.2.8 Event Distribution to Monitoring Systems in CEF

More and more Security Information and Event Management (SIEM) systems are deployed in the
financial industry. These SIEM systems use rules, heuristics and artificial intelligence to detect
abnormal patterns in event logs of all types.
Until Release 7.2, the access to event details was limited and the structure was not formalised.
Release 7.2 introduces the ability to use the Common Event Format (CEF) when writing events to
the operating system log.
Most SIEM systems can then retrieve the information in CEF from the logs of the operating system.
It is now possible, similar to the event distribution via SNMP, to define for each event type whether it
should be distributed in CEF format to the local system log (syslog or Windows Event Journal).
Alliance Access also provides the option to use JSON or formatted JSON next to CEF, using the
same formalisation of data.
The security parameter Journalise Msg Text also applies to CEF events. Therefore, by
configuring this you indicate whether the message related events must also carry the messages
payload.
UNIX and Linux versions have a new security parameter Syslog facility to define in which
syslog facility the events must be stored.
For more information, see the section System in the Alliance Access Configuration Guide.

1.2.9 Improved Information in Events

Based on customer feedback, several events have been enhanced to provide clearer text or to
provide more details.

20 April 2018 14
Alliance Access 7.2 Overview
Release Letter

As a practical example, when writing a FIN batch file or a FileAct file to disk, an additional event
(10161 Message File Processed) will be logged at the end of the processing and provide:
• File name
• Full File path
• File creation date/time
• File last modification date/time
• File owner (if any)
• File size in bytes
• File Digest (using SHA256)
Additionally, when manually uploading a file for transmission by FileAct the event 30007 will also
log:
• File name
• File size in bytes
• Digest
Another example is event 3000, logging a succesful sign-on. Like all events that are the result of a
human operation, this event now also provides the hostname and the IP address of the system
where the browser is running used to perform the sign-on.
See Knowledge Base tip 5021833 for a detailed list of of added, updated, and removed events.

1.2.10 Support for Process Whitelisting Tools

One of the potential defences against cyber threats is the use of tools that validate that only
whitelisted processes are started. To be able to deploy such tools on the Alliance Access host, you
need to know which processes are used by Alliance Access.
These processes are listed in the saa_whitelist_embedded.txt and
saa_whitelist_hosted.txt files on the release media. In the $ALLIANCE\Access\data
directory, it is called whitelist.txt.
For more information, see Process Whitelisting in the Security Guide.

1.2.11 Support for SWIFTNet FileAct Enhancements

Alliance Access 7.2 supports the SWIFTNet FileAct enhancements implemented via SWIFTNet
Link 7.2.
For details on the FileAct enhancements, see the SWIFTNet Link 7.2 Release Letter.

Important Make sure that you read related information provided in Impact of Using FileAct with
Release 7.2 on page 4.

1.2.12 CREST over SWIFTNet Enhancements

Enhanced security
With Alliance Access 7.2 it is possible to select a more secure encryption algorithm for the
encryption between Network Security Layer (NSL) or CREST Programming Interface (CRPI) and
Alliance Access. This enhanced encryption requires the usage of at least NSL 7.2 or CRPI 7.2.

20 April 2018 15
Alliance Access 7.2 Overview
Release Letter

As of Alliance Access 7.2, the minimum encryption key length is enforced to 128-bit for the
encryption algorithm used by NSL and CRPI versions prior to 7.2.
SWIFT recommends to upgrade to the NSL 7.2 and CRPI 7.2 versions during the interfaces 7.2
migration window and to use the enhanced encryption algorithm.
For more information, see Network Security Layer in the Customer Application Integration Guide
(UNIX and Linux, Windows).

New CREST related permissions

The granularity of roles and permissions related to CREST over SWIFTNet has increased.
In addition, three pre-defined profiles are created using these new roles and permissions. It is
strongly advised that CREST clients assign the new (and more granular) roles and permissions to
their end-users.
During the migration, impact for the traffic-related profiles has been avoided. For configuration
tasks, the new admin profile or a customer-defined one needs to be assigned to the operators
following the migration.
For more information, see Default Operator Profiles (CRnet Interface Application) in the Security
Guide.

Local authentication for CRPI and CRFI back-office adapters

We have added to possibility to use Local Authentication for the CRPI and CRFI adapters, allowing
you to assure integrity and authenticity on these message flows.
For new CREST customer applications (CRPI or CRFI), the Local Authentication (LAU) will be
selected by default. It is still possible to deactivate the LAU. A warning message will be displayed
and a security event will be logged in such case.
For more information, see Using Local Authentication in the Configuration Guide.

CRFI output file format

A new output file format is added to the existing two (‘Sequence Number’, ‘Time stamp’), called
‘Time stamp extended’. The current ‘Time Stamp’ format uses the current time (hhmmss) to
construct a filename, so is limited to one file per second. If another file arrives in the same second,
CRFI must wait for the current time to move to the next second before it can store the file. The new
format adds a 2-digit extension to the filename when multiple files arrive in the same second.
For more information, see File Naming Conventions in the Customer Application Integration Guide
(Windows, AIX, Linux, Solaris)).

Link level encryption

The Network Security Layer (NSL) interface used between the CREST GUI and the Alliance
Access system, and the CRPI interface between the customer back-office and the Alliance Access
system allows the messages sent over the interface to be encrypted (called link-level encryption:
LLE).
As of Alliance Access 7.2, next to the previous LLE algorithm, a more secure LLE algorithm is
supported. For each workstation listener it needs to be indicated if the previous LLE algorithm or
the more secure algorithm is used. The more secure algorithm can be configured by selecting the
"Enhanced encryption" checkbox in the CRNet GUI.
It is not possible to receive traffic for both LLE algorithms on the same port. Per host/port
combination only 1 security algorithm can be used. In order to use the enhanced encryption
algorithm, CRPI 7.2 or higher and NSL 7.2 or higher is required. Older versions can only connect
with the previous LLE algorithm (by leaving the enhanced encryption checkbox unselected).

20 April 2018 16
Alliance Access 7.2 Overview
Release Letter

The key used for previous LLE algorithm can be of various lengths and, when the connection is
established, the client and server negotiate which is the highest key length they both support. Each
end specifies a minimum and maximum key length for negotiation. A key length of 0 means no
encryption. As of Alliance Access 7.2, the default minimum key length is set to 128. This value is
supported by NSL version 3.2 or higher and CRPI 3.2 or higher. If you are still using older versions
of NSL or CRPI you might need to lower the minimum key length.
For more information on how to configure such a minimum key length in Alliance Access, please
see the section "Encrypting Messages" in the Customer Application Integration Guide (Windows,
AIX, Linux, Solaris))

1.2.13 Message/Instance Search Enhancement

The GUI application Message Instance Search has been removed and the functionality has been
integrated into the Message Search application.
This facilitates the search actions by having a single centralised GUI screen from which you can
perform any message or instance search.
Changes have therefore been made to the search criteria, to incorporate the options to search on
instances and to choose what to search on.
For more information, see Search for Messages in the Message Management Guide.

1.2.14 Identifying Messages Touched by Human

Upon demand from the community we have enhanced Alliance Access to clearly indicate which
messages have been processed in a fully automated way, and which messages have experienced
operator interaction during its lifetime in Alliance Access. This will not include only messages
created by an operator, but also messages modified or completed by an operator.
In the message search GUI, two new search criteria are provided:
• a Touched by Human checkbox, allowing you to filter out those messages where a human
interaction took place
• an Operator field to be used in combination with Touched by Human, to list only those
messages that a specific operator had interaction with.
For more information, see Search by Source and Creation in the Message Management Guide.

1.2.15 Security Best Practice Check Tool

In order to help administrators and auditors in their work to monitor the security status of their
system, and collect evidence to assure compliance with the SWIFT Customer Security Framework,
SWIFT has created a Security Best Practice Check Tool. The tool provides you with information
that helps you identify how well your configuration meets the security controls defined in the
Security Guidance for Alliance document.
The tool can only be executed from the command line by the Alliance Access Administrator
account, and the report generated is only accessible by the same Alliance Access Administrator
account.
For more information, see "Security Best Practice Check Tool" in the Security Guide.

20 April 2018 17
Alliance Access 7.2 Overview
Release Letter

1.2.16 Changes in Operator Behaviour

Release 7.2 introduces enhancements in the operator's area to allow the implementation of more
efficient security controls.
• When an operator is only allowed to access the system between certain hours of the day, they
will be logged out once the time limit is reached, regardless of whether their session is still
active or not. Before 7.2, the session would remain open while activity was still ongoing.
The operator will receive a warning a few minutes before the time limit will be reached.
• Release 7.2 also introduces the possibility to prevent access on holidays. This is controlled by
associating a calendar to the Signon Permission of an operator's profile.
• A time zone can also be defined in the operator details. That local time zone information will
then be used when the operator signs on the Alliance Access applications to perform the
necessary access checks (like validating the limitation based on time, calendar…).
By default, the Alliance Access server time zone value is assigned to the operator.
• An email address can optionally be associated to each operator. This parameter is only
provided as information and allows you to reconcile user reports with other data more easily.
• In the GUI applications, after a successful operator sign on, the message status bar will briefly
display the “Last login date and time”. The information is provided so that the user can notice if
somebody else has used their credentials.
For more information, see the section Sign-on Time Limits in the Alliance Access Security Guide.

1.2.17 New Security Parameters to Control the JVM Options for

the Integration Platform (IPLA)
To change the values for the JVM properties, the JvmOption configuration file had to be edited
previously.
This file has become uneditable in Alliance Access 7.2 and two new security parameters have been
introduced to allow the JVM properties to be altered. These parameters are IPLA max heap size
and IPLA Extra System Properties and are used to configure the different JVM properties
needed for the specific IPLA solution.
Similar security parameters have been put in place for Operational Reporting and Web Service.
The added benefit is that these parameters will be persisted through an upgrade of the software.

1.2.18 Alliance Access Operator Required to Launch Integration

Platform (IPLA) Command Line Tools
The Alliance Access software owner account remains mandatory to launch any of the IPLA
command line tools.

With Release 7.2, all command line tools will in addition also require a valid Alliance Access
operator with its related password. The operator will need to be defined with the needed
entitlements through the Alliance Access configuration GUI packages.

With Release 7.2, the usage of the ipla_admin tool becomes mandatory to install any components
or user-libs inside the Integration Platform. The formerly allowed method which consisted to drop
files directly into the userlib folder or into the deploy folder is no longer allowed.

20 April 2018 18
Alliance Access 7.2 Overview
Release Letter

1.2.19 Unique Identifier per Installed Instance

Each installed instance of Alliance Access is assigned a unique identifier (UUID) during installation.
This identifier does not change as a consequence of any subsequent upgrade. This will help you to
associate reports and log information to specific systems even when the report or log is consulted
offline.
This unique identifier will be used amongst others:
• In events forwarded to monitoring systems via SNMP
• In events forwarded to syslog
• In the output of the command saa_system Version
• For each event when using saa_query –event
• In the licensing screen
• In the User session info in the application GUI when you are connected to a system

1.3 Resolved Problems

See Knowledge Base tip 5021834 for a detailed list of all change requests addressed in this
release.

1.4 Software Distribution

This Release of Alliance Access is available on the Download Centre on www.swift.com.
The software package consists of two files that need to be downloaded separately:
• a .tar file (Access7200_RHEL.tar) containing the following:
- Alliance Access 7.2
- Alliance Access/Entry 7.2 GUI package
• a .tar file (EmbeddedDatabaseFootprint72_RHEL.tar) containing the Oracle embedded
database file

CREST components
The software for the CRNet Programming Interface (CRPI) and Network Security Layer (NSL) are
available on the Download Centre on www.swift.com as separate packages.

1.4.1 Validating Downloads from the SWIFT Download Centre

For all software products that are available for download on the SWIFT Download Centre, SWIFT
publishes security information that allows customers to verify the data integrity of the downloaded
product.
For more information about the security mechanism used for this validation, see Knowledge Base
tip 5021288.

1.5 Support Duration

20 April 2018 19
Alliance Access 7.2 Overview
Release Letter

This base release of Alliance Access 7.2 will be supported until the next annual update becomes
mandatory. This will be the 2018 Message Standards update, planned to be mandatory by 16
November 2018.

1.6 System Requirements

1.6.1 Hardware Requirements for Release 7.2

New environment for Release 7.2
For Release 7.2, an in-place upgrade path is not available. The migration process assumes a
separate environment is available in line with the OS baseline.
For guidance on system sizing (number of CPUs, memory) see the Hardware Requirements page
on www.swift.com.
In addition, the following requirements need to be taken into account:
• TEMP directory, minimum 1 GB
• installation directory (including database), minimum 20 GB

1.6.2 Operating System Requirements for Release 7.2

Operating system (OS) versions
Release 7.2 software is qualified using the English language version of the following operating
systems:

Operating system Support version

AIX AIX v7.2 with TL01 and SP01. TL01 can be installed after the base AIX
v7.2 installation. SP01 must be installed after the TL01 installation.
IBM PowerHA SystemMirror Standard Edition 7.2.0 has been used for
qualifying Alliance Access 7.2 with licences containing 11:DUAL
HARDWARE, and requires RSCT 3.1.2.0 or higher.

Linux Red Hat Enterprise Linux 7.2, 64-bit

Red Hat Enterprise Linux 6.7, 64-bit, is supported until February 2020 to
provide time for customers to deploy Red Hat Enterprise Linux 7.2.

Oracle Solaris Oracle Solaris 11.3.7.5.0

Windows Windows Server 2016 (Server with Desktop Experience)

SWIFT provides support for higher versions of these operating systems, as outlined in the
knowledge base tip, Can you install SWIFT products on Operating System or third-party software
versions that are different from those on which they have been qualified? (1212959).

Hardening supported operating system

SWIFT requires hardening of your operating system. For more information, see Information for
Hardening Supported Operating Systems.

20 April 2018 20
Alliance Access 7.2 Overview
Release Letter

Related information
OS Levels and Patches Baseline
Alliance Product Family Compatibility Matrixes

1.6.2.1 Web Browsers

Release 7.2 GUIs have been qualified using the English language version of the following
browsers.

Web browser versions

Browsers must be running on Windows operating system and must be configured with TLS 1.2
enabled.

Windows version Web browser Browser version

Windows 7 Professional, 32-bit Internet Explorer 11 32-bit or 64-bit
or 64-bit (client)
Firefox ESR 52.0 32-bit or 64-bit
Windows 10 Enterprise, 64-bit Internet Explorer 11 32-bit or 64-bit
(client)
Firefox ESR 52.0 32-bit or 64-bit
Microsoft Edge only in 64-bit
Chrome 57 only in 64-bit

Related information
For more information, see the section about Web Browser Settings in the Installation Guide:
Alliance Web Platform Server-Embedded Installation Guide - Linux

1.6.3 Memory Requirements

The memory requirements for Alliance Access 7.2 available on the Release 7.2 hardware reference
page on swift.com.
On UNIX and Linux, the system should be configured to have at least 8 GB of swap space before
you start an installation or upgrade for Alliance Access 7.2.

1.6.4 SWIFTNet Requirements

Alliance Access 7.2 has the following SWIFTNet requirements:
• Alliance Access connects to SWIFTNet through Alliance Gateway 7.2 (or higher) using relaxed
mode.

1.6.5 Integration Platform

Consult with the provider of your IPLA components to find out if your component is compatible with
Alliance Access 7.2.

20 April 2018 21
Alliance Access 7.2 Overview
Release Letter

The following SWIFT provided IPLA components are compatible with Access 7.2:
• Connector for T2S version 1.2.10
• Connector for Sanctions version 1.2.40
• Connector for SWIFT gpi (all versions)

1.6.6 Application Developer Kit

Alliance Developer Kit components need to be built for Access 7.2 or higher. Versions used on
Alliance Access 7.1 are not compatible.

1.6.7 Other Requirements

1.6.7.1 Software from Oracle for Hosted Database Option

The installation of Alliance Access 7.2 with the hosted database option requires an Oracle
database with one of the following versions:
• Oracle 12.1, or higher

1.6.7.2 IBM MQ
If you want to use the IBM MQ Host Adapter integrated in Alliance Access 7.2, then the following
IBM MQ software version must be installed:
• IBM MQ 8.0.0.6
Note While SWIFT ran the full release 7.2 qualification cycle using IBM MQ 8.0.0.6, IBM
has not certified this for usage on Windows Server 2016. Soon after the availability
of release 7.2; IBM will release IBM MQ 8.0.0.8, certified on Windows Server 2016.
This version of the MQ Client is fully supported by SWIFT (see KB tip 1212959).
SWIFT recommends to only use in production IBM MQ 8.0.0.8 and higher on the
Windows platform to be in line with the SWIFT Customer Security Controls
Framework.
As of Alliance Access 7.2, Alliance Access can only be integrated with the IBM MQ Client. Direct
integration with IBM MQ Server is not supported anymore.

1.6.7.3 LDAP Packages

Client LDAP packages are required if you want to use the LDAP functionality.
Please refer to the OS Levels and Patches Baseline document, dated 25 August 2017, for the list of
necessary packages.

1.6.7.4 Alliance Access and Network Drives

SWIFT has not qualified Alliance Access/Gateway/Web Platform Server-Embedded whereby
software or database files reside on an NFS-mounted or mapped network drive.
See Knowledge Base tip 5020267 for for more detail.

20 April 2018 22
Alliance Access 7.2 Overview
Release Letter

1.6.7.5 CREST over SWIFTNet

When using Alliance Access for the CREST service it is required to deploy Oracle Tuxedo on the
same system.
New versions of CRPI client and NSL are provided, allowing CREST clients to upgrade the
connectivity of their client applications, in combination with the 7.2 upgrade.
Alliance Access 7.2 for CREST has the following requirements:
• Tuxedo 12cR2 must be installed together with patch RP089 or higher. The patch is available
from the Download Centre on www.swift.com.
• Alliance Access 7.2 will mandate that encryption keys have a minimum length of 128 bits. If it
does not work because the client is using an old version of CRPI or NSL, you must manually
change the key length back to 0. For more information, see the section "Encrypting Messages"
in the Customer Application Integration Guide (Windows, AIX, Linux, Solaris).
• CRnet File Interface (CRFI) and CRnet Programming Interface (CRPI): configure Local
authentication (LAU) between the back-office application and Alliance Access.
• The current version of CRPI and NSL and the new CRPI 7.2 and NSL 7.2 can connect to
Alliance Access 7.2.
After the Alliance Access 7.2 migration, SWIFT recommends that you upgrade NSL and CRPI to
the 7.2 versions.
• After the Alliance Access 7.2 installation, validate the configuration in the CRNet GUI and start
the CRNet component to ensure that the system is fully operational.

1.6.7.6 CRPI and NSL for CREST over SWIFTNet

CRPI 7.2 can be installed on IBM AIX v7.2, Red Hat Enterprise Linux 6.7 or 7.2, Oracle Solaris
11.3.7.5.0, and Windows systems.
CRPI 7.2 will remain in 32-bit mode for AIX, Solaris, and Windows, and in 64-bit mode for Red Hat
Enterprise Linux platforms.
NSL 7.2 software can be installed on Windows only.

1.6.7.7 Supported Encryption Algorithms in TLS, SOAP and IPLA IBM MQ

As from Release 7.2, all TCP/IP connections will use TLS version 1.2. These are the supported
cryptographic algorithms:
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

1.7 Documentation
The following documents have been updated to describe additional functionality and change
requests addressed in Alliance Access 7.2:
• Alliance Access Administration Guide - Linux
• Alliance Access Installation Guide - Linux
• Alliance Access Message Management Guide

20 April 2018 23
Alliance Access 7.2 Overview
Release Letter

• Alliance Access Monitoring Guide

• Alliance Access Relationship Management Guide
• Alliance Access REST API Developer Guide
• Alliance Access Security Guide
• Alliance Access Service Description
• Alliance Security Guidance
• Information for Hardening Supported Operating Systems

Documentation for CREST over SWIFTNet Users

The following guides are specifically for CREST over SWIFTNet users:
• CREST over SWIFTNet Customer Application Integration Guide - UNIX and Linux
• CREST over SWIFTNet Customer Application Integration Guide - Windows

1.8 Warnings and Known Issues

See Knowledge Base tip 5021835 for the latest detailed list of all warnings and known issues with
Release 7.2.

1.8.1 Licensing
Alliance Access 7.2 does not require a license for Release 7.2.

Fresh installation
During the fresh installation of Alliance Access 7.2, the license of the current version can be used.
However, check that current Alliance Access licensing does not have the option 18:CAS TCP/IP
selected. If you have it, then you must retrieve the latest license sheet using Secure Channel, and
use the new license during the installation of Alliance Access 7.2.
Note If you change the platform to AIX, Oracle Solaris, or Windows, from any other
operating system then you must obtain the license for the platform you are migrating
to.

Migration to the same platform

If you install Alliance Access 7.2 using the Install Alliance Access 7.2 from prepared backup file
option, then the licensing option is not provided during installation. However, check that current
Alliance Access licensing does not have the option 18:CAS TCP/IP selected. If you have it, then
you must retrieve the latest license sheet using Secure Channel and relicense Alliance Access
7.1.x before preparing the backup.

Migration to Linux
If you change the platform to Linux from AIX, Oracle Solaris, or Windows, and install Alliance
Access 7.2 on Linux with the option Install Alliance Access 7.2 from prepared backup file, then
the licensing option is not provided during installation. However, SWIFT recommends that you
obtain a new license sheet and perform the relicensing after the migration.
Check that current Alliance Access licensing does not have the option 18:CAS TCP/IP selected. If
you have it, then you must retrieve the latest license sheet using Secure Channel and relicense
Alliance Access 7.1.x before preparing the backup.

20 April 2018 24
Alliance Access 7.2 Overview
Release Letter

1.8.2 Change in Process to Consult Archives from Previous

Releases
Due to the technology refresh, the process to restore message and event archive backups made on
release 6.2 onwards has changed.
A separately installed tool is provided to convert the archives.
For more information, see the section "Convert Backups of Message and Event Log Archives" in
the Installation Guide (AIX,Linux,Solaris,Windows).

1.8.3 Changes to Permissions

New permissions

Compared to Alliance Access 7.1.23 and 7.1.30, the following permissions have been introduced to
support the new features described earlier:

Permission Description

Applic. Interface - Configure LTA Controls whether an operator is allowed to see and
edit the LTA configuration fields or not.

Security Definition - Pwd Blacklist Controls whether an operator is allowed to see and
edit the password blacklist, which contains pattern
occurences that cannot be part of an operator
password.

Access Control - Signon New permission "Assign Calendar" allows a calender

to be assigned to an operator profile.

Calendar - Modiy Calender Year New permission that allows an operator profile to
modify a calendar year of a calendar assigned to an
operator .

Message File - Open\Save File Controls when an operator can view the details of a
FileAct message and to download the File itself out
from the message.

New permissions for CREST over SWIFTNet

Permission Description

CRnet Interface - Dashboard Allows the operator to administer and monitor the
CREST traffic and applications.

CRnet Interface - Communication Configure SAG connections

Configure Workstation Listeners

CRnet Interface - CRFI Appplications Configure, Hold/Release, Manage LAU left part,
Manage LAU right part

20 April 2018 25
Alliance Access 7.2 Overview
Release Letter

1.8.4 Changes to Events

See Knowledge Base tip 5021833 for a detailed list of of added, updated, and removed events.

1.8.5 Changes to Parameters

New parameters

Compared to Alliance Access 7.1.23 and 7.1.30, the following parameters have been introduced to
support the new features described earlier:

Parameters Description

LTA Enabling To disable the usage of the LTA feature for all
Message Partners.

System - Auth type available Defines the different accepted Authentication types
available for Human operators.
Accepted values are: Password, RADIUS one-
time password, LDAP, Password and TOTP.

System - Extra Sec Officer Determine whether both security officers (LSO/RSO)
have the right to create additional security officers.

System - 4 Eyes mechanism To force the 4 Eyes mechanism for the Operator,
Message Partner and Routing schema entities.

System - Syslog facility Describes the local syslog facility where the Alliance
Access events must be stored (UNIX only)

Security - Journalise Msg Text Determines whether the message related events
must also carry the messages payload.

IPLA max heap size The Integration Platform maximum heap size (in MB).
The Integration Platform component must be
restarted for changes to this parameter to take effect.

IPLA Extra System Properties Additional system properties for the Integration
Platform, to be entered as JVM options (one by row).
Example: -Dproperty1=value1. The Integration
Platform component must be restarted for changes to
this parameter to take effect.

Minimum blacklist size Specifies the minimum amount of distinct password

occurrences that need to be contained in the
password blacklist.

System – Syslog Format Format of the messages that will be sent to the
syslog.
Accepted values are: Raw, CEF, Json, Json
formatted. Default value: CEF

20 April 2018 26
Alliance Access 7.2 Overview
Release Letter

Removed parameters

Parameter Description

Enabled Crypto Protocols Security parameter that allowed the management of

the accepted TLS version.

Sec Officer - OTP Srv Group security parameter Was used to specify the authentication server group
assigned to Security Officers.

Sec Officer - Authentication Type security parameter Was used to specify the authentication type for
Security Officers.

GPII fields display Was used to allow the operator to hide or display the
GPII related fields from the message editor.

1.8.6 Security Parameter “System – 4 Eyes mechanism”

Known limitation
Once the security parameter System – 4 Eyes mechanism (controlling 4Eyes) parameter is set
then the CREST customers must enable/disable the CREST specific Message Partners through
the standard Message Partner GUI.

1.8.7 Migration impact

• The default superkey profiles will be removed during the migration to release 7.2.
• Gateway Connection definitions without LAU will be marked unreliable and can not be used for
message flows to/from SWIFT.

1.8.8 Alliance Developers Toolkit

The manual launch of the Alliance Developers Toolkit (ADK) process using the launch command is
no longer supported. The ADK process has to be registered in Alliance Access and then launched
automatically by the Automatic Process Launch.
Please refer to the ADK Developer documentation in the Alliance Access software release tree:
$ALLIANCE/ADK/doc/index.html (Unix)

%ALLIANCE%\ADK\doc\index.html (Windows)

1.9 Obsolete Functionality

1.9.1 End of Support for Alliance Workstation

As of Release 7.2, there is no support for Alliance Workstation. This GUI platform was already
deprecated several years ago, and has been completely removed in Alliance Access 7.2
Make sure that operators and end-users of Alliance Access are trained to use the GUI applications
on Alliance Web Platform Server-Embedded, which replace Alliance Workstation.

20 April 2018 27
Alliance Access 7.2 Overview
Release Letter

Consequences of the Retirement of Alliance Workstation

With 7.2 all remnants of the Alliance Workstation have been removed. This has the following
impact:
• customers who used the Alliance Workstation GUI on the server to perform message
processing or system administration must now use the Alliance Web Platform Server Embedded
based GUIs.

1.9.2 End of support for Common Application Server (CAS)

The CAS protocol has not been supported for a while. With Release 7.2 you will see that several
artefacts that were still referring to CAS have been removed from both the software and the
documentation.

20 April 2018 28
Alliance Access 7.2 Installation and Migration
Release Letter

2 Installation and Migration

Refer to the appropriate version of the Installation Guide (AIX, Linux, Oracle Solaris, Windows) for
detailed instructions to guide you through the installation of Alliance Access 7.2.

2.1 Fallback Activities

There is no possibility to fallback to a previous release from Alliance Access 7.2.
Alliance Access 7.2 and the other 7.2 release products run on a different operating system
architecture than previous releases. This requires the installation to be done on an independent
new environment. Therefore, if you are migrating from an existing operational system and you are
unable to successfully install Alliance Access 7.2, or any other 7.2 release products on the same
host, then you must revert to your previous system to remain operational:
• If you are unable to successfully install Alliance Access 7.2 and SWIFTNet Link 7.2 is not
installed on the same host, then you can revert to your previous system
• If you are unable to successfully install Alliance Access 7.2 and SWIFTNet Link 7.2 is installed
on the same host, then see Revert to Previous System in the applicable SWIFTNet Link 7.2
Installation Guide
• If you are unable to successfully install any other 7.2 release products on the same host as
Alliance Access 7.2, then see the Fallback section in the corresponding installation guide
To attempt to re-install Alliance Access 7.2, you must first remove the existing Alliance Access 7.2
installation.

20 April 2018 29
Alliance Access 7.2 Support
Release Letter

3 Support
Support for SWIFT customers
By default, SWIFT Support is the single point of contact to report all problems and queries that
relate to SWIFT services and products. Support is available to all SWIFT customers.
Individuals within a customer organisation must register to use the Support service.
For more information about the different services that SWIFT offers as part of the support
packages and the procedure to order support, see Comparison of support packages on swift.com.

Related information
For more information about Support services, see the service description related to the applicable
support package:
Support documentation

20 April 2018 30
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

A Routing Keyword Extraction and Verifiable

Fields
The following table lists the Standards MT November 2017 routing keywords and verifiable fields for
each message in this Deployment Package.
The first set of columns, entitled "Keyword", lists per Message Type (MT) the fields that are
extracted for the default keywords, Currency/Amount, and Date. These keywords, which are verified
against operator permission, are used to facilitate search criteria and sorting functions in GUI
applications, such as the Message Approval application.
Note For repetitive fields, and unless specified otherwise, keywords are always extracted
from their first occurrence, and in the case of repetitive sub sequences, only the first
instance is considered.
A message is scanned top-down and the first field that matches the table is extracted.
The second set of columns, entitled "Verifiable", lists those fields that need to be re-entered by an
operator for message approval. Unless specified otherwise, all occurrences of repetitive fields are
verified.

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

101 Seq A.F20 Seq B.F32B Seq B.F32B F32B,F33B F32B,F33B

F32A,F32B, F19,F32A,F
102 Seq A.F20 Seq C.F32A Seq C.F32A Seq C.F32A F33B,F71F,F 32B,F33B,F F32A
71G 71F,F71G

F32A,F32B, F19,F32A,F
102.
Seq A.F20 Seq C.F32A Seq C.F32A Seq C.F32A F33B,F71F,F 32B,F33B,F F32A
STP
71G 71F,F71G

F32A,F33B, F32A,F33B,
103 F20 F32A F32A F32A F32A
F71F,F71G F71F,F71G

103.
F32A,F33B, F32A,F33B,
REMI F20 F32A F32A F32A F32A
F71F,F71G F71F,F71G
T

103. F32A,F33B, F32A,F33B,

F20 F32A F32A F32A F32A
STP F71F,F71G F71F,F71G

F19,F32B,F3
F32B,F33B,
104 Seq A.F20 Seq C.F32B Seq C.F19 F30 3B,F71F,F71 F30
F71F,F71G
G

105 F20

F19,F32B,F3
F32B,F33B,
107 Seq A.F20 Seq B.F32B Seq C.F19 F30 3B,F71F,F71 F30
F71F,F71G
G

20 April 2018 31
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

110 F20 F32A,F32B F32A,F32B F32A F32A,F32B F32A,F32B F32A

111 F20 F32A,F32B F32A,F32B F32A F32A,F32B F32A,F32B F32A

112 F20 F32A,F32B F32A,F32B F32A F32A,F32B F32A,F32B F32A

190 F20 F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D

191 F20 F32B F32B F32B F32B

192 F20

195 F20

196 F20

198 F20

199 F20

200 F20 F32A F32A F32A F32A F32A F32A

201 F20 F32B F19 F30 F32B F19,F32B F30

202 F20 F32A F32A F32A F32A F32A F32A

202.
F20 F32A F32A F32A F32A,F33B F32A,F33B F32A
COV

203 F20 F32B F19 F30 F32B F19,F32B F30

204 Seq A.F20 Seq B.F32B Seq A.F19 Seq A.F30 F32B F19,F32B F30

205 F20 F32A F32A F32A F32A F32A F32A

205.
F20 F32A F32A F32A F32A,F33B F32A,F33B F32A
COV

210 F20 F32B F32B F30 F32B F32B F30

290 F20 F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D

291 F20 F32B F32B F32B F32B

292 F20

295 F20

296 F20

20 April 2018 32
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

298 F20

299 F20

Seq Seq F32B,F33B, F32B,F33B,

300 Seq A.F20 Seq B.F30V Seq B.F30V
B1.F32B B1.F32B F71F F71F

Seq Seq F32B,F32G, F32B,F32G,

304 Seq A.F20 Seq B.F30V Seq B.F30V
B1.F32B B1.F32B F33B F33B

F32B,F33B, F32B,F33B,
305 F20 F32B F32B F34P,F34R
F34P,F34R F34P,F34R

F32B,F33B, F32B,F33B,
Seq Seq
306 Seq A.F20 Seq B.F30X F33E,F34B, F33E,F34B, Seq B.F30X
B1.F34B B1.F34B
F71F,F32H F71F,F32H

F32B,F32H, F32B,F32H,
320 Seq A.F20 Seq B.F32B Seq B.F32B Seq B.F30V F33B,F33E, F33B,F33E, Seq B.F30V
F34E,F71F F34E,F71F

Seq Seq Seq Seq

Seq B.F19A:PRI B.F19A:PRI Seq B.F19A:PRI B.F19A:PRI Seq
321 A.F20C:SE N, Seq N, Seq B.F98A:VAL N,Seq N, Seq B.F98A:VAL
ME B.F19A:NIN B.F19A:NIN U B.F19A:NIN B.F19A:NIN U
T T T T

F32B,F32H, F32B,F32H,
Seq B.F32B, Seq B.F32B,
330 Seq A.F20 Seq B.F30V F33B,F33E, F33B,F33E, Seq B.F30V
Seq B.F32H Seq B.F32H
F34E F34E

Seq
F32B,F71F,F F32B,F71F,F
340 Seq A.F20 Seq B.F32B Seq B.F32B Seq B.F30F B.F30F,Seq
32H 32H
F.F30F

341 Seq A.F20 Seq B.F32B Seq B.F32B Seq B.F30F F32B,F34E F32B,F34E Seq B.F30F

F32B,F33B, F32B,F33B,
350 Seq A.F20 Seq B.F32B Seq B.F32B Seq B.F30V F33E,F34B, F33E,F34B, Seq B.F30V
F71F F71F

F32B,F32M, F32B,F32M,
360 Seq A.F20 Seq A.F32B Seq A.F32B Seq A.F30V Seq A.F30V
F32U,F71F F32U,F71F

F32B,F32M, F32B,F32M,
361 Seq A.F20 Seq A.F32B Seq A.F32B Seq A.F30V F32U,F33B, F32U,F33B, Seq A.F30V
F71F F71F

20 April 2018 33
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

F32H,F32M, F32H,F32M,
362 Seq A.F20 Seq B.F33F Seq B.F33F Seq A.F30V Seq A.F30V
F33E,F33F F33E,F33F

F32B,F32G, F32B,F32G,
364 Seq A.F20 Seq A.F32B Seq A.F32B Seq A.F30V Seq A.F30V
F32M F32M

F32B,F32G, F32B,F32G,
365 Seq A.F20 Seq A.F32B Seq A.F32B Seq A.F30V F32M,F33B, F32M,F33B, Seq A.F30V
F33E F33E

370 Seq A.F20C Seq B.F19A Seq B.F19A Seq B.F98A Seq B.F19A Seq B.F19A Seq B.F98A

Seq Seq Seq

380 A.F20C:SE Seq B.F19B Seq B.F19B B.F98A:RVA B.F98A:RVA
ME L L

Seq Seq
381 Seq A.F20C Seq B.F19B Seq B.F19B B.F98A:VAL B.F98A:VAL
U U

390 F20 F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D

391 F20 F32B F32B F32B F32B

392 F20

395 F20

396 F20

398 F20

399 F20

F32A,F32B, F32A,F32B, F32A,F32B, F32A,F32B,

400 F20 F32A F32A,F33A
F32K F32K F32K,F33A F32K,F33A

F32A,F32B, F32A,F32B, F32A,F32B, F32A,F32B,

410 F20 F32A F32A
F32K F32K F32K F32K

412 F20 F32A F32A F32A F32A F32A F32A

Seq B.F32A, Seq B.F32A,

F32A,F32B, F32A,F32B,
416 Seq A.F20 Seq B.F32B, Seq B.F32B, Seq B.F32A F32A
F32K,F71F F32K,F71F
Seq B.F32K Seq B.F32K

F32A,F32B, F32A,F32B, F32A,F32B, F32A,F32B,

420 F20 F32A F32A
F32K F32K F32K F32K

20 April 2018 34
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

F32A,F32B, F32A,F32B, F32A,F32B, F32A,F32B,

422 F20 F32A F32A
F32K F32K F32K F32K

Seq A.F32A, Seq A.F32A,

Seq A.F32K, Seq A.F32K, F32A,F32K, F32A,F32K,
430 Seq A.F20 Seq A.F32A F32A,F33A
Seq A.F33A, Seq A.F33A, F33A,F33K F33A,F33K
Seq A.F33K Seq A.F33K

450 F20 F32A F32A F32A F32A F32A F32A

F32A,F33C, F32A,F33C, F32A,F33C,

455 F20 F32A F32A F32A
F33D F33D F33D

F32A,F32B, F32A,F32B,
456 F20 F32A,F32B F32A,F32B F32A F32A,F33D
F33D F33D

490 F20 F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D

491 F20 F32B F32B F32B F32B

492 F20

495 F20

496 F20

498 F20

499 F20

Seq B.F98A,
500 Seq A.F20C
Seq B.F98C

Seq B.F98A,
501 Seq A.F20C
Seq B.F98C

Seq Seq
B.F19A:ORD B.F19A:ORD
502 Seq A.F20C R, Seq R, Seq
B.F19A:CAN B.F19A:CAN
C(1) C(1)

Seq Seq Seq

503 A.F20C:SE B.F19B:COV B.F19B:COV
ME A A

Seq Seq Seq

504 A.F20C:SE B.F19B:COV B.F19B:COV
ME A A

20 April 2018 35
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

Seq
505 A.F20C:SE
ME

Seq
506 A.F20C:SE
ME

Seq
507 A.F20C:SE
ME

Seq
508 A.F20C:SE
ME

509 Seq A.F20C

Seq
B.F98A:RRE
510 Seq A.F20C G, Seq
B.F98C:RRE
G

Seq
C.F98A:TRA
Seq C.F19A, Seq C.F19A,
D, Seq
Seq Seq
513 Seq A.F20C C.F98C:TRA
D3.F19A:SE D3.F19A:SE
D, Seq
TT TT
C.F98E:TRA
D

Seq
Seq Seq B.F98A:TRA
B.F19A:SET B.F19A:SET D, Seq
514 Seq A.F20C T, Seq T, Seq B.F98C:TRA
C3.F19A:SE C3.F19A:SE D, Seq
TT TT B.F98E:TRA
D

Seq
Seq C.F19A, Seq C.F19A,
C.F98A:SET
Seq Seq
515 Seq A.F20C T, Seq
D3.F19A:SE D3.F19A:SE
C.F98C:SET
TT TT
T

Seq B.F32A, Seq B.F32A,

516 Seq A.F20 Seq B.F32A F32A,F32B F32A,F32B F32A
Seq B.F32B Seq B.F32B

20 April 2018 36
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

517 Seq A.F20C

Seq
Seq B.F19A, Seq B.F19A,
B.F98A:SET
Seq Seq
518 Seq A.F20C T, Seq
C3.F19A:SE C3.F19A:SE
B.F98C:SET
TT TT
T

Seq B.F98A,
519 Seq A.F20C
Seq B.F98C

Seq B.F98A,
524 Seq A.F20C
Seq B.F98C

526 Seq A.F20

Seq
Seq Seq Seq A.F98A:EXR
527 A.F20C:SE B.F19A:TRA B.F19A:TRA Q, Seq
ME A A A.F98C:EXR
Q

530 Seq A.F20C

535 Seq A.F20C

536 Seq A.F20C

537 Seq A.F20C

538 Seq A.F20C

Seq
B.F98A:SET
540 Seq A.F20C T, Seq
B.F98C:SET
T

Seq
Seq Seq B.F98A:SET Seq Seq
541 Seq A.F20C E3.F19A:SE E3.F19A:SE T, Seq E3.F19A:SE E3.F19A:SE
TT TT B.F98C:SET TT TT
T

Seq
B.F98A:SET
542 Seq A.F20C T, Seq
B.F98C:SET
T

20 April 2018 37
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

Seq
Seq Seq B.F98A:SET Seq Seq
543 Seq A.F20C E3.F19A:SE E3.F19A:SE T, Seq E3.F19A:SE E3.F19A:SE
TT TT B.F98C:SET TT TT
T

Seq
B.F98A:ESE
544 Seq A.F20C T, Seq
B.F98C:ESE
T

Seq
Seq Seq B.F98A:ESE
545 Seq A.F20C E3.F19A:ES E3.F19A:ES T, Seq
TT TT B.F98C:ESE
T

Seq
B.F98A:ESE
546 Seq A.F20C T, Seq
B.F98C:ESE
T

Seq
Seq Seq B.F98A:ESE
547 Seq A.F20C E3.F19A:ES E3.F19A:ES T, Seq
TT TT B.F98C:ESE
T

Seq
Seq Seq B.F98A:SET
548 Seq A.F20C B.F19A:SET B.F19A:SET T, Seq
T T B.F98C:SET
T

549 Seq A.F20C

Seq
Seq Seq Seq A.F98A:EXR
558 A.F20C:SE B.F19A:TRA B.F19A:TRA Q, Seq
ME A A A.F98C:EXR
Q

F32G,F32M, F19,F32G,F
559 F20 F34A F19 F34A
F34A 32M,F34A

20 April 2018 38
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

Seq
564 A.F20C:SE
ME

Seq
Seq D.F98A,
565 A.F20C:SE
Seq D.F98C
ME

Seq
Seq Seq Seq D1.F98A:PO
566 A.F20C:SE D2.F19B:PS D2.F19B:PS ST, Seq
ME TA TA D1.F98C:PO
ST

Seq
567 A.F20C:SE
ME

Seq
568 A.F20C:SE
ME

569 Seq A.F20C

575 Seq A.F20C

576 Seq A.F20C

Seq
Seq Seq B.F98A:SET Seq Seq
578 Seq A.F20C E3.F19A:SE E3.F19A:SE T, Seq E3.F19A:SE E3.F19A:SE
TT TT B.F98C:SET TT TT
T

581 F20 F34B F34B

586 Seq A.F20C

590 F20 F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D

591 F20 F32B F32B F32B F32B

592 F20

595 F20

596 F20

598 F20

20 April 2018 39
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

599 F20

F33G,F34P,
600 Seq A.F20 F33G F33G Seq B.F34P F34P,F34R F34P,F34R
F34R

F32B,F33B, F32B,F33B, F34P,F34R,

601 F20 F32B F32F F31G
F34P,F34R F34P,F34R F31G

604 F20 F30

605 F20 F30

606 F20 F30

607 F20 F30

F60F,F60M, F60F,F60M, F60F,F60M,

F62F, F62F, F62F,
608 F20
F62M,F64,F F62M,F64,F F62M,F64,F
65 65 65

F32B,F32H, F32B,F32H,
F34E, F34E,
620 F20 F32B F32B F30V F30V
F33B,F33E, F33B,F33E,
F71F F71F

670 Seq A.F20C

671 Seq A.F20C

690 F20 F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D

691 F20 F32B F32B F32B F32B

692 F20

695 F20

696 F20

698 F20

699 F20

700 F20 F32B F32B F32B F32B

701 F20

705 F20 F32B F32B F32B F32B

20 April 2018 40
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

F32B,F33B, F32B,F33B, F32B,F33B, F32B,F33B,

707 F20
F34B F34B F34B F34B

710 F20 F32B F32B F32B F32B

711 F20

720 F20 F32B F32B F32B F32B

721 F20

730 F20 F32B,F32D F32B,F32D F32D

732 F20 F32B F32B F32B F32B

F32A,F33A, F32A,F33A,
734 F20 F32A F32A F32A F32A,F33A
F33B F33B

740 F20 F32B F32B F32B F32B

F32B,F33B, F32B,F33B,
742 F20 F32B F32B F34A
F34A,F34B F34A,F34B

F32B,F33B, F32B,F33B, F32B,F33B, F32B,F33B,

747 F20
F34B F34B F34B F34B

F32B,F33B, F32B,F33B,
750 F20 F32B F32B
F34B F34B

F32B,F33A, F32B,F33A, F32B,F33A, F32B,F33A,

752 F20 F33A
F33B F33B F33B F33B

F32A,F32B, F32A,F32B,
754 F20 F32A,F32B F32A,F32B F32A F33B,F34A, F33B,F34A, F32A,F34A
F34B F34B

756 F20 F32B F32B F32B,F33A F32B,F33A F33A

760 F20

767 F20

768 F20 F32B,F32D F32B,F32D F32D

F32B,F32D, F32B,F32D,
769 F20 F32D
F33B,F34B F33B,F34B

790 F20 F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D

20 April 2018 41
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

791 F20 F32B F32B F32B F32B

792 F20

795 F20

796 F20

798 F20

799 F20

F32A,F33B, F32A,F33B,
800 F20 Seq B.F32A Seq B.F32A Seq B.F32A F32A
F34B F34B

801 F20 F33B F33B F33B,F34B F33B,F34B

802 F20 F32A F32A F32A F32A F32A F32A

824 F20 F68A F19 F68A F19,F68A

890 F20 F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D

891 F20 F32B F32B F32B F32B

892 F20

895 F20

896 F20

898 F20

899 F20

900 F20 F32A F32A F32A F32A F32A F32A

910 F20 F32A F32A F32A F32A F32A F32A

920 F20 F34F F34F

935 F20 F37H F30 F37H F30

F60F,F60M, F60F,F60M, F60F,F60M,

940 F20 F62F,F62M F62F,F62M F62F,F62M F62F,F62M, F62F,F62M, F62F,F62M,
F64,F65 F64,F65 F64,F65

20 April 2018 42
Alliance Access 7.2 Routing Keyword Extraction and Verifiable Fields
Release Letter

Keyword Verifiable field

MT
TRN Currency Amount Value Date Currency Amount Date

F60F,F62F,F F60F,F62F,F
F60F,F62F,F
941 F20 F62F F62F F62F 64,F65,F90 64,F65,F90
64,F65
C,F90D C,F90D

F34F,F90C,F F34F,F90C,F
942 F20 F34F F34F
90D 90D

F60F,F60M, F60F,F60M, F60F,F60M,

950 F20 F62F,F62M F62F,F62M F62F,F62M F62F,F62M, F62F,F62M, F62F,F62M,
F64 F64 F64

F60F,F60M, F60F,F60M, F60F,F60M,

970 F20 F62F,F62M F62F,F62M F62F,F62M F62F,F62M, F62F,F62M, F62F,F62M,
F64 F64 F64

971 F20 F62F F62F F62F F62F F62F F62F

F60F,F60M, F60F,F60M, F60F,F60M,

972 F20 F62F,F62M F62F,F62M F62F,F62M F62F,F62M, F62F,F62M, F62F,F62M,
F64 F64 F64

973 F20

985 F20

986 F20

990 F20 F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D F32C,F32D

991 F20 F32B F32B F32B F32B

992 F20

995 F20

996 F20

998 F20

999 F20

(1) The value with the CANC qualifier will be extracted only if the function of the message (F23G) is equal to CANC.

20 April 2018 43
Alliance Access 7.2 Switch-over Planning for Standards MT
Release Letter

B Switch-over Planning for Standards MT

The information contained in this appendix will help you in your planning for the switch-over to the
Standards MT November 2017. It lists in chronological order the actions that need to be taken.

B.1 Actions to be Taken Now

Assess the impact of the changed standards for your company (for example: Check whether you
either use any of the changed messages or will use any of the new messages. Check whether
back-office systems need an upgrade (for example).

B.2 Actions to be Taken as Soon as Possible

Complete these actions:
• Update your Alliance Access server to release 7.2.
• Install the relevant Web Platform Server-Embedded GUI packages and deployment packages.
Note Customers must install the Standards Release 2017 Message Management
Deployment Package at the latest on 19th November 2017.
• If relevant, inform the Web Platform GUI packages users that they must use the new URL.
• Assign the Standards MT November 2017 to your Test and Training logical terminals.
• Upgrade back-office systems where required.

B.3 Actions to be Taken Before 18th November 2017

For the new/changed messages, train your staff and test your back-office systems by sending
messages to the Test and Training network.

B.4 Actions to be Taken on 15th, 16th, or 17th

November 2017 (Last Business Day of the Week)
Complete these actions:
• Send your business messages as soon as possible.
• At the end of your business week, make sure that all your pending messages are transmitted.
• When your business week is finished, log out from the SWIFT network and log back in for
reception only. In this way, you can still receive and correctly process messages from other
correspondents.
• Close all your "from" message partners and open all your "to" message partners. In this way, all
received messages can still follow automatic processing.
Note On 18th November 2017 at 16:00 GMT, SWIFT will disconnect all users and
activate the new Standards MT November 2017.

20 April 2018 44
Alliance Access 7.2 Switch-over Planning for Standards MT
Release Letter

B.5 Actions to be Taken Before Your First Log In on

19th or 20th November 2017
Complete these actions:
• Make sure that as many messages as possible have been processed by Alliance Access. This
means that only a few or even no live messages must be left in the system.
• Assign the Standards MT November 2017 to all your live logical terminals.
• Log in to SWIFT and activate all the message partners that you use normally.
• Monitor your Alliance Access and back-office systems for correct behaviour (for example, check
all your templates for correct resolution).

B.6 Actions to be Taken after the First Login

Most of your FIN message templates will still be linked to the old Message Standards. Upon usage,
these templates will have to be resolved to be associated with the new standards, and might need
further changes before they are saved as templates again.

20 April 2018 45
Alliance Access 7.2 Standards Switch-over Planning for InterAct Services
Release Letter

C Standards Switch-over Planning for InterAct

Services
The information contained in this appendix will help you in your planning for the switch-over to a
new version of ISO 20022 standards used by a specific InterAct service. It lists in chronological
order the actions that need to be taken.
Contrary to the FIN annual message standards cut-over, the introduction of new versions of ISO
20022 messages is not a big bang event, but provides a relatively long migration period, a period
which does not have the same length for every ISO 20022 InterAct service and is determined and
communicated by the service administrator.
To cater for this, ISO 20022 InterAct services typically support two versions of the standards in
parallel for a period of time.
The high level guidelines below can help you plan adoption of new versions for the ISO 20022
InterAct services, of which you are a member.

C.1 Actions to be Taken When You Are Notified of a

Service Change
If you are a member of an InterAct service that will adopt new ISO 20022 message standards, you
want to make an initial assessment of how this will impact your infrastructure. You should look into
the following areas, among others:
• Understand what messages or message versions are added/removed from the service, and how
you use them
• Establish if Alliance Access is used for manual processing of these messages (create, modify,
verify, authorise)
• Establish if your Alliance Access routes messages based on message types or message
keywords
• Validate the readiness of the impacted back office systems.

C.2 Get Ready for Testing

Normal practice on InterAct is to allow both the current version and the next version of a particular
message type for a particular service at the same moment in time.
It is important to understand that once a service is provisioned for a new version of a message
type, the service will accept from your correspondents both the new version of that message type
added to the service and the previous version of that message type allowed in the service, and will
send them to you. You cannot choose to not receive the new version of a message at the technical
level. In most cases however there will be a bilateral agreement or group guideline, about the date
as of which it is allowed to use the new version of the message, first for the pilot service and later
for the production service.
For message flows to or from your back-office, make sure that you have a clear view of when your
back-office will be capable of supporting the changes in message standards. By default Alliance
Access does not distinguish a new version of a message type from an old version and will process
all messages through the routing you set up to distribute the messages to your back office. So it is
important that you know how your back office will behave when receiving new message versions for
the pilot service.

20 April 2018 46
Alliance Access 7.2 Standards Switch-over Planning for InterAct Services
Release Letter

In order to allow manual processing (create, modify, verify, authorise), and printing in human
readable format, you need to download the appropriate message standards Deployment Package
from the download centre on www.swift.com or from mystandards.swift.com. If you are using
specific usage guidelines for the service, also download the usage guideline specific deployment
package from mystandards.swift.com.
From the Alliance Access Configuration GUI package, install the new deployment packages. If a
previous version of the deployment package was installed, the installation process will mark all
messages types for that service as obsolete, and merge the message types from the new
deployment package with this. As a result of this process, all message types already loaded, and
no longer occuring in the latest deployment package will still be there and marked as obsolete,
while all messages in the latest deployment package will be marked as not obsolete and will be
available to the users. If there were some messages that should not be used by your users, you
can mark these manually as obsolete to prevent message creation. The release letters of the
deployment packages provide the details of what message versions are included in the deployment
package.
If you have usage guidelines installed, you need to do the same for each usage guideline linked to
the same service. It is possible that a specific usage guideline does not yet support the new
message standards version, and will not have an updated deployment package. For more
information, contact the publisher of the usage guideline.
In case you have created manually defined verifiable fields for a message in this service that got a
new version, you will need to configure the new version of the message to also have the
appropriate verifiable fields.
Once the deployment package is installed, the new message standard can be used both for the
production and all pilot/test versions of the service. If one of your users would create a message
using the new version before it has been activated on the SWIFT network a NACK will be returned.
If you try to create a message using a template that is linked to an obsolete message version,
Alliance Access will automatically try to convert it to the latest version available.
When no manual processing or human readable printing is required, the deployment package
installation is not necessary.

C.3 Migrate to the New Standards

Once the new message standards have been activated for the service you will typically be able to
use both the previously allowed version and the new version for a period of time. Keep in mind
however that while you can choose which versions you send (in agreement with your
correspondent), you may receive new versions of the messages on the production service.
You will need to inform your users who manually process messages about which message to use
and when.

C.4 Wind Down Use of the Old Standards

Once the new message version is in use you have entered a migration period where both versions
are available. When the end-of-support of an older message version is announced, you can start
monitoring usage to make sure that you have no business need for the old version by the time that
the message version reaches end-of-support.
In order to enforce the usage of the latest message version during manual processing you can use
the Alliance Access Configuration GUI package to configure the message version as obsolete.

20 April 2018 47
Alliance Access 7.2 Standards Switch-over Planning for InterAct Services
Release Letter

During this period, however, your back-office systems are expected to still be capable of processing
older message versions until they are removed from the service.

C.5 Stop Using the Old Standard

Old versions of messages standards would typically be removed during a subsequent update of the
service, which would bring you back to Actions to be Taken When You Are Notified of a Service
Change on page 46.
As long as you add new deployment packages for a specific service, you will keep track of
obsoleted message versions which means you will still be able to see messages using that old
message version in a human readable form. If you remove the old deployment package before
adding the new one, you will lose the information on obsolete messages and an attempt to display/
print them would result in a printout that is in an XML style format.

20 April 2018 48
Alliance Access 7.2 Legal Notices
Release Letter

Legal Notices
Copyright
SWIFT © 2018. 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. SCRL. The following are registered trademarks of SWIFT:
the SWIFT logo, SWIFT, SWIFTNet, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo,
MyStandards, and SWIFT Institute. Other product, service, or company names in this publication
are trade names, trademarks, or registered trademarks of their respective owners.

20 April 2018 49