LSEHub FIX Network. Technical Guide

Transcription

1 LSEHub FIX Network Technical Guide

2

3 Contents 1.0 Introduction Service Access Static test harness 18 Customer to customer testing Network access Service enablement Technical enablement process LSEHub enablement environments Service hours Key Features Appendices Appendix 1: Network access Appendix 2: Rejection Mapping Appendix 3: Test Harness Buy Appendix 4: Test Harness Sell Appendix 5: Message Header Mapping Appendix 6: FIX Message Schema Enablement of message types 7 Message routing 7 Network status messages 10 Initiation of logon 11 Store and Forward Testing requirements FIX Live Connectivity Test (FCON) 12 FIX Connectivity Testing process Message Interface Specification FIX Routing tags 14 FIX 4.2 Messages 14 FIX 4.4 Messages 14 Message validation Customised message flow FIX Interface version conversion 15 Message pre-processor Additional Test Services Dynamic execution test harness 17

4 1.0 Introduction London Stock Exchange has leveraged its existing infrastructure to provide a service to the wider FIX community which takes advantage of our experience in delivering and maintaining state of the art, highly reliable trading systems for the whole UK market. In order to continually improve the service the LSEHub has a dedicated product team assigned to the management, development of the Hub and ancillary services. The LSEHub is a FIX message routing service combining the benefits of a hub with the flexibility of a direct connection. It has been introduced to provide a single FIX connection to multiple global liquidity pools, including customers not previously accessed electronically. The Hub allows customers to agree bilateral business relationships to exchange FIX 4.2 and a range of FIX 4.4 messages. This gives control over who they receive messages from as well as the ability to target messages to multiple counterparties based on their CompID over a single FIX session. 2.0 Service Access 2.1 Network access Customers can connect directly to the LSEHub through a selection of networks or via partner hubs Network connectivity options Direct connectivity to the LSEHub is currently available via London Stock Exchange (Extranex, Hosting & CMC), BT Radianz, TNS and Verizon VPN and the IPC Connexus Network (Please see Appendix 1). Extranex access to the LSEHub is via an address range allocated by London Stock Exchange as part of the enablement process. Further details on how the Extranex service is provided are available at the following address: For IPC Connexus, BT Radianz, and TNS users, this will also be allocated by the provider. Customers using Extranex can either use the native addressing scheme or use their devices to translate to and from the allocated addresses. To discuss your connectivity options or other functional queries please contact your Technical Account Manager, at +44 (0) or at londontam@lseg.com Partner hubs Customers can choose to connect via partner hubs that are already connected to the LSEHub and can be the intermediary (virtual) participants between the end customer and the Hub. For further details regarding our partner hubs please contact us, at +44 (0) or at lsefix@lseg.com 4

5 2.2 Service enablement In order to receive the service, customers must complete the necessary documents and return them to the Exchange for the completion of the technical enablement and business relationship creation process. The following table details the documentation that needs to be completed, and by whom: Form Purpose Completed by LSEHub Order Form and T&Cs To order access to LSEHub Customers LSEHub connection set-up details To register company contact details and the setup specifications on the connection Customers 2.3 Technical enablement process New customers are required to specify their CompIDs. CompIDs are used as the identifier of the company in the Hub. As CompIDs need to be unique on the Hub, it may not be possible to use a CompID if it has already been setup on the Hub. For example LSEHub and LSEGATEWAY have been reserved for Exchange use only and can not be assigned to a different customer. Customers can have multiple CompIDs assigned to them on multiple or on a single IP Address. Existing customers who wish to create a new CompID need to also complete a new questionnaire. All CompIDs used via the LSEHub are case sensitive. As part of the setup of a business relationship between two counterparties the CompIDs are communicated between the customers and are enabled on the Hub. Business relationships are initially enabled after connection to the LSEHub for both parties has been completed. In order to setup a new CompID or modify a business relationship an needs to be sent to the LSE FIX Management at lsefix@lseg.com, expressing this wish. The parties can also choose to cancel a relationship. In that case a 90-day cancellation policy applies, as documented in the LSEHub Order Form and TCs. 2.4 LSEHub enablement environments The Hub consists of two separate environments; the User Acceptance Testing (UAT) environment, sometimes also referred to as Customer Development Service (CDS) and the Production (Live) environment. The Production environment consists of two inter-connected hubs: EMEA and APAC this is to cover various time zones around the world with no service disruption during that time zones core trading hours. The CompIDs and the relevant business relationships between the customers are first enabled in the UAT/CDS environment and then in Production on the relevant time zone instance. This allows the customers to identify and solve potential errors in the process before the relationships are enabled in Production and live trading activity starts. The process for the service enablement is the same for both the live and the UAT environments. The customers need to send separate s for the enablement of their relationships in UAT and Production. 2.5 Service hours The main EMEA Production hub runs from Saturday 22:59 to the following Saturday at 03:00 excluding maintenance daily between 22:30 and 22:59 and between 03:00 on Saturday to 22:35 on Saturday. The Testing (UAT) environment availability is subject to prior arrangement but will normally occur at the same times as the production environment. The APAC Hub runs from Saturday 15:29 to Friday 15:00 excluding maintenance daily between 15:00 and 15:29 and between 15:00 on Friday to 15:29 on Saturday. 5

6 Please see the below table for a summary of the Service Hours: Instance Start of week (SOW) End of day (EOD) Start of day (SOD) End of week (EOW) EMEA (Live) Sat@ 22: * 22:30 22:35-22:59* Sat@ 03:00 APAC (Live) Sat@ 15:05-15:29* 15:00 15:05 15:29* Fri@ 15:00 CDS (UAT) 22:35** 22:35 From 22:35** Sat@ 03:00 * The Start of Day process will occur from the earlier time where possible, but no later than the time stated ** The availability of our test environment is subject to prior arrangement but will normally occur at the times stated All times are recorded as London Time (GMT, adjusted for daylight saving) 6

7 3.0 Key Features 3.1 Enablement of message types By default, customers of the LSEHub are enabled for all the FIX 4.2 messages except for the Network Status messages (Please see Appendix 6a for a description of the enabled messages). Customers who do not want to receive specific messages can request their disablement via the FIX Helpdesk at any point in time. This removes the overhead of receiving unwanted messages and allows customers to define the messages that they don t want to be delivered to them. For example where a customer does not want to receive IOIs, the Hub will not send these messages to the customer even if it receives any of these messages designated for the customer. When a customer sends a message that they are not enabled for, the LSEHub will reject the message with the appropriate FIX application rejection message (see Appendix 2: Rejection message type mapping). 3.2 Message routing The LSEHub routes messages from one customer to another specified customer. The messages can be routed directly from one customer to another via the LSEHub standing in between or can be directed via a partner hub to the LSEHub and then to the end customer. During this process the LSEHub transforms the message headers to populate the necessary tags and forward the message to the respective customer. The LSEHub routes only business level messages. Session level messages are not routed and are restricted to the session; i.e Logons, Hearbeats, Test-Requests etc are never routed across the LSEHub. The primary routing tags are the following: Tags Field name Required Comments 49 SenderCompID YES 56 TargetCompID YES 115 OnbehalfOfCompID DEPENDS ON SCENARIO 128 DeliverToCompID DEPENDS ON SCENARIO This should be populated by the sender of the message. This should be populated with LSEHub or LSEGATEWAY depending on which LSE hub is being used. This will denote the original sending customer when routed on by the LSEHub. This will denote the final destinations of the message. This tag is mandatory in the Standard Message Header for all messages except for IOI, News, and custom Network Status messages. It is also mandatory in Advertisement messages. The possible routing scenarios and the respective tags that are generated are described in the following three sub- sections. Every single message in and out of the LSEHub will be classed as one of these four scenarios with no exception. A full list of tag mappings can be found in Appendix 5. Tags in the following table are mandatory for that scenario and leg. N/A shows that particular tag should not be included for that scenario leg. 7

8 3.2.1 Participant to participant routing This is the simplest setup in terms of routing and required tags. Both the participants are directly connected via the LSEHub. Scenario 1: Participant to Participant routing Customer A Leg A LSEHub / LSE GATEWAY Leg B Customer B Tags Leg A Leg B 49 (Sender CompID) Customer A LSEHub 56 (Target CompID) LSEHub Customer B 128 (DeliverToCompID) Customer B [Blank] 115 (OnBehalfOfCompID) [Blank] Customer A Participant to Hub routing Scenario 2: Hub/Virtual- Participant Customer A Leg A LSEHub / LSE GATEWAY Leg B Partner Hub Customer B Tags Leg A Leg B 49 (Sender CompID) Partner Hub A LSEHub 56 (Target CompID) LSEHub Partner Hub B 128 (DeliverToCompID) Customer B Customer B 115 (OnBehalfOfCompID) Customer A Customer A 8

9 3.2.3 Hub to participant routing In this setup, inbound messages are received from the Partner hub and the LSE forwards directly to the Participant. Scenario 3: Hub/Virtual-Participant to Participant Customer A Partner Hub Leg A LSEHub / LSE GATEWAY Leg B Customer B Tags Leg A Leg B 49 (Sender CompID) Partner Hub LSEHub 56 (Target CompID) LSEHub Customer B 128 (DeliverToCompID) Customer B N/A 115 (OnBehalfOfCompID) Customer A Customer A Hub-to-Hub Routing This is the most complex setup involving at least 3 hubs: LSEHub and two Partner hubs. Scenario 4: Hub/Virtual- Participant to Hub/Virtual - Participant Customer A Partner Hub A Leg A LSEHub / LSE GATEWAY Leg B Partner Hub B Customer B Tags Leg A Leg B 49 (Sender CompID) Partner Hub A LSEHub 56 (Target CompID) LSEHub Partner Hub B 128 (DeliverToCompID) Customer B Customer B 115 (OneBehalfOfCompID) Customer A Customer C 9

10 3.3 Network status messages A key feature of the LSEHub is to provide Network Status Management for all customers. These messages are generated automatically by the Hub and provide customers with information about the connection status of all of their counterparties. This is achieved either through the use of a custom FIX message. The custom FIX message method is based on the FIX 4.4 Network Status message which is sent to all customers who have elected to receive it and details the connection status of all counterparties with whom they have a relationship. Each time the connection status of counterparty changes an updated message will be sent. At the time of initial logon a customer receives a single message summarising the connection status of all their counterparties. At the End of Business all customers are disconnected from the LSEHub and as such Network Status messages will not be generated to inform other customer of these disconnections. All customers should assume that all other LSEHub users are updated to disconnected when End of Business is reached. Customers can also use the custom FIX message Network Status Request to enquire about the current connection status of all customers with whom they have a valid business relationship. In response to a Network Status Request message and also following successful logon to the LSEHub (if the customer is enabled to receive this message type) the customer will receive a Network Status Response) message. The following tables describe the Network Status Request message: Tag Field Name Required Comments 35 Standard Header Yes MsgType = BC 6800 NetworkRequestType Yes Must be set to 1 (i.e. Snapshot) 6801 NetworkRequestID Yes Standard Trailer Yes Tag Field Name Required Comments 35 Standard Header Yes MsgType = BD 6802 NetworkResponseType Yes Valid values: 1=Full 2=Incremental 6801 NetworkRequestID No 6803 NetworkResponseID Yes 6804 NoCompIDs Yes Specifies the number of repeating CompID s 6805 RefCompID No 6806 StatusValue No CompID that status is being report for. Required if NoCompIDs > 0 Valid Values: 1=Connected 3=Not Connected 4=In Process Standard Trailer Yes In addition to support for Network Status messages, the LSEHub provides a web-interface for those customers that do not support the custom Network Status messages. This offers a centrally accessible visual representation of the connection status of all counterparties with whom the viewing customer has a valid business relationship. The portal also allows customers to view IOI (Indication Of Interest)Target Lists which are setup and maintained on request by the Exchange. All customers will be provided with a valid username and password to access this screen which will be assigned by the Exchange as part of the enablement process. 10

11 3.4 Initiation of logon A Customer of the LSEHub can act as either the Initiator or the Acceptor. Where the Customer is defined as the initiator, logon and logout is done by the customers. This provides flexibility regarding the Start and End of Business and allows customers to use multiple IP addresses. We recommend that customers choose to act as Initiators of the session as that gives the customer more control over the session and eliminates the possibility of errors and the exchange of unwanted messages. Where the Customer acts as the Acceptor, the Hub will act as initiator and will log on to the customers by Start of Business and logout at End of Business. It also maintains connections and attempts to reconnect in the event of a connection being lost. Where the Hub initiates the session and the customer accepts the session, the LSEHub will attempt a TCP session and FIX logon every 60 seconds between Start of Day and End of Day. In order for a session sequence numbers to be re-set to 1 for the next day, customer FIX engines that are still connected at the End of Business should respond appropriately to the Logout messages issued by the LSEHub at this time. 3.5 Store and Forward Each customer on the LSEHub can request that messages are stored and forwarded in the event that a connection with another customer is dropped and messages are not delivered. These messages will be stored by the LSEHub and forwarded when the receiving customer s connection is re-established. For example, if the target participant is logged off and messages are being sent, the LSEHub can place the undelivered messages into the Store & Forward Cache and route them once the customers is logged on. This is happening at a standard rate so as not to overwhelm the customer. The Store & Forward function makes use of an extra temporary queue to distinct between the new and the stored messages waiting for the stored messages to be delivered first thus retaining the correct message sequence. Store and Forward functionality can be enabled for specific message types for each customer. For example Customer A may want execution reports stored and forwarded but not IOIs whereas Customer B may not want any messages stored. A standard rejection message will be sent for any message type not configured for Store and Forward while the customer is logged out. The amount of time a message is stored for is also configurable by a customer on a message by message basis. Once this time period has elapsed the appropriate rejection message is returned to the sender Store and Forward default settings Message Type Description Stored by Default 8 Execution Report Yes 9 Order Cancel Reject Yes j Business Message Reject Yes Q Don t Know Trade Yes J Allocation Yes P Allocation Ack Yes D New Order Single No E New Order List No F Order Cancel Request No G Order Cancel Replace Request [Mod] No BC Network Status Request No BD Network Status Response No 11

12 4.0 Testing requirements Upon completion of the service enablement, new customers that wish to connect directly to the Hub will be required to demonstrate that their LSEHub applications can connect successfully by undertaking a FIX Live Connectivity Test (FCON). This test is designed to give customers the opportunity to resolve any network or application level issues with direct Exchange and Third-Party Network support. An FCON test is required when a customer is connecting via a new IP source to the LSEHub production environment. FCON tests are not required for customers when: 1) connecting via a Hub as the Hub has already completed these tests. 2) Existing customers adding a new CompID to an existing production IP range. Once a new or existing customer is advised that the set up of their CompID is complete for UAT they are able to access this immediately with no further testing. However, for any code changes to the application directly interfacing with the LSEHub, customers should contact LSE Fix management (lsefix@lseg.com) and confirm they have successfully connected in UAT before rolling out the updated application to their production connections. FCON tests are not required for customers connecting via a Hub as the Hub has already completed these tests. Also excepted are existing customers adding a new CompID to production, they will only have to carry out a test if undertaking system changes then a FCT/FCON may be required. Once a new or existing customer is advised that the set up of their CompID is complete for UAT they are able to access this immediately with no further testing. 4.1 FIX Live Connectivity Test (FCON) The FCON is designed to demonstrate that customers can connect to the Production LSEHub service without any issues that may impact the live service. For Production a simple FCON test is required.as outlined below: Initiator - If the customer is an initiator then upon completion of the service enablement, the customer will be advised and requested to perform a telnet test. The customer can complete the telnet at their convenience and at any point during the live service hours of the LSEHub. The customer should confirm a successful telnet to the Market Access team marketaccess@lseg.com who will then enable the CompID and confirm back to the customer when the connection will be live. Acceptor - If the customer is an acceptor connection then once the service enablement is completed, the Market Access team will perform a telnet test to verify connectivity is good. Prior to the enablement completion and telnet, customers should confirm to Market Access if/when routing changes will be required/completed on the customer side ready for the FCON. This telnet test will be initiated by London Stock Exchange. 4.2 FIX Connectivity Testing process The following sections show the steps required for the FCON, distinguishing between customers that are Initiators and customers that are Acceptors. 12

13 Step Initiator Participant Activity Responsibility 1. TCP 3-way handshake initiated Customer 2. TCP 3-way handshake completes Customer and LSEHub 3. FIX Logon sent to LSE Customer 4. FIX Logon [acknowledgement] sent to Customer LSEHub 5. FIX Heartbeat message exchanged in both directions Customer or LSEHub (depending on which system responds first after the heartbeat timer fires) 6. Logoff message sent Customer 7. Logoff acknowledgement sent LSEHub 8. TCP session closes Step Acceptor Participant Activity Responsibility 1. TCP 3-way handshake initiated LSEHub 2. TCP 3-way handshake completes LSEHub and Customers 3. FIX Logon sent to Customer LSEHub 4. FIX Logon [acknowledgement] sent to LSE Customer 5. FIX Heartbeat message exchanged in both directions Customer or LSEHub (depending on which system responds first after the heartbeat timer fires) 6. Logoff message sent Customer 7. Logoff acknowledgement sent LSEHub 8. TCP session closes 5.0 Message Interface Specification The LSEHub currently supports the following FIX versions: All FIX 4.2 messages A selection of FIX 4.4 messages, with the ability to add more FIX 4.4 messages on request. A selection of FIX 4.4 messages posing in a FIX 4.2 header. 13

14 5.1 FIX Routing tags As both the LSEHubs (EMEA and APAC) are primarily routing hubs, some tags are mandatory for use with hubs and the nexthop topology. Tag Field Name Comments 49 SenderCompID Always populated with Sender. When sent outbound by LSE this will be LSEHub or LSEGATEWAY depending on instance. 56 TargetCompID Always populated with Target. When sent inbound to the LSE by a Participant of Partner Hub this should always be LSEHub or LSEGATEWAY depending on instance. 115 OnBehalfOfCompID This will denote the original sending customer when routed on by the LSEHub 128 DeliverToCompID This tag is mandatory in the Standard message Header for all messages except for IOI, News, and custom Network Status messages. It is also mandatory in Advertisement messages 215 NoRoutingIDs When used in IOI, News and messages this field is mandatory and the DeliverToCompID will not be processed. 216 Routing Type When used in IOI, News and messages this field is mandatory and the DeliverToCompID will not be processed. Also Blocking Lists are not supported 217 RoutingID When used in IOI, News and messages this field is mandatory and the DeliverToCompID will not be processed. 5.2 FIX 4.2 Messages The FIX 4.2 technical specifications are available from the following addresses: The LSEHub s support all FIX.4.2 message types. A full of the supported messages can be found in Appendix FIX 4.4 Messages The LSEHub originally and primarily supports FIX 4.2 messages. In order to offer extended functionality the Hub was enhanced to additionally support a subset of FIX 4.4 message types. These can be found in Appendix: FIX.4.4 Application/Business Layer Messages. 5.4 Message validation The content of a FIX message received by the Hub is only checked to ensure it is correctly formed, to get routing information and check business relationships no further data is validated within the message. 14

15 As per the FIX4.2 protocol the LSEHub rejects inbound messages that fail business level validation with the appropriate reject message type. For example a New Single Order is rejected with an Execution Report detailing the reason for rejection. Additionally inbound messages that fail session-level validation are rejected with a Reject message. For example a custom Network Status Request message that fails business level validation will be rejected with a Business Message Reject. Where a destination customer is not logged on an error message will be sent to the sending customer except for multicast messages such as IOIs, News or . Business message rejects can be returned to customers by the LSEHub to indicate that business level validation failure has occurred. However these messages can also be sent to the LSEHub to be routed to another customer. Where this is the case the message content will not be updated. Where an incoming broadcast-type message (i.e. Indication of Interest, News or ) specifies multiple destination customers and only a sub-set of destination customers pass business level validation, a single Business Message Reject is returned to the sending customer detailing the reason(s) for each validation failure. The original inbound message is forwarded on to those destination customers that pass business level validation. A table showing the Rejection Message Type mappings is attached in Appendix Customised message flow The LSEHub contains all the functional requirements to accommodate the use of custom tags for its customers. The custom tags can be assigned different functions for different participants depending on the requirements of the customers at both ends. This increased functionality is particularly designed to fit customer requirements which can include high frequency and algorithmic trading. The available ranges of custom tags and their definition as internally or externally used are described below: : External custom use & registered with FIX Protocol Limited : Internal custom use : External custom use Please note that the range is registered for internal use only by London Stock Exchange and cannot be used by external corporations. For further details regarding the custom tags are provided in the following addresses: and, FIX Interface version conversion The LSEHub can implement a conversion internally and on the FIX engine interface. Using this implementation allows FIX.4.2 to be sent in a FIX.4.4 header, and the FIX.4.2 messages to be sent in FIX.4.4 header. 6.2 Message pre-processor The LSEHub contains a dynamic message pre-processor, designed to perform ad-hoc, manipulative instructions on the FIX messages, based upon each message matching a predefined key. 15

16 6.2.1 Predefined key The predefined key is the means the pre-processor uses to select whether to perform instruction(s) on a particular message. The key can be very broad, or extremely granular. Please see the following table for examples of keys: Key Granularity Description 49=LSEHub 49=LSEHub 56=CustomerA 49=CustomerA 56=LSEHub 49=LSEHub 56=CustomerA 35=D 49=LSEHub 56=CustomerA 35=D 11=* 49=LSEHub 56=CustomerA 35=D 11=ABC1234 Very broad Broad Broad Fine Very fine Extremely fine Key matches all messages leaving the LSEHub as 49=LSEHub appears in every message sent by LSE. Key matches all messages leaving the LSEHub that are being sent to CustomerA. Key matches all messages arriving at the LSEHub that are being sent from CustomerA. Key matches all messages being sent from LSEHub to CustomerA that are of Message Type: NewOrderSingle Key matches all messages being sent from LSEHub to CustomerA that are of Message Type: NewOrderSingle and where ClOrdID exists. Key matches all messages being sent from LSEHub to CustomerA that are of Message Type: NewOrderSingle with a Customer Order ID of ABC1234 The key can consist of any integer value for the tag component, and one of the following modifiers for the value component: Key Value Modifier Absent Exact Match Wildcard Description The specified field must not be present within the message. The value of this element of the key must match exactly the value specified. (The field must be present in the message.) The value of this element can be anything, but it must be present in the message Pre-processing Instructions Once a key is matched to a message, one or more configured instructions are performed on the message using one or more of the following verbs: 16

17 Verb ADD CONCAT COPY MOVE REMOVE REPLACE Description Adds the specified tag with the value supplied to the message Concatenates the values of two source tags and places the result into the destination tag Copies the value from the source tag into the destination tag (NB Arg3 is ignored if the destination is already present in the message) Copies the value from the source tag into the destination tag and removes the source tag (NB Arg3 is ignored if the destination is already present in the message) Removes the specified tag from the message Replaces the value of the specified tag with the value supplied Pre-processor example The following an example of how the LSE FIX Pre-processor can be used: Key: 49=LSEHub 56=CustomerA 35=D Instructions: REPLACE tag 15 (Current) with GBX ADD tag 1 (Account) TestAccount This Key and Instruction set will work on all NewOrderSingle message from LSE to CustomerA, replacing Tag 15 (Currency) with GBX and at the same time adding Tag 1 (Account) with a value of TestAccount. Please note the Instruction tags do not need appear in the Key as they are separate entities. The Key is to match the message; the instruction(s) are the functions to perform on the matched messages. 7.0 Additional Test Services The LSEHub includes a number of services to assist in the implementation of FIX 4.2 and the additional functionality offered by the LSEHub. These services provide automatic message generation and response functionality to mimic Buy-side and Sellside customers and are available over the Internet and live service networks. The service can also be used for ad-hoc testing between two or more customers of the service. These tests are available for both the EMEA and APAC hub. It is assumed that customers systems that connect to the LSEHub are able to establish and support basic FIX 4.2 sessions and exchange business messages. 7.1 Dynamic execution test harness A dynamic execution harness exists on the CDS/UAT environment with CompID: TestHarnessExecute1. This test harness accepts limit orders of any volume and price, and will dynamically file the order over a random period of time, with random prices and volumes per execution. This test harness operates between 00:00 and 22:30 each day the CDS service is operational. Buy-side Customers wishing to test against this harness should request a relationship between their CompID and TestHarnessExecute1, and then start sending limit orders. 17

18 7.2 Static test harness A static test harness exists that runs multiple CompIDs in order to reflect customer activity and the unique functionality of the LSEHub. Each section of the test service is accessed by customers registering a business relationship with one or more of the LSE Test Harness CompIDs, which generates activity for that section of the service or registering for inclusion in a test List in order to receive IOI messages. The CompIDs and IOI Lists are as follows: TestHarnessBuy1 Dummy Buy-Side generating Order messages and uses SEDOL in Tag 48 TestHarnessBuy2 Dummy Buy-Side generating Order messages and uses ISIN in Tag 48 TestHarnessSell1-5 Dummy Sell-Side customers that generate IOIs and respond to Order messages with Execution Reports TestHarnessSell1List1 List used by the dummy Sell-Side CompID to disseminate IOIs NetworkStatus1 Dummy customer that logs on/off at 5 minute intervals, generating Network Status messages for those customers with whom they have a valid business relationship. If a Customer no longer wishes to use these test services they simply need to request that their business relationship with a CompID or inclusion in a List is disabled TestHarnessBuyX: Buy-side dummy customer The Buy-side test service mimics Buy-side customer activity, using a test CompID (TestHarnessBuy1) registered on the LSEHub. This allows customers to route messages to the LSEHub Test service, and for the LSEHub Test service to send messages to customers. New Order Single messages are generated every 5 minutes, specifying a Limit Order for a single valid Tradable Instrument at a single price and size. The service attempts to send this message to each customer that the test CompID has a valid relationship with. (Please see Appendix 3 for the values included in this message). New Order Single messages are also generated in response to Indication of Interest (IOI) messages that have been routed to the test CompID. The order message is routed back to the original IOI sender, and contains fields mapped from the incoming IOI message, as well as fields containing pre-defined values (such as Order Type of 2 Limit). This allows Sell-side customers to test the processing of point-to-point (DeliverToCompID) and List (RoutingID) message routing types TestHarnessSellX: Sell-side dummy customer The Sell-side test service mimics Sell-side customer activity, using a test CompID (TestHarnessSell1) registered on the LSEHub. This allows customers to route messages to the LSEHub Test service, and for LSEHub Test service to send messages to customers. Indication of Interest messages are generated every 5 minutes, specifying a single valid Tradable Instrument at a single price and size. The service sends this message to a pre-defined List (TestHarnessSell1List1). The LSEHub then routes the IOI to each customer currently enabled for the List who is also enabled to receive IOI messages and has a business relationship with TestHarnessSell1 (Please see Appendix 4 for the values included in this message). Execution Report messages are generated in response to order messages that have been routed to the test CompID. The Execution Report message is routed back to the original Order sender, and contains fields mapped from the incoming message, as well as fields containing pre-defined values (such as Exec Type and Order Status of 2 Filled). This allows Buy-side customers to test the processing of point-to-point (DeliverToCompID) message routing types. 18

19 7.2.3 Network status test service The NetworkStatus1 CompID generates Network Status message activity by logging on to the LSEHub, waiting 5 minutes, logging off from the LSEHub, waiting 5 minutes, and then repeating this cycle. Customers that wish to test their Network Status implementation need to request that their business relationship with the Network Status CompID is enabled. This will allow them to receive the appropriate unsolicited Network Status messages each time the test service connects and disconnects from the LSEHub. The test CompID is enabled to receive all message types but does not generate any responses. This allows a customer to test the rejection processing that occurs when a destination customer disconnects from the LSEHub. 7.3 Customer to customer testing The test service (UAT) allows for customers to test between themselves using identical functionality to the live service. To facilitate this, the UAT will follow the live service hours and allow enablements to be setup in the same way as in the live environment. Therefore customers will have to complete business relationships and enablements via the FIX Helpdesk as they would for the Live service. 19

20 8.0 Appendices 8.1 Appendix 1: Network access Access to the LSEHub Production environment is provided through IPC Connexus Network, Extranex, Verizon internet VPN, BT Radianz and TNS. For the UAT environment, only, access can also be accommodated via the Internet. IP Addresses for Exchange and customer hosts are provided as part of the enablement process. Extranex customer host addresses will be in the range 10.x.x.x. For access to the Internet Test service participants will need to provide an IP address as part of the enablement process. The destination addresses for all the LSEHub services are presented in the following table: Environment Access IP Address Port EMEA Production (Live) APAC Production (Live) Testing (UAT) EMEA Production (Live) APAC Production (Live) Testing (UAT) Testing (UAT) EMEA Production (Live) APAC Production (Live) Testing (UAT) Extranex, 1Gb Optical, CMC, Hosting & IPC Extranex, 1Gb Optical, CMC, Hosting & IPC Extranex, 1Gb Optical, CMC, Hosting & IPC Verizon ivpn Verizon ivpn Verizon ivpn Internet BT Radianz BT Radianz BT Radianz

21 8.2 Appendix 2: Rejection Mapping Incoming Message MsgType Outgoing Rejection Message MsgType Indication of Interest (IOI) 6 Business Message Reject j Network Status Request BC Business Message Reject j Network Status Response BD Business Message Reject j Advertisement 7 Business Message Reject j News B Business Message Reject j C Business Message Reject j Order Cancel Reject 9 Business Message Reject j Allocation ACK P Business Message Reject j List Status N Business Message Reject j Don't Know Trade (DK) Q Business Message Reject j Settlement Instructions T Business Message Reject j Market Data-Snapshot/Full Refresh Market Data-Incremental Refresh W Business Message Reject j X Business Message Reject j Market Data Request Reject Y Business Message Reject j Quote Acknowledgment b Business Message Reject j Security Definition d Business Message Reject j Security Status f Business Message Reject j Trading Session Status h Business Message Reject J New Order - Single D Execution Report 8 Order Status Request H Execution Report 8 New Order - List E Execution Report 8 List Execute L Execution Report 8 Order Cancel Request F Order Cancel Reject 9 Order Cancel/Replace Request G Order Cancel Reject 9 List Cancel Request K Order Cancel Reject 9 Execution Report 8 Don t Know Trade (DK) Q Allocation J Allocation ACK P List Status Request M List Status N Quote Request R Quote Acknowledgment b Quote S Quote Acknowledgment b Mass Quote i Quote Acknowledgment b Quote Cancel Z Quote Acknowledgment b Quote Status Request a Quote Acknowledgment b 21

22 Incoming Message MsgType Outgoing Rejection Message MsgType Market Data Request b Market Data Request Reject Y Security Definition Request c Security Definition c Security Status Request e Security Status f Trading Session Status Request G Trading Session Status H Reject messages containing 58=SD [Session Disconnected] will be transmitted back to the sender when the destination participant is disconnected, and one of the following settings has been configured against the sender s message attributes: FixReject- reject message sent back to sender, original message will be dropped. PersistWithReject- reject message sent back to sender, original message will be added to store and forward cache for later delivery when destination participant reconnects. 22

23 8.3 Appendix 3: Test Harness Buy1 Tag Field Name Value 8 BeginString FIX BodyLength <message length> 35 MsgType D 49 SenderCompID LSEHub 56 TargetCompID <participant CompID> 115 OnBehalfOfCompID TestHarnessBuy1 34 MsgSeqNum <sequence number> 52 SendingTime <sending time UTC> 370 OnBehalfOfSendingTime <OnBehalfOfSending time UTC> 11 ClOrdID <unique identifier> 1 Account TestAccount 78 NoAllocs 0 63 SettlmntTyp 0 21 HandlInst 3 18 ExecInst MinQty NoTradingSessions 0 55 Symbol GB SecurityID IDSource SecurityExchange L 106 Issuer BARCLAYS PLC 107 SecurityDesc BARCLAYS PLC ORD 25P 54 Side 1 60 TransactTime <UTCTIME> 38 OrderQty OrdType 2 44 Price Currency GBX 58 Text Order sent by TestHarnessBuy1 10 CheckSum <checksum 23

24 8.4 Appendix 4: Test Harness Sell1 Tag Field Name Value 8 BeginString FIX BodyLength <message length> 35 MsgType 6 49 SenderCompID LSEHub 56 TargetCompID <participant CompID> 115 OnBehalfOfCompID TestHarnessSell1 34 MsgSeqNum <sequence number> 52 SendingTime <sending time UTC> 370 OnBehalfOfSendingTime <OnBehalfOfSending time UTC> 23 IOIid <unique identifier> 28 IOITransType N 55 Symbol GB SecurityID IDSource SecurityExchange L 106 Issuer VODAFONE GROUP 107 SecurityDesc VODAFONE GROUP PLC ORD SHS $ Side 2 27 IOIShares Price Currency GBX 62 ValidUntilTime <UTCTIME + 10 minutes> 25 IOIQltyInd H 130 IOINaturalFlag Y 199 NoIOIQualifiers IOIQualifier M 104 IOIQualifier L 58 Text IOI sent by TestHarnessSell1 60 TransactTime <UTCTIME> 10 CheckSum <checksum> 24

25 Scenario From To Sender CompID (49) Target CompID (56) DeliverTo CompID (128) OnBehalfOf CompID (115) Sender CompID (49) Target CompID (56) DeliverTo CompID (128) OnBehalfOf CompID (115) LSEHub Technical Guide 8.5 Appendix 5: Message Header Mapping The LSEHub application performs inbound-to-outbound mapping of header tags on each and every business level message that passes through the Hub. There is also built-in helper function to correct the message when the application spots the protocol is not being used correctly by participants. All users of the LSEHub, whether Customers or vendors/service providers/3 rd part hubs should be aware of the header mapping that takes place as per the protocol standards. For each of the mapping tables, the LSE sits between the From [Inbound] and the To [Outbound], and maps the inbound tags to the relevant outbound tags depending on the scenario (see Section 4 Message Routing). Each of the table cell values are example tag values so the inbound-to-outbound mapping can be clearly seen. A NULL indicates that the tag value should not be sent inbound to the LSEHub, and will not be sent outbound by the LSEHub. The helper function attempts to correct messages where a tag may have been sent inbound where it should ve been NULL CompID Mapping The application performs the following inbound-to-outbound mapping of CompIDs: INBOUND TO LSE OUTBOUND FROM LSE 1 Participant Participant SenderA LSEHub TargetB NULL LSEHub SenderB NULL SenderA 2 Participant Hub SenderA LSEHub TargetB NULL LSEHub HubA SenderB SenderA 3 Hub Participant HubA LSEHub TargetB SenderA LSEHub SenderB NULL SenderA 4 Hub Hub HubA LSEHub TargetB SenderA LSEHub HubB SenderB SenderA 25

26 Scenario From To Sender LocationID (142) Target LocationID (143) DeliverTo LocationID (145) OnBehalfOf LocationID (144) Sender LocationID (142) Target LocationID (143) DeliverTo LocationID (145) OnBehalfOf LocationID (144) Scenario From To Sender SubID (50) Target SubID (57) DeliverTo SubID (129) OnBehalfOf SubID (116) Sender SubID (50) Target SubID (57) DeliverTo SubID (129) OnBehalfOf SubID (116) LSEHub Technical Guide SubID Mapping The application performs the following inbound-to-outbound mapping of SubIDs: INBOUND TO LSE OUTBOUND FROM LSE 1 Participant Participant SubA NULL SubB NULL NULL SubB NULL SubA 2 Participant Hub SubA NULL SubB NULL NULL NULL SubB SubA 3 Hub Participant NULL NULL SubB SubA NULL SubB NULL SubA 4 Hub Hub NULL NULL SubB SubA NULL NULL SubB SubA LocationID Mapping The application performs the following inbound-to-outbound mapping of LocationIDs: INBOUND TO LSE OUTBOUND FROM LSE 1 Participant Participant LocA NULL LocB NULL NULL LocB NULL LocA 2 Participant Hub LocA NULL LocB NULL NULL NULL LocB LocA 3 Hub Participant NULL NULL LocB LocA NULL LocB NULL LocA 4 Hub Hub NULL NULL LocB LocA NULL NULL LocB LocA 26

27 Scenario From To SendingTime (52) OnBehalfOf SendingTime (370) SendingTime (52) OnBehalfOf SendingTime (370) LSEHub Technical Guide SendingTime Mapping The application performs the following inbound-to-outbound mapping of SendingTime: INBOUND TO LSE OUTBOUND FROM LSE 1 Participant Participant DateTime1 NULL DateTime2 DateTime1 2 Participant Hub DateTime1 NULL DateTime2 DateTime1 3 Hub Participant DateTime2 DateTime1 DateTime3 DateTime1 4 Hub Hub DateTime2 DateTime1 DateTime3 DateTime Helper Function The header mapping process also contains a helper function to aid in correct protocol use this is because flow through the LSEHub has been analysed and found to be used incorrectly by participants. The helper function aims to correct the message, in terms of SubID / LocationID / SendingTime tags, if possible. For example, destination SubID for all scenarios should be sent inbound to LSEHub in DeliverToSubID(129). This will then be mapped on the outbound session to either TargetSubID(57) for scenarios 1 & 3 where the message is being sent directly to the end participant, or mapped to DeliverToSubID(129) for scenarios 2 & 4 where the messages is being forwarded via a partner hub for onward delivery to the end participant. In many cases, participants are incorrectly sending destination SubID information inbound to the LSEHub in TargetSubID(57), rather than the expected DeliverToSubID(129). The helper function will then use TargetSubID(57) to map to the relevant outbound tag if DeliverToSubID(129) inbound does not exist. The following table describes all helper functions for correcting inbound messages: Scenario Primary Tag Secondary Tag 1 SenderSubID (50) OnBehalfOfSubID (116) 1 DeliverToSubID (129) TargetSubID (57) 1 SenderLocationID (142) OnBehalfOfLocationID (144) 1 DeliverToLocationID (145) TargetLocationID (143) 2 SenderSubID (50) OnBehalfOfSubID (116) 2 DeliverToSubID (129) TargetSubID (57) 2 SenderLocationID (142) OnBehalfOfLocationID (144) 2 DeliverToLocationID (145) TargetLocationID (143) 27

28 Scenario Primary Tag Secondary Tag 3 OnBehalfOfSubID (116) SenderSubID (50) 3 DeliverToSubID (129) TargetSubID (57) 3 OnBehalfOfLocationID (144) SenderLocationID (142) 3 DeliverToLocationID (145) TargetLocationID (143) 4 OnBehalfOfSubID (116) SenderSubID (50) 4 DeliverToSubID (129) TargetSubID (57) 4 OnBehalfOfLocationID (144) SenderLocationID (142) 4 DeliverToLocationID (145) TargetLocationID (143) The Primary tag is the correct tag to be used when sending inbound to the LSEHub. If this tag does not exist in a particular message, and the Secondary tag does exist, then the helper function will map the Secondary tag to the relevant tag on the outbound message. 28

29 8.6 Appendix 6: FIX Message Schema FIX 4.2 & FIX 4.4 Session Layer Messages Type Name Category Section Description 0 Heartbeat Session Session 1 TestRequest Session Session The Heartbeat monitors the status of the communication link and identifies when the last of a string of messages was not received. The test request message forces a heartbeat from the opposing application. 2 ResendRequest Session Session The resend request is sent by the receiving application to initiate the retransmission of messages. This function is utilized if a sequence number gap is detected, if the receiving application lost a message, or as a function of the initialization process. 3 Reject Session Session The reject message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. 4 SequenceReset Session Session 5 Logout Session Session A Logon Session Session The sequence reset message is used by the sending application to reset the incoming sequence number on the opposing side. The logout message initiates or confirms the termination of a FIX session. The logon message authenticates a user establishing a connection to a remote system FIX 4.2 Application/Business Layer Messages Type Name Category Section Description J Allocation Allocation PostTrade The Allocation message provides the ability to specify how an order or set of orders should be subdivided amongst one or more accounts. P AllocationInstructio nack Allocation PostTrade The allocation ACK message is used to acknowledge the receipt and status of an allocation message received from the institution. j BusinessMessage Reject Common Other The Business Message Reject message can reject an applicationlevel message which fulfills session-level rules and cannot be rejected via any other means. B News EventCom munication The news message is a general free format message between the broker and institution. C EventCom munication The message is similar to the format and purpose of to the News message; however, it is intended for private use between two parties. 6 IOI Indication 7 Advertisement Indication Indication of interest messages market merchandise which the broker is buying or selling in either a proprietary or agency capacity. Advertisement messages are used to announce completed transactions. V MarketDataReque st MarketData Some systems allow the transmission of real-time quote, order, trade and/or other price information on a subscription basis. W MarketDataSnaps hotfullrefresh MarketData The Market Data messages are used as the response to a Market Data Request message. X MarketDataIncrem entalrefresh MarketData The second Market Data message format is used for incremental updates. 29

30 Type Name Category Section Description Y MarketDataReque streject MarketData The Market Data Request Reject is used when the broker cannot honor the Market Data Request, due to business or technical reasons. E OrderList ProgramTra ding Trade The NewOrderList Message can be used in one of two ways depending on which market conventions are being followed. K ListCancelRequest ProgramTra ding Trade The list cancel request message type is used by institutions wishing to cancel previously submitted lists either before or during execution. L ListExecute ProgramTra ding Trade The list execute message type is used by institutions to instruct the broker to begin execution of a previously submitted list. M ListStatusRequest ProgramTra ding Trade The list status request message type is used by institutions to instruct the broker to generate status messages for a list. N ListStatus ProgramTra ding Trade The list status message is issued as the response to a List Status Request message sent in an unsolicited fashion by the sell-side. k BidRequest ProgramTra ding The BidRequest Message can be used in one of two ways depending on which market conventions are being followed. l BidResponse ProgramTra ding The Bid Response message can be used in one of two ways depending on which market conventions are being followed. In the "Non disclosed" convention the Bid Response message can be used to supply a bid based on the sector, country, index and liquidity information contained within the corresponding bid request message. See "Program/Basket/List Trading" for an example. In the "Disclosed" convention the Bid Response message can be used to supply bids based on the List Order Detail messages sent in advance of the corresponding Bid Request message. m ListStrikePrice ProgramTra ding Trade The strike price message is used to exchange strike price information for principal trades. It can also be used to exchange reference prices for agency trades. R QuoteRequest QuotationN egotiation In some markets it is the practice to request quotes from brokers prior to placement of an order. The quote request message is used for this purpose. S Quote QuotationN egotiation The quote message is used as the response to a Quote Request message and can be used to publish unsolicited quotes. Z QuoteCancel QuotationN egotiation The Quote Cancel message is used by an originator of quotes to cancel quotes. a QuoteStatusReque st QuotationN egotiation The quote status request message is used by the institution to generate an execution report that contains the quote status message back from the counterparty. b QuoteAcknowledg ement QuotationN egotiation An optional response to Quote, Mass Quote, Quote Cancel, and Quote Request message is the Quote Acknowledgement message. i MassQuote QuotationN egotiation The Mass Quote message can contain quotes for multiple securities to support applications that allow for the mass quoting of an option series. c SecurityDefinitionR equest SecurityAnd TradingSes siondefinitio norstatus The Security Definition Request message is used for the following: 1. Request a specific Security to be traded with the second party. The request security can be defined as a complex security made up of one or more underlying securities. 2. Request a list of the Security Types that can be traded with the second party. 30