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

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 – 22-23 January 2014

Agenda Overview of SWIFTNet retrieval capabilities Recovery for MI Channel SWIFT message retrieval and replay capabilities – 22-23 January 2014

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 – 22-23 January 2014

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 – 22-23 January 2014 Partner_Meeting_20090304_v1

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 – 22-23 January 2014 Partner_Meeting_20090304_v1

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 7.0.75) 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_20090304_v1

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 – 22-23 January 2014 Partner_Meeting_20090304_v1

Portfolio Evolution March 2009 Message retrieval Example system message xsys.015.001.01 Retrieval Request What information are people looking for, when responsible for SWIFT operations? [read the slide] See SWIFTNet system messages (User Handbook): https://www2.swift.com/uhbonline/books/protected/en_uk/sn_7_0_ufsm/index.htm SWIFT message retrieval and replay capabilities – 22-23 January 2014 Partner_Meeting_20090304_v1

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 – 22-23 January 2014 Partner_Meeting_20090304_v1

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 – 22-23 January 2014 Partner_Meeting_20090304_v1

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 – 22-23 January 2014 Partner_Meeting_20090304_v1

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 – 22-23 January 2014 Partner_Meeting_20090304_v1

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 10000 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 – 22-23 January 2014 Partner_Meeting_20090304_v1

Agenda Overview of SWIFTNet retrieval capabilities Recovery for MI Channel SWIFT message retrieval and replay capabilities – 22-23 January 2014

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 – 22-23 January 2014

MI Channel – Emission flow – From member to CLS 1 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 – 22-23 January 2014

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

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 – 22-23 January 2014

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 – 22-23 January 2014

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

MI Channel - Reception flow 5 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 – 22-23 January 2014

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

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 – 22-23 January 2014

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 – 22-23 January 2014

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>2014-01-22T08: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>2014-01-22T08: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>2014-01-22T08:00:01Z</SwMsg:SnFDeliveryTime> 08 … Batch 2 has not been completely received B2.Msg1 SWIFT message retrieval and replay capabilities – 22-23 January 2014

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 – 22-23 January 2014

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 – 22-23 January 2014

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 – 22-23 January 2014

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 – 22-23 January 2014

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>2014-01-22T08: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 2014-01-22T08: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 – 22-23 January 2014

. 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>2014-01-22T08: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 – 22-23 January 2014

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 – 22-23 January 2014 B4.Msg2

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 – 22-23 January 2014 * Or command line Product_portfolio_20081021_v1

Q&A SWIFT message retrieval and replay capabilities – 22-23 January 2014

Thank you SWIFT message retrieval and replay capabilities – 22-23 January 2014

Appendix SWIFT message retrieval and replay capabilities – 22-23 January 2014

MI Channel Emission side – error flow 1 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

MI Channel Reception side – error flow 5 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

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 – 22-23 January 2014

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 – 22-23 January 2014