Technical User Group. 21 luglio 2008 Palazzo Mezzanotte Milano

Transcript

1 Technical User Group 21 luglio 2008 Palazzo Mezzanotte Milano

2 TradElect - functionality, performance and capacity Mark Reece Trading System Architect London Stock Exchange 1

3 Introduction to TradElect The main characteristics of TradElect: support for Order Driven Market Models limit orders, market orders, iceberg orders, named orders, quotes Good til Time, Good til Cancelled, Fill or Kill, Execute and Eliminate, At The Open and At The Close continuous execution, auctions, quote display price/time priority anonymity for executions integrated with X-TRM and existing post-trade services. 2

4 Main technical characteristics of TradElect TradElect is the latest generation technical platform launched on 2 April Currently supports trading on the London Stock Exchange, Johannesburg Stock Exchange and Dutch Trading Service markets for equities, ETF and covered warrants. Almost unlimited processing capability (currently tps) thanks to the extreme horizontal scalability of the system; each transaction is made of independent processing units that are processed by concurrent systems. TradElect s latency is 4 times faster when compared to the current one (6 ms as opposed to 24 ms as of now). High reliability and system availability; the active-active configuration guarantees a hot recovery even in case of total unavailability of the primary site. Maximum flexibility in the configuration of the different market models. 3

5 Main characteristics of market model The main new characteristics of TradElect: the definition of tick sizes (dynamic tick) is in relation to the price of the orders entered specialists quotes (executable quotes) are not anonymous automatic activation of a volatility auction phase at the attempt to execute trades outside the price tolerance levels the new algorithm for the determination of the indicative auction price an extension of 5 minutes of the closing auction phase when the indicative price is not valid Parked Orders which allow to enter orders (in auction and continuous trading phase) with a deferred validity asynchronous messaging. 4

6 Main characteristics of market model and the main functions on Affari that will not be available: the validation of the price of orders with respect to the control price the cross order functionality the cancellation of principal versus principal trades executed by the same participant the definition of tick sizes in relation to the reference prices of the previous trading day the anonymity of the Specialist quotes. 5

7 Main characteristics of market model Market structure Market Defines the geographical elements of a trading environment, including: - opening and closing hours - business calendar - time zone LSE Segment Defines the high level characteristics of a trading model - order/quote/hybrid model - trade reporting model - minimum/maximum order and quote sizes SET1 Sector Defines the detailed specifications of a trading model - default period schedule - price monitoring thresholds - maximum spreads FT10 Security An individual tradable instrument (ISIN). The same tradable instruments may be traded in more than one segment on TradElect - temporary period schedules VOD 6

8 Main characteristics of market model Period rules Segment Period rules for: -execution - mechanism type Defines the high level features: - valid order types - valid quote types - price monitoring parameters - automatic order deletion - valid execution combinations OBT Sector Periods Defines the trading behaviour in a time window - continuous execution - call periods - auction uncrossing - trade reporting - order management - administration OBT Security Period extensions Additional periods triggered automatically by defined market situations - automatic executions suspension periods - price monitoring and - market order extensions AESP Temporary periods Security specific period schedule used after certain market situations - regulatory suspensions - Introduction of securities intra-day [xxx] 7

9 Main characteristics of market model Member structure Member ID The mandatory high level public identifier for a participant - used to identify a participant in public (broadcast) messages - used by a participant to identify its counterparty in TradElect - typically assigned to the legal entity - each member ID is associated with a unique trading mnemonic MERRILL Trader Group The mandatory private identifier for a participant - only used on private messages between the Exchange and the relevant member ID - all roles in TradElect are set at this level - could be assigned to a business unit, trading desk, or individual customer - provides business level granularity and control ML1 Trader ID The optional low level private identifier within a participant - only used on private messages between the Exchange and the relevant Trader Group - can be mandated (and validated) if required - could be assigned to individual traders, algorithms, customers - no functionality operates at Trader ID level JSMITH Role A defined set of activities that may be undertaken by an authorised Trader Group - the ability to enter orders and the use of specific order types - the ability to enter quotes and the use of specific quote types - the ability to enter trade reports and the use of specific trade types BROK 8

10 Capacity and performance TradElect has an on-going programme of technical enhancements: currently (today) it supports 4,200 messages per second with a latency of 6ms for Phase 1 of the Affari migration, it will support 7,000 messages per second with a latency of 5ms in October, it is planned to reduce latency further to 3ms, with an expected rise in messages per second further capacity will be added in Release 4 (December 2008 ready for Affari Phase 2 migration) and Release 5 this is in addition to functional enhancements at those releases. 9

11 Performance optimisation Depending on your trading patterns, there are ways to optimise the performance you experience. Once network latency and the latency of your systems up to the measurement point is taken into account, you should experience latency similar to 6ms. This may not be the case for a number of reasons: on TradElect, as capacity is reached, latency will rise, therefore, it may be that you are trading at busy periods alternatively, it may be the rate at which you are sending orders. 10

12 Performance optimisation TradElect supports multiple connections: minimum connection to TradElect is a single USAP with a single connection each connection can run at up to approx 600 messages per second if this is not sufficient or you are seeing latency, consider using multiple connections up to 4 are permitted per USAP, giving an aggregate of approx 2,400 messages per second note: connections share Session Keys. 11

13 Performance optimisation TradElect supports multiple USAPs per Trader Group. Each USAP has to pass through a common layer of the TradElect architecture to implement duplicate processing correctly. Throughput is approx 3,000 messages per second. Since 4 connections can run up to about 2,400 messages per second, the USAP is not the limit. However, if the capacity of 4 connections does not meet your requirements, then you can request additional USAPs. Note: multiple USAPs require independently managed Session Keys. 12

14 Performance optimisation TradElect system throttling When a connection runs above a certain rate, it will be throttled. This is to protect the system when it is being overloaded by incoming messages. The throttle is based on the number of in-flight messages as the system reaches 4,200 messages per second, latency will rise, ultimately triggering the throttle. Throttling works by stopping reading from connections and relying on TCP/IP to apply back-pressure to your systems. You may see sends block and you should ensure that your application will continue to receive messages. 13

15 Performance optimisation Nagelling Critical: Make sure Nagelling is switched off since this will severely increase latency. Congestion on the lines supporting TCP/IP will delay the delivery of your trading responses. 14

16 Migrazione del mercato MTA alla piattaforma di negoziazione TradElect Stato di avanzamento Simona Cervi Head of Clients Services BIt Systems 15

17 Introduzione Come anticipato nella presentazione del 7 febbraio 2008, nel corso di questi mesi sono state effettuate le seguenti attività: Predisposizione dell ambiente di avviamento CDS per Tradelect, Infolect e MDF- DDM Plus Spedizione delle KEKs per accesso all ambiente CDS a tutti i clienti (operatori e ISVs) Configurazione degli USAPs di trading a delle utenze di informativa Predisposizione dell ambiente di Conformance Test per Tradelect ed Infolect Schedulazione ed esecuzione dei conformance test per Tradelect, Infolect e MDF- DDM Plus 16

18 Conformance test TradElect Eseguiti con successo il 50% dei conformance test previsti Il rimanente 50% verrà eseguito entro la metà di agosto MDF-DDM Plus Eseguiti con successo il 30% dei conformance test previsti Ulteriore 40% verrà eseguito entro il 31 luglio Il rimanente 30% verrà ultimato entro il 31 agosto Infolect Per la partenza di MTA su Tradelect non sono previsti conformance test di clienti italiani su Infolect 17

19 Configurazione di produzione propedeutica al collaudo di settembre Il Member id (6 caratteri) assegnato ad ogni cliente è composto da: IT + codice Ced Ad ogni cliente è stato attribuito di default un Trader Group (11 caratteri alfanumerici) che è così composto: MA + codice Ced (= 5 campi liberi che possono essere modificati su richiesta del cliente) Per Operatori Specialist è stato assegnato un Trader Group aggiuntivo che consentirà di identificare l attività svolta per ottemperare a tali obblighi. Per ciascun cliente è stato generato lo stesso numero di user attualmente utilizzato per negoziare in produzione su MTA; il rapporto GAM AMI user/usap generato è pertanto pari a 1. Sono già state generate le KEKs per la produzione (3 per USAP) che verranno distribuite alla fine della presentazione. 18

20 Prossimi passi 11 agosto: integrazione di X-TRM alla piattaforma Tradelect su CDS Inizio settembre: test di connettività in ambiente di produzione. Al fine di poter verificare la corretta login al sistema di negoziazione Tradelect, Vi invitiamo a farci pervenire il risultato ottenuto dal calcolo delle KEKs entro il mese di agosto. Settembre: sessioni di collaudo obbligatorie in ambiente di produzione così organizzate: Test di connettivià (una sessione) Test funzionali (due sessioni) Migrazione (ultima sessione) 19

21 Contatti Per qualsiasi informazione potete contattare BIt Systems: Clients Services: 02/ Technical Support Desk: 20

22 Migrazione Affari: fase 1 aggiornamento sul Post trading Simone D'Ippolito Regulation and Post Trading Borsa Italiana S.p.A 21

23 I Trader Group e i riflessi sul post-trading Sul punto si ricorda come il Regolamento del mercato, in fase di approvazione da parte della CONSOB, prevede che: gli operatori possono configurare il proprio accesso al mercato utilizzando codici di accesso diversi (Trader Groups). A tal fine, gli stessi operatori devono preventivamente prendere contatti con Borsa Italiana (tramite BIt Club - Membership); qualora nello svolgimento delle attività di controllo individui situazioni o comportamenti che possono comportare rischi per l integrità del mercato, Borsa Italiana può richiedere all operatore di segregare specifiche attività di negoziazione tramite i Trader Groups; gli operatori devono comunicare a Borsa Italiana l elenco degli addetti che possono chiedere la cancellazione delle proposte, in caso di disfunzioni tecniche dei propri sistemi, per ciascun Trader Group utilizzato. Nei servizi di post-trading l implementazione della suddetta configurazione sarà gestita in due fasi, come descritto nelle slide successive. 22

24 I Trader Group e i riflessi sul post-trading FASE 1 (partenza migrazione): L utilizzo dei Trader Groups non ha riflessi sul posttrading, consentendo la segregazione dell operatività dell intermediario soltanto a livello di trading MEMBER ID Trading TG 1 TG 2 TG n X-TRM e CC&G COD SIA (CED) (ABI e BIC opzionali) GCM Express II COD SIA (CED) (ABI e BIC opzionali) Conto liquidazione 23

25 I Trader Group e i riflessi sul post-trading FASE 2: L utilizzo dei Trader Groups consente la segregazione dell operatività dell intermediario sia a livello di trading sia a livello del post-trading MEMBER ID Trading TG 1 TG 2 TG n X-TRM e CC&G COD SIA (CED) (ABI e BIC opzionali) COD SIA (CED) (ABI e BIC opzionali) GCM Express II COD SIA (CED) (ABI e BIC opzionali) COD SIA (CED) (ABI e BIC opzionali) Conti liquidazione/ Liquidatore 24

26 I Trader Group e i riflessi sul post-trading Al fine di fornire un quadro completo dell informativa relativa ad un partecipante aderente al mercato, si riporta la seguente tabella che illustra i dettagli disponibili su TradElect: 25

27 Infolect/MDF-DDM Plus: integration update and Accredited Proximity Hosting Ollie Cadman Product Manager, Real Time Data London Stock Exchange 26

28 Agenda Data feed integration update background feedback summary bandwidth management reliability flexibility of data subscriptions commercials timescales support Accredited Proximity Hosting 27

29 Background Following the merger, our vision is to create a bridge between London and Milan through a single technology platform that enables customers to access a deeper pool of liquidity and take advantage of new trading and investment opportunities. The migration of MTA and Expandi to our world-leading trading system, TradElect in September this year will be the first major step in this integration process. During the first half of 2009 an enriched version of Infolect will become the single information delivery mechanism for both Borsa Italiana and London Stock Exchange market data, taking us a step closer to achieving our vision. It is our intention to bring together the most valued functionality of each feed to this single information system and we have consulted with customers over the last three months to understand which existing MDF-DDM Plus features should be retained. 28

30 Infolect Service Channels Infolect is the Exchange s low latency market data system, publishing real time full depth order and trade information in only 2ms. Launched in September 2005 Infolect is built on next generation technology, providing a flexible, scalable platform which is one of the fastest market data systems in the world. Infolect publishes market data as a series of Service Channels, which are logically grouped. A Service Channel will publish a series of fixed width messages on a specific multicast IP address. 29

31 Feedback summary In summary, customer feedback indicated that the following areas of the existing DDM Plus service were important and needed to be supported on the combined Infolect feed: management of bandwidth reliability flexibility of data subscriptions. The Group has ensured the new enhanced Infolect will meet all of these requirements. Each enhancement is discussed in more detail on the following slides. 30

32 Bandwidth management Infolect will be enhanced with a new snapshot service, compressed using FAST to ensure customers extract the most from existing bandwidths. For each existing Italian market new Service Channels will be introduced providing a choice of 5, 10 and 20 depth shots of each instrument, either aggregated or non-aggregated. The new channels will be calculated twice a second, published in multicast and compressed in FAST. Infolect currently publishes market data in Multicast rather than TCP. As a protocol, TCP does not deliver any saving on bandwidth in comparison to Multicast. Although TCP is able to manage the level of data transmitted on a connection, in order to deliver market data in a timely manner, the bandwidth requirements for a TCP feed would mirror those of a multicast feed. 31

33 Reliability Infolect ensures reliable message transmission through the use of the rerequest service, which allows customers to request the re-transmission of any message across a dedicated TCP connection. Customer feedback indicated reliability was a key benefit of TCP as it guarantees delivery. With the correct bandwidth and network configuration multicast will offer an equivalent level of service. The interactive service allows customers to re-request missed messages, identified through a gap in unique sequence numbers, via a dedicated TCP connection across all channels and services. 32

34 Flexibility of data subscriptions The configuration for the new snapshot services will be set at an appropriately granular structure to allow customers to select which feeds they receive and therefore which instruments they receive price updates on. Each group will contain a subset of instruments for each particular market, allowing customers to further define the price updates they receive. These groups will be generic and will not be possible to configure for a particular user. This is a future Infolect enhancement that is currently being considered and feedback is welcome. We are keen to work with customers to ensure the correct and most efficient structure is implemented for the snapshot channels. 33

35 Key commercial points Phase 1 September 2008 There will be no change to the products offered via the MDF/DDM Plus platform. MTA and Expandi data will continue to be available. Customers can elect to receive MTA and Expandi market data via new services on Infolect. If you choose this option you will be bound to similar terms and conditions to the existing Infolect agreement and have to account for and report data usage. Phase 2 H All customers will be required to sign a new contract as well as account for and report data usage via the new integrated feed. 34

36 Migration time line Sept 08 Q Q Q Publish Service & Technical Description Testing DDM DDM Plus/MDF Infolect Enriched Infolect Migrated markets available via Infolect. All Italian markets available via MDF/DDM Plus One integrated feed based on Infolect, will include IDEM 35

37 Support The Group will support customers through each step of the migration: regular updates will be provided at the Technical User Groups your technical and primary account managers will be available to offer support and answer any questions/queries a full Service and Technical Description will be published to detail the new services all existing services on Infolect are described in detail in the Technical Specifications published by the Group. 36

38 Accredited Proximity Hosting For those customers who wish to host their systems in London, the Exchange plans to accredit proximity hosting provider sites. This will be particularly relevant for those customers based overseas wishing to reduce latency, or looking for flexibility/scalability of a hosted facility. For the lowest latency offering, Accredited Proximity Hosting customers are advised to subscribe to Infolect for their market data. 37

39 Potential Accredited Proximity Hosting providers The Exchange will accredit those hosting providers in London that comply with our selection criteria, based on site location, space, power, cooling, connectivity, BCP, support etc. Full details are available in our accreditation document. We are in discussions with these and other potential accredited hosting providers in London and we will provide details of these companies to you as soon as they have been approved. 38

40 Accredited Proximity Hosting The commercial model is currently in discussion with potential providers and customers Details of accredited providers will be published on the Group s websites and in relevant supporting literature. Those customers with latency sensitive trading strategies interested in Accredited Proximity Hosting should contact their primary or technical account manager to discuss the services available in more detail. 39

41 FIX interface for TradElect Stuart English Technical Account Manager, Client Technology Group London Stock Exchange 40

42 Contents Background why FIX? Optional FIX trading interface for TradElect Benefits of using FIX FIX version 5.0 Core design decisions Next steps and timescales 41

43 Objectives of this presentation today The aim of this presentation today is to introduce you to the main aspects concerning the introduction of an optional FIX interface for trading on TradElect, and in particular: why we are introducing this protocol for trading connectivity to TradElect to share with you some of the key core design decisions that have been made and explain functional differences between the current fixed width protocol provide you with detail on next steps and future timescales. 42

44 Why FIX? The Financial Information exchange Protocol is a messaging standard developed specifically for the real-time electronic exchange of securities transactions. A FIX Global Survey conducted by TowerGroup at the end of last year announced that 75% of buy-side and 80% of sell-side firms interviewed use FIX for electronic trading, and that both groups plan to focus substantial efforts on expanding their FIX usage in Source: FIX Protocol Limited website Features: de-facto messaging standard for pre-trade and trade communication globally within the equity markets supports Straight-Through-Processing (STP) from Indication-of-Interest (IOI) to Allocations and Confirmations supports other asset classes eg fixed income and derivative markets. 43

45 Optional FIX trading interface The availability of an optional FIX trading interface would translate messages into our common message format at the input gateway of our system. TradElect TradElect Existing Existing Exchange Exchange Fixed Fixed Width Width Interface Interface FIX FIX Interface Interface Exchange network Fixed Width Interface Fixed Width Interface Vendor Vendor Order Order Routing Routing Systems Systems FIX Interface FIX Interface Fixed Width Interface Fixed Width Interface Host Host to to Host Host Customers Customers Vendor Network Vendor Vendor Access Access Customers Customers FIX Interface FIX Interface FIX-Compliant FIX-Compliant Host Host to to Host Host Customers Customers 44

46 What are the benefits of using the FIX interface? The main benefits for using the FIX interface for trading on TradElect: performance improvement our goal is for the FIX interface to match the performance of the current fixed width interface and give us the flexibility to make further performance gains by introducing efficiencies within our trade processing cycle access to our markets will be easier for clients as the FIX messaging protocol has been adopted as the industry standard reduce clients costs for both initial access and ongoing support by removing the need to code to an underlying message structure (facilitates STP) clear published interfaces making use of open standards rich product support (more order types, more asset classes to trade). 45

47 FIX version 5.0 We will adopt FIX version 5.0 as this is best placed to support existing trading functionality and multi-asset access. Key points: FIX 5.0 has been developed with additional functionality that allows FIX to be used more effectively between participants and Exchanges, eg: improved quotation models improved trade capture models and MiFID trade reporting support multiple fills on an execution mass cancels. Richer product support eg increased support for pegged orders. Message structure aligned with ISO for handoff to downstream processing eg parties block for settlement details. 46

48 Core design decisions The main core design decisions for the FIX interface on TradElect: Functional compatibility our goal is for system functionality to remain backward compatible where possible, ie order handling will behave as per today eg a modification that takes an order quantity below zero will equate to a cancel. Recovery model under normal circumstances message recovery and resends will be managed by the FIX session. In the event of a cross site failure FIX sessions will be closed and all open orders removed. Security identification the 4 way key will be populated into a single security identifier field (tag 48) on transactional message flows. USAP COMPID relationship one USAP can have many COMPIDs. Each TCP session will be identified by a COMPID. Participant hierarchy will remain the same. 47

49 Core design decisions cont. Hubbing interface will not act as a hub or an order router. Private order code will be replaced with CliOrdID and OrigClOrdID and assigned by the client. Participant identification Member ID, Trader Group and Trader ID will be carried in the parties repeating group. Security the use of MAC keys will no longer be required. An alternative based on TLS and IP SEC will be available. Participants decide on level of security required. Order types all supported including both cash and CFD. Order handling functionality remains the same, eg acknowledgements will include execution information (unless there is no immediate execution). 48

50 Key dates all dates are indicative and subject to confirmation Q Service and Technical documentation Q Go live July 08 Technical User Group Q CDS available 49

51 50 Q&A