Overview of Message Retrieval capabilities on SWIFTNet

Transcription

1 of Message Retrieval capabilities on SWIFTNet V September 2013 As of 2014, SWIFT is offering several ways to retrieve messages that were received through a store-and-forward service. This paper outlines different retrieval capabilities, their characteristics and the context in which they can be used. The retrieval options available via a SWIFTNet Store and Forward interface: Message retrieval a generic solution for messages that were received during the last 124 days. Similarly to FIN, it supports a number of retrieval parameters to select the message(s) to be retrieved (service, time range, sequence numbers,...). Retrieved messages are delivered to a store-and-forward queue and are marked as "retrieved". Short-term bulk retrieval this service can help to "fill the gap" of missing messages, in a scenario where data is asynchronously replicated to another site and an uncontrolled switch to that site was performed, resulting in data loss. The retrieved traffic is bundled in files that are delivered to a store-and-forward queue. It contains all traffic received for all services since a certain point in time. The retrieval option available via the MI Channel: Message replay a specific mechanism that allows replaying messages as of a certain (recent) moment in time. The replayed messages can be easily processed by the back-office and requires very little integration work. This option is available only to customers that use the MI Channel. These are members of a Market Infrastructure that has decided to support this messaging channel. The replay is performed through the MI Channel and is specific for the service. The following sections discuss each option in more details, and a summary table is provided at the end. of Message Retrieval capabilities on SWIFTNet September 2013 Page 1

2 Message retrieval An archival/retrieval service can help customers in the following scenarios: Recovery of lost SWIFTNet messages following a disaster involving the customer's SWIFTNet interface. Recovery of lost SWIFTNet messages following a technical failure at the user site, such as data corruption or loss of internal archives. This option is available via a standard SWIFTNet Store and Forward interface. It is not available through the MI Channel. SWIFT provides an on-line retrieval service for InterAct store-and-forward messages. With this new service, all users will be able to retrieve live InterAct store-and-forward messages sent or received during the previous 124 days (4 days for pilot and ITB traffic). Requesting a retrieval: Customers will be able to choose between triggering a retrieval request from a browse screen (through the SWIFTNet Online Operations Manager), or submitting a retrieval request using a new system message. Optionally, a retrieval report can be requested, which identifies potential exceptions during the retrieval process. Retrieval processing: Because SWIFT processes retrieval requests in the background, there may be some time between the submission of the retrieval request and the availability of the retrieved messages. Receiving retrieval results: Retrieved messages are queued to the queue specified in the retrieval request. While they are delivered just like other storeand-forward messages, they are clearly marked as "retrieved message". The optional retrieval report is also queued to the same queue. If no messages match the retrieval request criteria, then no messages are queued, except if the retrieval report was requested, in which case the report will indicate that the result set was empty (or an error occurred). A single retrieval request can span at most a period of 24 hours. The available selection criteria include unique reference or time range, and input or output sequence range. Additional criteria include service, sender, receiver, request type, user reference and SNL. Customers, who want to benefit from this new feature, need a compatible version of their messaging interface, because support for a specific store-and-forward protocol version is required. This is also to ensure that the messaging interface can clearly distinguish between treatment of normal store-and-forward traffic compared to retrieved messages. It is the customer's responsibility to further process the retrieved messages (for example, to re-build or complete a local archive). Specification is available. The feature will be made available early of Message Retrieval capabilities on SWIFTNet September 2013 Page 2

3 Short-Term Bulk Retrieval This is typically useful for users who run systems that use asynchronous replication between sites. In such cases, an unexpected site switchover may result in some loss of information that was not yet replicated. The short-term retrieval service can help to "fill the gap" in such a scenario by retrieving the recently sent or received store-andforward Users can request the retrieval online by means of a system message request. SWIFT then delivers the corresponding bulk file (or files) through FileAct store-andforward. This option is available via a standard SWIFTNet Store and Forward interface, which supports FileAct store-and-forward. It is not available through the MI Channel. Process The customer sends a Bulk Retrieval Request system message to SWIFT, mentioning the time range to cover, and indicating if the scope is live or pilot 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. These files contain all messages and files (for all services) sent and received via store-and-forward during the indicated timeframe. It is the customer's responsibility to un-bulk the file and further process the retrieved Subscription Customers must contact their SWIFT service manager (or SWIFT account manager) to subscribe to this feature. The subscription is done on a per-bic basis. Access control The user who sends the Bulk Retrieval Request system messages must have the SnFRetriever role on the service swift.snf.system. SWIFT provisions this role for the institution once it has subscribed to use this feature. of Message Retrieval capabilities on SWIFTNet September 2013 Page 3

4 Message replay Customers using the MI Channel can benefit from a replay feature which helps in a recovery scenario where customers use asynchronous replication between sites. In case of a restart from a secondary site, and whereby not all data have been synchronised, this feature allows to receive again the messages that were successfully delivered to the primary site but were not yet copied to the secondary site. This option is only available through the MI Channel. It is not available via a standard SWIFTNet Store and Forward interface. The MI Channel offers an integrated recovery mechanism that automatically resynchronises after a failure and subsequent restart. For customers using synchronous replication between their data centres, this covers both planned as well as unexpected site takeover scenarios, because the databases in both sites are always up-to-date. For customers using asynchronous replication between sites, in case of an unplanned site takeover, not all data of the primary site may have been copied to the secondary site. The procedure to perform recovery is then as follows: - For traffic sent, the customer's application will need to resend with a "possible duplicate" indication, all messages for which no acknowledgement from SWIFT was received. - For traffic received, it is possible that some traffic is missing, because traffic that was received on the primary site may not fully be available at the secondary site. To cover the latter scenario, the MI Channel offers an integrated "replay" recovery feature. When activated, SWIFT will re-deliver messages in the same way as the original delivery. SWIFT also adds a "potential duplicate" indication and delivery history. This allows the secondary site to "fill the gap" by identifying and processing the missing messages, before the normal traffic exchange resumes. In order to have full control on the recovery process, users of the MI Channel trigger the "replay" feature with a start command, and provide as parameters the queue name, as well as the timestamp that indicates as of when SWIFT needs to reply the Optionally, to reduce the amount of traffic delivered, an OSN (output sequence number) can be specified together with the timestamp. In that case all traffic that was originally delivered as of the given timestamp and with an OSN higher than the one specified, will be replayed. Note: This feature of the MI Channel is specifically designed for the above-mentioned scenario (and only covers traffic received). It is not to be used to retrieve previously received messages for dispute resolution or for large retrievals for auditing or archiving purpose (in that case, a "normal" message retrieval must be used instead). of Message Retrieval capabilities on SWIFTNet September 2013 Page 4

5 of retrieval options (SWIFTNet traffic) Typical use case Message retrieval Message investigation or interface recovery Short term bulk retrieval Point-in time recovery to other site Message replay Point-in time recovery to other site Scope Any message All traffic One market infrastructure service Selection criteria Supported period Flexible (timeframe, reference, sequence numbers,...) Last 124 days, requests of messages. Timeframe Last 24 hours Timestamp or Timestamp + OSN Last 8 hours Eligibility All customers Subscribed customers Market Infrastructure customers using MI Channel Trigger mechanism Delivery mechanism Retrieved message handling Messaging services supported System message or O2M screen Message-per-message re-delivery Application required to process retrieved traffic InterAct Store and Forward System message Traffic bulked in files Application required to process retrieved files, and extract and process the needed information InterAct and FileAct Store and Forward Command line parameter Message-permessage re-delivery Easy integration, messages are redelivered as they were delivered initially InterAct Store and Forward of Message Retrieval capabilities on SWIFTNet September 2013 Page 5