1. SWIFT message retrieval and replay capabilities for CLS members
CLS Member Gateway Elimination Project
Pieter Herrebout/Damien Vanderveken/Pamela Amick
22-23 January 2014

2. Session objectives Objective of today’s session is to
Provide an overview of the various retrieval capabilities available on SWIFTNet
Illustrate the recovery process for the MI Channel using the new replay service
SWIFT message retrieval and replay capabilities – January 2014

3. Agenda Overview of SWIFTNet retrieval capabilities
Recovery for MI Channel
SWIFT message retrieval and replay capabilities – January 2014

4. Retrieval on SWIFTNet For store-and-forward traffic
Retrieval options available via a store-and-forward interface
Message retrieval
generic message(s) retrieval - similar to FIN
to support investigations or message recovery
Short-term bulk retrieval
retrieves all traffic in bulk (max last 24 hrs)
allows to "fill the gap" in case of unplanned site takeover with missing traffic
Retrieval options available via MI Channel
Leveraging the underlying availability and reliability of MV-SIPN and SWIFT security and features.
Message replay
retrieves ("replays") messages in an easy way
allows to "fill the gap" in case of unplanned site takeover with missing traffic
SWIFT message retrieval and replay capabilities – January 2014

5. Portfolio Evolution
March 2009
Message retrieval
SWIFT stores message traffic in an archive when customers send traffic via a store-and-forward service
Customers can retrieve a copy of their traffic sent and/or received from the archive
Find a message e.g. dispute between sender/receiver, question from regulator, ...
Recover lost traffic e.g. after an interface crash
Typical use
What information are people looking for, when responsible for SWIFT operations?
[read the slide]
SWIFT message retrieval and replay capabilities – January 2014
Partner_Meeting_ _v1

6. SWIFTNet message retrieval process
Portfolio Evolution
March 2009
SWIFTNet message retrieval process
Two ways to trigger the retrieval request
Using a GUI screen (in the SWIFTNet Online Operations Manager)
Using a messaging interface that sends system message
Received messages arrive in a store-and-forward queue, the messaging interface picks them up (as usual)
for manual treatment, or
possibly automated treatment by interface or backoffice
Trigger
Selection
Processing
Delivery
Use
O2M screen
Screen parameters
- ISN/OSN range
- time range...
- queue to deliver
S&F queue
S&F retrieval
interface 1
automated
System message parameters
- ISN/OSN range
- time range...
- queue to deliver
S&F queue
S&F retrieval
interface 2
SWIFT message retrieval and replay capabilities – January 2014
Partner_Meeting_ _v1

7. Message retrieval Highlights
Portfolio Evolution
March 2009
Message retrieval Highlights
Features:
Each customer can retrieve their traffic (sent or received)
covers messages sent/received with InterAct store-and-forward
includes traffic to/from central institution in case of Y-Copy
124 days retrieval capability
(pilot and ITB traffic 4 days)
Online retrieval
trigger through system message or GUI screen (SWIFTNet Online Operations Manager)
retrieved traffic arrives in a store-and-forward queue
Input or output retrieval, with various selection criteria
Access control using an RBAC role
Interfaces:
Requires updated interface release to submit retrieval requests and process retrieval responses (e.g. Alliance Access )
Overall functionality is similar to FIN
there are some technical differences mainly relevant to developers
What information are people looking for, when responsible for SWIFT operations?
[read the slide]
Partner_Meeting_ _v1

8. Message retrieval Example screen - Online Operations Manager GUI
Portfolio Evolution
March 2009
Message retrieval Example screen - Online Operations Manager GUI
What information are people looking for, when responsible for SWIFT operations?
[read the slide]
SWIFT message retrieval and replay capabilities – January 2014
Partner_Meeting_ _v1

9. Portfolio Evolution
March 2009
Message retrieval Example system message xsys Retrieval Request
What information are people looking for, when responsible for SWIFT operations?
[read the slide]
See SWIFTNet system messages (User Handbook):
SWIFT message retrieval and replay capabilities – January 2014
Partner_Meeting_ _v1

10. SWIFTNet short-term bulk retrieval Overview
Portfolio Evolution
March 2009
SWIFTNet short-term bulk retrieval Overview
What
Retrieve all InterAct/FileAct of max 24 hours old
Allows to "fill the gap" if customer lost data in transit
Subscription based
Ongoing sync
Site disaster – possible data loss
011
101
01001
How
Request via system message
Delivery of traffic is bulked inside files delivered via FileAct
Requires specific development to process file contents
Bulk retrieval request to "fill the gap"
SWIFT
SWIFT message retrieval and replay capabilities – January 2014
Partner_Meeting_ _v1

11. SWIFTNet short-term bulk retrieval Highlights
Portfolio Evolution
March 2009
SWIFTNet short-term bulk retrieval Highlights
Covers (max) last 24hrs of traffic
Single retrieval criterion: timerange
Retrieves all store-and-forward traffic sent and received
Requires some development
The customer sends a Bulk Retrieval Request system message to SWIFT, mentioning the time range to cover.
SWIFT replies with a Bulk Retrieval Report system message that lists the files that have been generated.
SWIFT delivers the files through FileAct store-and-forward. They arrive in the notification queue that is specified when sending the Bulk Retrieval system message to SWIFT.
Customer needs to process the bulk files (e.g. filter on service name).
SWIFT message retrieval and replay capabilities – January 2014
Partner_Meeting_ _v1

12. Message replay (with MI Channel) Overview
Portfolio Evolution
March 2009
Message replay (with MI Channel) Overview
SWIFT
site1
site2
Switch to site2
SWIFT
site1
site2
Automatically resume normal traffic delivery
SWIFT
Activate replay
site1
site2
copy
Normal traffic delivery
SWIFT message retrieval and replay capabilities – January 2014
Partner_Meeting_ _v1

13. Message replay (with MI Channel) Highlights
Portfolio Evolution
March 2009
Message replay (with MI Channel) Highlights
MI Channel has an integrated "replay" recovery feature:
SWIFT will re-deliver messages received in the same way as the original delivery (+ "potential duplicate" indication)
Allows the secondary site to "fill the gap" by identifying and processing the missing messages
After the replay, normal traffic delivery resumes automatically
Preserves message delivery order
User initiates replay using the following parameters:
timestamp: re-delivery of all messages received since this time
+ optional OSN(s) per SnF queue: re-delivery of only messages with higher OSN
SWIFT message retrieval and replay capabilities – January 2014
Partner_Meeting_ _v1

14. Short term bulk retrieval
Portfolio Evolution
March 2009
Comparison
Message retrieval
Short term bulk retrieval
Message replay
Typical use case
Message investigation or interface recovery
Point-in time recovery to other site
Scope
Any message
All traffic
One market infrastructure service
Selection criteria
Flexible (timeframe, reference, sequence numbers, ...)
Timeframe
Timestamp or
timestamp+OSN
Supported period
Last 124 days, requests of messages.
Last 24 hours, requests of 1 hour max
Last 8 hours
Eligibility
All customers
Subscribed customers
Market Infrastructure customers using MI Channel
Trigger mechanism
System message or O2M screen
System message
Alliance Gateway GUI (or command line)
Delivery mechanism
Message-per-message re-delivery
Traffic bulked in files
Retrieved message handling
Application required to process retrieved traffic
Application required to process retrieved files, and extract and process the needed information
Easy integration, messages are re-delivered as they were delivered initially
Messaging services supported
InterAct Store and Forward
InterAct and FileAct Store and Forward
InterAct Store and Forward
SWIFT message retrieval and replay capabilities – January 2014
Partner_Meeting_ _v1

15. Agenda Overview of SWIFTNet retrieval capabilities
Recovery for MI Channel
SWIFT message retrieval and replay capabilities – January 2014

16. MI Channel recovery in case of data loss
Active
Inactive
MI Channel
component status
Primary
site
WebSphere MQ
queue manager
Alliance Gateway
MI Channel
component
Back-Office application
HSMs
WebSphere MQ
queue manager
SWIFTNet
Store and Forward
Alliance Gateway
Secondary
site
MI Channel
component
HSMs
SWIFT message retrieval and replay capabilities – January 2014

17. MI Channel – Emission flow – From member to CLS1
Emission Queue 2 5
Alliance Gateway
MI Channel
component 7
Notification Queue 6
MQ client
MI Channel 3
Back-Office application 4
SWIFTNet
Store and Forward
Back-office application stores a message to be sent in an emission queue
The MI Channel MQ adapter reads the message from the queue
The MI Channel component batch, compresses, sign and sends the messages over SWIFTNet
Confirmation of storage is received from SWIFTNet store and forward
MI Channel MQ client removes message from emission queue
Optionally, MI Channel MQ client puts a positive notification in the notification queue
Back office gets the positive notification from the notification queue
Error Queue
SWIFT message retrieval and replay capabilities – January 2014

18. Recovery in case of data loss – Emission flow
Primary site
Back
Office
Emission
Queue
Notification
Queue
Alliance Gateway
Msg3
Notif1
MI Channel
component
SWIFT
Msg1
Notif2
Msg2
MQ client
MI Channel
S&F
Msg3
Batch1
Msg4
Msg1
Msg2
Back-Office
emission status
Secondary site
Emission
Queue
Notification
Queue
Alliance Gateway
ACK received
MI Channel
component
Waiting ACK
MQ client
MI Channel
Ready to send

19. Example – Identifying status of sent messages
Element
Type
Description
SentMessage
[1] SentMessage
Contains resulting transfer details of the message which was attempted to be sent
SentHeader
[0..1] SentHeader
Contains the routing information found for the message in the queue
MessageRef
[1] String
Unique reference of the message
BatchIndex
[0..1] Integer
Optional element present when messages have been batched together and share the same SnFRef. The value represents the index position of the message in the batch starting from one.
BatchCount
Optional element present when messages have been batched together and share the same SnFRef. The value represents the total number of messages in the batch.
TransferAnswer
“Accepted”, “Failed Storage”, “Failed Delivery”
Indicates that SWIFT has accepted the storage of a message, failed to store the message, or a message that was stored successfully failed to be delivered
SnFRef
[0..1] String
SWIFT reference of the request. Includes a trusted time stamp.
TransferError
[0..1] TransferError
Present if the Transfer Answer is not “Accepted”
ErrorCode
Error code of the error
ErrorText
Error description
extract from MI Channel Interfaces Specifications
SWIFT message retrieval and replay capabilities – January 2014

20. Example – Identifying status of sent messages
01 <SwMsg:SentMessage xmlns:SwMsg="urn:swift:snl:ns.SwMsg">
02 <SwMsg:SentHeader>
03 <SwMsg:MessageRef>MyUniqueRef</SwMsg:MessageRef>
04 <BatchIndex>1</BatchIndex>
05 <BatchCount>2</BatchCount>
05 </SwMsg:SentHeader>
06 <SwMsg:TransferAnswer>Accepted</SwMsg:TransferAnswer>
07 <SnFRef>... </SnFRef>
08 </SwMsg:SentMessage>
SWIFT message retrieval and replay capabilities – January 2014

21. Recovery in case of data loss – Emission Flow
Primary site
SWIFT
Back
Office
Emission
Queue
Notification
Queue
Alliance Gateway
S&F
Msg3
Notif1
MI Channel
component
Batch1
Msg1
Notif2
Msg1
Msg2
MQ client
MI Channel
Msg2
Msg3
Msg4
Batch2
Msg1
PDE
Secondary site
Msg2
Back-Office
emission status
PDE
Emission
Queue
Notification
Queue
Alliance Gateway
Batch3
Msg1
Notif1
ACK received
Msg3
PDE
MI Channel
component
PDE
Waiting ACK
Msg2
Notif2
PDE
Msg4
MQ client
MI Channel
Ready to send
Msg3
Notif3
PDE
Msg4
Notif4

22. MI Channel - Reception flow5
Reception Queue 2
Alliance Gateway
MI Channel
component
Non-repudiation Queue 3
MQ client
MI Channel 1
Back-Office application 4
SWIFTNet
Store and Forward
MI Channel component receives a batch of messages from SWIFTNet Store-and-forward
MI Channel uncompresses, unbatches, reverifies the digests of the individual messages, and distributes the messages over the MQ reception queues.
The signature of the entire batch is put into the non-repudiation queue
After all the messages are stored in their MQ queues and the signature is stored in the non-repudiation queue, then the batch is acknowledged to SWIFT store-and-forward, and the next batch is processed.
Back Office application can read messages received from the reception queues
Notification Queue
Error Queue
SWIFT message retrieval and replay capabilities – January 2014

23. Recovery in case of data loss – Reception flow
SWIFT
Primary site
Back
Office NR
Queue
Reception
Queue
Alliance Gateway
S&F
Batch1
B1.Msg1
MI Channel
component
Batch1
B1.Msg1
Batch1
B1.Msg2
Batch2
B1.Msg2
Batch2
MQ client
MI Channel
B2.Msg1
Batch3
B2.Msg2
Batch4
Secondary site NR
Queue
Reception
Queue
Alliance Gateway
Delivered
Not yet delivered
SWIFT delivery
status
MI Channel
component
MQ client
MI Channel

24. Options to determine the replay restart point
Starting time
OSN & associated delivery time
Input criteria
Based on knowledge of the local routing, replication, queue processing, determine the point in time where all messages have been processed.
CLS member application must determine, for each SnF queue, the last OSN received (without gaps) where all messages within the batch have been processed
Behaviour
All traffic as of the starting time will be replayed in the same way as the original delivery with "potential duplicate" indication
All traffic as of sequence number +1 will be replayed in the same way as the original delivery with "potential duplicate" indication
Pro’s
Easy to implement
More precise selection criterion hence limiting the number of duplicates and the time required to receive replayed messages.
Con’s
Less precise selection criterion hence increasing the number of duplicates and the time required to receive replayed messages.
Requires back office application to implement complex reconciliation logic
SWIFT message retrieval and replay capabilities – January 2014

25. Example – Identifying the replay trigger parameters – extract from MI Channel specs
Element
Type
ReceivedMessage
[1] ReceivedMessage
Contains the detailed format of the messages sent to SWIFT and
received by the member or CLS
ReceivedHeader
[1] ReceivedHeader
Contains the routing information for the message in the queue
Requestor
[1] String
Requestor DN used to send the original message
Responder
Responder DN of the receiving institution
Service
SWIFTNet service name used when sending the original message
RequestType
ISO standard business request type in the format xxxx.nnn.nnn.nn
MessageRef
Unique Sender reference of the message
PDIndication
[0..1] DateTime
PDIndication [0..1] DateTime Indicator of possible duplicate emission in UTC
BatchIndex
[0..1] Integer
Optional element present when messages have been batched together and share the same SnFRef. The value represents the index position of the message in the batch.
BatchCount
Optional element present when messages have been batched together and share the same SnFRef. The value represents the total number of messages in the batch.
SnFRef
SWIFT reference of the request. Includes a trusted time stamp.
RetrievedMessageIndication
[0..1] Boolean
Indicates that the message has previously been delivered and has been re-sent as a result of an operational recovery.
SnFInfo
[1] SnFInfo
Store-and-forward related transfer information
SnFDeliveryInfo
[1-10] SnFDeliveryInfo
Provides the delivery attempt history
SnFSessionId
Identifies the Output Session used to deliver the message from SWIFT. Can be used in union with the OutputSeq number to verify that all messages sent can be accounted for once Delivered
SnFOutputSeq
[1] Integer
Store-and-forward output sequence number for the message retrieved
within the session
SnFDeliveryTime
[1] DateTime
Time of delivery of the message in UTC
RequestPayload
[1] XML[Any]
An XML string that contains the ISO message to be sent
SWIFT message retrieval and replay capabilities – January 2014

26. Identifying the replay trigger parameters
01 …
02 <SwMsg:BatchIndex>1</SwMsg:BatchIndex>
03 <SwMsg:BatchCount>2</SwMsg:BatchCount>
04 …
05 <SwMsg:SnFSessionId>bankbebb_clsinstrnot:d:12345</SwMsg:SnFSessionId>
06 <SwMsg:SnFOutputSeq>1</SwMsg:SnFOutputSeq>
07 <SwMsg:SnFDeliveryTime> T08:00:00Z</SwMsg:SnFDeliveryTime>
08 …
B1.Msg1
Batch 1 has been completely received
01 …
02 <SwMsg:BatchIndex>2</SwMsg:BatchIndex>
03 <SwMsg:BatchCount>2</SwMsg:BatchCount>
04 …
05 <SwMsg:SnFSessionId>bankbebb_clsinstrnot:d:12345</SwMsg:SnFSessionId>
06 <SwMsg:SnFOutputSeq>1</SwMsg:SnFOutputSeq>
07 <SwMsg:SnFDeliveryTime> T08:00:00Z</SwMsg:SnFDeliveryTime>
08 …
B1.Msg2
01 …
02 <SwMsg:BatchIndex>1</SwMsg:BatchIndex>
03 <SwMsg:BatchCount>2</SwMsg:BatchCount>
04 …
05 <SwMsg:SnFSessionId>bankbebb_clsinstrnot:d:12345</SwMsg:SnFSessionId>
06 <SwMsg:SnFOutputSeq>2</SwMsg:SnFOutputSeq>
07 <SwMsg:SnFDeliveryTime> T08:00:01Z</SwMsg:SnFDeliveryTime>
08 …
Batch 2 has not been completely received
B2.Msg1
SWIFT message retrieval and replay capabilities – January 2014

27. Tentative
Triggering replay from Alliance Gateway: Generic approach for operating profile
Operating profile functions available for MI Channel support interface
Define operating profile with relevant functions for starting / stopping message flow:
Enable a Message Flow Instance
Start Replay for a Message Flow Instance
Disable a Message Flow Instance
Define operator and assign operating profile
SWIFT message retrieval and replay capabilities – January 2014

28. Triggering replay from Alliance Gateway
Tentative
Triggering replay from Alliance Gateway
Copyright <text>
Configuration
Alliance Gateway: <instanceName> -
Licensing Configuration
System
User Management +
Event Log
Application Interface
SWIFTNet Interface
MI Channel Support Interface
File Transfer
Routing
User: <name> Alliance Server Instance: <name>
Status
Help
Logout
Change Password
About
Alliance Gateway Administration <n>
Monitoring
Home
HSM Management
Message Flow Instances
Name
Port
Rows in list: <n>, in selection: <n>
Window Size
Min. Delay
<nameOfMI>
Emission Endpoints
Reception Endpoints
Reliable Messaging
Change View
Add
Delete
Enable
Disable
Max. Delay
Base Port
Condition
< Previous
Next >
Report
State
Refresh
Batch Classes
Sites
MQ Managers
MQ Queues
MQ Channels
SnF Queues
Routing Rules
Routing Rule Sets
Replay
MFP<nn> <value> <value> <value> <value> <value> Disabled <value> stopped 
Cancel OK
Replay for Message Flow Instance
Name
Help
Status
State
SnF Queue Parameters
Remove
Add
Edit
stopped
Disabled
MFP<nn>
File Path
Use Existing File No
UTC Time
yyyy-mm-ddThh24:mi:ssZ
Include OSN per SnF Queue
Force Start
Condition
<value>
Notes: From the list of instances, consider having a button bar trigger called Replay. To initiate replay, the user must select an instance in the list and click Replay – it is however the same operating profile function as for Enable a Message Flow Instance. TBD if there is some relevant and/or invalid combination for Status / State values to consider for allowing the Replay trigger to be active (i.e. not greyed out). A popup appears allowing the user to add info to be used with the swiftnet start command (syntax for replay not yet available), either indicating the name of an already existing file or info that allows Alliance Gateway to build a file. Default to use an existing file is No. Default to Include OSN per SnF Queue is No; the list box for SnF queues is empty. See next slide for behaviour if the user clicks Yes to use an existing file.
SWIFT message retrieval and replay capabilities – January 2014

29. Triggering replay from Alliance Gateway – option 1: file input
Tentative
Triggering replay from Alliance Gateway – option 1: file input
Copyright <text>
Configuration
Alliance Gateway: <instanceName> -
Licensing Configuration
System
User Management +
Event Log
Application Interface
SWIFTNet Interface
MI Channel Support Interface
File Transfer
Routing
User: <name> Alliance Server Instance: <name>
Status
Help
Logout
Change Password
About
Alliance Gateway Administration <n>
Monitoring
Home
HSM Management
Message Flow Instances
Name
Port
Rows in list: <n>, in selection: <n>
Window Size
Min. Delay
<nameOfMI>
Emission Endpoints
Reception Endpoints
Reliable Messaging
Change View
Add
Delete
Enable
Disable
Max. Delay
Base Port
Condition
< Previous
Next >
Report
State
Refresh
Batch Classes
Sites
MQ Managers
MQ Queues
MQ Channels
SnF Queues
Routing Rules
Routing Rule Sets
Replay
MFP<nn> <value> <value> <value> <value> <value> Disabled <value> stopped 
Cancel OK
Replay for Message Flow Instance
Name
Help
Status
State
SnF Queue Parameters
Remove
Add
Edit
stopped
Disabled
MFP<nn>
File Path
Use Existing File
Yes
UTC Time
yyyy-mm-ddThh24:mi:ssZ
Include OSN per SnF Queue No
Force Start
Condition
<value>
File built by CLS back office application
Notes: If the user clicks Yes to indicate use of an existing file, the File Path field becomes editable. The other fields in the popup become uneditable. The user must type the complete path including file name. When the user clicks OK, the sagpi_misna process must prepare the swiftnet start command using the file-related information that the user provided.
SWIFT message retrieval and replay capabilities – January 2014

30. Triggering replay from Alliance Gateway – option 2: manual input
Tentative
Copyright <text>
Configuration
Alliance Gateway: <instanceName> -
Licensing Configuration
System
User Management +
Event Log
Application Interface
SWIFTNet Interface
MI Channel Support Interface
File Transfer
Routing
User: <name> Alliance Server Instance: <name>
Status
Help
Logout
Change Password
About
Alliance Gateway Administration <n>
Monitoring
Home
HSM Management
Message Flow Instances
Name
Port
Rows in list: <n>, in selection: <n>
Window Size
Min. Delay
<nameOfMI>
Emission Endpoints
Reception Endpoints
Reliable Messaging
Change View
Add
Delete
Enable
Disable
Max. Delay
Base Port
Condition
< Previous
Next >
Report
State
Refresh
Batch Classes
Sites
MQ Managers
MQ Queues
MQ Channels
SnF Queues
Routing Rules
Routing Rule Sets
Replay
MFP<nn> <value> <value> <value> <value> <value> Disabled <value> stopped 
Cancel OK
Replay for Message Flow Instance
Name
Help
SnF Queue Parameters
Remove
Add
Edit
MFP<nn>
File Path
Use Existing File No
UTC Time
yyyy-mm-ddThh24:mi:ssZ
Include OSN per SnF Queue
Status
State
stopped
Disabled
Force Start
Condition
<value>
Parameters to be manually filled in
Notes: If the user changes Use Existing File to No, the File Path field is uneditable. It is necessary to provide a value in the UTC Time field. If OSN is not needed for any SnF queue, the user just clicks OK at this point. TBD what will build the file? The sagpi_misna process must prepare the swiftnet start command using a file created based on the information that the user provided.
If OSN is needed, the user must select Yes for Include OSN per SnF Queue. See next slide.
SWIFT message retrieval and replay capabilities – January 2014

31. Tentative
Triggering replay from Alliance Gateway – option 2 manual input – continued
Copyright <text>
Configuration
Alliance Gateway: <instanceName> -
Licensing Configuration
System
User Management +
Event Log
Application Interface
SWIFTNet Interface
MI Channel Support Interface
File Transfer
Routing
User: <name> Alliance Server Instance: <name>
Status
Help
Logout
Change Password
About
Alliance Gateway Administration <n>
Monitoring
Home
HSM Management
Message Flow Instances
Name
Port
Rows in list: <n>, in selection: <n>
Window Size
Min. Delay
<nameOfMI>
Emission Endpoints
Reception Endpoints
Reliable Messaging
Change View
Add
Delete
Enable
Disable
Max. Delay
Base Port
Condition
< Previous
Next >
Report
State
Refresh
Batch Classes
Sites
MQ Managers
MQ Queues
MQ Channels
SnF Queues
Routing Rules
Routing Rule Sets
Replay
MFP<nn> <value> <value> <value> <value> <value> Disabled <value> stopped 
01 …
02 <SwMsg:BatchIndex>1</SwMsg:BatchIndex>
03 <SwMsg:BatchCount>2</SwMsg:BatchCount>
04 …
05 <SwMsg:SnFSessionId>bankbebb_clsinstrnot:d:12345</SwMsg:SnFSessionId>
06 <SwMsg:SnFOutputSeq>1</SwMsg:SnFOutputSeq>
07 <SwMsg:SnFDeliveryTime> T08:00:00Z</SwMsg:SnFDeliveryTime>
08 …
Cancel OK
Replay for Message Flow Instance
Name
Help
Status
SnF Queue Parameters
Disabled
MFP<nn>
File Path
Use Existing File No
UTC Time
yyyy-mm-ddThh24:mi:ssZ
Include OSN per SnF Queue
Yes
T08:00:00Z
Remove
Add
Edit
bankbebb_clsopdata
bankbebb_clsrep
bankbebb_clsinstrnot
State
stopped
Force Start
Condition
<value>
Notes: Clicking Yes for Include OSN per SnF Queue populates the list box from the SAG database; the user can then select each queue and click Edit, and then provide the necessary info in the resulting popup window. See next slide.
SWIFT message retrieval and replay capabilities – January 2014

32. .
Tentative
Triggering replay from Alliance Gateway – option 2 manual input – continued
Copyright <text>
Configuration
Alliance Gateway: <instanceName> -
Licensing Configuration
System
User Management +
Event Log
Application Interface
SWIFTNet Interface
MI Channel Support Interface
File Transfer
Routing
User: <name> Alliance Server Instance: <name>
Status
Help
Logout
Change Password
About
Alliance Gateway Administration <n>
Monitoring
Home
HSM Management
Message Flow Instances
Name
Port
Rows in list: <n>, in selection: <n>
Window Size
Min. Delay
<nameOfMI>
Emission Endpoints
Reception Endpoints
Reliable Messaging
Change View
Add
Delete
Enable
Disable
Max. Delay
Base Port
Condition
< Previous
Next >
Report
State
Refresh
Batch Classes
Sites
MQ Managers
MQ Queues
MQ Channels
SnF Queues
Routing Rules
Routing Rule Sets
Replay
MFP<nn> <value> <value> <value> <value> <value> Disabled <value> stopped 
01 …
02 <SwMsg:BatchIndex>1</SwMsg:BatchIndex>
03 <SwMsg:BatchCount>2</SwMsg:BatchCount>
04 …
05 <SwMsg:SnFSessionId>bankbebb_clsinstrnot:d:12345</SwMsg:SnFSessionId>
06 <SwMsg:SnFOutputSeq>1</SwMsg:SnFOutputSeq>
07 <SwMsg:SnFDeliveryTime> T08:00:00Z</SwMsg:SnFDeliveryTime>
08 …
Cancel OK
Replay for Message Flow Instance
Name
Help
Status
SnF Queue Parameters
Disabled
MFP<nn>
File Path
Use Existing File No
UTC Time
yyyy-mm-ddThh24:mi:ssZ
Include OSN per SnF Queue
Yes
<value>
Remove
Add
Edit
bankbebb_clsopdata
bankbebb_clsrep
bankbebb_clsinstrnot
State
stopped
Force Start
Condition
Cancel OK
Edit SnF Queue Parameters
Help
Session Details
bankbebb_clsinstrnot:d:12345
OSN
queue:d:nnnnn 1
Notes: After adding a value for OSN, the user clicks Add and the OSN value is appended to the name of the queue.
In case there are SnF queues populated that are not in the “cooked” configuration, the user can select a queue and click Remove.; see next slide
SWIFT message retrieval and replay capabilities – January 2014

33. Recovery in case of data loss – Reception flow
SWIFT
Primary site
Back
Office NR
Queue
Reception
Queue
Alliance Gateway
S&F
Batch1
B1.Msg1
MI Channel
component
Batch1
B1.Msg1
Batch1
B1.Msg2
Batch2
B1.Msg2
Batch2
MQ client
MI Channel
B2.Msg1
Batch3
B2.Msg2
B2.Msg1
Batch4
PDM
B2.Msg2
PDM
Resumes normal delivery
B3.Msg1
Secondary site
B3.Msg2 NR
Queue
Reception
Queue
Alliance Gateway
Delivered
Not yet delivered
SWIFT delivery
status
SWIFT delivery
status
B4.Msg1
B4.Msg2
Batch2
Batch3
B3.Msg1
B2.Msg1
MI Channel
component
PDM
PDM
B2.Msg2
B3.Msg2
Delivered
Batch4
PDM
MQ client
MI Channel
B4.Msg1
Not yet delivered
SWIFT message retrieval and replay capabilities – January 2014
B4.Msg2

34. Connectivity and Messaging Portfolio La Hulpe
October2008
Recovery using replay
Summary
Recover from data loss resulting from site failover
Easy to integrate
Requires traffic reconciliation from Back Office
Triggered through Alliance Gateway Administration GUI*
while preserving message sequencing
SWIFT message retrieval and replay capabilities – January 2014
* Or command line
Product_portfolio_ _v1

35. Q&A
SWIFT message retrieval and replay capabilities – January 2014

36. Thank you
SWIFT message retrieval and replay capabilities – January 2014

37. Appendix
SWIFT message retrieval and replay capabilities – January 2014

38. MI Channel Emission side – error flow1
Emission Queue 1 2
Alliance Gateway 4
MI Channel
component 6
Notification Queue 1 5
MQ client
MI Channel 3
Back-Office application
SWIFTNet
Store and Forward
Back-office application stores a message to be sent in an emission queue
The MI Channel MQ adapter reads the message from the queue
The MI Channel component batch, compresses, sign and tries to send the messages over SWIFTNet but message cannot be sent for example because of
· rejection of an emission message (because of non-compliance with expected XML format)
· invalid routing when received at SWIFT
MI Channel MQ client removes message from emission queue and moves it to the error queue
MI Channel MQ client puts a negative delivery acknowledgement in the notification queue
Back office gets the negative acknowledgement notification from the notification queue and the original message from the error queue
Error queue
CLS Member Gateway Elimination Project workshop – 12 November 2013

39. MI Channel Reception side – error flow5
reception Queue 1 2
Alliance Gateway
MI Channel
component 3
Non-repudiation queue
MQ client
MI Channel 1
Back-Office application 4
SWIFTNet
Store and Forward
MI Channel component receives a batch of messages from SWIFTNet Store-and-forward
MI Channel uncompresses, unbatches, reverifies the digests of the individual messages and distributes the messages over the MQ reception queues. Messages or batches of messages that fail the signature reverification are stored in the error queue. The error queue allows CLS members to store failed messages for problem investigation. The notification reception queue receives an error notification containing a description of the error.
The signature of the entire batch is put into the non-repudiation queue
After all the messages are stored in their MQ queues and the signature is stored in the non-repudiation queue, then the batch is acknowledged to SWIFT store-and-forward, and the next batch is processed.
Back office retrieves successul messages from reception queues, error description in the notification queue and failed messages from the error queue
Notification queue
Error queue
CLS Member Gateway Elimination Project workshop – 12 November 2013

40. Replay Invocation Standalone SNL
swiftnet start [-g <group> | -s <subsys>] [ -F ] [ -R <argument> ]
Where :
-g <group>: optional parameter. sub-system group.
Example - mfp
-s <subsys>: optional parameter. sub-system name.
Example - Support
-F : Force Start.
-R <argument> : Replay Mode
argument - <timestamp> or< file-name>
<timestamp> format yyyy-mm-ddThh24:mi:ssZ
<file-name> - file with replay information as per interface spec.
<file-name> is the name of the replay parameters file. MI Channel subsystem will fail to start if there are no snf queues configured or if snf queues in file-name do not match the configured snf queues for this MI Channel.
<timestamp> is in UTC. MI Channel subsystem will start replay from all the configured snf queues of the MI Channel. It fails if there are no snf queues configured for this MI Channel.
Some examples: to start/resume replay:
swiftnet start -R <file-name>
swiftnet start –R <timestamp>
swiftnet start -F -R <file-name>
swiftnet start –F –R <timestamp>
SWIFT message retrieval and replay capabilities – January 2014

41. Replay File Element Type Description Replay
Required information to restart in replay mode
SnFInfo
[0..n] SnFInfo
Store-and-forward related transfer information for each queue
SnFDeliveryInfo
[1-10] SnFDeliveryInfo
Provides the delivery attempt history
SnFOutputSeq
[1] Integer
Store-and-forward output sequence number for the message retrieved within the session
SnFSessionId
[1] String
Identifies the Output Session used to deliver the message from SWIFT. Can be used in union with the OutputSeq number to verify that all messages sent can be accounted for once delivered.
SnFDeliveryTime
[1] DateTime
Time of delivery of the message in UTC
RecoveryTime
Mandatory.
The time when the customer is sure that all traffic has been replicated up to the last OSN gap when all the messages in the batch have been processed.
SWIFT message retrieval and replay capabilities – January 2014