1 / 11

Trade Half Matching

Trade Half Matching. Description of message flows in Emapi and FIX. Background. In Release 2.0, an outgoing (from Burgundy) TradeCaptureReportRequest was added to the counterparty of a TradeCaptureReport.

akiko
Download Presentation

Trade Half Matching

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. Trade Half Matching Description of message flows in Emapi and FIX

  2. Background • In Release 2.0, an outgoing (from Burgundy) TradeCaptureReportRequest was added to the counterparty of a TradeCaptureReport. • The system sends a Trade Capture Report Request also for the second Trade Capture Report sent in by the counterparty as a trade confirmation. • Issue: there was not enough information in the Execution Report to identify a matched trade in an Execution Report with such a Trade Capture Report Request.

  3. Background • Solution: the tag 198 (SecondaryOrderID) of ExecutionReport now contains TradeRequestID of the counterparty’s TradeCaptureReportRequest for ExecType = ’F’ (Trade) / MatchType = 2 (two-party trade report).

  4. Scenario • Trading Members A and B have agreed upon a trade over the phone. • A enters his side of the trade, TradeHalf-A • Both A and B receive a private trade events with TradeHalf-A • A sees TradeHalf-A in the GUI as ”Sent and unconfirmed” • B sees TradeHalf-A in the GUI as ”Received and unconfirmed”

  5. Scenario cont. • B confirms TradeHalf-A by sending in TradeHalf-B. • A and B receive a private trade event each with TradeHalf-B • B sees TradeHalf B as ”Received and unconfirmed” for a minimal time in the GUI. • Immediately after, the system matchas TradeHalf-A and TradeHalf-B and sends a matched Trade. • Both A and B see the Trade as Confirmed in their GUI:s.

  6. Private Trade Event flow in Emapi • TradeHalf-A • To A • TRADE_REPORT_HALF, ownMember = A, receivingMember = null, isBid = true, tradeId = T1G09KKC3G-0, bidSideId = null, askSideId = null • A’s client displays trade as ”Sent and unconfirmed” • To B: • TRADE_REPORT_HALF, ownMember = A, receivingMember = A, isBid = true, tradeId = T1G09KKC3G-0, bidSideId = null, askSideId = null • B’s client displays trade as ”Received and unconfirmed” • Note that receivingMember is set to A to indicate that this is a copy of B’s trade half.

  7. Private Trade Event flow in Emapi cont. • TradeHalf-B: • To A • TRADE_REPORT_HALF, ownMember = B, receivingMember = B, isBid = false, tradeId = T1G09KKFIA-0, bidSideId = null, askSideId = null • A’s client displays trade as ”Received and unconfirmed”. • Note that receivingMember is set to B to indicate that this is a copy of B’s trade half. • To B • TRADE_REPORT_HALF, ownMember = B, receivingMember = null, isBid = false, tradeId = T1G09KKFIA-0, bidSideId = null, askSideId = null • B’s client displays trade as ”Sent and unconfirmed”

  8. Private Trade Event flows in Emapi, cont. • Matched trade: • To A • NEW, ownMember = A, receivingMember = null, isBid = false, tradeId = T1G09KKFIA-1, bidSideId = T1G09KKC3G-0, askSideId = T1G09KKFIA-0 • To B • NEW, ownMember = B, receivingMember = null, isBid = true, tradeId = T1G09KKFIA-1, bidSideId = T1G09KKC3G-0, askSideId = T1G09KKFIA-0 • The trading clients of A and B use the bidSideId and askSideId to change the status of the unconfirmed trade halves to confirmed.

  9. Message flow in FIX • A enters TradeCaptureReport with ClOrdID = AXYZ • Client may optionally set OrderID to AXYZ instead. • BURG system creates TradeID T1G09KKC3G-0 for A’s side of the trade. • A’s client displays trade as ”Sent and unconfirmed”. • BURG sends TradeCaptureReportRequest to B with TradeRequestID = T1G09KKC3G-0 • B’s client displays trade as ”Received and unconfirmed”

  10. Message flow in FIX, cont. • B confirms trade by sending in TradeCaptureReport with ClOrdID = BXYZ. • BURG system creates TradeID T1G09KKFIA-1 for B’s side of the trade. • BURG sends TradeCaptureReportRequest to A with TradeRequestID = T1G09KKFIA-0 • A’s client displays trade as ”Received and unconfirmed”.

  11. Message flow in FIX cont. • BURG sends matched trade as ExecutionReport • To A • ClOrderID = AXYZ • SecondaryOrderID = T1G09KKFIA-0 • To B • ClOrderID = BXYZ • SecondaryOrderId = T1G09KKC3G-0 • The trading clients of A and B use ClOrderID and SecondaryOrderID to change the status of the unconfirmed trade halves to confirmed.

More Related