5022378 - SR2018 impact on Alliance products

Frequently Asked Questions (FAQ)

Introduction
This tip provides answers to frequently asked questions (FAQ) related to the impact of the Standard Release
2018 on Alliance Access/Entry, Alliance Messaging Hub and Alliance Lite2.

Standards MT Release 2018 (https://www.swift.com/standards/standards-resources?category=7021) introduces

an important mandatory change to the core payment messages. A Unique End-to-end Transaction Reference
(UETR) in field 121 of block 3 will be mandatory for the message types MT 103, MT 103 REMIT, MT 103 STP, MT
202, MT 202 COV, MT 205 and MT 205 COV. To maintain the SWIFT certified FIN Interface status, FIN interfaces
must provide features to automatically add a UETR when it is missing from these message types. This document
describes how Alliance Access/Entry, Alliance Messaging Hub and Alliance Lite2 implement UETR automatic
addition.

Disclaimer
This tip describes functional behaviour planned for a future 2018 delivery of Alliance Access/Entry, Alliance
Messaging Hub and Alliance Lite2. As such it describes intended behaviour, without any guarantee that the final
software delivery will deliver exactly what is described below.

Glossary
Field 111 Service type identifier – a new field in block 3 of FIN messages. Previously known as the
SLA ID.

Field 121 Unique end-to-end transaction reference (UETR) - a new field in block 3 of FIN
messages

Service type identifier Field 111 in Block 3 identifying which SWIFT gpi service the sender is subscribed to.

SR2018 Standards MT Release 2018.

SWIFT gpi The project that aims to improve customer experience in cross-border payments by
increasing their speed, transparency, and traceability. To achieve this, SWIFT gpi
customers agree to respect service-specific business rules and technical requirements
captured in rulebooks. The rules for the gCCT (gpi Customer Credit Transfer) service
are described in the SWIFT gpi Customer Credit Transfer
(https://www2.swift.com/uhbonline/books/public/en_uk/udic/trm_67611976.htm)
rulebook which covers Customer Credit Transfers, Cover (gCOV) and Stop & Recall
(gSRP) services. A rulebook will be developed for each additional service. The SWIFT
gpi product suite comprises three components, the Tracker for SWIFT gpi
(https://www2.swift.com/uhbonline/books/public/en_uk/udic/trm_67610856.htm), the
Observer Insights for SWIFT gpi
(https://www2.swift.com/uhbonline/books/public/en_uk/udic/trm_67610550.htm), and
 the Directory for SWIFT gpi
(https://www2.swift.com/uhbonline/books/public/en_uk/udic/trm_67602495.htm).

UETR Unique End-to-end Transaction Reference - a unique reference on FIN payment

messages using the FIN block 3 field 121.

Table of Contents

Frequently asked questions

Alliance Access/Entry question
Alliance Messaging Hub questions
Alliance Lite2 questions
Appendix A: Alliance Access/Entry
Sample messages

Frequently asked questions

1. Where can I find more information on the 2018 standards changes?
Standards MT Release 2018 information can be found on swift.com
(https://www.swift.com/standards/standards-resources?category=7021). The main source is the
Standards Release Guide
(https://www2.swift.com/uhbonline/books/public/en_uk/srg_20171222/index.htm). The highlights can be
found here (https://www.swift.com/news-events/webinars/past-webinars/standards-mt-release-
2018_important-mandatory-changes-coming-up-in-core-swift-payment-messages). A Frequently Asked
Questions (https://www.swift.com/file/48466/download?token=pu4MdNHv) list on the standards definition
as well as recorded presentations (https://www.swift.com/file/48486/download?token=L-NFa8Ig) will be
provided at the same location.
 Three new self-training modules
(https://swiftsmart.swift.com/Saba/Web_spf/EU1PRD0018/common/categorydetail/categ00000000000302
have been made available on SWIFTSmart to provide the overview of the SR2018 changes in a
comprehensive way.

2. What are the benefits introduced by SR2018?

The benefits to the community of Standards MT Release 2018 are explained in both the self-training
SWIFTSmart modules and in the Standards Frequently Asked Questions which can be found here
(https://www.swift.com/standards/standards-releases/release-highlights?tl=en#topic-tabs-menu).

3. Which messages are impacted by SR2018 and SWIFT gpi?

All SWIFT users (irrespective whether they are a member of SWIFT gpi or not) are impacted when
sending MTs 103, 103 STP, 103 REMIT, 202, 202 COV, 205 and 205 COV. These messages must always
contain a UETR (field 121) as part of SR 2018.

Field 111 Service type identifier is used together with field 121 within SWIFT gpi (Global Payments
Innovation). SWIFT users which are not a member of the SWIFT gpi service are not allowed to generate
or forward field 111 in messages sent.

From a receiving perspective, to cover (potential) expansion of the gpi service (not necessarily linked to a
Standards MT Release) any SWIFT user is requested in SR 2018 to implement the ability to receive the
fields 111 and 121 in header block 3 for all category 1 and all category 2 MTs (for example, a SWIFT gpi
bank can send an MT 192 with UETR to a non-gpi bank).

4. When will SR2018 become active?

The cut-over date for live traffic is November 18, 2018. Test and Training will be available as of July 22,
2018.

5. How do I test for SR 2018 readiness?

Each institution needs to apply sufficient regression tests to prepare for a Standards Release change.

In addition, the tank file contains messages that you can use to tune to your environment.

For institutions generating cover payments, it is important to understand the difference in behaviour
depending on whether MT 202 COV is sent before or after the corresponding MT 103 when you chose to
let the interface adding the UETR.

6. Can the SWIFT interfaces receive messages with a UETR?

Yes, all FIN interfaces provided by SWIFT (Alliance Access/Entry, Alliance Messaging Hub and Alliance
Lite2) will accept any category 1 or category 2 message that has a UETR and/or Service Type Identifier
in the message header.

7. Will something change to the MT 096 or MT 097?

In SR2016 (when SWIFT gpi was introduced) SWIFT did not copy fields 111 (Service Type Identifier) and
121 (UETR) into the MT 096 (i.e. this had no impact on FINCopy Central Institutions).

In SR2017, if the field 111 and 121 were present in the MT 103 they were copied in the block 4 (body) of
the MT 096 by SWIFT.
 This means the FIN copy server is potentially already receiving MT 096 with 111 and 121.
Alliance Access and AMH did not perform any particular change for the MT 097, and processed what it
got from the back-office.

For SR2018 there are no changes in this area from a definition point of view. Depending on the FINCopy
service definition, it will be possible that the MT 103, MT 202 and MT 205 only contains the field 121
(UETR), so the MT 096 can only have the field 121 in block 4.

Back to Table of Contents

Alliance Access/Entry questions

1. When and how will SR2018 be delivered for Alliance Access/Entry?
For Alliance Access/Entry the following software updates will be provided to implement SR2018:

Update Planned availability Content

7.2.50 mid July 2018 · SR2018 including UETR related changes
Mandatory · All fixes and security updates since 7.2.00
· Limited number of fixes
7.3.00 end August 2018 · SR2018 including UETR related changes
Optional · All fixes and security updates since 7.2.00
· Limited new features
· Fixes

While Alliance Access/Entry 7.3 was announced already in 2017 to implement SR2018, SWIFT will also
provide update 7.2.50 on top of release 7.2 in line with the SWIFTNet and Alliance release policy
(https://www2.swift.com/uhbonline/books/protected/en_uk/s_snrp/s_snrp.pdf).

IMPORTANT: As Alliance Access/Entry 7.1 will reach end of support end November 2018, no SR2018
update will be made available for Alliance Access/Entry 7.1. Migration from 7.1.xx to release 7.2.00 is
required prior to the upgrade to 7.2.50.

2. How much effort will it take to implement the SR2018 update?

Both Access/Entry 7.2.50 and Access/Entry 7.3.00 are comparable in effort with 7.1.20 and 7.1.40. They
are mainly the Standards update with some fixes (and for 7.3.00 enhancements). Depending on whether
you implemented all security updates since 7.2.00, the installation time might take a bit longer due to the
update of the embedded third-party products.

Assuming you already migrated to release 7.2 you will require to perform the following steps:

· Upgrade to 7.2.50. or 7.3 similar to standards updates in previous years

· Install the Message Syntax table 2018

· Assign the new Message Syntax table to the Logical Terminals

· Install FIN SR 2018 for Message Management and Online Help

 · As the impact on payment flows is important, make sure that you test SR2018 flows in Test&Training
mode before the standards cut-over

Knowledge base tip 5020348 (https://www2.swift.com/support/knowledgebase/tip/5020348) explains in

general how to configure Alliance Access for the new FIN Message Standards

3. What will happen if I send messages without UETR after the cut-over and Alliance Access/Entry

has not been updated?

If you do not upgrade to the mandatory 7.2.50 or optional 7.3.00 or don’t assign your LTs to SR2018,
Messages for which it is mandatory to add a UETR and which do not have a UETR, will be NAK’ed by
FIN with NAK code U13 and arrive in the Alliance Access/Entry modification queue.

4. When will Alliance Access/Entry be able to automatically add the UETR?

When the SR2018 update (7.2.50 or 7.3.00) is installed on 7.2, for BICs assigned to SR2018, Alliance
Access/Entry will automatically add the UETR to all MT 103, MT 103.REMIT, MT 103 STP, MT 202, MT
202 COV, MT 205 and MT 205 COV which do not have a UETR at the moment the message is added to
the database.

Only assigning the LT to SR2018 at the cut-off date (22 July for Test&Training, 18 November in live) to
avoid unwanted NAK’ed messages.

5. Can I rely on Alliance Access/Entry to always add the appropriate UETR?

No, as per FIN interface certification requirements
(https://www2.swift.com/uhbonline/books/public/en_uk/s_cert_intf_imi_f121_e_e_trn_ref/index.htm), the
interfaces are expected to add the appropriate UETR for the majority of use-cases. Adding the UETR is
an activity that functionally belongs with the business application. Alliance Access/Entry provides a stop-
gap solution that can be used until the back-office systems are capable of adding the UETR at the
source.

SWIFT FIN Interfaces will not offer functionality to pass on the UETR unchanged from received
(incoming) message into outgoing message. Therefore intermediary institutions must not rely on the
FIN interface and implement this change in the back-office.

6. I’m becoming a SWIFT gpi bank. Can I rely on Alliance Access/Entry for adding UETR and Service

Type Identifier?
Alliance Access/Entry can help to fast track SWIFT gpi roll-out, but you cannot rely on Alliance
Access/Entry for all SWIFT gpi needs. In the end SWIFT gpi business logic must be built in your
payments system.

Alliance Access/Entry SR2018 implementation will have a configuration parameter to add for a specific
BIC the Service Type Identifier 001 in field 111 for every MT 103 and related MT 202 COV. This will help
banks in the role of Instructing Agent to become a SWIFT gpi member very fast without the need to
change the back office to add UETR and Service Type Identifier immediately. Banks in this case should
however enhance their back-office to create UETR and Service Type Identifier at their earliest
convenience to take the full benefits from the SWIFT gpi service.

Banks joining SWIFT gpi in another role (i.e. Intermediary Agent) will however have to implement
additional changes in the back office as of the start. Typically, after receiving an MT 103, MT 202 COV,
MT 205 COV where they act as intermediary bank, they will have to use the same UETR in the forwarded
 MT 103 and (if applicable) MT 202 COV and MT 205 COV. Alliance Access/Entry does not provide such
features.

Adding the field 111 configuration option must only be used by gpi member banks and BICs that are
configured in the gpi Closed User Group. Use of this option by non-gpi member banks will result in the
messages being NAKed because of presence of field 111.

7. How will Alliance Access/Entry add UETR on manually created messages?

Alliance Access/Entry allows since version 7.1.20 the addition of Service Type Identifier (field 111) and/or
UETR (field 121) through manual message creation. A button in the GUI is available for every message
type to create a UETR based on RFC4122 variant 4. Before release 7.2 Access/Entry had to be
configured by setting the “gpii fields display” configuration parameter to have the button visible in the GUI.
As of release 7.2 the button is always there.

When the SR2018 update is installed on 7.2, for BICs assigned to SR2018, Alliance Access/Entry will
automatically add a UETR to all MT 103, MT 103 REMIT, MT 103 STP, MT 202, MT 202 COV, MT 205
and MT 205 COV which do not have a UETR at the moment the message is added to the database.

8. How will Alliance Access/Entry add UETR on messages from the back-office?
Alliance Access/Entry allows since version 7.1.20 the addition of Service Type Identifier (field 111) and/or
UETR (field 121) through any channel that can add messages (including Message Partners, ADK
modules, IPLA modules and REST APIs).

When the SR2018 update is installed on 7.2, for BICs assigned to SR2018, Alliance Access/Entry will
automatically add a UETR to all MT 103, MT 103.REMIT, MT 103 STP, MT 202, MT 202 COV, MT 205
and MT 205 COV which do not have a UETR at the moment the message is added to the database. For
the MT 202 COV this is dependent on finding the related MT 103. (See question 10)

9. When in the message flow will Alliance Access/Entry add the UETR?
Alliance Access/Entry will add the UETR on messages for which it is mandatory at the moment the
message is created in the Alliance Access/Entry database, independent of the method used to create the
message. (i.e. manual entry, message partners of all types as well as ADK and IPLA components)
Alliance Access/Entry will make no distinction between FIN Input messages and FIN output messages
when it comes to adding a UETR.

10. Which UETR will Alliance Access/Entry add?

When the SR2018 update is installed on 7.2, and when Alliance Access/Entry needs to add a UETR
(because it is mandatory for the message type and was not present in the message received from the
back-office application), it will:

· Add a random RFC4122 variant 4 for the MT 103, MT 103 REMIT, MT 103 STP, MT 202, MT
205 and MT 205 COV
· For the MT 202 COV, Alliance Access/Entry will:
o look in the live database (excluding archives) if it can find an MT 103, MT 103 REMIT, MT
103 STP with a sender BIC and TRN (field 20) matching the sender BIC and related TRN
(field 21) of the MT 202 COV
§ If exactly one is found the MT 202 COV will get the same UETR as the MT 103
§ If none or multiple are found, the MT 202 COV will be routed to the modification
queue for manual processing
 Note: If the MT 103 was received on a different instance of Alliance Access than the one from which the
MT 202 COV is sent, or if the MT 202 COV related reference doesn’t match the referenc of the MT 103,
Alliance Access will not be able to find that MT 103, and move the MT 202 COV to the modification
queue for manual handling.

Note: Through system wide configuration (BSS – Message – MT 103 look-up), it will be possible to
disable the UETR look-up feature for MT 202 COV and use random UETR instead. This to avoid
excessive number of MT 202 COV to go to the modification queue In certain cases. Such scenario
however will result in the institution not implementing the Standards Usage guidelines as a new UETR
will always be created for the MT 202 COV whereas the Standards require copying the same UETR in
the MT 202 COV as in the underlying MT 103. Although the messages will not be rejected by the
network, this will break the end-to-end tracking of the messages within the payment chain which SWIFT
is currently building on all payment transactions.

11. What will happen if my back-office sends the MT 202 COV first?
In case the back office sends the MT 202 COV without UETR before the MT 103 to your Alliance
Access/Entry, the MT 202 COV will be routed to the modification queue for manual processing. It will be
up to the person who handles the MT 202 COV to wait for the related MT 103 to find the UETR, find the
UETR from another source or add a random UETR.

At the moment that the related MT 103 without UETR is sent from the back-office to Alliance
Access/Entry, no lookup will be done for a related MT 202 COV and a random UETR will be added to the
MT 103.

If this is your normal business scenario it is highly recommended to make sure that the back-office adds
the same UETR to both MT 103 and MT 202 COV belonging to the same transaction in order to avoid
excessive manual repair. Alternatively it will be possible to disable the MT 202 COV UETR look-up
feature and use random UETR instead.

12. Will Alliance Access/Entry validate a UETR added by my back office

No, when a UETR is present in a message from the back office Alliance Access/Entry will not perform
any actions on the UETR.

13. Will Alliance Access/Entry add the same UETR to an outgoing MT 103 if I’m an Intermediary

institution?
Intermediary institutions are expected to pass on, unchanged, a received UETR in the MT 103, MT 103
REMIT, MT 103 STP, MT 202, MT 205, MT 202 COV and MT 205 COV in the next MT sent in the
transaction chain. When such an MT 103, MT 103 REMIT, MT 103 STP, MT 202, MT 205, MT 202 COV
or MT 205 COV is sent, Alliance Access/Entry will add a random UETR if no UETR was provided. There
is no UETR look-up feature like the one we provide for the MT 202 COV. Such scenario however will
result in the user not implementing the Standards Usage guidelines as a new UETR will always be
created whereas the Standards require to pass unchanged the same UETR from the incoming message
to the next message in the transaction chain when acting as intermediary institution. Although the
messages will not be rejected by the network, this will break the end-to-end tracking of the messages
within the payment chain which SWIFT is currently building on all payment transactions.

14. How does Alliance Access/Entry send the UETR to the back-office?
 Already today, message ACK sent to Back Office always contains the MT-Blocks 1,2,3,5 of the original
message even if the Message Partner configuration parameter Transfer Original Message with
Notification is set to Never. Therefor the UETR and Service Type Identifier are part of the block 3.

· When using simple batch files (like RJE) the header of the original message would be appended
to the ACK and it would carry the UETR and Service type identifier
· When using the XMLv2 format (revision 7 introduced with 7.1.15 or later), the information would
be provided via
<xs:element name="ServiceLevelAgreement" type="ServiceLevelAgreement" minOccurs="0" />

<xs:element name="E2ETransactionReference" type="E2ETransactionReference"

minOccurs="0" />

As this is the case already today; this can be tested with the current software..

For examples, see Appendix A.

15. What if my back-office cannot handle the UETR?

As from Alliance Access/Entry 7.2.50 and 7.3.00, Message Partners will have a checkbox "Transfer
UETR" for the following Data Format:

· DOS/PCC
· MERVA/2
· RJE
· MQ MT
The checkbox will be checked by default and propagate the UETR field to the back-office. If the checkbox
is not checked, then Alliance Access/Entry will remove the UETR (field 121) field from the block 3 of FIN
messages sent to the back-office. The Service Type Identifier (field 111) will not be removed with this
option.

For the XMLv2, the checkbox is not available and the UETR is always sent to the back-office. Back-office
systems parsing XMLv2 typically ignore XML tags that they don’t know by default.

16. Can I search on UETR in Alliance Access/Entry

Alliance Access/Entry 7.1.40 already allows to search for messages with a specific Service Type Identifier
(SLA ID) or UETR, as part of the search criteria in the section ID and Content, when the message format
FIN is selected.

Back to Table of Contents

Alliance Messaging Hub questions

1. Which AMH release will support SR2018 and the mandatory UETR addition?
In order to support the Standards MT Release 2018, mandatory AMH updates will be released (AMH
3.4.20, 3.5.20, 3.6.20 and 3.7.20). These updates are planned for March 30, 2018 and will contain the
needed software changes to meet the SWIFT gpi requirements that will go live in November 2018. Your
AMH must therefore be updated before November 2018.
 On top of these updates, the SWIFT Standards MT Release 2018 standards deployment package
(Netpack) must also be installed in order to activate the addition logic (as this Netpack contains the
definition of the FIN message types for which the UETR becomes mandatory).

AMH 3.3 (AMH 3.3.x) is out of support in August 2018, i.e. before the November 2018 SR 2018 cut-over.
There will be no AMH update 3.3.20, and no Netpack on AMH 3.3 in support of the Standards MT 2018.
This means that AMH 3.3 will not support SR 2018, and will not be able to send MT messages with a
UETR.

2. What will happen if I send messages without UETR after the cut-over via AMH to SWIFTNet and

AMH has not been updated?

UETR will not be automatically added, so the messages, for which it is mandatory to have a UETR, will
be NAK’ed by FIN with NAK code U13 and arrive in the AMH exception queue where they will need to be
repaired before they can be sent to the network successfully.

3. What logic does AMH use when automatically adding the UETR (field 121)?
AMH 3.x.20 foresees a mechanism that checks to see if the UETR is present for messages where the
field is mandatory and automatically adds a UETR when it is missing. For the MT 202 COV, an extra logic
is added to match the message to its corresponding MT 103 (103 variant) and copy the UETR from the
MT 103. This mechanism is activated by default but may be disabled.

No workflow changes are required to implement this logic (it is incorporated on the rule sequence
processing messages from a back-end). For manually entered messages, see question 7.

4. What logic does AMH use when adding the Service Type Identifier (field 111) to SWIFT gpi

messages?
AMH 3.x.20 foresees an optional mechanism that adds the Service Type identifier (SLA ID) according to
a configurable logic for the MT 103 variants and MT 202 COV. The configuration logic determines
whether all SWIFT gpi messages get the SLA ID added or only message with pre-defined sender BICs
are filled in with the SLA ID. The SLA ID will be set to ‘001’.

No workflow changes are required to implement this logic (it is incorporated in the same rule sequence
logic to add the UETR).

Note: This configuration option must only be used by gpi member banks and BICs that are configured in
the gpi Closed User Group. Use of this option by non-gpi member banks will result in the messages being
NAKed because of presence of field 111.

5. Can I rely on AMH to always add the appropriate UETR?

No, as per FIN interface certification requirements, the interfaces are expected to add the appropriate
UETR for the majority of use-cases. Adding the UETR is an activity that functionally belongs with the
business application. AMH provides a stop-gap solution that can be used until the back-office systems
are capable of adding the UETR at the source.

SWIFT FIN Interfaces will not offer functionality to pass on the UETR unchanged from received
(incoming) message into outgoing message. Therefore intermediary institutions must not rely on the
FIN interface and implement this change in the back-office.
6. I’m becoming a SWIFT gpi bank. Can I rely on AMH for adding UETR and Service Type Identifier?
AMH can help to fast track SWIFT gpi roll-out, but you cannot rely on AMH for all SWIFT gpi needs. In
the end SWIFT gpi business logic must be built in your payments system..

AMH 3.x.20 implementation will have a configuration parameter to add the Service Type Identifier(SLA Id
) value 001 in field 111 for every MT 103 and related MT 202 COV. This will help banks in the role of
Instructing Agent to become a SWIFT gpi member very fast without the need to change the back office to
add UETR and Service Type Identifier immediately. Banks in this case should however enhance their
back-office to create UETR and Service Type Identifier at their earliest convenience to profit more from
SWIFT gpi.

Banks joining SWIFT gpi in another role (Intermediary Agent) will however have to implement additional
changes in the back office. Typically, after receiving an MT 103, they will have to use the same UETR in
the forwarded MT 103 and (if applicable) MT 205 COV. AMH 3.x.20 does not provide such features.

7. How will AMH add UETR on manually created messages?

AMH allows, since version 3.5 :

- the addition of Service Type Identifier (SLA ID, field 111) and/or UETR (field 121) through manual
message creation.
- the addition of a UETR (field 121), either by typing or pasting it manually, or with a ‘Generate UETR’
button in the GUI next to field 121 to create a random UETR based on RFC4122 variant 4.

With 3.4.20, the above will also be possible for customers willing to stay on the AMH 3.4 release.

The configuration parameter used to control the visibility of UETR and SLA ID fields is removed from
AMH 3.5.20/3.6.20/3.7.20 onwards. As a consequence, in 3.x.20, those two fields are always displayed
on the transaction detail panel, for every FIN message.

This is also the case for SIC messages (which support a variant of UETR field since AMH 3.7). As an
example, as SIC pacs.008 & pacs.009 are part of the list of messages supporting the UETR field, any
pacs.008 and pacs.009 opened for SIC/euroSIC will have the gpi field displayed

If the operator that enters the message manually forgets to add the UETR, and if the UETR (field 121) is
mandatory for that SR 2018 message type, then normal validation for mandatory fields applies.

8. Which UETR will AMH add?

When the 3.x.20 updates and Netpack for FIN SR2018 are installed, and when AMH needs to add a
UETR (because it is mandatory for the message type and was not present in the message received from
the back-office application), it will:

· Add a random UETR based on RFC4122 variant 4 for the MT 103, MT 103 REMIT, MT 103 STP,
MT 202, MT 205 and MT 205 COV
· For the MT 202 COV, AMH will, by default :
o look in the live database if it can find an MT 103, MT 103 REMIT, MT 103 STP with a
sender BIC and TRN (field 20) matching the sender BIC and related TRN (field 21) of the
MT 202 COV
§ If exactly one is found the MT 202 COV will get the same UETR as the MT 103
§ If none or multiple are found, the MT 202 COV will be routed to the modification
queue for manual processing
 Note: If the MT 103 was received on a different instance of AMH than the one from which the MT 202
COV is sent, AMH will not be able to find that MT 103, and move the MT 202 COV in exception for
manual handling.

Note: Through configuration (application property), it will be possible to disable the UETR look-up feature
for MT 202 COV and use random UETR instead

9. What will happen if my back-office sends the MT 202 COV first?

In case the back office sends the MT 202 COV without UETR before the MT 103 to AMH, the MT 202
COV will end up in the exception inventory and will need to be repaired manually. It will be up to the
person who handles the MT 202 COV to wait for the related MT 103 and manually copy the UETR from
this MT 103 or to manually add a random UETR. This does not apply if the UETR look-up feature for MT
202 COV is disabled, since in that case a random UETR will be added to the MT 202 COV.

10. Will AMH validate a UETR added by my back office

No, when a UETR is present in a message from the back office AMH will not perform any actions on the
UETR.

11. Will AMH add the same UETR to an outgoing MT 103 if I’m an Intermediary agent?
Institutions that act as Intermediary Agent are expected, for an received (incoming)MT 103, to pass on
unchanged the UETR of that received MT 103, in the next MT that they send in the transaction chain.
This is the role of the back-office application. When such an MT 103 is sent, and no UETR is provided by
the back-office, then AMH will add a random UETR . There is no UETR look-up feature (like the one we
provide for the MT 202 COV), since AMH cannot automatically know if an outgoing MT 103 corresponds
to a previously received MT 103.

12. How does AMH send the UETR to the back-office?

For received (incoming) messages, all supported AMH versions already support passing the received
UETR to the back-office, as field 121 in the header block 3 of the message.

For sent (outgoing) messages, all 3.x.20 versions support the returning of the SWIFT gpi information (via
dedicated XML tags for UETR and SLA ID) in the AMP feedback report used to report ACK information.
This report is sent to the back office from AMH for FIN input messages. This can be used to report a
UETR generated by AMH to the back-office.

13. Is the gpi directory needed to activate some or all of the features above?
No. AMH supports SWIFTRef gpi directory upload since AMH 3.6, but only gpi members can obtain the
gpi directory. Therefore, it is not possible to leverage the gpi directory to make these features also
available for non SWIFT gpi customers.

Gpi members that use AMH can use the gpi directory information from within AMH e.g. for customised
processing of SWIFT gpi messages.

Back to Table of Contents

Alliance Lite2 questions

1. When will Alliance Lite2 be available for SR2018 testing?
The Standards MT Release 2018 will be activated in production as of November 18, 2018 and as per the
Alliance Lite2 service description available in test and training 6 weeks before on October 7, 2018.

2. What will happen if I send messages without UETR after the cut-over?
The central Alliance Lite2 infrastructure will always add a UETR to the messages that must have one
when the UETR is missing. Through Alliance Lite2 it will not be possible to send a message that must
have a UETR without UETR to the FIN network.

3. Where will the UETR appear in the messages I receive via AutoClient?
To avoid any back office issues SWIFT will NOT transmit the UETR to the customer AutoClient by default.
If an Alliance Lite2 customer uses a UETR-ready back office system the UETR can be kept and passed
to the customer AutoClient for further back office processing. This will have to be requested via SWIFT
support as a customisation request.

Note that this doesn’t apply for XMLv2 files passed to back-office which will always contain the UETR
when present.

4. When will Alliance Lite2 be able to add the UETR?

Alliance Lite2 allows already the STP processing of messages with Service Type Identifier (field 111)
and/or UETR (field 121) as well as through manual message processing. A button in the message
creation and message modification GUI is available to add a UETR based on RFC4122 variant 4.

When the SR2018 is activated, Alliance Lite2 will automatically add the UETR to all MT 103, MT 103
REMIT, MT 103 STP, MT 202, MT 202 COV, MT 205 and MT 205 COV which do not have a UETR at the
moment the message is added to the database.

5. Can I rely on Alliance Lite2 to always add the appropriate UETR?

No, as per FIN interface certification requirements, the interfaces are expected to add the appropriate
UETR for the majority of use-cases. Adding the UETR is an activity that functionally belongs with the
business application. Alliance Lite2 provides a stop-gap solution that can be used until the back-office
systems are capable of adding the UETR at the source.

6. How will Alliance Lite2 add UETR on manually created messages?

Alliance Lite2 already allows the addition of Service Type Identifier (field 111) and/or UETR (field 121)
through manual message creation. A button in the GUI is available to create a UETR based on RFC4122
variant 4. If an operator doesn’t use this option and therefore does not generate manually the UETR
when it is mandatory, Alliance Lite2 will generate the required reference automatically.

7. How will Alliance Lite2 add UETR on messages from the back-office?
When the SR2018 will be made available, Alliance Lite2 will automatically add the UETR to all MT 103,
MT 103 REMIT, MT 103 STP, MT 202, MT 202 COV, MT 205 and MT 205 COV which do not have a
UETR at the moment the message is added to the database.

8. When in the message flow will Alliance Lite2 add they UETR?
Alliance Lite2 will add the UETR on messages for which it is mandatory at the moment the message is
created in the database, independent of the method used to create the message (manual entry or
AutoClient).
 9. Which UETR will Alliance Lite2 add?
When the SR2018 is activated, and when Alliance Lite2 needs to add a UETR (because it is mandatory
for the message type and was not present in the message received from the back-office application), it
will:

· Add a random RFC4122 variant 4 for the MT 103, MT 103 REMIT, MT 103 STP, MT 202, MT
205 and MT 205 COV
· For the MT 202 COV, Alliance Lite2 will:
o look in the live database if it can find an MT 103, MT 103 REMIT, MT 103 STP with a
sender BIC and TRN (field 20) matching the sender BIC and related TRN (field 21) of the
MT 202 COV
§ If exactly one is found the MT 202 COV will get the same UETR as the MT 103
§ If none or multiple are found, the MT 202 COV will be routed to the modification
queue for manual processing

10. What will happen if my back-office sends the MT 202 COV first?
In case the back office sends the MT 202 COV without UETR before the MT 103 to Alliance Lite2, the MT
202 COV will end up in the modification queue for manual processing. It will be up to the person who
handles the MT 202 COV to wait for the related MT 103 or add a random UETR.

At the moment that the related MT 103 without UETR is sent from the back-office to Alliance Lite2, no
lookup will be done for a related MT 202 COV and a random UETR will be added.

If this is your normal business scenario it is highly recommended to make sure that the back-office adds
an appropriate UETR in order to avoid excessive manual repair.

11. Will Alliance Lite2 add the same UETR if I’m an intermediate institution?
Intermediary institutions are expected to pass on, unchanged, a received UETR in the MT 103, MT 103
REMIT, MT 103 STP, MT 202, MT 205, MT 202 COV and MT 205 COV in the next MT sent in the
transaction chain. When such an MT 103, MT 103 REMIT, MT 103 STP, MT 202, MT 205, MT 202 COV
or MT 205 COV is sent, Alliance Lite2 will add a random UETR if no UETR was provided. There is no
UETR look-up feature like the one we provide for the MT 202 COV. Such scenario however will result in
the user not implementing the Standards Usage guidelines as a new UETR will always be created
whereas the Standards require to pass unchanged the same UETR from the incoming message to the
next message in the transaction chain when acting as intermediary institution. Although the messages will
not be rejected by the network, this will break the end-to-end tracking of the messages within the
payment chain which SWIFT is currently building on all payment transactions.

Back to Table of Contents

Appendix A: Alliance Access/Entry Sample

messages
The following messages are examples that show how Alliance Access/Entry returns UETR information to
the back-office. The output has been slightly formatted for human readability:
 RJE representation of message with Transfer Original Message with Notification set to Never

{1:F21SWHQBEBBBXXX0067084395}{4:{177:1802201155}{451:0}}
{1:F01SWHQBEBBBXXX0067084395}{2:I103SWHQBEBBXXXXN}{3:{111:001}{121:9f02c25b-e6f5-4cfd-
9482-40d63f1bf930}}{5:{CHK:0A14F68DFBF0}}{S:{CON:}}
RJE representation of message with Transfer Original Message with Notification set to Always

{1:F21SWHQBEBBBXXX0067084395}{4:{177:1802201155}{451:0}}
{1:F01SWHQBEBBBXXX0067084395}{2:I103SWHQBEBBXXXXN}{3:{111:001}{121:9f02c25b-e6f5-4cfd-
9482-40d63f1bf930}}{4:
:20:test
:23B:CRED
:32A:101118EUR9533,61
:33B:EUR1958,47
:50K:FRANZ GMBH
MAINZ
:59:/BE62510007547061
JOHANN DOE
RUE FERDINANT III, 119
1040 BRUSSELS
:71A:SHA
-}{5:{CHK:0A14F68DFBF0}}{S:{SPD:}}

XMLv2 representation of message with Transfer Original Message with Notification set to Never

<?xml version="1.0" encoding="UTF-8" ?><Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0"

xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt"
xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec">
<Saa:Revision>2.0.7</Saa:Revision><Saa:Header><Saa:TransmissionReport>
<Saa:SenderReference>ISWHQBEBBXXX103test$180220691970</Saa:SenderReference>
<Saa:ReconciliationInfo>180220SWHQBEBBBXXX0067084395</Saa:ReconciliationInfo>
<Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus>
<Saa:OriginalInstanceAddressee><Saa:X1>SWHQBEBBXXX</Saa:X1>
<Saa:FinancialInstitution>S.W.I.F.T. HEADQUARTERS</Saa:FinancialInstitution><Saa:CityName>LA
HULPE</Saa:CityName><Saa:CountryCode>BE</Saa:CountryCode></Saa:OriginalInstanceAddressee>
<Saa:ReportingApplication>FINInterface</Saa:ReportingApplication><Saa:NetworkInfo>
<Saa:Priority>Normal</Saa:Priority><Saa:IsPossibleDuplicate>true</Saa:IsPossibleDuplicate>
<Saa:IsNotificationRequested>false</Saa:IsNotificationRequested><Saa:Service>swift.fin</Saa:Service>
<Saa:Network>FIN</Saa:Network><Saa:SessionNr>0067</Saa:SessionNr>
<Saa:SeqNr>084395</Saa:SeqNr><Saa:FINNetworkInfo>
<Saa:MessageSyntaxVersion>1605</Saa:MessageSyntaxVersion><Saa:FINUserHeader>{111:001}
{121:9f02c25b-e6f5-4cfd-9482-40d63f1bf930}</Saa:FINUserHeader>
<Saa:ServiceLevelAgreement>001</Saa:ServiceLevelAgreement>
<Saa:E2ETransactionReference>9f02c25b-e6f5-4cfd-9482-
40d63f1bf930</Saa:E2ETransactionReference></Saa:FINNetworkInfo></Saa:NetworkInfo>
<Saa:Interventions><Saa:Intervention><Saa:IntvCategory>TransmissionReport</Saa:IntvCategory>
<Saa:CreationTime>20180220105416</Saa:CreationTime>
<Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin><Saa:Contents>
{1:F21SWHQBEBBBXXX0067084395}{4:{177:1802201155}{451:0}}</Saa:Contents></Saa:Intervention>
</Saa:Interventions><Saa:IsRelatedInstanceOriginal>true</Saa:IsRelatedInstanceOriginal>
<Saa:MessageCreator>Messenger</Saa:MessageCreator>
<Saa:IsMessageModified>false</Saa:IsMessageModified>
<Saa:MessageFields>NoOriginal</Saa:MessageFields></Saa:TransmissionReport></Saa:Header>
</Saa:DataPDU>

Back to Table of Contents

Audience
Customer

Last update
12/03/2018

Product
Alliance Access
Alliance Entry
Alliance Lite2
Alliance Messaging Hub

Release

Platform

Change request

Found in

Fixed in