User Guide & Implementation Guidelines for using the Transaction Delivery Agent (TDA) 3.0

Transcription

1 Using SWIFTNet to communicate with the Deriv/SERV system at DTCC User Guide & Implementation Guidelines for using the Transaction Delivery Agent (TDA) 3.0 Version 2.0 August 2009 Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 1

2 Table of contents 1. Introduction Technical infrastructure design Ordering and subscription processes Registering your institution for Deriv/SERV Subscribing to the Deriv/SERV services on SWIFTNet Ordering TDA TDA installation and configuration guidelines Installation prerequisites TDA installation procedure...9 Re-license SWIFTAlliance Gateway...10 Create the TDA message partner on SAG...10 Create the TDA endpoint on SAG...10 Download the TDA application certificate onto SAG...11 Install and configure Remote API on the TDA machine...11 Configure your firewall(s)...11 Install TDA...11 Configure TDA...12 Prepare TDA to run for the first time Testing Deriv/SERV through SWIFTNet Verifying the end-to-end configuration Deriv/SERV application level testing with DTCC Failure scenarios Disaster recovery testing Problem Escalation and Customer Support...15 Appendix A References...16 Appendix B Sample TDA configuration file...16 Appendix E XML Declaration Statement...18 Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 2

3 Preface Objective The purpose of this document is to provide an overview of the steps and processes involved in establishing connectivity to DTCC s Deriv/SERV system through SWIFTNet. Its objective is to guide you through the preparation, implementation and testing of both the Transaction Delivery Agent (TDA) and the Deriv/SERV application. Intended Audience This document is intended for all members of the implementation team of an institution that wants to establish connectivity to Deriv/SERV through SWIFTNet. It covers project management, ordering, installation and implementation aspects of accessing Deriv/SERV through SWIFTNet. Assumptions and Pre-requisites This document assumes that the Deriv/SERV participant is already a member of SWIFT, has connectivity to the SWIFTNet environment and is using the SWIFTAlliance Gateway software component. Should this not be the case, please contact your SWIFT account manager, consult for more information or send an to derivserv@swift.com. The document also assumes that readers have a high-level understanding of both Deriv/SERV and SWIFTNet. Terminology and Abbreviations The following terms and abbreviations are used throughout this document: CUG DN MQ PKI RAHA SAG SNL SO TDA Closed User Group x.500 Distinguished Name WebSphere MQ Public Key Infrastructure Remote API Host Adapter SWIFTAlliance Gateway SWIFTNet Link SWIFTNet Security Officer Transaction Delivery Agent Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 3

4 Participant, DTCC and SWIFT Roles and Responsibilities To ensure a smooth installation and activation process for the Deriv/SERV service on SWIFTNet, it is important to understand the roles and responsibilities of the different parties involved. As a participant to DTCC s Deriv/SERV system, you will mainly be responsible for - the required requests to DTCC for activation on Deriv/SERV; - the required requests to SWIFT for activation on the relevant SWIFTNet services; - the design of your technical infrastructure to access Deriv/SERV through SWIFTNet; - all aspects of your WebSphere MQ environment; - the installation and configuration of SWIFT s Transaction Delivery Agent software component; - the generation of the relevant FpML messages for submission to the Deriv/SERV system. (Information on the Deriv/SERV message formats can be found on derivserv.dtcc.com.) - the processing capabilities for the relevant incoming FpML messages, sent to you by the Deriv/SERV application. (Information on the Deriv/SERV message formats can be found on derivserv.dtcc.com.) - the testing of your Deriv/SERV infrastructure prior to go-live, according to your institutions best practices for application and connectivity testing. Testing may include failure scenarios or disaster recovery testing, in accordance with your Business Continuity Planning (BCP) requirements. DTCC will - activate you on the Deriv/SERV system, if appropriate, and approve your request for activation on the relevant SWIFTNet Deriv/SERV services; - assist you on all implementation aspects that relate directly to the Deriv/SERV system (e.g. by answering queries on the FpML message formats); - perform initial connectivity tests with you to ensure messages can be exchanged in both directions between your TDA environment and the DTCC s TDA; - perform Deriv/SERV application level testing with you prior to go-live; - assist in your disaster recovery testing. SWIFT s role is to - activate you in the relevant SWIFTNet Closed User Group environments for Deriv/SERV, provided DTCC approves your subscription requests; - assist you on all implementation aspects that relate to SWIFT s products and services, including the installation and configuration of the TDA software component; - address any questions you may have on the set-up of your SWIFTNet infrastructure to access the Deriv/SERV environment; - provide you with the transport services for your FpML messages to and from Deriv/SERV. Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 4

5 1. Introduction DTCC Deriv/SERV automates the post-trade processing of over-the-counter (OTC) derivatives, bringing greater operational efficiency, lower cost and risk management to the market. Deriv/SERV s matching and confirmation service electronically processes a wide range of OTC credit, interest rates and equity derivatives products. It also provides real-time, bilateral payment matching and netting for credit derivatives. Access to Deriv/SERV is available through different DTCC communication infrastructures: - the Internet (for participants using the browser-based interface or the spreadsheet upload functionality); - the DTCC s SMART network environment and SWIFTNet (for Deriv/SERV participants that require automated, application-to-application communication). Additional information on Deriv/SERV and the different methods to interact with the Deriv/SERV system can be found on derivserv.dtcc.com or by contacting your DTCC Relationship Manager for Deriv/SERV. This document will discuss access to Deriv/SERV through SWIFTNet. Note that this communication method only supports automated, application-to-application communication with Deriv/SERV. It does not allow use of the browser-based interface or spreadsheet uploads. Deriv/SERV through SWIFTNet uses the SWIFTNet InterAct messaging service to transport messages from a participant s SWIFTNet infrastructure to DTCC and back. Transactions are performed in real-time, on a message-per-message basis and secured with SWIFTNet s Public Key Infrastructure (PKI). The messages transported over SWIFTNet are FpML messages, for which the relevant schemas and sample messages are available in the Participants Section of derivserv.dtcc.com. FpML (Financial product Markup Language) is the industry s standard protocol for complex financial products and brings processing efficiency to the OTC derivatives post-trading processes. Deriv/SERV participants that want to use SWIFTNet as a messaging channel to DTCC will need to implement SWIFT s Transaction Delivery Agent (TDA) software component. TDA is an application that runs on SWIFTAlliance Gateway (SAG) and that offers guaranteed once-andonly-once delivery of messages over the SWIFTNet environment. It interfaces with your internal application through IBM s WebSphere MQ product, while communicating to SWIFTAlliance Gateway through the Remote API Host Adapter (RAHA). Additional information on TDA can be found in the relevant SWIFT documentation and further in this document. Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 5

6 2. Technical infrastructure design As already indicated in the Preface, this document assumes your institution is a SWIFT member and already has a SWIFTNet infrastructure in place, including SWIFTNet connectivity components, the mandatory SWIFTNet Link software component and SWIFTAlliance Gateway. Should this not be the case, please contact your local SWIFT account manager or consult for more information and the contact details of the nearest SWIFT representative office. When designing your technical infrastructure to access Deriv/SERV through SWIFTNet, the main decisions that you will need to take relate to - the set-up of your WebSphere MQ environment. Following are some aspects to consider: the location of your Queue Manager; the naming convention for your WebSphere MQ queues; the resilience of your WebSphere MQ environment. Note that TDA 3.0 supports the use of WebSphere MQ queues that are part of a cluster; the security of your WebSphere MQ environment. Note that TDA 3.0 supports the use of SSL on Queue Managers and WebSphere MQ queues. - the location of the TDA component in your SWIFTNet environment. TDA communicates with SWIFTAlliance Gateway by using the Remote API software component. As a consequence, TDA can be installed on the same host as the SAG or TDA can run on a separate machine, different from the host running the SAG software. TDA is not a heavy software application. It does not consume a lot of resources of a machine and can therefore typically be added to an existing SAG environment without performance impact. The advantage of installing TDA on an existing SAG environment is clearly that no additional hardware needs to be purchased and that all installation pre-requisites for TDA should already be met. The advantages of installing TDA on a separate host are: TDA can be located outside the DMZ; the communication between TDA and SAG can be limited to a single port, thereby limiting the communication from the DMZ into your internal network environment; TDA can use its automatic failover capability in case the SAG it connects to encounters an issue or in case of connectivity issues towards SWIFTNet. In addition, security and resilience aspects will need to be taken into account for TDA as well. These will be discussed in more detail throughout this document. Any questions you may have about the design of your SWIFTNet infrastructure should be discussed with your local SWIFT technical representative. Alternatively, you can contact your local SWIFT Customer Service Centres. Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 6

7 3. Ordering and subscription processes 3.1 Registering your institution for Deriv/SERV Signing up as a user of Deriv/SERV is coordinated through DTCC s Relationship Management and Implementations departments. Agreements can be printed out through the Deriv/SERV website. - The Deriv/SERV website can be accessed through derivserv.dtcc.com. - Select the Membership section. - Print out the membership package. - Complete and send the original documents to DTCC s Implementation group, as indicated. Should you require any assistance in this process, please do not hesitate to contact a relationship manager, by clicking on Relationship Manager. Fill out the form and a DTCC Relationship Manager will be assigned to your account and will contact you. 3.2 Subscribing to the Deriv/SERV services on SWIFTNet Your institution will need to be activated in the Deriv/SERV Closed User Group environments on SWIFTNet. To request activation, you will be required to subscribe to the following services: - dtcc.otc.derivserv for the Deriv/SERV production (live) service; - dtcc.otc.derivserv!p for the Deriv/SERV pilot (test) service. As a registered SWIFT.COM user complete the relevant SWIFTNet Service Subscription forms, please access or, more specifically, the Joining a Market Infrastructure page. - In the list presented to you on the Joining a Market Infrastructure page, subscribe to both services listed above. Note that you will have to complete 2 SWIFTNet Service Subscription forms, i.e. one form for the Test service and a one Live service. - In the SWIFTNet Service Subscription page, complete the following details: select your Preferred implementation date. Note that activations on SWIFTNet will always be performed during a weekend. The earliest possible date you can select is the second weekend from the date you are completing the form; in the SWIFTNet Closed User Group Information section, accept the default values listed, which are based on your BIC8 and the Deriv/SERV Closed User Group specifications. Use of the Advanced option is not required; in the Traffic routing for real time services section, indicate the SNL IDs of the systems you will use for the specific Deriv/SERV environments you are Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 7

8 registering for (i.e. the test or the production service). The Routing end point should be ok. The Advanced option is not required. After completing all details in the form, verify and confirm your order. SWIFT will validate the content of your order and forward it to DTCC for approval. Once DTCC has approved your request to join the Deriv/SERV service on SWIFTNet, you can be activated. The activation process typically takes 2 weeks from the time you ve completed the SWIFTNet Service Subscription forms 3.3 Ordering TDA As indicated in Section 1 Introduction, participants that want to access Deriv/SERV through SWIFTNet need to implement SWIFT s TDA software component. Though TDA is a separate application that runs in combination with SWIFTAlliance Gateway (SAG), it must be added to your SAG license. The following ordering procedure will ensure you receive new passwords for SWIFTAlliance Gateway and will be able to install and run the Transaction Delivery Agent: - go to - access the Ordering section for Existing customers ; - in the SWIFTAlliance section, select Change SWIFTAlliance Gateway ; - select the version of SAG you would like to order TDA for; - in the page Change SWIFTAlliance Gateway Configuration, complete the mandatory fields (most of these will not require any specific input). In the System Configuration section, select to Add TDA in the Agent type drop-down menu; - should you decide to run TDA on a separate host, you will need the Remote API Host Adapter (RAHA) in your SAG license. In case RAHA is not part of your existing SAG license, select Add RAHA from the Host Adapter type drop-down list; - complete the remaining mandatory fields, verify and confirm your order. SWIFT will validate the content of your order, update your SAG license and send the new SAG passwords to your SWIFTNet Security Officers. It typically takes 2 weeks to receive updated passwords from the moment you have submitted your order. A CD-ROM containing TDA 3.0 software will be shipped to you. Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 8

9 4. TDA installation and configuration guidelines This section provides a high-level overview of the steps involved in the installation and configuration of your TDA. It refers to the corresponding documentation for additional details, if required. 4.1 Installation prerequisites The installation pre-requisites for TDA are listed at the beginning of Chapter 2 Installing TDA of the TDA 3.0 Installation and Operations Guide. Refer to TDA Release Letter 3.0 for the system requirements. Should you decide to install TDA on a separate machine, please verify the platforms on which this SWIFT software component is supported. Before starting the TDA installation process, it is recommended to configure your WebSphere MQ environment, including a WebSphere MQ Client on the host where TDA will be installed. For Websphere MQ Queue configuration details refer to Chapter 1.7 of the TDA 3.0 Installation and Operations Guide. 4.2 TDA installation procedure The following tasks will need to be performed and will be discussed in this section: - re-license your SWIFTAlliance Gateway(s); - create the TDA message partner on your SWIFTAlliance Gateway(s); - create the TDA endpoint on your SWIFTAlliance Gateway(s); - download the required SWIFTNet PKI application certificate(s) for TDA onto your SWIFTAlliance Gateway(s); - install and configure the Remote API software component on the machine where you intend to install and operate TDA; - if you intend to run TDA on a separate machine (i.e. a different host than where your SWIFTAlliance Gateway is running), configure your firewall to allow communication between the TDA machine and the SAG; - install TDA; - configure TDA; - prepare TDA to run for the first time. Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 9

10 Re-license SWIFTAlliance Gateway You should collect the new SWIFTAlliance Gateway passwords from your SWIFTNet Security Officers (each will have received only one part of the passwords). The procedure to re-license SWIFTAlliance Gateway is explained in the SWIFTAlliance Gateway Installation Guide - chapter 4 for SWIFTAlliance Gateway 6.x Important note: Please note that you need the SWIFTAlliance Gateway software CD-ROM to perform the re-licensing steps. Create the TDA message partner on SAG Every application that wants to communicate with SWIFTAlliance Gateway needs to be defined as a Message Partner. Follow the steps explained in Chapter 3.1 of the TDA 3.0 Installation and Operations Guide A message partner needs to be defined on each SWIFTAlliance Gateway that TDA will communicate with. Repeat the steps to define a SAG message partner with the same name on multiple systems if needed. Note down the name of the SAG message partner you have defined, as you will need this information to complete the TDA configuration file. Create the TDA endpoint on SAG In order to allow SWIFTAlliance Gateway to deliver incoming Deriv/SERV traffic to your TDA environment, an endpoint needs to be defined on every SAG that will communicate with TDA. Follow the steps explained in section 3.3 of the TDA 3.0 Installation and Operations Guide Use the following details in the Routing tab: - Service Name complete one of the following Deriv/SERV service names, as appropriate: for the production service Service Name = dtcc.otc.derivserv for the test service Service Name = dtcc.otc.derivserv!p In the Destination tab, insert the following details Interface Application Interface Application Your Message Partner (as defined previously) Mode Relaxed Cryptographic Protocol Automatic Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 10

11 Download the TDA application certificate onto SAG You can follow the procedures explained in Chapter 3.4 of the TDA 3.0 Installation and Operations Guide. As a first step, your Security Officers need to create the certificates that will be used by TDA. The Security Officers must set the certificates up for certification and provide you with the relevant Reference Number and Authorisation Code to be able to download these certificates onto the SAG, as explained in the sections referenced above. It is important to note down the Distinguished Name of the certificate(s) you have just created, as you will require this information when completing the TDA configuration file. Install and configure Remote API on the TDA machine Follow the procedure as explained in the SWIFTAlliance Gateway Remote API Installation Guide, which you can find on the SWIFTAlliance Gateway CD-ROM. The installation wizard will guide you through the installation and configuration process. If you are installing TDA on a separate machine, note down the Remote API communication port you are selecting during the installation process. This port is by default set to Important notes: Even if TDA will run on the same machine as your SWIFTAlliance Gateway, you need to install the Remote API software component. If your TDA environment will need to connect to multiple SWIFTAlliance Gateways, only one instance of the Remote API component software needs to be installed on the machine where TDA will run. To configure RA for this specific environment, please consult Chapter of the SWIFTAlliance Gateway Remote API Operations Guide. Configure your firewall(s) This step is only required if you will install TDA on a separate system from your SWIFTAlliance Gateway and have a firewall between the two systems. You need to ensure that communication between the Remote API component on the TDA machine and SWIFTAlliance Gateway is allowed. This communication uses the Remote API port you have specified in the Remote API installation (see previous step). Please ensure communication between TDA and all SAGs concerned is enabled. Install TDA Refer to chapter 2 of the TDA 3.0 Installation and Operations Guide. Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 11

12 Configure TDA Before starting TDA, you will have to complete the TDA configuration file. All parameters of this XML configuration file are explained in chapter 4 of the TDA 3.0 Installation and Operations Guide. You can request the electronic version of this configuration file by sending an to derivserv@swift.com. SWIFT is available to assist you in fine-tuning the specific aspects of the TDA configuration. Prepare TDA to run for the first time When preparing TDA to start for the first time, do not forget to follow the procedure listed in chapter 6 of the TDA 3.0 Installation and Operations Guide. The TDA instance lock record must be created and TDA must be started in verbose mode, to create the semaphore records for the emission queue(s) you have created. Once you have brought up TDA with a valid XML configuration file, you are ready to start testing your SWIFTNet infrastructure for Deriv/SERV. Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 12

13 5. Testing Deriv/SERV through SWIFTNet Three distinct testing phases can be identified for your implementation of connectivity to Deriv/SERV through SWIFTNet: - establishing successful connectivity with DTCC; - Deriv/SERV application level testing; - failure and recovery testing scenarios. 5.1 Verifying the end-to-end configuration A successful message exchange between the participant s infrastructure and DTCC via SWIFTNet proves that the TDA configuration files, central SWIFTNet routing rules, WebSphere MQ queue and channel definitions, the SWIFTNet PKI security and the internal firewalls at both your site and at DTCC have been configured correctly. The following steps can be used to test your end-to-end connectivity with DTCC: - act as a sender of messages to DTCC. Generate a message and put the message on your emission queue to DTCC (e.g. by using a small utility program). The message should be picked up by TDA and sent to DTCC, where it should arrive on DTCC s reception queue for you as a Deriv/SERV participant. Once the message has been removed from the emission queue by TDA and no errors or warnings have been generated, you can confirm with DTCC that your message has been transferred successfully; - act as a receiver of messages from DTCC. DTCC will generate a message and put it on your emission queue. The message should appear on the reception queue you have defined for receiving traffic from DTCC. To initiate these simple connectivity tests and verify the end-to-end configuration to send messages to and receive messages from DTCC, please contact the Participant Interface Planning team at DTCC: - from North America (888) option 1 option 5 - from outside North America by pip@dtcc.com 5.2 Deriv/SERV application level testing with DTCC Please contact DTCC s Deriv/SERV client services group to coordinate testing with the Deriv/SERV system. The exact procedure to exchange messages with the Deriv/SERV system will be provided by the Deriv/SERV client services group. - From North America (888) option 3 - From outside North America Deriv/SERV through SWIFTNet User Guide Version 2.0 August 2009 Page 13

14 - By 5.3 Failure scenarios DTCC recommends performing a minimum set of tests to ensure your Deriv/SERV through SWIFTNet environment is capable of handling certain problematic situations. For Troubleshooting, refer to Chapter 12 of the TDA 3.0 Installation and Operations Guide. Below is a short overview of the minimum recommended tests: - ensure your application is able to handle messages rejected by TDA. Note also that messages will only be moved to the defined Error Queue if they are too large to be handled by SWIFTNet InterAct or when their XML format is invalid. Testing should ensure your sending application is capable of handling these situations; - testing of connectivity issues. Several types of connectivity issues can be identified: the correspondent you are trying to reach is not available. Note that when TDA is unable to reach a certain correspondent, it will automatically try to re-send the message a number of times (as typically specified in the DefaultRetryCount parameter of the TDA configuration file). If still unable to reach the correspondent after the defined number of retries, TDA will stop processing messages to this correspondent. You may decide to use scripts to re-start the relevant emission queue in this case. Check the TDA Installation and Operations Guide for more information about the command syntax of the tdacmd utility. your connectivity to SWIFTNet fails or similarly, your SWIFTAlliance Gateway environment encounters an issue. In case you have configured the TDA configuration file to use multiple SWIFTAlliance Gateway environments (in the SagConnection sections of the TDA configuration file), TDA should automatically and transparently redirect your outgoing traffic through the secondary (or alternate) SAG. Note that once TDA has re-directed its outgoing traffic, it will not automatically switch back to the primary SAG environment when it becomes operational again. You will have to perform a controlled fallback by TDA to the primary environment once you have verified that this environment is running to your satisfaction again. In case you start a backup TDA instance connected to another SWIFTAlliance Gateway, this backup TDA instance can re-use the same TDA configuration file as your primary TDA instance, as TDA doesn t store any specific messaging data and the TDA configuration file contains all information required for TDA to work. The backup TDA instance will need to have access to all defined WebSphere MQ queues. The Instance Lock Queue will ensure only one TDA instance will have access to emission queues that are in use, even if several TDA instances would be started by accident. In both cases you will have to re-direct the incoming TDA traffic to the alternate SNL environment you have defined in your SWIFT MRR routing rules for the Deriv/SERV service. This reroute procedure is explained in the SWIFTAlliance WebStation 6.0 User Guide, chapter 6 Using the Message Routing Module and in the SWIFTNet Admin Services: Operational Interface Guide that is available on the SWIFTNet Link Deriv/SERV through SWIFTNet User Guide Version 1.5 May 2007 Page 14

15 software CD-ROM. - testing of WebSphere MQ failures and recovery scenarios. Special care should be taken to evaluate the manual synchronisation procedure that will be required in case the content of the different working queues would be removed or in case the queues themselves would be deleted. Check the Re-synchronising procedures in the TDA Installation and Operations Guide. Contact the SWIFT Support Helpdesk for further technical assistance. The contact details can be found on /support. 5.4 Disaster recovery testing DTC encourages all users of this service to conduct annual disaster recovery testing from an alternate processing site. To coordinate this testing, please contact DTCC s Participant Interface Planning (PIP) group: - from North America (888) option 1 option 5 - from outside North America by pip@dtcc.com 5.5 Problem Escalation and Customer Support If, for any reason, there is a problem with your SWIFT DTCC functionality after the connection is established you may contact DTCC at the numbers below for problem troubleshooting. - from North America (888) option 1 option 3 - from outside North America by pip@dtcc.com Deriv/SERV through SWIFTNet User Guide Version 1.5 May 2007 Page 15

16 Appendix A References References to the following documents were made in this User Guide: - SWIFTAlliance Gateway Remote API Installation Guide - SWIFTAlliance Gateway Remote API Operations Guide - SWIFTNet Admin Services: Operational Interface - SWIFTAlliance WebStation User Guide - TDA 3.0 Installation and Operations Guide - TDA 3.0 Release Letter Appendix B Sample TDA configuration file Refer to Chapter 4 of the TDA 3.0 Installation and Operations Guide. You can request an XML version of the configuration file below by sending an to derivserv@swift.com. Appendix C WebSphere MQ naming convention example Each Deriv/SERV participant will have naming conventions that are unique to their own internal environment and setup. For your information, DTCC s naming convention is outlined below and can be used as a guideline (typically in case you do not have a WebSphere MQ naming convention at this point). Using the same convention for corresponding MQ queue names can facilitate the support communication. - The different emission and reception queues are application-specific queues. In DTCC s environment, they are prefixed by DER, which identifies the Deriv/SERV application. A specific emission queue and a specific reception queue need to be created for each correspondent. DTCC s naming convention for these queues are: DER.TDA.AAAABBCC.EQ.Q01 DER.TDA.AAAABBCC.RQ.Q01 The DER prefix identifies the application software. TDA identifies the systems software. AAAABBCC is the relevant participant s BIC code. EQ stands for emission queue, RQ stands for reception queue. The Q01 suffix identifies a local queue. Deriv/SERV through SWIFTNet User Guide Version 1.5 May 2007 Page 16

17 - The emission working queue and reception working queue are TDA s internal system queues. They are absolutely critical for the correct functioning of TDA and their integrity (and that of the messages in these queues) should be guaranteed at all times. In DTCC s environment, these queues have been prefixed by TDA to differentiate them from the emission and reception queues, which are application queues. This leads to the following names of the Emission Working Queues and Reception Working Queues: TDA.DER.DTCCUS33.EWQ TDA.DER.DTCCUS33.RWQ The TDA prefix identifies these as TDA systems queue. DER identifies the application, Deriv/SERV. DTCCUS33 is DTCC s BIC code, which should be replaced by your own BIC code. EWQ stands for emission working queue, RWQ stands for reception working queue. - The error queue follows the same basic naming convention of the emission and reception queues. In the above example, it is: DER.TDA.AAAABBCC.ERROR The ERROR suffix identifies the usage of this specific queue. - The rescue queue is not referenced in the TDA configuration file, but is used in the resetqueue command. It follows the same basic naming convention as the emission and reception queues. In DTCC s set-up, it is called: DER.TDA.AAAABBCC.RESCUE The RESCUE suffix identifies the usage of the queue. Deriv/SERV through SWIFTNet User Guide Version 1.5 May 2007 Page 17

18 Appendix E XML Declaration Statement TDA uses the SWIFTNet InterAct messaging service to exchange messages with correspondents. An InterAct message is an XML document. With TDA however, it is possible to send non-xml formatted messages. The TDA Optimized parameter defines whether TDA has to 'base64 encode the messages into an XML document before sending them over SWIFTNet. Two situations can occur: - if the Optimized parameter in the TDA configuration file is set to false (default value), TDA will always encode the message; - if the Optimized parameter is set to true, then TDA will not encode the message. If the message is not a valid XML document, the message is moved to the Error queue and TDA stops sending from that Emission queue. Encoding increases the message data by 30%. An XML document can start with an XML declaration statement, e.g. <?xml version = "1.0" encoding = "UTF-8">. Such a declaration must be the first line of the XML document. The XML document provided by the application to TDA is put in the payload element of the InterAct message and as such it cannot contain an XML declaration statement. If it contains the XML declaration statement, TDA will treat the message as a non-valid XML document and the message will be moved to the Error queue, unless the Optimised parameter is set to false, as explained above. The FpML standards, as well as our sample documentation, include the XML declaration statement. However, to prevent all messages being encoded in this manner the following must be done: - confirm with DTCC that you will send and receive FpML messages without an XML declaration statement; - set the Optimized parameter to true; - for the message flow from DTCC to you: if your XML parser needs the XML declaration statement, add it before passing the message to the application; - for the message flow from you to DTCC: remove the declaration statement before putting the message in the Emission queue. Deriv/SERV through SWIFTNet User Guide Version 1.5 May 2007 Page 18