ASX TradeAccept FIX Specification

Transcription

1 ASX TradeAccept FIX Specification

2 Table of Contents 1. INTRODUCTION SUPPORTED PRODUCT TYPES FOR TRADE REPORTING Bilateral Trade Reporting Third Party Trade Reporting SUPPORTED MESSAGES COMMON MESSAGE STRUCTURES Standard Header Standard Trailer ADMINISTRATIVE MESSAGES Logon (MsgType = A) Heartbeat (MsgType = 0) Test Request (MsgType = 1) Resend Request (MsgType = 2) Sequence Reset (MsgType = 4) Reject (MsgType = 3) Logout (MsgType = 5) APPLICATION MESSAGES Trade Capture Report (MsgType = AE) Trade Capture Report Ack (MsgType = AR) REPORTING PROCESS BILATERAL TRADE REPORTING Bilateral Trade Reporting Workflow Selling Participant Buying Participant THIRD PARTY TRADE REPORTING Third Party Trade Reporting Workflow Third Party Platform Selling Participant Buying Participant SESSION MANAGEMENT AND BUSINESS CONTINUITY SESSION MANAGEMENT BUSINESS CONTINUITY Primary Gateway Secondary Gateway APPENDIX A. BILATERAL WORKFLOW - SELLING PARTICIPANT MESSAGES APPENDIX B. BILATERAL WORKFLOW - BUYING PARTICIPANT MESSAGES APPENDIX C. THIRD PARTY WORKFLOW THIRD PARTY PLATFORM MESSAGES APPENDIX D. THIRD PARTY WORKFLOW SELLING PARTICIPANT MESSAGES APPENDIX E. THIRD PARTY WORKFLOW BUYING PARTICIPANT MESSAGES... 35

3 1. Introduction ASX provides the capability for its participants to report off-market Exchange for Physical (EFP) trades via the Financial Information Exchange Protocol (FIX). This form of electronic messaging allows Straight Through Processing (STP) of off-market deals resulting in operational cost efficiencies. It caters for bilateral trade reporting: the seller directly reports the trade and the buyer subsequently approves it; as well as third party trade reporting: a separate entity reports the trade to ASX on behalf of both seller and buyer who then both subsequently approves it. The protocol for trade reporting via electronic messaging: is based on FIX 5.0 SP2 with extension pack EP186 as published by FIX Trading Community unless specifically stated uses field numbers, names and data types as published by aforementioned specification is based upon FIX Trading Community recommended best practice supports reporting and cancellation of off-market EFP trades for bilaterally negotiated trades supports reporting of EFP trades negotiated via a third party platform does not support encrypted connections 1.1. Supported Product Types for Trade Reporting Bilateral Trade Reporting For a bilaterally negotiated trade, the Selling Participant has the responsibility to report the trade. Electronic messaging supports the following products: bond EFP swap EFP SPI vs EJO EFP Third Party Trade Reporting Reporting of a trade negotiated via a third party platform is initiated by the third party platform. Electronic messaging supports the following products: bond EFP swap EFP Copyright 2015 ASX Limited ABN All rights reserved

4 2. Supported Messages This specification details the fields, messages and values that are used to support the reporting of offmarket trades to ASX. Notes: On incoming messages, any fields and messages not defined in this specification will be ignored. Outgoing messages will only contain the fields and values defined in this specification. If a mandatory tag contains a value that is not recognised it will be rejected and a Reject (3) message sent with the exception of messages missing one or more of tags BeginString (8), BodyLength (9), MsgType (35) and CheckSum (10). In this case a Reject (3) message will not be sent. The column Req in the message definition tables contains Y if a tag is defined as required in FIX 5.0 SP2 EP 186 as per standard FIX protocol practice. Tags that are not marked as Y are required in order to support ASX reporting functionality unless otherwise specified in the comments. If an optional tag contains a value that is not recognised the default value will be assumed. In Extension Pack 186 certain tags that were previously mandatory in FIX 5.0 SP2 are now optional Common Message Structures Standard Header The standard header is the first part of every message. It identifies the message and provides information to ensure correct interpretation of the contents of the message. 8 BeginString Y String Identifies beginning of new message and protocol version. Always first field in message. FIXT BodyLength Y Length Message length, in bytes, forward to the CheckSum field. Always second field in message. 35 MsgType Y String Defines message type. Always third field in message. See individual messages for value to be used. 49 SenderCompID Y String Identifies firm sending message. 56 TargetCompID Y String Identifies firm receiving message. 34 MsgSeqNum Y SeqNum Message sequence number. 43 PossDupFlag Boolean Required for retransmitted messages. Indicates possible retransmission of message with this sequence number. N Original Transmission Y Possible duplicate 97 PossResend Boolean ASX will send 97=Y from the secondary gateway on messages that were queued prior to a successful connection to the Copyright 2015 ASX Limited ABN All rights reserved

5 secondary gateway. N Original Transmission Y Possible Resend See Secondary Gateway for more details ApplVerID String The version of FIX used in this specific message. 9 FIX 5.0 SP2 52 SendingTime Y UTCTimestamp Time of transmission in UTC. 122 OrigSendingTime UTCTimestamp Required for messages sent as a result of a ResendRequest. Original time of message transmission in UTC Standard Trailer The standard trailer terminates every message. 10 CheckSum Y String Three byte checksum as defined in the FIX 5.0 SP2 specification. Always last field in message Administrative Messages Administrative messages are concerned with maintaining the session between counterparties. The following messages are supported: Logon (MsgType = A) Heartbeat (MsgType = 0) Test Request (MsgType = 1) Resend Request (MsgType = 2) Sequence Reset (MsgType = 4) Reject (MsgType = 3) Logout (MsgType = 5) Logon (MsgType = A) The logon message authenticates a participant connecting to TradeAccept via FIX. It is up to the participant to initiate the FIX session. SenderCompID and TargetCompID are agreed when the service is setup. HeartBtInt is recommended to be set to 30 seconds. If the Logon message received from the participant contains ResetSeqNumFlag=Y (141=Y) the FIX session sequence numbers for both sides of the connection will be set to 1 and only messages generated for the client after the login message will be sent. If ResetSeqNumFlag=N or if the tag is omitted in the Logon message then any messages queued for the client will be sent immediately after login. Copyright 2015 ASX Limited ABN All rights reserved

6 Upon successfully authenticating the user, ASX will respond to the participant with a Logon message in response. If authentication fails ASX will issue a Logout message. See Logout. Standard Header Y Header MsgType=A (uppercase) 98 EncryptMethod Y int Method of encryption. Valid Values: 0 None/Other 108 HeartBtInt Y int Heartbeat interval in seconds. Values between 5 and 120 accepted; 30 recommended. 553 Username String TradeAccept username. User must be designated as an electronic messaging user. This is done by assigning the EM Role within TradeAccept user administration. Customer to supply when logging in. Not returned in response from ASX. 554 Password String TradeAccept password. Customer to supply when logging in. Not returned in response from ASX DefaultApplVerID Y String The default version of FIX messages used in this session. 9 FIX 5.0 SP2 141 ResetSeqNumFlag Boolean Indicates that both sides of the FIX session should reset sequence numbers. MsgSeqNum must be 1. Standard Trailer Y Trailer N No Y Yes, reset sequence numbers Successful Logon Example This following example illustrates a successful logon at the start of the day (or trading session) sequence numbers on both sides are 1. For a successful login during the day (or trading session) see Resend Request Example. < 8=FIXT.1.1 9=103 35=A 49=ACMECLEARERS 56=ASX 34=1 52= :49:08 98=0 108= =9 553=acmeefpreport 554=vsecret 10=106 > 8=FIXT.1.1 9=84 35=A 49=ASX 56=ACMECLEARERS 34=1 52= :49: =9 98=0 108= =9 10= Unsuccessful Logon Example This following example illustrates an unsuccessful logon due to an issue with sequence numbers. < 8=FIXT.1.1 9=104 35=A 49=ACMECLEARERS 56=ASX 34=14 52= :54:45 98=0 108= =9 553=acmeefpreport 554=vsecret 10=156 > 8=FIXT.1.1 9=117 35=5 49=ASX 56=ACMECLEARERS 34=17 52= :54: =9 58=MsgSeqNum too low, expecting 17 but received 14 10=047 Copyright 2015 ASX Limited ABN All rights reserved

7 Heartbeat (MsgType = 0) The Heartbeat message is sent during periods of inactivity to confirm the communication link. Its use is as described in the FIX 5.0 SP2 specification. Standard Header Y Header MsgType=0 112 TestReqID String Required when the heartbeat is issued in response to a Test Request message. Identifier included in Test Request message to be returned in resulting Heartbeat. Standard Trailer Y Trailer Test Request (MsgType = 1) The Test Request message forces the opposing side to generate a Heartbeat message. Its use is as described in the FIX 5.0 SP2 specification. Standard Header Y Header MsgType=1 112 TestReqID Y String Unique identifier of this Test Request. To be returned in the Heartbeat generated upon receipt of the Test Request. Standard Trailer Y Trailer Test Request Example This example below shows a Test Request and the Heartbeat response. < 8=FIXT.1.1 9=77 35=1 49=ACMECLEARERS 56=ASX 34=17 52= :00:49 112= :00:49 10=030 > 8=FIXT.1.1 9=88 35=0 49=ASX 56=ACMECLEARERS 34=15 52= :00: =9 112= :00:49 10= Resend Request (MsgType = 2) The Resend Request is sent to initiate the retransmission of messages when the sending application detects a sequence number gap. Use this message as specified in the FIX 5.0 SP2 specification. Note: Either party may send a Resend Request. Standard Header Y Header MsgType=2 7 BeginSeqNo Y SeqNo Message sequence number of first message in range to be resent. 16 EndSeqNo Y SeqNo Message sequence number of last message in range to be resent. If all messages subsequent to BeginSeqNo are required set EndSeqNo=0. Standard Trailer Y Trailer Copyright 2015 ASX Limited ABN All rights reserved

8 Resend Request Example This following example shows an intra-day (intra-trading session) login. A resend request is issued upon detection of a gap in message sequence numbers. Sequence Reset messages replace administrative messages sent in the original message sequence. < 8=FIXT.1.1 9=104 35=A 49=ACMECLEARERS 56=ASX 34=35 52= :13:22 98=0 108= =9 553=acmeefpreport 554=vsecret 10=150 > 8=FIXT.1.1 9=85 35=A 49=ASX 56=ACMECLEARERS 34=29 52= :13: =9 98=0 108= =9 10=096 < 8=FIXT.1.1 9=65 35=2 49=ACMECLEARERS 56=ASX 34=36 52= :13:25 7=12 16=0 10=146 > 8=FIXT.1.1 9=109 35=4 49=ASX 56=ACMECLEARERS 34=12 43=Y 52= :13: = :13: =9 123=Y 36=30 10= Sequence Reset (MsgType = 4) The Sequence Reset message is used to: replace administrative or application messages that will not to be resent set a higher sequence number in the event of an unrecoverable application failure. Use this message as specified in the FIX 5.0 SP2 specification. See Resend Request Example for an example of a gap fill request. Standard Header Y Header MsgType=4 123 GapFillFlag Boolean Indicates if the Sequence Reset message is replacing administrative or application messages which will not be resent or being used to reset the sequence number. N Sequence Reset, Ignore Msg Seq Num Y Gap Fill Message, Msg Seq Num Field Valid 36 NewSeqNo Y SeqNum New sequence number Reject (MsgType = 3) Standard Trailer Y Trailer A Reject message is issued when a message cannot be properly processed due to session-level violations. Examples are when a message fails CheckSum or BodyLength checks. Standard Header Y Header MsgType=3 45 RefSeqNum Y SeqNum MsgSeqNum of rejected message. 371 RegTagID int Tag number of the FIX field being referenced. 372 RefMsgType String The MsgType of the FIX message being referenced. 373 SessionRejectReason int Code to identify reason for a sessionlevel Reject message. Copyright 2015 ASX Limited ABN All rights reserved

9 Reject Example Required Tag Missing The following example illustrates the response to a message with a required tag missing. < 8=FIXT.1.1 9=60 35=2 49=ACMECLEARERS 56=ASX 34=51 52= :19:25 7=12 10=187 > 8=FIXT.1.1 9=224 35=3 49=ASX 56=ACMECLEARERS 34=42 52= :19: =9 45=51 371=16 372=2 373=1 58=Bad message. Required field is missing. Field [tag=16, scope=message Body]. Message [type=2, seqnum=51, dictionary=fix.5.0_sp2]. 10= Reject Example Tag Value Missing The following example illustrates the response to a resend request with a missing tag. < 8=FIXT.1.1 9=64 35=2 49=ACMECLEARERS 56=ASX 34=71 52= :28:19 7=12 16= 10=105 > 8=FIXT.1.1 9=216 35=3 49=ASX 56=ACMECLEARERS 34=60 52= :28: =9 45=71 371=16 372=2 373=4 58=Bad message. Empty field value. Field [tag=16, scope=message Body]. Message [type=2, seqnum=71, dictionary=fix.5.0_sp2]. 10= Logout (MsgType = 5) 0 Invalid Tag Number 1 Required Tag Missing 2 Tag not defined for this message type 3 Undefined tag 4 Tag specified without a value 5 Value is incorrect (out of range) for this tag 6 Incorrect data format for value 9 CompID problem 10 SendingTime Accuracy Problem 11 Invalid MsgType 13 Tag appears more than once 14 Tag specified out of required order 17 Non "Data" value includes field delimiter (<SOH> character) 99 Other 58 Text String Text explaining reason for rejection. Standard Trailer Y Trailer The logout message is used to initiate and to confirm the termination of a FIX session. Use this message as specified in the FIX 5.0 SP2 specification. Standard Header Y String As defined in Common Message Structures Standard Header; MsgType=5 58 Text String Free format text string. Copyright 2015 ASX Limited ABN All rights reserved

10 If a Logout is sent as a result of authentication failure, ASX will provide a reason in this field SessionStatus int Status of FIX session. Returned by ASX if Logout is sent as a result of authentication failure. 5 Invalid username or password 6 Account locked 7 Logons are not allowed at this time 8 Password expired Standard Trailer Y As defined in Standard Trailer Successful Logout Example The following example illustrates the participant logging out successfully. < 8=FIXT.1.1 9=55 35=5 49=ACMECLEARERS 56=ASX 34=39 52= :14:25 10=235 > 8=FIXT.1.1 9=91 35=5 49=ASX 56=ACMECLEARERS 34=32 52= :14: =9 58=Logout acknowledgment 10= Response to Unsuccessful Login The following example illustrates a logout message sent by the ASX that is rejecting an attempt of a participant logging in. < 8=FIXT.1.1 9=109 35=A 49=ACMECLEARERS 56=ASX 34=1 52= :55:31 108= =9 553=acmeefpreport 554=vsecret 141=Y 98=N 10=183 > 8=FIXT.1.1 9=150 35=5 49=ASX 56=ACMECLEARERS 34=1 52= :55: =9 58=Unable to authenticate user at this time. Please contact the ASX Helpdesk. 1409=7 10= Application Messages Application messages are used to describe the reporting of an EFP. The following messages are supported: Trade Capture Report (MsgType = AE) Trade Capture Report Ack (MsgType = AR) Trade Capture Report (MsgType = AE) The Trade Capture Report message is used to: report an off-market trade to the ASX notify a buyer of a trade reported by a seller notify a seller of a trade reported by a third party allow a buyer to accept or reject a trade reported by a seller notify the seller of a buyer s rejection of an alleged trade notify buyer and seller of ASX acceptance or rejection of a trade. For more information on the Trade Capture Report message and additional sample messages see 3 Reporting Process. Copyright 2015 ASX Limited ABN All rights reserved

11 Standard Header Y Header MsgType=AE 571 TradeReportID String Unique identifier of the trade report. Assigned by each sender. Uniqueness must be guaranteed within all messages from a sender. 487 TradeReportTrans Type int Identifies the type of trade report transaction - i.e. what the report is being used for (e.g. report a new trade, cancel an existing one). 0 New 1 Cancel 2 Replace See the relevant appendix for combining with TradeReportType. 828 TrdType int Type of trade being reported. 2 Exchange for physical (EFP) 856 TradeReportType int Type of trade report - status in the process. 0 Submit 1 Alleged 2 Accept 3 Decline See the relevant appendix for information on combined use with Trade ReportTransType TradeHandlingInstr int Model of reporting being used. 0 Trade Confirm 3 One-Party Report for Matching 4 Automated floor order routing See the relevant appendix for usage of this field in reporting workflow. 573 MatchStatus char The status of the trade with respect to matching. 0 Compared, matched or affirmed 1 Uncompared, unmatched or unaffirmed See the relevant appendix for usage of this field in reporting workflow SecondaryTradeID String TradeAccept deal number. This is sent by ASX on messages issued once the trade report is accepted for processing. Required on messages sent by Copyright 2015 ASX Limited ABN All rights reserved

12 participants except for the seller s initial Trade Capture Report. It is the sole identifier used to determine the trade to which the message refers. 207 SecurityExchange Exchange ISO MIC codes for the exchange on which the future or option is traded. XSFE ASX Trade24 XNZF New Zealand F&O 75 TradeDate LocalMktDate ASX Trade24 trading day that the trade occurred. 60 TransactTime UTCTimestamp Agreement date and time. 55 Symbol Y String This field is mandatory as per the FIX specification. However, for ASX offmarket trade reporting, the LegSymbol field (see below) will be used to determine the contract name. Therefore its value is not validated by ASX. Suggested value to use is n/a. 751 TradeReportReject Reason int Specifies the reason for rejecting a trade. Required by the participant when rejecting a trade. Sent by ASX when informing a participant of a rejected trade. 1 Invalid party onformation (Invalid Counterparty) 2 Unknown instrument (Invalid Contract) 5 Price exceeds current price band (Invalid Price) 99 Other (Other) 100 Duplication 101 Invalid Physical 102 Invalid Volume Description of standard FIX values matches FIX specification. Text in brackets is the reason displayed in the TradeAccept website when a trade is rejected RejectText String Description as to why the trade report was rejected. When TradeReportReject Reason is Other (99), this field is then required by the participant. It is included when this message is sent by ASX NoRootPartyIDs NumInGroup Number of root parties. Required for third party reported trades; only valid value is 1. RootPartyID, RootPartIDSource and RootPartyRole describe the third party platform. Copyright 2015 ASX Limited ABN All rights reserved

13 Start of Repeating Group 1116, NoRootPartyIDs 1117 RootPartyID String Identifies the party (third party platform). Required if NoRootPartyIDs > RootPartyIDSource String Describes what is contained in RootPartyID. Required if NoRootPartyIDs > 0. G MIC (ISO Market Identifier Code) 1119 RootPartyRole int The role of the party in the transaction e.g. executing firm. Required if RootPartyID specified. End of Repeating Group 1116, NoRootPartyIDs 73 Execution Venue 1041 FirmTradeID String Identifier assigned by third party platform. Only processed by ASX when accepting trades under the third party reporting model TradeHandlingInstr=Automated floor order routing (1123=4) AverageDeltaValue float SPIvsXJO only: Required. Decimal number between 0 and 1000, with up to 3 decimal places. 552 NoSides NumInGroup Number of side repeating groups Must be present; only valid value is 2. Start of Repeating Group 552, NoSides 54 Side char Side of order. Must be present if NoSides is present. 1 Buy 2 Sell 58 Comment String Free text comments for the relevant side of the trade. Supplied by the participant for the side of the trade on which they are acting e.g. a seller populates the sell side. ASX returns those comments entered by a participant for the side of the trade for which the participant is acting. Comments entered by other participants are not returned. E.g. comments entered by the buyer are returned to the buyer, not to the seller. 453 NoPartyIDs NumInGroup Number of parties involved in the trade. Start of Repeating Group 453, NoPartyIDs 1 or PartyID String Identifies the party. Required if Copyright 2015 ASX Limited ABN All rights reserved

14 NoPartyIDs > PartyIDSource String Describes what is contained in PartyID. Required if NoPartyIDs > 0. D Proprietary/Custom code 452 PartyRole int The role of the party in the transaction e.g. executing firm. Required if PartyID specified. End of Repeating Group 453, NoPartyIDs End of Repeating Group 552, NoSides 1 Executing Firm 3 Client ID 555 NoLegs NumInGroup Number of legs. Start of Repeating Group 555, NoLegs For a Bond EFP: 2. (1 future/option and 1 bond) For a Swap EFP: 2. (1 future/option and 1 swap) For a SPIvsXJO EFP: 2 or more (1 SPI future/option and at least 1 [maximum of 4] XJO option) 600 LegSymbol String Identifies the instrument. Valid Values Future, Option: ASX 24 contract series ID e.g. IRU2015F, YTU2014C Bond: One of the options below: CGL NSW TC QLD TC VIC TC SAFA TAS TC WA TC NZ GOVT OTHER Swap, SPIvsXJO: n/a (field is required for repeating group). 608 LegCFICode String CFI code of the leg instrument. Used to determine the type of leg. FXXXXX Future OXXXXX Option DBXXXX Bond XXXWXX Swap OFIXXX XJO (in SPIvsXJO) Copyright 2015 ASX Limited ABN All rights reserved

15 685 LegOrderQty Qty Future, Option: Number of contracts. Bond, Swap: Required. Face value. XJO: Required. Volume. 566 LegPrice Price Future, Option, XJO: Required. Registration price Delta float Option only: Delta value. Decimal number between 0 and 1000, to 2 decimal places. 588 LegSettDate LocalMktDate Bond only: Settlement date. 739 LegDatedDate LocalMktDate Swap only: Start date LegMarketYield Percentage Bond only: Market yield. 615 LegCouponRate Percentage Bond only: Coupon rate LegSwapFloating Rate Percentage Swap only: Optional. Floating rate of swap contract LegSwapFixedRate Percentage Swap only: Fixed rate of swap contract LegCoupon FrequencyUnit String Bond: Time unit of the bond s coupon payment frequency LegCoupon FrequencyPeriod 9002 LegSwapFrequency Period int int Mo = Month Bond: Number of LegCouponFrequencyUnit periods between bond coupon payments. 1 monthly 2 every 2 months 3 quarterly 6 twice yearly 12 annually Swap: Number of months in swap periods. 3 quarterly 6 twice yearly 12 annually 620 LegSecurityDesc String Bond only: Additional information about a security. Required when LegSymbol=OTHER for a bond leg (LegCFICode=DBXXXX). 611 LegMaturityDate LocalMktDate Bond: Required. Maturity date. Swap: Required. Maturity date. SPIvsXJO: Required. XJO option expiry date (only year and month are validated) LegNumber int SPIvsXJO only: Unique sequentially assigned number starting at 1 to identify the XJO option legs within a reported trade. Valid values between 1 and 4 Copyright 2015 ASX Limited ABN All rights reserved

16 (SPIvsXJO only allows 4 legs maximum). 990 LegReportID String SPIvsXJO only: ASX Trade Slip Number of XJO option trade. 612 LegStrikePrice Price SPIvsXJO only: Strike price of XJO option LegPutorCall int SPIvsXJO only: Type of XJO option. 0 Put 1 Call 9005 ASXCleared Boolean Swap only: Optional. True if swap is cleared by ASX. End of Repeating Group 552, NoLegs Standard Trailer Y Trailer Trade Capture Report Example Accepted For Processing The following example illustrates a Trade Capture Report registering a Bond EFP for IRZ2014F, submitted by ACL (the seller) for RPI (the buyer). 8=FIXT.1.1 9=401 35=AE 49=ACMECLEARERS 56=ASX_FIX 34=2 52= :53: =acmeefp =0 828=2 856=0 1123=3 207=XSFE 75= = :53:01 55=n/a 552=2 54=2 58=Standard contract 453=2 448=ACL 447=D 452=1 448=Invest01 447=D 452=3 54=1 453=1 448=RPI 447=D 452=1 555=2 600=IRZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = =1 615=1 2163=6 2164=Mo 611= = Trade Capture Report Ack (MsgType = AR) The Trade Capture Report Ack message is sent by the ASX to: acknowledge initial trade capture reports received from a seller or third party reject a trade capture report received from a counterparty or third party acknowledge a buyer s response to an alleged trade inform the seller of a buyer s acceptance of an alleged trade. Further details on uses of the Trade Capture Report Ack message can be found in 3 Reporting Process, including additional sample messages. Standard Header Y Header MsgType=AR 571 TradeReportID String Unique identifier of the trade report. Assigned by each sender. Uniqueness must be guaranteed for within all messages from a sender. 572 TradeReportRefID String TradeReportID (571) identifier to which this message refers. Populated by ASX when accepting or rejecting an initial trade report. 487 TradeReportTrans Type int Identifies the type of trade report transaction - i.e. what the report is being used for (e.g. report a new trade). Copyright 2015 ASX Limited ABN All rights reserved

17 0 New 2 Replace 828 TrdType int Type of trade being reported. 2 Exchange for physical (EFP) 856 TradeReportType String Type of trade report - status in the process. 0 Submit 2 Accept 3 Decline 1123 TradeHandlingInstr int Model of reporting being used. 3 One-Party Report for Matching 4 Automated floor order routing 1040 SecondaryTradeID String TradeAccept deal number. Sent by ASX, populated once trade report is accepted for processing. 207 SecurityExchange Exchange ISO MIC codes for exchange future or option is traded on. XSFE ASX Trade24 XNZF New Zealand F&O 75 TradeDate LocalMktDate Required. ASX Trade24 trading day that the trade occurred. 60 TransactTime UTCTimestamp Required. Agreement date and time. 55 Symbol Y String This field is mandatory as per the FIX specification. However, for ASX offmarket trade reporting, the LegSymbol field (see below) will be used to determine the contract name. Therefore its value should not be validated by the participant. The TradeAccept system will populate the value with n/a. 751 TradeReportReject Reason int Populated if the referenced trade report has been rejected. RejectText (1328) will contain a description. 1 Invalid party onformation (Invalid Counterparty) 2 Unknown instrument (Invalid Contract) 3 Unauthorised to report trades (The trading participant is not one of the counterparties) 4 Invalid trade type - wrong value in one of the following tags: TradeType (828) Copyright 2015 ASX Limited ABN All rights reserved

18 TradeReportTransType (487) TradeReportType (856) TradeHandlingInstr (1123) 5 Price exceeds current price band (Invalid Price) 99 Other (Other) 100 Duplication 101 Invalid Physical 102 Invalid Volume Description of standard FIX values matches FIX specification. Text in brackets is the reason displayed in the TradeAccept website when a trade is rejected RejectText String Populated if the referenced trade report has been rejected. Description of why trade report was rejected NoRootPartyIDs NumInGroup Number of root parties. Required for third party reported trades; only valid value is 1. RootPartyID, RootPartIDSource and RootPartyRole describe the third party platform. Start of Repeating Group 1116, NoRootPartyIDs 1117 RootPartyID String Identifies the party (third party platform). Required if NoRootPartyIDs > RootPartyIDSource String Describes what is contained in RootPartyID. Required if NoRootPartyIDs > 0. G MIC (ISO Market Identifier Code) 1119 RootPartyRole int The role of the party in the transaction e.g. executing firm. Required if RootPartyID specified. End of Repeating Group 1116, NoRootPartyIDs 73 Execution Venue 1041 FirmTradeID String Identifier assigned by third party platform. Only processed by ASX when accepting trades under the third party reporting model i.e. when TradeHandlingInstr=Automated floor order routing (1123=4) AverageDeltaValue float SPIvsXJO only: Decimal number between 0 and 1000, with up to 3 decimal places. 552 NoSides NumInGroup Number of side repeating groups. Must be present; only valid value is 2. Start of Repeating Group 552, NoSides Copyright 2015 ASX Limited ABN All rights reserved

19 54 Side char Side of order. Must be present if NoSides is present. 1 Buy 2 Sell 58 Comment String Free text comments for the relevant side of the trade. ASX returns those comments entered by a participant for the side of the trade for which the participant is acting. Comments entered by other participants are not returned. E.g. comments entered by the buyer are returned to the buyer, not to the seller. 453 NoPartyIDs NumInGroup Number of parties involved in the trade. Start of Repeating Group 453, NoPartyIDs 1 or PartyID String Identifies the party. Required if NoPartyIDs > PartyIDSource String Describes what is contained in PartyID. Required if NoPartyIDs > 0. D Proprietary/Custom code 452 PartyRole String The role of the party in the transaction e.g. executing firm. Required if PartyID specified. End of Repeating Group 453, NoPartyIDs End of Repeating Group 552, NoSides 1 Executing Firm 3 Client ID 555 NoLegs NumInGroup Number of legs. Start of Repeating Group 555, NoLegs For a Bond EFP: 2. (1 future/option and 1 bond). For a Swap EFP: 2. (1 future/option and 1 swap). For a SPIvsXJO EFP: 2 or more (1 SPI future/option and at least 1 [maximum of 4] XJO option) 600 LegSymbol String Identifies the instrument. Valid Values Future, Option: ASX 24 contract series ID e.g. IRU2015F, YTU2014C Bond: One of the options below: CGL Copyright 2015 ASX Limited ABN All rights reserved

20 NSW TC QLD TC VIC TC SAFA TAS TC WA TC NZ GOVT OTHER Swap, SPIvsXJO: n/a (field is required for repeating group). 608 LegCFICode String CFI code of the leg instrument. Used to determine the type of leg. FXXXXX Future OXXXXX Option DBXXXX Bond XXXWXX Swap OFIXXX XJO (in SPIvsXJO) 685 LegOrderQty Qty Future, Option: Number of contracts. Bond, Swap: Face value. XJO: Volume. 566 LegPrice Price Future, Option, XJO: Registration price Delta float Option only: Delta value. Decimal number between 0 and 1000, with up to 2 decimal places. 588 LegSettDate LocalMktDate Bond only: Settlement date. 739 LegDatedDate LocalMktDate Swap only: Start date LegMarketYield Percentage Bond only: Market yield. 615 LegCouponRate Percentage Bond only: Coupon rate LegSwapFloating Rate Percentage Swap only: Optional. Floating rate of swap contract LegSwapFixedRate Percentage Swap only: Fixed rate of swap contract LegCoupon FrequencyUnit String Time unit of the bond s coupon payment frequency LegCoupon FrequencyPeriod int Mo = Month Number of LegCouponFrequencyUnit periods between bond coupon payments. 1 monthly 3 quarterly 6 twice yearly 12 annually 9002 LegSwapFrequency int Swap: Number of months in swap Copyright 2015 ASX Limited ABN All rights reserved

21 Period periods. 3 quarterly 6 twice yearly 12 annually 620 LegSecurityDesc String Bond only: Additional information about a security. Required when LegSymbol=OTHER for a bond leg (LegCFICode=DBXXXX). 611 LegMaturityDate LocalMktDate Bond, swap: Maturity date SPIvsXJO: XJO option expiry date (only year and month are provided day defaulted to 1) 1152 LegNumber int SPIvsXJO only: Unique sequentially assigned number starting at 1 to identify the XJO option legs within a reported trade. Valid values between 1 and 4 (SPIvsXJO only allows 4 legs maximum). 990 LegReportID String SPIvsXJO only: ASX Trade Slip Number of XJO option trade. 612 LegStrikePrice Price SPIvsXJO only: Strike price of XJO option LegPutorCall int SPIvsXJO only: Type of XJO option. 0 Put 1 Call 9005 ASXCleared Boolean Swap only: Optional. True if swap is cleared by ASX. End of Repeating Group 552, NoLegs Standard Trailer Y Trailer Trade Report Ack Example Successful Submission The following example illustrates a Trade Capture Report successfully registering a Bond EFP for IRZ2014F, submitted by ACL (the seller) for RPI (the buyer). 8=FIXT.1.1 9=401 35=AE 49=ACMECLEARERS 56=ASX_FIX 34=2 52= :53: =acmeefp =0 828=2 856=0 1123=3 207=XSFE 75= = :53:01 55=n/a 552=2 54=2 58=Standard contract 453=2 448=ACL 447=D 452=1 448=Invest01 447=D 452=3 54=1 453=1 448=RPI 447=D 452=1 555=2 600=IRZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = =1 615=1 2163=6 2164=Mo 611= =004 8=FIXT.1.1 9=440 35=AR 49=ASX_FIX 56=ACMECLEARERS 34=2 52= :53: =9 571=TAEM =0 856=0 828=2 572=acmeefp = :53:01 555=2 600=IRZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = =1 615=1 2164=Mo 2163=6 611= = =2 54=2 58=Standard contract 453=2 448=ACL 447=D 452=1 448=Invest01 447=D 452=3 54=1 453=1 448=RPI 447=D 452=1 1040=E =3 207=XSFE 55=n/a 10=232 Copyright 2015 ASX Limited ABN All rights reserved

22 Trade Report Ack Example Unsuccessful Submission The following example illustrates a Trade Capture Report Ack rejecting an attempt to register a Bond EFP. 8=FIXT.1.1 9=401 35=AE 49=ACMECLEARERS 56=ASX_FIX 34=7 52= :53: =acmeefp =0 828=2 856=4 1123=3 207=XSFE 75= = :53:01 55=n/a 552=2 54=2 58=Standard contract 453=2 448=ACL 447=D 452=1 448=Invest01 447=D 452=3 54=1 453=1 448=RPI 447=D 452=1 555=2 600=IRZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = =1 615=1 2163=6 2164=Mo 611= =003 8=FIXT.1.1 9=504 35=AR 49=ASX_FIX 56=ACMECLEARERS 34=7 52= :53: =9 571=TAEM =0 856=4 828=2 572=acmeefp =4 60= :53:01 555=2 600=IRZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = =1 615=1 2164=Mo 2163=6 611= = =2 54=2 58=Standard contract 453=2 448=ACL 447=D 452=1 448=Invest01 447=D 452=3 54=1 453=1 448=RPI 447=D 452=1 1123=3 207=XSFE 1328=Must specify a valid TradeReportType (856). Do not recognise 4. 55=n/a 10=087 Copyright 2015 ASX Limited ABN All rights reserved

23 3. Reporting Process The sections below describe the workflow between ASX, the Seller, the Buyer and the Third Party Platform for trade reporting Bilateral Trade Reporting Note: Where a firm acts for both the seller and the buyer on reporting a trade, then that firm will receive both sets of messages destined for the seller and for the buyer Bilateral Trade Reporting Workflow The diagram below displays the workflow between the seller, buyer and ASX for a bilateral trade report. Figure 1 Bilateral Trade Reporting Workflow A description of each message is detailed in the following sections. Copyright 2015 ASX Limited ABN All rights reserved

24 Selling Participant The Selling Participant initiates the workflow by reporting the off-market trade. The process for the seller is as follows: 1. Selling Participant sends a Trade Capture Report (TCR) message to report the trade to ASX (S1). 2. ASX responds with a Trade Capture Report Acknowledgement (TCR Ack) that will either reject the message (S2) due to it failing basic validation (e.g. unknown instrument) or acknowledge receipt (S3) of the TCR. If the message passes validation, ASX sends the details to the Buying Participant. 3. If the Buying Participant accepts the trade, ASX sends the Selling Participant a TCR Ack (S6); if the Buying Participant amends the trade (effectively using the Save function on the TradeAccept web site) or rejects the trade then ASX sends the Selling Participant a TCR (S5). 4. Once the TradeAccept system has processed the trade report it will send a TCR informing of either confirmation (S8) or rejection (S7) of the trade. The tags and values used to identify each of these messages are defined in Appendix A Bilateral Workflow - Selling Participant Messages. For more information on Application Messages see 2.3 Application Messages Successful Bond EFP - Example Messages This example illustrates the message flow between ASX and the seller during the successful lodgement of a bond EFP. Seller submits a bond EFP to ASX 8=FIXT.1.1 9=414 35=AE 49=ACMECLEARERS 56=ASX_FIX 34=361 52= :52: =efpsys =0 828=2 856=0 1123=3 207=XSFE 75= = :52:11 55=n/a 552=2 54=2 58=Comment from seller 453=2 448=ACL 447=D 452=1 448=SellClient 447=D 452=3 54=1 453=1 448=RPI 44 7=D 452=1 555=2 600=XTZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = = = =6 2164=Mo 611= =203 ASX acknowledges receipt of EFP submission 8=FIXT.1.1 9=444 35=AR 49=ASX_FIX 56=ACMECLEARERS 34=365 52= :52: =9 571=TAEM =0 856=0 828=2 60= :52:00 555=2 600=XTZ2014F 608=FXXXXX 685= = =CGL 608=DBXX XX 685= = = = =Mo 2163=6 611= = =2 54=2 58=Comment from seller 453=2 448=ACL 447=D 452=1 448=SellClient 447=D 452=3 54=1 453=1 448=RPI 44 7=D 452=1 1040=E =3 207=XSFE 55=n/a 10=136 ASX notifies seller of buyer acceptance of the EFP 8=FIXT.1.1 9=444 35=AR 49=ASX_FIX 56=ACMECLEARERS 34=367 52= :52: =9 571=TAEM =2 856=2 828=2 60= :52:00 555=2 600=XTZ2014F 608=FXXXXX 685= = =CGL 608=DBXX XX 685= = = = =Mo 2163=6 611= = =2 54=2 58=Comment from seller 453=2 448=ACL 447=D 452=1 448=SellClient 447=D 452=3 54=1 453=1 448=RPI 44 7=D 452=1 1040=E =3 207=XSFE 55=n/a 10=155 ASX informs the seller the EFP has been accepted by ASX 8=FIXT.1.1 9=450 35=AE 49=ASX_FIX 56=ACMECLEARERS 34=372 52= :53: =9 571=TAEM =2 856=0 828=2 75= =2 6 00=XTZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = = = =Mo 2163=6 611= = :52:00 573=0 552=2 54=2 58=Comment from Copyright 2015 ASX Limited ABN All rights reserved

25 seller 453=2 448=ACL 447=D 452=1 448=SellClient 447=D 452=3 54=1 453=1 448=RPI 44 7=D 452=1 1040=E =0 207=XSFE 55=n/a 10= Buying Participant The Buying Participant responds to the message from ASX informing them of the Selling Participant s report of the trade. The process and message flow between the Buying Participant and ASX is as follows: 1. ASX sends the Buying Participant a TCR informing them of the trade (B3). 2. The Buying Participant sends back a TCR accepting (B4b) or rejecting (B4a) the trade. 3. ASX sends a TCR Ack acknowledging receipt of the Buying Participant s TCR (B5 or B6). 4. If the Buying Participant accepted the report, ASX sends a final TCR informing of either confirmation (B8) or rejection (B7) of the trade. The tags and values used to identify each of these messages are defined in Appendix B Bilateral Workflow - Buying Participant Messages. For more information on application messages see 2.3 Application Messages Successful Bond EFP - Example Messages This example illustrates the message flow between ASX and the buyer during the successful lodgement of a bond EFP. ASX notifies the buyer of the bond EFP submitted by the seller 8=FIXT.1.1 9=394 35=AE 49=ASX_FIX 56=REDPLANETINV 34=361 52= :52: =9 571=TAEM =0 856=1 828=2 75= =2 6 00=XTZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = = = =Mo 2163=6 611= = :52:00 552=2 54=2 453=1 448=ACL 447=D 452=1 54=1 453=1 448=RPI 447=D 452= =E =3 207=XSFE 55=n/a 10=180 The buyer accepts the EFP 8=FIXT.1.1 9=419 35=AE 49=REDPLANETINV 56=ASX_FIX 34=360 52= :52: =efpsys =2 828=2 856=2 1123=3 1040=E =XSFE 75= = :52:29 55=n/a 552=2 54=2 453=1 448=ACL 447=D 452=1 54=1 58=Buyer comment 453=2 448=RPI 447=D 452=1 448=BuyClient 447=D 452=3 555=2 600=XTZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = = = =6 2164=Mo 611= =194 ASX acknowledges receipt of buyer acceptance 8=FIXT.1.1 9=437 35=AR 49=ASX_FIX 56=REDPLANETINV 34=363 52= :52: =9 571=TAEM =2 856=2 828=2 60= :52:00 555=2 600=XTZ2014F 608=FXXXXX 685= = =CGL 608=DBXX XX 685= = = = =Mo 2163=6 611= = =2 54=2 453=1 448=ACL 447=D 452=1 54=1 58=Buyer comment 453=2 448=RPI 447=D 452=1 448=BuyClient 447=D 452=3 1040=E =3 207=XSFE 55=n/a 10=036 ASX informs the buyer the EFP has been accepted by ASX 8=FIXT.1.1 9=443 35=AE 49=ASX_FIX 56=REDPLANETINV 34=368 52= :53: =9 571=TAEM =2 856=0 828=2 75= =2 6 00=XTZ2014F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = = = =Mo 2163=6 611= = :52:00 573=0 552=2 54=2 453=1 448=ACL 447=D 452=1 54=1 58=Buyer comment 453=2 448=RPI 447=D 452=1 448=BuyClient 447=D 452=3 1040=E =0 207=XSFE 55=n/a 10=036 Copyright 2015 ASX Limited ABN All rights reserved

26 3.2. Third Party Trade Reporting Third Party Trade Reporting Workflow The diagram below displays the workflow between the third party platform, the seller, the buyer and ASX for a third party trade report. Figure 2 Third Party Trade Reporting Workflow A description of each message is detailed in the following sections. Copyright 2015 ASX Limited ABN All rights reserved

27 Third Party Platform The Third Party Platform initiates the reporting of the trade. The process and message flow between the Third Party Platform and ASX is as follows: 1. Third Party Platform sends a Trade Capture Report (TCR) message to report the trade to ASX (T1). 2. ASX responds with a Trade Capture Report Acknowledgement (TCR Ack) that will either reject the message (T2) due to it failing basic validation (e.g. unknown instrument) or acknowledge receipt (T3) of the TCR. If the message passes validation, ASX sends the details to the Selling Participant. The tags and values used to identify each of these messages are defined in Appendix C Third Party Workflow Third Party Platform Messages. For more information on application messages see 2.3 Application Messages Successful Third Party Bond EFP Example Messages Third Party Platform submits a bond EFP to ASX 8=FIXT.1.1 9=469 35=AE 49=THIRDPARTY 56=ASX_FIX 34=2 52= :41: =efptpbond =0 856=0 828=2 75= =2 600=XTH2015F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = = = =Mo 2163=6 611= = :41:36 552=2 54=2 453=2 448=ACL 447=D 452=1 448=SellClient 447=D 452=3 54=1 453=2 448=RPI 447=D 452=1 4 48=BuyClient 447=D 452=3 1041=thirdpartyid =1 1117=XTPF 1118=G 1119= =4 207=XSFE 55=n/a 10=147 ASX acknowledges valid bond EFP submission by Third Party Platform 8=FIXT.1.1 9=514 35=AR 49=ASX_FIX 56=THIRDPARTY 34=2 52= :41: =9 571=TAEM =0 856=0 828=2 572=efptpbond445 60= :41:00 555=2 600=XTH2015F 608=FXXXXX 685= = =CGL 608=DBX XXX 685= = = = =Mo 2163=6 611= = =2 54=2 453=2 448=ACL 447=D 452=1 448=SellClient 447=D 452=3 54=1 453=2 448=RPI 447=D 452=1 448=BuyClient 447=D 452=3 1040=E =third partyid =1 1117=XTPF 1118=G 1119= =4 207=XSFE 55=n/a 10= Selling Participant The Selling Participant responds to the message from ASX informing them of the Third Party Platform s report of the trade. The process and message flow between the Selling Participant and ASX is as follows: 1. ASX sends the Selling Participant a TCR informing them of the trade (S9). 2. The Selling Participant sends back a TCR accepting (S10b) or declining (S10a) the trade. 3. ASX sends a TCR Ack acknowledging receipt of the Selling Participant s TCR (S11 or S3). 4. If the Selling Participant accepts the report, ASX sends the details to the Buying Participant. 5. If the Buying Participant accepts the trade, ASX sends the Selling Participant a TCR Ack (S6); if the Buying Participant rejects the trade ASX sends the Selling Participant a TCR (S5). 6. Once ASX has processed the request it will send the Selling Participant a TCR informing of either confirmation (S8) or rejection (S7) of the trade. The tags and values used to identify each of these messages are defined in Appendix D Third Party Workflow Selling Participant Messages. For more information on application messages see 2.3 Application Messages Seller Approves Third Party Bond EFP Example Messages ASX notifies seller of Third Party Platform submission of the EFP Copyright 2015 ASX Limited ABN All rights reserved

28 8=FIXT.1.1 9=473 35=AE 49=ASX_FIX 56=ACMECLEARERS 34=2 52= :41: =9 571=TAEM =0 856=1 828=2 75= =2 600=XTH2015F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = = = =Mo 2163=6 611= = :41:00 552=2 54=2 453=2 448=ACL 447=D 452=1 448=SellClient 447=D 452=3 54=1 453=1 448= RPI 447=D 452=1 1040=E =thirdpartyid =1 1117=XTPF 1118=G 1119= =4 207=XSFE 55=n/a 10=021 Seller accepts the EFP 8=FIXT.1.1 9=476 35=AE 49=ACMECLEARERS 56=ASX_FIX 34=2 52= :41: =efptpbond =0 856=2 828=2 75= =2 600=XTH2015F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = = = =Mo 2163=6 611= = :41:36 552=2 54=2 58=Comment Seller 453=2 448=ACL 447=D 452=1 448=ClientSell 447=D 452=3 54=1 453=1 448=RPI 447=D 452=1 1040=E =thirdpartyid =1 1117=XTPF 1118=G 1119= =4 207=XSFE 55=n/a 10=234 ASX acknowledges seller approval of EFP 8=FIXT.1.1 9=508 35=AR 49=ASX_FIX 56=ACMECLEARERS 34=3 52= :41: =9 571=TAEM =0 856=0 828=2 572=efptpbond445 60= :41:00 555=2 600=XTH2015F 608=FXXXXX 685= = =CGL 608=DBX XXX 685= = = = =Mo 2163=6 611= = =2 54=2 58=Comment Seller 453=2 448=ACL 447=D 452=1 448=ClientSell 447=D 452=3 54=1 453=1 448=RPI 447=D 452=1 1040=E =thirdp artyid =1 1117=XTPF 1118=G 1119= =4 207=XSFE 55=n/a 10= Buying Participant The Buying Participant responds to the message from ASX informing them of the Selling Participant s acceptance of the trade that was originally reported by the Third Party Platform. The process and message flow between the Buying Participant and ASX is as follows: 1. ASX sends the Buying Participant a TCR informing them of the trade (B3). 2. The Buying Participant sends back a TCR accepting (B4b) or rejecting (B4a) the trade. 3. ASX sends a TCR Ack acknowledging receipt of the Buying Participant s TCR (B5 or B6). 4. If the Buying Participant accepted the report, ASX sends a final TCR informing of either confirmation (B8) or rejection (B7) of the trade. The tags and values used to identify each of these messages are defined in Appendix E Third Party Workflow Buying Participant Messages. For more information on application messages see 2.3 Application Messages Buyer Approves Third Party Bond EFP Example Messages ASX notifies buyer of EFP approved by seller; submitted by Third Party Platform 8=FIXT.1.1 9=469 35=AE 49=ASX_FIX 56=REDPLANET 34=2 52= :41: =9 571=TAEM =0 856=1 828=2 75= =2 600=XTH2015F 608=FXXXXX 685= = =CGL 608=DBXXXX 685= = = = =Mo 2163=6 611= = :41:00 552=2 54=2 453=1 448=ACL 447=D 452=1 54=1 453=2 448=RPI 447=D 452=1 448=BuyCli ent 447=D 452=3 1040=E =thirdpartyid =1 1117=XTPF 1118=G 1119= =4 207=XSFE 55=n/a 10=234 Buyer accepts the EFP 8=FIXT.1.1 9=415 35=AE 49=REDPLANET 56=ASX_FIX 34=2 52= :27: =efptcr =2 856=2 828=2 75= =2 600=XTH2015F 608=FXXXXX Copyright 2015 ASX Limited ABN All rights reserved