Presentation is loading. Please wait.

Presentation is loading. Please wait.

SWIFT message retrieval and replay capabilities for CLS members CLS Member Gateway Elimination Project Pieter Herrebout/Damien Vanderveken/Pamela Amick.

Similar presentations


Presentation on theme: "SWIFT message retrieval and replay capabilities for CLS members CLS Member Gateway Elimination Project Pieter Herrebout/Damien Vanderveken/Pamela Amick."— Presentation transcript:

1 SWIFT message retrieval and replay capabilities for CLS members CLS Member Gateway Elimination Project Pieter Herrebout/Damien Vanderveken/Pamela Amick 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 2 SWIFT message retrieval and replay capabilities – January 2014

3 3 Agenda Overview of SWIFTNet retrieval capabilities Recovery for MI Channel

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

5 Message retrieval SWIFT message retrieval and replay capabilities – January 2014 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 traffice.g. after an interface crash Typical use 5

6 SWIFTNet message retrieval process TriggerSelectionProcessingDeliveryUse SWIFT message retrieval and replay capabilities – January 2014 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 6

7 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 Message retrieval Highlights 7

8 Message retrieval Example screen - Online Operations Manager GUI SWIFT message retrieval and replay capabilities – January

9 Message retrieval Example system message xsys Retrieval Request SWIFT message retrieval and replay capabilities – January See SWIFTNet system messages (User Handbook): https://www2.swift.com/uhbonline/books/protected/en_uk/sn_7_0_ufsm/index.htm

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

11 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

12 Message replay (with MI Channel) Overview SWIFT message retrieval and replay capabilities – January SWIFT site1site2 copy Normal traffic delivery SWIFT site1site2 Switch to site2 SWIFT site1site2 Automatically resume normal traffic delivery Activate replay

13 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

14 Comparison SWIFT message retrieval and replay capabilities – January Message retrievalShort term bulk retrieval Message replay Typical use caseMessage investigation or interface recovery Point-in time recovery to other site ScopeAny messageAll trafficOne market infrastructure service Selection criteriaFlexible (timeframe, reference, sequence numbers,...) TimeframeTimestamp or timestamp+OSN Supported periodLast 124 days, requests of messages. Last 24 hours, requests of 1 hour max Last 8 hours EligibilityAll customersSubscribed customersMarket Infrastructure customers using MI Channel Trigger mechanismSystem message or O2M screen System messageAlliance Gateway GUI (or command line) Delivery mechanismMessage-per-message re-delivery Traffic bulked in filesMessage-per-message re-delivery 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

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

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

17 MI Channel – Emission flow – From member to CLS 17 Alliance Gateway MQ client Back-Office application MI Channel component SWIFT message retrieval and replay capabilities – January 2014 Emission Queue Notification Queue Error Queue SWIFTNet Store and Forward MI Channel

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

19 Example – Identifying status of sent messages SWIFT message retrieval and replay capabilities – January ElementTypeDescription SentMessage[1] SentMessageContains resulting transfer details of the message which was attempted to be sent SentHeader[0..1] SentHeaderContains the routing information found for the message in the queue MessageRef[1] StringUnique reference of the message BatchIndex[0..1] IntegerOptional 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 [ 0..1] Integer 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[1] String “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] StringSWIFT reference of the request. Includes a trusted time stamp. TransferError[0..1] TransferErrorPresent if the Transfer Answer is not “Accepted” ErrorCode[1] StringError code of the error ErrorText[1] StringError description extract from MI Channel Interfaces Specifications

20 MyUniqueRef Accepted Example – Identifying status of sent messages SWIFT message retrieval and replay capabilities – January

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

22 MI Channel - Reception flow 22 Alliance Gateway MQ client Back-Office application MI Channel component SWIFT message retrieval and replay capabilities – January 2014 Reception Queue Non- repudiation Queue Notification Queue SWIFTNet Store and Forward Error Queue 3 MI Channel

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

24 Options to determine the replay restart point SWIFT message retrieval and replay capabilities – January Option Behaviour Pro’s Con’s Based on knowledge of the local routing, replication, queue processing, determine the point in time where all messages have been processed. Input criteria Starting time OSN & associated delivery time 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 Easy to implement More precise selection criterion hence limiting the number of duplicates and the time required to receive replayed messages. 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 CLS member application must determine, for each SnF queue, the last OSN received (without gaps) where all messages within the batch have been processed

25 Example – Identifying the replay trigger parameters – extract from MI Channel specs SWIFT message retrieval and replay capabilities – January ElementType 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[1] String Responder DN of the receiving institution Service[1] String SWIFTNet service name used when sending the original message RequestType[1] String ISO standard business request type in the format xxxx.nnn.nnn.nn MessageRef[1] String 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 [0..1] Integer 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[1] String 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[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 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

26 Identifying the replay trigger parameters SWIFT message retrieval and replay capabilities – January B1.Msg2 B1.Msg1 B2.Msg1 01 … … 05 bankbebb_clsinstrnot:d: T08:00:00Z 08 … 01 … … 05 bankbebb_clsinstrnot:d: T08:00:00Z 08 … 01 … … 05 bankbebb_clsinstrnot:d: T08:00:01Z 08 … Batch 1 has been completely received Batch 2 has not been completely received

27 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 Tentative

28 Triggering replay from Alliance Gateway SWIFT message retrieval and replay capabilities – January Tentative Cancel OK Replay for Message Flow Instance Name Help Status State SnF Queue Parameters Remove Add Edit stopped Disabled MFP File Path Use Existing File No UTC Time yyyy-mm-ddThh24:mi:ssZ Include OSN per SnF Queue No Force Start No Condition

29 Triggering replay from Alliance Gateway – option 1: file input SWIFT message retrieval and replay capabilities – January Tentative Cancel OK Replay for Message Flow Instance Name Help Status State SnF Queue Parameters Remove Add Edit stopped Disabled MFP File Path Use Existing File Yes UTC Time yyyy-mm-ddThh24:mi:ssZ Include OSN per SnF Queue No Force Start No Condition File built by CLS back office application

30 Triggering replay from Alliance Gateway – option 2: manual input 30SWIFT message retrieval and replay capabilities – January 2014 Tentative Cancel OK Replay for Message Flow Instance Name Help SnF Queue Parameters Remove Add Edit MFP File Path Use Existing File No UTC Time yyyy-mm-ddThh24:mi:ssZ Include OSN per SnF Queue No Status State stopped Disabled Force Start No Condition Parameters to be manually filled in

31 Triggering replay from Alliance Gateway – option 2 manual input – continued 31SWIFT message retrieval and replay capabilities – January 2014 Tentative Cancel OK Replay for Message Flow Instance Name Help Status SnF Queue Parameters Disabled MFP 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 No Condition 01 … … 05 bankbebb_clsinstrnot:d: T08:00:00Z 08 …

32 Triggering replay from Alliance Gateway – option 2 manual input – continued 32. SWIFT message retrieval and replay capabilities – January 2014 Tentative Cancel OK Replay for Message Flow Instance Name Help Status SnF Queue Parameters Disabled MFP File Path Use Existing File No UTC Time yyyy-mm-ddThh24:mi:ssZ Include OSN per SnF Queue Yes Remove Add Edit bankbebb_clsopdata bankbebb_clsrep bankbebb_clsinstrnot State stopped Force Start No Condition Cancel OK Edit SnF Queue Parameters Help Session Details bankbebb_clsinstrnot:d:12345 OSN queue:d:nnnnn 1 01 … … 05 bankbebb_clsinstrnot:d: T08:00:00Z 08 …

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

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

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

36 36 Thank you

37 SWIFT message retrieval and replay capabilities – January Appendix

38 MI Channel Emission side – error flow 38 Alliance Gateway MQ client Back-Office application MI Channel component CLS Member Gateway Elimination Project workshop – 12 November 2013 Emission Queue 1 Notification Queue 1 Error queue SWIFTNet Store and Forward MI Channel

39 MI Channel Reception side – error flow 39 Alliance Gateway MQ client Back-Office application MI Channel component CLS Member Gateway Elimination Project workshop – 12 November 2013 reception Queue 1 Non- repudiation queue Notification queue SWIFTNet Store and Forward 1 4 Error queue MI Channel 5 5 5

40 Replay Invocation Standalone SNL swiftnet start [-g | -s ] [ -F ] [ -R ] Where : -g : optional parameter. sub-system group. Example - mfp -s : optional parameter. sub-system name. Example - Support -F : Force Start. -R : Replay Mode argument - or format yyyy-mm-ddThh24:mi:ssZ - file with replay information as per interface spec. 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. 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 swiftnet start –R swiftnet start -F -R swiftnet start –F –R SWIFT message retrieval and replay capabilities – January

41 Replay File ElementTypeDescription Replay Required information to restart in replay mode SnFInfo[0..n] SnFInfoStore-and-forward related transfer information for each queue SnFDeliveryInfo[1-10] SnFDeliveryInfoProvides the delivery attempt history SnFOutputSeq[1] IntegerStore-and-forward output sequence number for the message retrieved within the session SnFSessionId[1] StringIdentifies 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] DateTimeTime of delivery of the message in UTC RecoveryTime[1] DateTimeMandatory. 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


Download ppt "SWIFT message retrieval and replay capabilities for CLS members CLS Member Gateway Elimination Project Pieter Herrebout/Damien Vanderveken/Pamela Amick."

Similar presentations


Ads by Google