Aa 7 1 20 RL PDF

Alliance Access 7.1.
20
Release Letter
This document contains release information for Alliance Access 7.1.20.
02 September 2016
Alliance Access 7.1.20
Release Letter Table of Contents
Table of Contents
Practical Information............................................................................................................................... 4
1 Release Overview.......................................................................................................................... 5
1.1 Purpose of this Document............................................................................................................. 5
1.2 Enhancements and Features........................................................................................................ 5
1.3 Resolved Problems..................................................................................................................... 12
1.4 Software Distribution................................................................................................................... 12
1.5 System Requirements................................................................................................................. 12
1.6 Documentation............................................................................................................................ 17
1.7 Warnings and Known Issues....................................................................................................... 18
1.8 Obsolete Functionality................................................................................................................. 19
1.9 Other Information........................................................................................................................ 20
2 Installation and Upgrade............................................................................................................. 21

2.1 Alliance Access........................................................................................................................... 21
2.2 Alliance Web Platform Server-Embedded................................................................................... 24
2.3 Alliance Workstation.................................................................................................................... 25
2.4 Additional Tasks.......................................................................................................................... 25
3 Support......................................................................................................................................... 26
A Routing Keyword Extraction and Verifiable Fields................................................................... 27
B Switch-over Planning for Standards MT.................................................................................... 42

B.1 Actions to be Taken Now............................................................................................................. 42
B.2 Actions to be Taken as Soon as Possible....................................................................................42
B.3 Actions to be Taken Before 19th November 2016....................................................................... 42
B.4 Actions to be Taken on 16th, 17th, or 18th November 2016 (Last Business Day of the
Week).......................................................................................................................................... 42
B.5 Actions to be Taken Before Your First Log In on 20th or 21st November 2016........................... 43
B.6 Actions to be Taken after the First Login..................................................................................... 43
C Standards Switch-over Planning for InterAct Services............................................................44

C.1 Actions to be Taken When You Are Notified of a Service Change.............................................. 44
C.2 Get Ready for Testing..................................................................................................................44
02 September 2016 2
Release Letter Table of Contents
C.3 Migrate to the New Standards..................................................................................................... 45

C.4 Wind Down Use of the Old Standards.........................................................................................45
C.5 Stop Using the Old Standard.......................................................................................................46
Legal Notices......................................................................................................................................... 47
02 September 2016 3
Release Letter Practical Information
Practical Information
Installation type Mandatory by 20 November 2016
Operating system requirements Same as for Alliance Access 7.1.1x

See System Requirements on page 12.
Customer installation path For Alliance Access:

Release 7.1.20
For Alliance Web Platform Server-Embedded GUI packages:
Release 7.1.20
Customer upgrade path For Alliance Access:

Release 7.1.10 - [7.1.11] - [7.1.12] - [7.1.13] - [7.1.14] - [7.1.15] -
7.1.20
For Alliance Web Platform Server-Embedded GUI packages:
Release 7.1.20
Product dependencies Same as for Alliance Access 7.1.1x

This release has dependencies on other products:
Alliance Web Platform Server-Embedded 7.0.20 (or higher)
Alliance Gateway 7.0 (or higher)
See also SWIFTNet Requirements on page 14 and Other
Requirements on page 16.
02 September 2016 4
Release Letter Release Overview
1 Release Overview
1.1 Purpose of this Document
This document contains release information for Alliance Access 7.1.20 (including Alliance Web
Platform Server-Embedded GUI package and Alliance Workstation).
Alliance Access 7.1.20 supports the Standards MT November 2016 release.
If you have not yet started to use the browser-based GUI on Alliance Web Platform Server-
Embedded, this is a good moment to plan ahead. This update brings the final functionality in
Alliance Web Platform Server-Embedded that will allow every remaining Alliance Workstation
user to complete the migration. Deploying Alliance Web Platform Server-Embedded will reduce
the effort you need to deploy Alliance Workstation on the different end-user systems. Alliance
Workstation end-of-life was announced in March 2015 and is planned for March 2017, without
any support extension foreseen. Alliance Web Platform Server-Embedded and Alliance
Workstation can be used in parallel to ease the transition.
First read this release letter, and then use the other documentation provided for more detailed
information (for a complete list of the documentation, see Documentation on page 17).
1.2 Enhancements and Features
1.2.1 Overview
Alliance Access 7.1.20 includes all changes introduced since release 7.1 (7.1.10, 7.1.11, 7.1.12,
7.1.13, 7.1.14, and 7.1.15). If you are upgrading from a version earlier than 7.1.15, please read
the 7.1.15 Release Letter, where significant enhancements are described.
This update contains the following enhancements and new features:
Updates for Standards MT November 2016
Support for two-factor authentication
Password policy changed
CREST over SWIFTNet enhancement
Global payments innovation initiative (gpii)
New XMLv2 revision
Change the syntax version on multiple LTs simultaneously
Locked message in text_modification, change in behaviour
Alarms visibility and actions, change in functionality
New licensing configuration application
Additional validation of existing RMA
Local printer support
RESTful API available to provide browser-based GUI
02 September 2016 5
ADK integrity now checked when Alliance Access started

User documentation set extended with Security Guidance guide
See also Knowledge Base tip 5021025 for a detailed list of other functional enhancements that
are implemented in 7.1.20.
1.2.2 Updates for Standards MT November 2016

Alliance Access 7.1.20 introduces the Standards MT November 2016 and implements all
required changes to support the new standards. For more information, see the Standards page
on swift.com.
1.2.3 Support for Embedded Two-Factor Authentication

Embedded two-factor authentication has been introduced in Alliance Access and Alliance Entry.
Two-factor authentication (2FA) is a method of user authentication where at least two different
components are required to authenticate a user. Typically this is something you know
(username/password) and something you have (a one-time-password generator, for example).
Following a sudden increase in demand for information about the one-time password feature in
Alliance Access and Alliance Entry, SWIFT decided to enhance its offering in authentication
methods by providing an embedded 2FA solution next to the existing local user database. This
solution is less complex and costly than implementing a RADIUS environment.
Based on recent TOTP technology (RFC 6238), SWIFT now provides a secure 2FA setup that
can be used with an off-the-shelf application. The application could be installed on a separate
device such as a mobile phone or tablet. It should not be installed on the PC used to display the
GUIs of the Alliance products. SWIFT does not select a specific vendor of client TOTP solutions,
allowing the customer the freedom of choice.
New configuration parameters are available on Alliance Web Platform Server-Embedded that
allow you to specify for which Alliance products you want two-factor authentication to be
enabled.
In order to enable embedded two-factor authentication the following high level steps need to be
taken:
1. On Alliance Web Platform Server-Embedded (minimum version 7.0.70), change the
configuration parameter for two-factor authentication for the Alliance products where you
want it to be applied. This will change the logon screen to allow the second factor to be
entered in a separate Use Two-Factor Authentication field.
2. On the relevant Alliance product, configure the operator to use time-based one-time-
password.
3. During the next logon, the operator will be presented with the secret key, which has to be
provided to the device that will generate the second factor.
4. From then on, the operator has to use the second factor during logon. When not logging on
via the GUI, the second factor has to be entered together with the fixed password.
For more information, see the section Embedded Two-Factor Authentication in the Configuration
Guide.
This feature requires Alliance Web Platform Server-Embedded 7.0.70.
02 September 2016 6
Note For more information on TOTP technology see RFC 6238 for formal specifications
or Wikipedia for a less technical description.
1.2.4 Password Policy Changed

If you are using the local username/password store of Alliance Access, you must be aware that
we have changed several parts of the policies that control the minimum requirements for a valid
password.
End-users who have passwords that do not meet these requirements will be asked to select a
new password. This will happen at the first logon following the installation of 7.1.20.
The following changes will be implemented as part of the installation of 7.1.20:
Increase the minimum password length to 8 (12 for new installation) and the maximum
password length to 50.
The security parameter strong parameter has been removed. Alliance Access now always
validate that user passwords contain a combination of alphabetic and numeric characters,
with at least one numeric character.
Reduce the maximum number of bad passwords to 5, with actual minimal value set to 3
Increase the lower boundary of minimum number of retained passwords to 8
Do not allow passwords to never expire
In a future update, we will change the password policies further to enforce industry best
practices. In order to anticipate to that, we recommend that you configure the minimum
password length security parameter already to 12 characters as minimum length.
If you are using LDAP or RADIUS one-time password (OTP), these above changes do not affect
you as password length is controlled by LDAP or RADIUS OTP.
Furthermore, the following Configuration parameters have been changed and impact access
control:
Parameter Description
System Disable The number of calendar days after which an operator is disabled if there
Period was no successful sign-on.
Change: minimum value increased to 1, maximum value reduced to 63
(from 999). Default value is 30.
If your current value was 0 before the upgrade, it will become 30 after the
upgrade.
Signon Timeout The number of seconds that an operator can be inactive. Change:
maximum value reduced to 1800 (from 28800).
Signoff - Timeout The number of seconds after an inactivity time out before an operator
signed on using Alliance Workstation is automatically signed off.
Change: minimum value increased to 60 (from 0).
02 September 2016 7
Password Master The number of days after which the Master password has to be changed.
Period
Change: minimum value increased to 1, maximum value reduced to 120
(from 365).
Password User Period The number of days after which the user password has to be changed.
Change: minimum increased to 1, maximum reduced to 90 (from 120).
For more information, see the section User Management in the Configuration Guide.
1.2.5 CREST over SWIFTNet Security Enhancement

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).
The key used for LLE 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, where the default minimum is 0 (no
encryption).
Prior to Alliance Access 7.1.20, no minimum key length value was configurable for the NSL and
CRPI interfaces. Alliance Access 7.1.20 enables you to configure a minimum key length. SWIFT
advises to put the minimum key length to 128. This value is supported by NSL version 3.2.1 or
higher and CRPI 7.0.1 or higher.
For more information on how to configure such a minimum key length in Alliance Access, please
refer to the Customer Application Integration Guide (Windows, AIX, Linux, Solaris).
1.2.6 Global Payments Innovation Initiative

Endorsed by over 45 of the worlds major transaction banks, the global payments innovation
initiative (gpii) will dramatically improve the customer experience in cross-border payments.
On the basis of gpii business rules agreed upon by the participating banks, the initiative aims to
increase the speed, transparency and predictability of cross-border payments.
Corporates will be able to receive an enhanced payments service directly from their banks, with
the following key features:
same day use of funds
transparency and predictability of fees
end-to-end payments tracking
transfer of rich payment information
More information is available on www.swift.com/gpii.
In the scope of gpii, the different parties involved in a payment transaction need to use an end-
to-end reference across different messages and processing agents, so that they can reconcile
all the messages of the chain in order to know the transaction status.
02 September 2016 8
For this purpose two new fields have been added in the block 3 of the FIN messages:
Field 111 Service type identifier a new field in FIN block 3
Field 121 Unique end-to-end transaction reference also known as UETR a new field in
FIN block 3
Updates in Alliance Access to support the two new fields

The Message Management applications have been enhanced to reflect the addition of the new
fields in block 3:
The search criteria of all the message applications
The list view of all message applications where messages are displayed
The sort functions of all message applications
The search templates of the message search application
The message editors to allow message creation and modification. A generate button is also
available next to the Field 121 in order to generate the unique end-to-end transaction
reference that will respect the format.
Additionally a new configuration parameter gpii fields display has been added allowing to hide or
display fields 111 and 121 in the message editor of all message applications.
For more information, see the Configuration Guide.
The Integration Platform has also been updated to support the new fields in block 3 in the
different areas such as creation, update, search capabilities, and generation of the UETR
reference.
Note The Alliance Workstation has not been updated with the gpii changes.
1.2.7 New XMLv2 Revision

A new XMLv2 revision, 2.0.7, introduces support for:
ServiceLevelAgreement (field 111 in block 3 for gpii)
E2EtransactionReference (field 121 in block 3 for gpii)
FinInformReleaseInfo (field 165 in block 3)
Sumid (only for message partner output)
ServiceURI (to be able to set the URI for messages based on MyStandards deployment
packages)
MessageTypeURI (to be able to set URI for messages based on MyStandards deployment
packages)
The previous XMLv2 revisions continue to be supported.
For more information, see the section XML Version 2 (XMLv2) in the Configuration Guide and
also the section XMLv2 Messages in the Developer Guide.
1.2.8 Changing the Syntax on Multiple LTs Simultaneously

In order to facilitate migration of LTs to a new syntax, a new button named Reassign syntax is
available in the "FIN Logical Terminal" application list view. This new button allows an operator
02 September 2016 9
to select one or multiple LT and assign a new syntax to all the LTs list in one operation. The
operator will be prompted to select the syntax to be applied from a list of available syntax
versions.
For more information, see the section Modify the Syntax Table Assigned to One or More Logical
Terminals in the Configuration Guide.
1.2.9 Locked Message in text_modification
In Alliance Access 7.1.15, the new concept of Locked Templates was introduced, allowing to
create templates where only some fields can be edited by the person who creates a message
from the template.
The behaviour of messages created from a locked template has been changed in 7.1.20. When
such a message arrives in the modification queue it will now be fully editable.
The locked-template functionality was introduced to limit what a user can enter in a message,
and this user is not expected to be able to modify it afterwards. The operator who only creates
messages from locked template should not have the permission to make modifications.
However, another operator who has the credential to modify messages should be able to repair
the message should it arrive in the text modification queue. This is why the change has been
introduced.
For more information, see the section Locked Message Templates in the Message Management
Guide.
1.2.10 Alarms Visibility and Actions

The behaviour when an alarm for info occurs has been improved: the operator will now be
notified in the same way as the alarms for action. This means that there will be a visual
notification in the banner above the screen and not just the alarm counter being updated.
Additionally, the banner has also been enhanced to provide action links next to the alarms,
allowing the operator to directly take action without having to open them each. The links will
allow to act upon the alarm (dismiss, treat, ...).
1.2.11 New Licensing Configuration Application (visualise the

licence)
To facilitate access to the licensing configuration, a new application named "Licensing
Configuration" is made available in the System application group of the Access Configuration
package. All information provided in the application are in read-only.
A specific permission ([Access Control - Run supportinfo]) is required to have access to this new
application. RSO/LSO roles will have automatically access to the application.
For more information, see the section Licensing Configuration in the Configuration Guide.
02 September 2016 10
1.2.12 Additional Validation of Existing RMA when filling the

Message Receiver Data
The Message Management editor already checks the existence of an RMA relation between
sender and correspondent when a message is routed, disposed to a queue (other than text
modification) or when triggering the validation.
To further facilitate message entry, an additional validation is now done whenever the "Receiver"
field is modified (for FIN messages) or the "ResponderDn" field (for MX messages). If at that
time the RMA validation is not successful, the field is immediately highlighted to show an error.
1.2.13 Local Printer Support

Prior 7.1.20, an operator configuring a Message Partner with the connection method set to
"Print" could only define the printer location as "Server".
As from 7.1.20, a new printer location "Local" is made available.
When running a Message Partner set up with this new configuration, the operator is displayed
with a print preview allowing them select a printer local to their system.
The difference of this "Local" configuration is that the printer does not need to be configured
inside of Alliance Access while when the location is set to "Server", the printer needs to be
defined inside of Alliance Access.
1.2.14 RESTful API Available to Provide Browser-based ADK

GUI
When you are using third party ADK components that have a GUI inside Alliance Workstation,
you were until now hindered to move to Alliance Web Platform SE for an easy to deploy
browser-based GUI.
In 7.1.20 we provide the third parties a set of new RESTful APIs that will allow them to build a
browser-based GUI for their custom components. If you are in this case, contact your third party
provider to obtain their plans to provide the browser based GUI. The third party providers have
received early copies of this new feature for development purpose earlier this year.
1.2.15 ADK Integrity Checked at Startup

As of 7.1.20, ADK software integrity is checked when you start the Alliance Access servers. If
the ADK component software fails the integrity check, Alliance Access will not start.
1.2.16 User documentation set extended with Alliance

Security Guidance document
In April 2016 SWIFT made a new Alliance Security Guidance document available.
This document covers recommended security control guidelines which are designed to assist
customers in protecting the deployment, access to, and use of, Alliance products. Broadly, the
document contains information on:
SWIFT security governance for customers, including the definition of security roles and
segregation of duties
Securing local server environments, including the physical and logical access controls that
secure the Alliance servers with servers they communicate with
Securing local client environments, including the physical and logical access controls that
secure end user workstations connections with servers hosting Alliance software
Securing local application environments, including support for 2FA, management of RMA
control, and enhanced confidentiality, integrity and authentication
Local network security controls, including network segregation
Other security recommendations, including detection, backup, resilience and incident
management.
1.2.17 Other Enhancements

See Knowledge Base tip 5021025 for a detailed list of other functional enhancements that are
implemented in 7.1.20.
1.3 Resolved Problems

See Knowledge Base tip 5021026 for a detailed list of all change requests addressed in this
release.
1.4 Software Distribution

This release of Alliance Access is available through the Download Centre on www.swift.com.
The software package contains the following:
Alliance Access 7.1.20 GUI package
Alliance Workstation 7.1.20
Note The GUI packages are provided together in a single access_7_1_20.ear file.
1.5 System Requirements

You must verify whether your current system is still sufficient or whether it needs to be upgraded
or renewed. Check the Hardware requirements page on www.swift.com to find out the system
requirements.
1.5.1 Operating System Requirements
1.5.1.1 Alliance Access

Alliance Access 7.1.20 has been qualified against the English-language version of the following
operating systems:
Windows Server 2008 R2 Enterprise edition and Standard edition
Windows Server 2012 R2 Standard edition
Oracle Solaris 10 Hardware revision 10/09
Oracle Solaris 11.1, SRU 10.6.0
AIX 6.1 - Technology Level 06 with SP2
Note To improve the performance of Integration Platform on AIX 6.1 systems, it is
strongly recommended to upgrade to AIX v6.1 TL06 SP8. This version of the
OS addresses a scalability issue when MALLOC operations are done
simultaneously in a multi-threading environment.
AIX 7.1 - Technology Level 02 with SP3
PowerHA SystemMirror 7.1 has been used for qualifying Alliance Access 7.1.20 with licences
containing 11:DUAL HARDWARE, and requires RSCT 3.1.2.0 or higher.
Red Hat Enterprise Linux 6.4 (64-bit)
For information on changing operating systems, see how to migrate the database to a different
operating system in the Installation Guide for AIX, Linux, Oracle Solaris, or Windows.
For information on moving to a different version of an operating system, see the Installation
Guide for AIX, Linux, Oracle Solaris, or Windows.
Note While SWIFT used the aforementioned operating systems versions, support is also
provided for higher versions as mentioned in Knowledge Base tip 1212959.
More information, see the OS Levels and Patches Baseline, dated 27th March 2015.
1.5.1.2 Alliance Workstation

Alliance Workstation 7.1.20 has been qualified against the English-language version of the
following operating systems:
Windows Vista Enterprise/Business Edition with Service Pack 2
Windows Server 2008 R2 Standard edition with Service Pack 1
Due to updated compilers, Alliance Workstation no longer functions on Windows XP or Windows
Server 2003. Customers still using these operating systems are suggested to upgrade their
desktop systems as quickly as possible, and preferably move to the Alliance Web Platform
Server-Embedded GUIs.
Note SWIFT will stop supporting Alliance Workstation as of the end of March 2017.
1.5.1.3 More information

Please consult the following:
System Configuration Recommendations and Guidelines
OS Levels and Patches Baseline, dated 27 March 2015
Alliance Product Family - Compatibility Matrix
1.5.2 Memory Requirements

The memory requirements for Alliance Access 7.1.20 are available in the Hardware
requirements for release 7.0 page on www.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.1.20.
For more details, please refer to the System Configuration Recommendations and Guidelines.
1.5.3 System Requirements on UNIX and Linux
For UNIX and Linux, Alliance Access 7.1.20 has specific system requirements. For more
information, see the user limit requirements in the Installation Guide for AIX, Linux, or Oracle
Solaris.
1.5.4 SWIFTNet Requirements

Alliance Access 7.1.20 has the following SWIFTNet requirements:
Alliance Access connects to SWIFTNet through Alliance Gateway 7.0 (or higher) using
relaxed mode.
1.5.5 Alliance Requirements

You must verify whether your current system is still sufficient or whether it needs to be upgraded
or renewed. Check the Hardware requirements page on www.swift.com for more information on
system requirements.
Note No changes have been made to these documents for 7.1.20.
1.5.5.1 Alliance Access

Alliance Access 7.1.20 can be installed as either of the following:
a new installation
an upgrade from Alliance Access 7.1.1x (7.1.10, 7.1.11, 7.1.12, 7.1.13, 7.1.14, or 7.1.15)
1.5.5.2 Alliance Workstation

Alliance Workstation 7.1.20 can be installed as any of the following:
a new installation
an upgrade from Alliance Workstation 7.1.1x
You can install Alliance Workstation 7.1.20 in conjunction with an existing 7.0 (or higher) release
of Alliance Workstation.
Note SWIFT will stop supporting Alliance Workstation as of the end of March 2017.
1.5.5.3 GUI package on Alliance Web Platform Server-Embedded

Alliance Access 7.1.20 has been qualified using the Alliance Access 7.1.20 GUI package
deployed on Alliance Web Platform Server-Embedded 7.0.20 through 7.0.65.
Note Alliance Web Platform Server-Embedded 7.0.70 is a pre-requisite for the usage of
time-based one-time passwords on Alliance Access and Alliance Web Platform
Server-Embedded.
In order to get the maximum benefit from the enhancements implemented, SWIFT recommends
using Alliance Web Platform Server-Embedded 7.0.65 or higher. When you use your Alliance
Web Platform Server-Embedded also to connect to your Alliance Gateway, it can only be
upgraded if your Alliance Gateway is at least version 7.0.25.
The package has been qualified using the following operating systems and browsers:
Windows 7 Professional (32-bit or 64-bit) with Firefox ESR 38 or Internet Explorer 11
Windows 8.1 with Firefox ESR 38 or Internet Explorer 11
Note SWIFT recommends that you remove unused packages (such as previous versions
when they are no longer required), in order to reduce memory usage of Alliance
Web Platform Server-Embedded.
The package is not compatible with Alliance Web Platform on IBM WebSphere
Application Server, which was retired at the end of 2015.
SWIFT does not use Internet Explorer 8, 9, or 10 anymore during qualification, as
Microsoft has ended support for these versions. Hence SWIFT also ends support
for its products on these browsers. Compatibility can not be guaranteed.
1.5.6 Alliance Developer Kit and Integration Platform

Alliance Developer Kit and Integration Platform ADK components need to be built for Access
7.1.00 or higher.
IPLA components using IBM MQ must not use TRIPLE_DES_SHA_US as SSL cipher (or other
ciphers not supported anymore by JAVA 1.7.xxx). TLS should be preferred over SSL to be more
future proof)
If any changes were made to IPLA configuration files to enable TLS on a previous version of
Alliance Access, then these changes will need to be reapplied after the update.
1.5.7 Other Requirements
1.5.7.1 Network Time Protocol server

Usage of an NTP (Network Time Protocol) server is recommended when using time-based one-
time passwords. This allows a minimal time drift between the server and the client authenticator
applications.
When using an NTP server, it must be configured in slew mode to ensure that the time stays
monotonic.
1.5.7.2 Disk space

The installation or upgrade of Alliance Access 7.1.20 requires 5 GB of available disk space. For
more information on the required disk space depending on your operational environment, see
the System Configuration Recommendations and Guidelines document.
1.5.7.3 NTFS compression and encryption (Windows only)

Alliance Access cannot be installed in a folder or drive with NTFS compression or encryption
enabled.
1.5.7.4 File system type for high-throughput systems (AIX only)

On the AIX platform, the file system(s) for Alliance Access must be jfs2 (and not jfs with large
file option) on high-throughput systems.
1.5.7.5 Software from Oracle for Hosted Database Option

The installation of Alliance Access 7.1.20 with the hosted database option requires an Oracle
database with one of the following versions:
when using Oracle 10gR2, version 10.2.0.4 or higher
Alliance Access 7.1.20 has not been qualified using Oracle 12 and is not supported.
Note If you are using Oracle10gR2 or 11gR1, the backups of archives generated on
Alliance Access 7.0 with embedded database cannot be restored in the hosted
database.
For specific database prerequisites, see the Installation Guide for AIX, Linux,
Oracle Solaris, or Windows.
1.5.7.6 IBM MQ
If you want to use the IBM MQ Host Adapter integrated in Alliance Access 7.1.20, then one of
the following IBM MQ software versions must be installed:
IBM MQ 7.0.1 (not supported by IBM since September 3, 2015)
IBM MQ 7.0.1.3
IBM MQ 7.5.0.2
Note The MQ versions are not necessarily supported by IBM on all the OS versions that
we qualify against. Only the MQ/OS combinations supported by IBM are supported
by SWIFT. See the OS Levels and Patches Baseline document, dated 27 March
2015, for information in which versions are supported on which platforms.
Even if the IBM MQ software is installed in the default directories, then you must
specify the environment variable to indicate the location of the IBM MQ libraries.
For more details, see the installation directory for IBM MQ in the Configuration
Guide. See also Knowledge Base tip 5020614.
In order to use Alliance Access with IBM MQ 8.0 Server, you need to install an IBM
MQ 7.x client on your Alliance Access system that is compatible with your IBM MQ
8.0 server environment. For compatibility details, see the IBM website. Alliance
Access 7.1.20 is not compatible with IBM MQ 8.0 client. For more information, see
Knowledge Base tip 5020656.
1.5.7.7 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 27 March 2015, for the list
of necessary packages.
1.5.7.8 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.
1.6 Documentation
This lists the documentation and addiitonal resources for Alliance Access.
The following documents have been updated to describe additional functionality (and change
requests) addressed in Alliance Access 7.1.20 :
Administration Guide - AIX
ADK GUI REST API Developer Guide (limited distribution)
Administration Guide - Linux
Administration Guide - Oracle Solaris
Administration Guide - Windows
Configuration Guide - Alliance Web Platform

Daily Operations Guide
Installation Guide - AIX
Installation Guide - Linux
Installation Guide - Oracle Solaris
Installation Guide - Windows
Message Management Guide - Alliance Web Platform
Monitoring Guide - Alliance Web Platform
Relationship Management Application User Guide
Relationship Management User Guide - Alliance Web Platform
Security Guide
Security Guide - Alliance Web Platform
Alliance Security Guidance
System Configuration Recommendations and Guidelines
System Management Guide
The following documents have been republished for Alliance Access 7.1.20 without release-
related changes:
Developer Guide
TARGET2 for Securities Web Services Developer Guide
Web Services Developer Guide
IBM PowerHA SystemMirror Standard Edition Installation and User Guide
This document is licence restricted and can be requested from customer support by
customers who have the 11:DUAL HARDWARE option in their licence sheet.
1.7 Warnings and Known Issues

See Knowledge base tip 5021027 for the latest, detailed list of all warnings and known issues in
Alliance Access 7.1.20.
Significant warnings and known issues
The following table lists the known issue that was identified during the qualification phase and
that has a potential impact on the main message flow, or on specific activities such as daily
operations or configuration.
CR number Impact Main Description

Message Flow
40153829 Yes FinCopy profiles become Inactive after uploading the

Application Service Profile(ASP) file
CR number Impact Main Description

Message Flow
- No When using the Alliance Access 7.1.20 GUI package with

older versions of Alliance Web Platform Server-Embedded,
you might experience cosmetic misbehaviour in some areas.
See the Alliance Web Platform Server-Embedded 7.0.65
Release Letter or the 7.0.70 Release Letter.
- Yes As of 7.1.20, ADK software integrity is checked when you start

the Alliance Access servers. If the ADK component software
fails the integrity check, Alliance Access will not start.
Before upgrading to Alliance Access 7.1.20:
Verify with your ADK vendor that your current version of
your ADK component is compliant with Alliance Access
7.1.20. If not, install the new version before upgrading to
Alliance Access 7.1.20.
Verify the integrity of all your ADK components (using the
saa_system integrity command). If the ADK
software integrity check fails, you may have to revert the
changes made to that executable (restore a copy or
backup making sure that the ownership and permissions
are correct) or de-register, uninstall, install again and
register the impacted ADK component. If you are not using
the faulty ADK component anymore, you have to properly
uninstall it as per instructions provided by the vendor.
- - The maximum length of the message Suffix increased from 11

to 16 characters. The first part is the creation date of the
message in YYMMDD format, 6-digit number. The second part
is an up to 10-digit number (from 1 to 10) generated by the
system. This number is incremental and unique for all
messages. See Knowledge Base tip 5021110 for more
information.
1.8 Obsolete Functionality

The following functionality is suppressed or replaced in this release of Alliance Access:
1.8.1 End of Support for Microsoft Browsers Released Before

Internet Explorer 11
In early August 2014, Microsoft announced that it would end support for Internet Explorer
versions prior to Internet Explorer 11 as of 12 January 2016. Alliance Access updates released
after 30 November 2015 will not be qualified on versions older than Internet Explorer 11.
While Internet Explorer 11 has a set of new tools to better support web pages designed for
earlier versions, this means a significant impact to most of the SWIFT community. Using older
browsers however, will have some side effects on the Alliance Access GUIs.
1.8.2 End of Support for Alliance Workstation

As announced in early March 2015, SWIFT will stop supporting Alliance Workstation as of the
end of March 2017. This means that the Message Standards 2017 update will not be compatible
with Alliance Workstation.
Note The SWIFT Campaign Management team tries to make sure that all impacted
customers are aware and are taking appropriate actions. If you have not informed
them of your plans or have difficulty meeting the deadline, please inform them as
soon as possible by email to Interface.changes@swift.com.
1.9 Other Information
1.9.1 Collection of Information by SWIFT

In line with what is already deployed in Alliance Gateway and SWIFTNet Link, Alliance Access
automatically sends some information to SWIFT for supportability purposes. This includes
information about the general configuration and the use of specific functions and features of
Alliance Access.
The information collected does not include any data that identifies the individuals using, or
defined on, Alliance Access, nor any message data. In future versions, Alliance Access will send
information to SWIFT about traffic volumes that it processes, for licence monitoring purposes.
1.9.2 Release 7.2

SWIFT announced at the end of September 2015 that it is planning a mandatory release 7.2.
Release 7.2 will be released in 2017, and will have a mandatory migration window of 15 months.
For more information see the Alliance 7.2 Final Release Overview.
Release Letter Installation and Upgrade
2 Installation and Upgrade

2.1 Alliance Access
Alliance Access 7.1.20 can be installed directly.
It can also be used to upgrade the current Alliance Access version on the same host.
We recommend that you consult the appropriate version of the Installation Guide (AIX, Linux,
Oracle Solaris, Windows) during the installation or upgrade.
2.1.1 Full Installation of Alliance Access 7.1.20

See the installation section in the relevant installation guide (AIX, Linux, Solaris, Windows).
Important After the installation, you will need to install the Alliance Security Update 2016-08.
2.1.2 Upgrade from Alliance Access 7.1.1x

See the upgrade section in the relevant installation guide (AIX, Linux, Solaris, Windows).
Note You can not use the Install from Prepared Backup File option to upgrade to 7.1.20.
ADK components: before upgrading to Alliance Access 7.1.20, verify the integrity
of all your ADK components (using the saa_system integrity command). If the ADK
software integrity check fails, you may have to revert the changes made to that
executable (restore a copy or backup making sure that the ownership and
permissions are correct) or de-register, uninstall, install again and register the
impacted ADK component.
Important If you are upgrading from a version earlier than 7.1.15, please read the following
information.
Important After the upgrade, you will need to install the Alliance Security Update 2016-08.
Existing Message Templates

When the new Msg temp 4-eyes global security configuration parameter is set to On for the
first time after upgrading to 7.1.20, all templates will require approval before being used. This is
because the migration performed during upgrade to 7.1.20 marks them as 'Not Approved'.
Settings and Preferences

As of 7.1.15, all user Preferences, user-defined Change View and the Column Widths are stored
in the Alliance Access database. This enables the settings to be preserved across sessions,
when connecting through a different Alliance Web Platform Server-Embedded GUI, or when
Alliance Access is restarted.
The current settings are not retained during the upgrade to 7.1.20, and must be redefined
manually after the upgrade.
The number of user preferences has been reduced. For the user preferences which have been
removed, the last used value will be used the next time you use the application or field. In
several other places the last used value is proposed by default to enhance the user experience.
For example, in the 7.1.20 Message Management GUI, the user Preferences does not contain
the Default Sender Logical Terminal and the Default Fin Category. The last selected values are
used instead in Message Creation.
Changes to Permissions
New permissions
Compared to Alliance Access 7.1.1x, the following permissions have been introduced to support
the new features described earlier:
Permission Description
Mesg Creation, Add/ Mod/ Rem Templ, locked Controls whether an operator can create MT/MX
messages from locked templates
Mesg Creation, Create Message, From Locked Controls whether an operator can only manage
Templates only MT/MX message templates that are locked.
SWIFTNet Interface, Corr/RT serv on Hold Controls access to 'Correspondent/Real-Time

Service on Hold'.
Changed permissions
Compared to Alliance Access 7.1.1x, the following permissions have been changed:
Permission Change
- Previously, when a LSO or RSO operator tried to

open a component under the System/Component
tab on Access GUI, the following error message
was displayed: "Your profile does not allow the
operation". This no longer occurs in 7.1.20.
Removed permissions
Permission Description
Message Search count The count permission was linked to the search
permission. The count feature is now available to all
users that have access to the message search
screens (message search permission).
Changes to Parameters
The following parameters have been introduced to support the new features:
Receive LAU Grace period Operators with the Security Definition permission (that is, LSO and
RSO), can define a grace period duration (in days) during which
both the new and the previous LAU keys are valid at reception. The
grace period starts when a new LAU key is assigned to a message
partner.
Possible values: 0 through 90. Default value is 0.
Msg Templ Approval Controls whether messages can only be created from approved
normal templates (set to On) or created from approved or non-
approved templates (set to Off).
Possible values: On or Off. Default value is Off.
Enabled Crypto Protocols Provides a list of protocols accepted by Alliance Access to

communicate with Alliance WebPlatform or WebServices clients.
Valid protocols are TLSv1.0, TLSv1.1 and TLSv1.2.
All the valid protocols are included initially.
Ref data upload auditing When set to On, events are logged when audit records are added,
updated or deleted during BIC upload/ SWIFTRef data upload.
Possible values: On or Off. Default value is Off.
Store Message Content When activated (parameter set to "Yes"), the full content of the
messages are stored in the messages interventions.
A Message as Transmitted, Message Content intervention is
created when sending a message to a Message Partner, to
SWIFT, or to SWIFTNet
A Message as Received, Message Content intervention is
created when receiving a message from a Message Partner,
from SWIFT, or from SWIFTNet
Note This feature has been developed specifically for test
purposes only. Due to the nature of this feature and
the disk I/O it needs, performance will be significantly
reduced when this feature is switched on.
Maximum Message Age If a message instance stays longer in the queue than the value set,
then this triggers an event and puts the queue in an exceptional
state.
Changes to Events
See Knowledge Base tip 5021028 for a detailed list of added, updated and removed events.
2.1.3 Installation on a Different Host

See the section Changing Your Environment in the relevant installation guide (AIX, Linux,
Oracle Solaris, Windows).
2.1.4 Recommendations When Moving to a New Operating

System Level
To upgrade to one of the new operating-system versions used to qualify Alliance Access (AIX
7.1, Oracle Solaris 11, Red Hat Enterprise 6.4, or Windows 2012 R2), see the section
Changing Your Environment in the relevant installation guide (AIX, Linux, Oracle Solaris,
Windows).
2.2 Alliance Web Platform Server-Embedded
2.2.1 Overview
See the Alliance Web Platform Server-Embedded 7.0.65 Installation Guide (AIX, Linux, Oracle
Solaris, Windows) for information about the installation and configuration of the GUI packages.
Note New versions of these guides will be published for Alliance Web Platform Server-
Embedded 7.0.70.
If you have not installed Alliance Access 7.1.15, Alliance Access 7.1.20 introduces a new default
application group, which combines the four existing application groups into one, so all
operations can be handled from the same menu without the need to create custom application
groups.
To locate the packages in the downloaded file, navigate to the GUIPackages directory. The
packages are locate in a single .ear file: access_7_1_20.ear.
Note To preserve user preferences, ensure that you install the 7.1.20 GUI packages
before removing the 7.1 or 7.1.1x package.
2.2.2 Installation procedure

1. Copy the content of the downloaded file to a local path.
2. Deploy release 7.1.20 (access_7_1_20.ear), which is cumulative, by running the
swp_config -packages -install command. The configuration from any previous GUI
packages will be migrated.
3. If you have created any custom application groups, update them with the new version of the
application(s) or create new specific custom groups with the new version of the
application(s).
4. To minimise resource consumption, if the previous GUI packages have already been
installed and are no longer needed, SWIFT recommends that you remove them by using the
swp_config -packages -uninstall command.
2.3 Alliance Workstation
2.3.1 Installation procedure

This procedure explains how to install a new Alliance Workstation, optionally in addition to an
existing previous version, without disturbing the previous version:
1. Copy the downloaded software to a folder accessible from the Alliance Workstation system.
2. Log in with the Alliance Workstation owner account.
3. Unzip the downloaded file and navigate to the win32\saa-install.exe file.
4. Double-click saa-install.exe to launch the installation.
If you are installing next to an existing Alliance Workstation, ensure that you specify a different
installation folder.
2.4 Additional Tasks
2.4.1 Update Gateway Connections for Automatic LAU Key

Renewal
In line with the recommendations mentioned in the Security Guidance document, you should
use LAU between your Alliance Access and Alliance Gateway. If this is not yet the case, we
strongly recommend that you implement this to protect both yourself and the whole community.
There are no pre-requirements to define LAU between your Alliance Access and Alliance
Gateway.
Once you have upgraded to Alliance Gateway to 7.0.25 or higher, you can change the
configuration of the Gateway Connections and switch on LAU Key Automatic Renewal. Using
LAU on the connection to your Alliance Gateway improves security, while turning on automatic
key renewal reduces maintenance effort as well.
Note For more information, see the Gateway Connection Details window in the
Configuration Guide.
2.4.2 Starting the Alliance Access Servers

If automatic start-up mode is configured, it is recommended that the Alliance Access servers be
started manually for the first time after the upgrade to 7.1.20.
2.4.3 Fallback Activities

Alliance Access 7.1.20 cannot be removed, and old database backups cannot be restored.
Release Letter Support
3 Support
Support for SWIFT customers
By default, SWIFT 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
Release Letter Routing Keyword Extraction and Verifiable Fields
A Routing Keyword Extraction and Verifiable

Fields
The following table lists the Standards MT November 2016 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, 32B,F33B,F F32A
F71G 71F,F71G
F32A,F32B, F19,F32A,F
102.
Seq A.F20 Seq C.F32A Seq C.F32A Seq C.F32A F33B,F71F, 32B,F33B,F F32A
STP
F71G 71F,F71G
F32A,F33B, F32A,F33B,
103 F20 F32A F32A F32A F32A
F71F,F71G F71F,F71G
103.
F32A,F33B, F32A,F33B,
REM F20 F32A F32A F32A F32A
F71F,F71G F71F,F71G
IT
103. F32A,F33B, F32A,F33B,

F20 F32A F32A F32A F32A
STP F71F,F71G F71F,F71G
F19,F32B,F
F32B,F33B,
104 Seq A.F20 Seq C.F32B Seq C.F19 F30 33B,F71F,F F30
F71F,F71G
71G
105 F20

MT
F19,F32B,F
F32B,F33B,
107 Seq A.F20 Seq B.F32B Seq C.F19 F30 33B,F71F,F F30
F71F,F71G
71G
110 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
207 Seq A.F20 F32B F32B F30 F32B F32B F30
210 F20 F32B F32B F30 F32B F32B F30
F32A,F71F, F19,F32A,F
F71G,F71H, 71F,F71G,F
256 Seq A.F20 Seq C.F32A Seq C.F32A Seq C.F32A F32A,F30
F71J,F71K, 71H,F71J,F
F71L 71K,F71L

MT
291 F20 F32B F32B F32B F32B
292 F20
295 F20
296 F20
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
F32B,F33B, F32B,F33B,
303 Seq A.F20 Seq B.F32B Seq B.F32B Seq B.F30V Seq B.F30V
F34B,F39P F34B,F39P
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
Seq Seq Seq

Seq Seq Seq Seq
307 A.F20C:SE B.F98A:VAL B.F98A:VAL
B3.F19B B3.F19B B3.F19B B3.F19B
ME U U
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
Seq Seq F32B,F32H, F32B,F32H,

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

MT
Seq
F32B,F71F, F32B,F71F,
340 Seq A.F20 Seq B.F32B Seq B.F32B Seq B.F30F B.F30F,Seq
F32H F32H
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
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
391 F20 F32B F32B F32B F32B
392 F20
395 F20
396 F20
398 F20

MT
399 F20
F32A,F32B, F32A,F32B, F32A,F32B, F32A,F32B,

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

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

420 F20 F32A F32A
F32K F32K F32K F32K

422 F20 F32A F32A
F32K F32K F32K F32K
Seq Seq
A.F32A, A.F32A,
Seq Seq
F32A,F32K, F32A,F32K,
430 Seq A.F20 A.F32K, A.F32K, Seq A.F32A F32A,F33A
F33A,F33K F33A,F33K
Seq Seq
A.F33A, A.F33A,
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
491 F20 F32B F32B F32B F32B
492 F20
495 F20
496 F20
498 F20

MT
499 F20
Seq
500 Seq A.F20C B.F98A,
Seq B.F98C
Seq
Seq B.F98C
Seq Seq
B.F19A:OR B.F19A:OR
502 Seq A.F20C DR, Seq DR, Seq
B.F19A:CA B.F19A:CA
NC(1) NC(1)
Seq Seq Seq

503 A.F20C:SE B.F19B:CO B.F19B:CO
ME VA VA
Seq Seq Seq

504 A.F20C:SE B.F19B:CO B.F19B:CO
ME VA VA
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:RR
510 Seq A.F20C EG, Seq
B.F98C:RR
EG

MT
Seq
Seq Seq C.F98A:TR
C.F19A, C.F19A, AD, Seq
513 Seq A.F20C Seq Seq C.F98C:TR
D3.F19A:SE D3.F19A:SE AD, Seq
TT TT C.F98E:TR
AD
Seq
Seq Seq B.F98A:TRA
B.F19A:SET B.F19A:SET D, Seq
514 Seq A.F20C T, Seq T, Seq B.F98C:TR
C3.F19A:SE C3.F19A:SE AD, Seq
TT TT B.F98E:TRA
D
Seq Seq Seq

C.F19A, C.F19A, C.F98A:SET
515 Seq A.F20C Seq Seq T, Seq
D3.F19A:SE D3.F19A:SE C.F98C:SE
TT TT TT
Seq Seq
516 Seq A.F20 B.F32A, B.F32A, Seq B.F32A F32A,F32B F32A,F32B F32A
Seq B.F32B Seq B.F32B
517 Seq A.F20C
Seq Seq Seq

B.F19A, B.F19A, B.F98A:SET
518 Seq A.F20C Seq Seq T, Seq
C3.F19A:SE C3.F19A:SE B.F98C:SET
TT TT T
Seq
Seq B.F98C
Seq
Seq B.F98C
526 Seq A.F20
Seq
Seq Seq Seq A.F98A:EX
527 A.F20C:SE B.F19A:TRA B.F19A:TRA RQ, Seq
ME A A A.F98C:EX
RQ

MT
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
B.F98C:SET
T
Seq
T
Seq
B.F98A:ESE
B.F98C:ES
ET
Seq
Seq Seq B.F98A:ESE
545 Seq A.F20C E3.F19A:ES E3.F19A:ES T, Seq
TT TT B.F98C:ES
ET

MT
Seq
B.F98A:ESE
B.F98C:ES
ET
Seq
Seq Seq B.F98A:ESE
547 Seq A.F20C E3.F19A:ES E3.F19A:ES T, Seq
TT TT B.F98C:ES
ET
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:EX
558 A.F20C:SE B.F19A:TRA B.F19A:TRA RQ, Seq
ME A A A.F98C:EX
RQ
F32G,F32M F19,F32G,F
559 F20 F34A F19 F34A
,F34A 32M,F34A
Seq
564 A.F20C:SE
ME
Seq Seq
565 A.F20C:SE D.F98A,
ME Seq D.F98C
Seq
Seq Seq Seq D1.F98A:P
566 A.F20C:SE D2.F19B:PS D2.F19B:PS OST, Seq
ME TA TA D1.F98C:P
OST
Seq
567 A.F20C:SE
ME

MT
Seq
568 A.F20C:SE
ME
569 Seq A.F20C
574.I Seq Seq Seq

RSL A.F20C:SE B2.F19A:G B2.F19A:G
ST ME RSS RSS
574. Seq
W8B A.F20C:SE
ENO ME
575 Seq A.F20C
576 Seq A.F20C
577 F20
Seq
T
579 F20
581 F20 F34B F34B
586 Seq A.F20C
591 F20 F32B F32B F32B F32B
592 F20
595 F20
596 F20
598 F20
599 F20
F33G,F34P,
600 Seq A.F20 F33G F33G Seq B.F34P F34P,F34R F34P,F34R
F34R

MT
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
609 F20 F68B,F68C F68B,F68C F68B,F68C
F32B,F32H, F32B,F32H,
F34E, F34E,
620 F20 F32B F32B F30V F30V
F33B,F33E, F33B,F33E,
F71F F71F
F32A,F32B, F32A,F32B,
F32P,F33B, F32P,F33B, F32A,F32P,
643 Seq A.F20 Seq A.F32A Seq A.F32A Seq A.F32A
F33P,F33R, F33P,F33R, F33P,F33R,
F34P,F34R
F34P,F34R F34P,F34R
F32A,F33B, F32A,F33B, F32A,F34P,

F34P,F34R F34P,F34R F34R
F32A,F32N, F32A,F32N, F32A,F32N,

F33B,F33N, F33B,F33N, F33N,F34N,
F34N,F34P, F34N,F34P, F34P,F34R,
F34R F34R F31F
670 Seq A.F20C
671 Seq A.F20C
691 F20 F32B F32B F32B F32B
692 F20
695 F20

MT
696 F20
698 F20
699 F20
700 F20 F32B F32B F32B F32B
701 F20
705 F20 F32B F32B F32B F32B
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

MT
760 F20
767 F20
768 F20 F32B,F32D F32B,F32D F32D
F32B,F32D, F32B,F32D,
769 F20 F32D
F33B,F34B F33B,F34B
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
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

MT
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
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, F34F,F90C,
942 F20 F34F F34F
F90D F90D
F60F,F60M, F60F,F60M, F60F,F60M,

F64 F64 F64
F60F,F60M, F60F,F60M, F60F,F60M,

F64 F64 F64
971 F20 F62F F62F F62F F62F F62F F62F
F60F,F60M, F60F,F60M, F60F,F60M,

F64 F64 F64
973 F20
985 F20
986 F20
991 F20 F32B F32B F32B F32B
992 F20
995 F20
996 F20
998 F20

MT
999 F20
(1) The value with the CANC qualifier will be extracted only if the function of the message (F23G) is equal to CANC.
Release Letter Switch-over Planning for Standards MT
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 2016. 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:
If used, install the relevant Web Platform Server-Embedded GUI packages and deployment
packages.
Note Customers must install the Standards Release 2016 Message Management
Deployment Package at the latest on 20th November 2016.
If used, update existing Alliance Workstations to release 7.1.20 or install it next to an existing
previous version of Alliance Workstation.
Update your Alliance Access server to release 7.1.20.
If relevant, inform the users that they must now use the Alliance Workstation 7.1.20.
If relevant, inform the Web Platform GUI packages users that they must use the new URL.
Assign the Standards MT November 2016 to your Test and Training logical terminals.
Upgrade back-office systems where required.
B.3 Actions to be Taken Before 19th November 2016

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 16th, 17th, or 18th

November 2016 (Last Business Day of the Week)
Send your business messages as soon as possible.
At the end of your business week, make sure that all your pending messages are
transmitted.
Release Letter Switch-over Planning for Standards MT
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 19th November 2016 at 16:00 GMT, SWIFT will disconnect all users and
activate the new Standards MT November 2016.
B.5 Actions to be Taken Before Your First Log In on

20th or 21st November 2016
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 2016 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.
Release Letter Standards Switch-over Planning for InterAct Services
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.
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.
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 44.
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.
Release Letter Legal Notices
Legal Notices
Copyright
SWIFT 2016. 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.

Aa 7 1 20 RL PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aa 7 1 20 RL PDF

Uploaded by

Copyright:

Available Formats

Alliance Access 7.1.

This document contains release information for Alliance Access 7.1.20.

2 Installation and Upgrade............................................................................................................. 21

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

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

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

C.3 Migrate to the New Standards..................................................................................................... 45

Operating system requirements Same as for Alliance Access 7.1.1x

Customer installation path For Alliance Access:

Customer upgrade path For Alliance Access:

Product dependencies Same as for Alliance Access 7.1.1x

1.2 Enhancements and Features

ADK integrity now checked when Alliance Access started

1.2.2 Updates for Standards MT November 2016

1.2.3 Support for Embedded Two-Factor Authentication

1.2.4 Password Policy Changed

Change: minimum increased to 1, maximum reduced to 90 (from 120).

1.2.5 CREST over SWIFTNet Security Enhancement

1.2.6 Global Payments Innovation Initiative

Updates in Alliance Access to support the two new fields

1.2.7 New XMLv2 Revision

1.2.8 Changing the Syntax on Multiple LTs Simultaneously

1.2.9 Locked Message in text_modification

1.2.10 Alarms Visibility and Actions

1.2.11 New Licensing Configuration Application (visualise the

1.2.12 Additional Validation of Existing RMA when filling the

1.2.13 Local Printer Support

1.2.14 RESTful API Available to Provide Browser-based ADK

1.2.15 ADK Integrity Checked at Startup

1.2.16 User documentation set extended with Alliance

1.2.17 Other Enhancements

1.3 Resolved Problems

1.4 Software Distribution

1.5 System Requirements

1.5.1 Operating System Requirements

1.5.1.1 Alliance Access

1.5.1.2 Alliance Workstation

1.5.1.3 More information

1.5.2 Memory Requirements

1.5.3 System Requirements on UNIX and Linux

1.5.4 SWIFTNet Requirements

1.5.5 Alliance Requirements

1.5.5.1 Alliance Access

1.5.5.2 Alliance Workstation

1.5.5.3 GUI package on Alliance Web Platform Server-Embedded

1.5.6 Alliance Developer Kit and Integration Platform

1.5.7 Other Requirements

1.5.7.1 Network Time Protocol server

1.5.7.2 Disk space

1.5.7.3 NTFS compression and encryption (Windows only)

1.5.7.4 File system type for high-throughput systems (AIX only)

1.5.7.5 Software from Oracle for Hosted Database Option

1.5.7.7 LDAP packages

1.5.7.8 Alliance Access and network drives

Configuration Guide - Alliance Web Platform

1.7 Warnings and Known Issues

Significant warnings and known issues

CR number Impact Main Description

40153829 Yes FinCopy profiles become Inactive after uploading the

CR number Impact Main Description

- No When using the Alliance Access 7.1.20 GUI package with

- Yes As of 7.1.20, ADK software integrity is checked when you start

- - The maximum length of the message Suffix increased from 11