1 / 17

Cooperative Brokerage Integration for Transaction Capacity Sharing: A Case Study in Hong Kong

Cooperative Brokerage Integration for Transaction Capacity Sharing: A Case Study in Hong Kong. Application Background. Further automation of Hong Kong Exchange and Clearing Limited (HKEX) Third Generation Automatic Order Matching and Execution System (AMS/3) Open system

nieve
Download Presentation

Cooperative Brokerage Integration for Transaction Capacity Sharing: A Case Study in Hong Kong

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Cooperative Brokerage Integration for Transaction Capacity Sharing: A Case Study in Hong Kong

  2. Application Background • Further automation of Hong Kong Exchange and Clearing Limited (HKEX) • Third Generation Automatic Order Matching and Execution System (AMS/3) • Open system • Many stock trading system developers integrate their flagship solutions such as the Broker Supplied System (BSS) for connection to HKEX

  3. System Architecture of AMS/3

  4. Open Gateway Connection Point

  5. Client Placing a Request

  6. More Advanced Emerging Requirements • Sharing very expensive trading capacity rights • Throttle rate control • Buying additional throttle rate is less expensive but on a monthly-fee basis • Improve trading order response • Hardware failure and outage • Business integration and extensibility • credit controllers, settlement officers, …

  7. Problems Motivating this Research • Communications among partners have no common standard of message protocols • No intelligent mechanisms for integration with the trading system for capacity sharing • Hard to manage the security issues using different kinds of encryption techniques. • Web services based integration for capacity sharing of partner brokerages. • Transaction Capacity Sharing System (TCSS)

  8. TCSS Overview

  9. Main TCSS Mechanism • When the request queue length exceed a certain threshold, route the request to TCSS in order to forward it to partner brokerages • Via asynchronous Web services • TCSS has to handle many outstanding orders simultaneously while the time when the orders can be fulfilled is unpredictable

  10. TCSS Intelligence and Heuristics • Outstanding backlog and forwarding threshold • Forwarding limit and cost of different brokerages • Number of partner brokerages Base on these, TCSS • adjust its forwarding threshold and forwarding limit dynamically according to its current queue length to achieve an effective flow control • send piggy-back with acknowledgements or broadcasted to partners if necessary • use such information for choosing an appropriate target of the next forwarded order • observe and honor this limit to maintain good relationship

  11. TCSS Architecture SOAP Partner Brokerage with TCSS / BSS Internet SOAP Transaction Service Web Dispatching Services and Aggregation TCP / IP BSS Application Web Services Adaptation Manager Interface ODBC TCSS Process Manager Database

  12. TCSS Protocol • Standard protocol called Financial Information eXchange (FIX) developed specifically for real-time electronic exchange of securities transactions • Adaptation Manager translates the message as FIX Markup Language (FIXML) using the FIX protocol 8=FIX.4.2;9=199;35=D;34=10;49=VENDOR;115=CUSTOMER;144=BOSTONEQ;56=BROKER; 57=DOT;143=NY;52=20000907-09:25:28;11=ORD_1;21=2;110=1000;55=EK;22=1; 48=277461109;54=1;60=20000907.09:25:56;38=5000;40=2;44=62.5; 15=HKD;47=A;10=165;

  13. <FIXML> <FIXML Message> <Header>. . .</Header> <ApplicationMessage> <Order> <CIOrdID>ORD_1</CIOrdID> <HandInst Value="2" /> <MinQty>1000</MinQty> <Instrument> <Symbol>EK</Symbol> <IDSource>1</IDSource> <SecurityID>277461109</SecurityID> </Instrument> <Side Value="1" /> <TransactTime>20000907.09:25:56</TransactTime> <OrderQuantity> <OrderQty>5000</OrderQty> </OrderQuantity> <OrderType> <LimitOrder Value="2"> <Price>62.5</Price> </LimitOrder> </OrderType> <Currency Value="HKD" /> <Rule80A Value="A" /> </Order> <ApplicationMessage> </FIXMLMessage> </FIXML> <?xml version=”1.0” encoding=”UTF-8”?> <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:SOAP-ENC=”http://schemas.xmlsoap.org/soap/encoding/” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” <SOAP-ENV:Body SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”> <sendMessage> <FIXMLMessage> <Header> <Sender> <CompID>Hopgood</CompID> </Sender> <Target> <CompID>Lloyds</CompID> </Target> </Header> <ApplicationMessage> <Indication> <IOIid>41926</IOIid> <Instrument> <Security> <Symbol>IBM</Symbol> </Security> </Instrument> <IOISide Value="1"/> <IOIShares>2000</IOIShares> <Price>30.00</Price> <Currency Value="GBP"/> <ValidUntilTime>22:50</ValidUntilTime> </Indication> </ApplicationMessage> </FIXMLMessage></sendMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> FIXML and SOAP example

  14. WS-Security • W3C security specifications • SOAP Header element to carry security-related data • XML Signature • header can contain the information defined by XML Signature that conveys how the message was signed, the key that was used, and the resulting signature value • XML Encryption • encryption information can be contained within the WS-Security header • WS-License • describes how existing digital credentials and their associated trust semantics

  15. Summary • TCSS share transaction capacity => decrease order queuing time • Avoid significant costs of buying extra trading rights, which is very expensive • Group SME brokerage together against large brokerages that have much better facilities and trading capacities • Employment of Web service technologies • Phased approach • Best for SME brokerages having multiple broker licenses • Alliance of different brokerages => legal / regulatory issues

  16. Future Work • Legal / regulatory issues • Inter-brokerage charging policies and schemes • How detail heuristics could be best formulated • Simulations to experiment various parameters • order processing and turnaround time • choice of parameters • Priority management in the routing • for valued customers • transactions that involve a large amount

  17. Question and Answer Thank you!

More Related