asx tradeaccept fix · pdf fileasx limited asx tradeaccept fix specification v1.1.s25 ... the...

ASX TradeAccept FIX Specification

Table of Contents

1. INTRODUCTION .............................................................................................................................................. 3

1.1. SUPPORTED PRODUCT TYPES FOR TRADE REPORTING ............................................................................... 3 1.1.1. Bilateral Trade Reporting ............................................................................................................... 3 1.1.2. Third Party Trade Reporting........................................................................................................... 3

2. SUPPORTED MESSAGES .............................................................................................................................. 4

2.1. COMMON MESSAGE STRUCTURES ............................................................................................................. 4 2.1.1. Standard Header ............................................................................................................................ 4 2.1.2. Standard Trailer ............................................................................................................................. 5

2.2. ADMINISTRATIVE MESSAGES ...................................................................................................................... 5 2.2.1. Logon (MsgType = A) .................................................................................................................... 5 2.2.2. Heartbeat (MsgType = 0) ............................................................................................................... 7 2.2.3. Test Request (MsgType = 1) ......................................................................................................... 7 2.2.4. Resend Request (MsgType = 2) .................................................................................................... 7 2.2.5. Sequence Reset (MsgType = 4) .................................................................................................... 8 2.2.6. Reject (MsgType = 3) ..................................................................................................................... 8 2.2.7. Logout (MsgType = 5) .................................................................................................................... 9

2.3. APPLICATION MESSAGES ......................................................................................................................... 10 2.3.1. Trade Capture Report (MsgType = AE) ....................................................................................... 10 2.3.2. Trade Capture Report Ack (MsgType = AR) ................................................................................ 16

3. REPORTING PROCESS................................................................................................................................ 23

3.1. BILATERAL TRADE REPORTING ................................................................................................................ 23 3.1.1. Bilateral Trade Reporting Workflow ............................................................................................. 23 3.1.2. Selling Participant ........................................................................................................................ 24 3.1.3. Buying Participant ........................................................................................................................ 25

3.2. THIRD PARTY TRADE REPORTING ............................................................................................................ 26 3.2.1. Third Party Trade Reporting Workflow ......................................................................................... 26 3.2.2. Third Party Platform ..................................................................................................................... 27 3.2.3. Selling Participant ........................................................................................................................ 27 3.2.4. Buying Participant ........................................................................................................................ 28

4. SESSION MANAGEMENT AND BUSINESS CONTINUITY ......................................................................... 30

4.1. SESSION MANAGEMENT .......................................................................................................................... 30 4.2. BUSINESS CONTINUITY ............................................................................................................................ 30

4.2.1. Primary Gateway.......................................................................................................................... 30 4.2.2. Secondary Gateway ..................................................................................................................... 30

APPENDIX A. BILATERAL WORKFLOW - SELLING PARTICIPANT MESSAGES ................................... 31

APPENDIX B. BILATERAL WORKFLOW - BUYING PARTICIPANT MESSAGES .................................... 32

APPENDIX C. THIRD PARTY WORKFLOW – THIRD PARTY PLATFORM MESSAGES .......................... 33

APPENDIX D. THIRD PARTY WORKFLOW – SELLING PARTICIPANT MESSAGES .............................. 34

APPENDIX E. THIRD PARTY WORKFLOW – BUYING PARTICIPANT MESSAGES ................................ 35

ASX Limited ASX TradeAccept FIX Specification v1.1.s25

© Copyright 2015 ASX Limited ABN 98 008 624 691. All rights reserved 2015 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

1.1.1. 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

1.1.2. 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



2. Supported Messages

This specification details the fields, messages and values that are used to support the reporting of off-market 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.

2.1. Common Message Structures

2.1.1. 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.

Field Field Name Req Data Type Description

8 BeginString Y String Identifies beginning of new message and protocol version. Always first field in message.

Valid values:

FIXT.1.1

9 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.

Valid values:

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




secondary gateway.

Valid values:

N Original Transmission

Y Possible Resend

See 4.2.2 Secondary Gateway for more details.

1128 ApplVerID String The version of FIX used in this specific message.

Valid values:

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.

2.1.2. 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.

2.2. 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)

2.2.1. 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.



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 2.2.7 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.

1137 DefaultApplVerID Y String The default version of FIX messages used in this session.

Valid values:

9 FIX 5.0 SP2

141 ResetSeqNumFlag Boolean Indicates that both sides of the FIX session should reset sequence numbers. MsgSeqNum must be 1.

Valid values:

N No

Y Yes, reset sequence numbers

Standard Trailer Y Trailer

2.2.1.1. 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 2.2.4.1 Resend Request Example.

< 8=FIXT.1.1|9=103|35=A|49=ACMECLEARERS|56=ASX|34=1|52=20140324-05:49:08|98=0|108=30|1137=9|553=acmeefpreport|554=vsecret|10=106|

> 8=FIXT.1.1|9=84|35=A|49=ASX|56=ACMECLEARERS|34=1|52=20140324-05:49:08.742|1128=9|98=0|108=30|1137=9|10=048|

2.2.1.2. Unsuccessful Logon Example

This following example illustrates an unsuccessful logon due to an issue with sequence numbers.


> 8=FIXT.1.1|9=117|35=5|49=ASX|56=ACMECLEARERS|34=17|52=20140324-05:54:45.864|1128=9|58=MsgSeqNum too low, expecting 17 but received 14|10=047|



2.2.2. 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.


2.2.3. 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.



112 TestReqID Y String Unique identifier of this Test Request. To be returned in the Heartbeat generated upon receipt of the Test Request.


2.2.3.1. 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=20140324-06:00:49|112=20140324-06:00:49|10=030|

> 8=FIXT.1.1|9=88|35=0|49=ASX|56=ACMECLEARERS|34=15|52=20140324-06:00:49.316|1128=9|112=20140324-06:00:49|10=040|

2.2.4. 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.



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.




2.2.4.1. 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=85|35=A|49=ASX|56=ACMECLEARERS|34=29|52=20140324-06:13:22.545|1128=9|98=0|108=30|1137=9|10=096|

< 8=FIXT.1.1|9=65|35=2|49=ACMECLEARERS|56=ASX|34=36|52=20140324-06: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=20140324-06:13:25.235|122=20140324-06:13:25.235|1128=9|123=Y|36=30|10=077|

2.2.5. 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 2.2.4.1 Resend Request Example for an example of a gap fill request.



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.

Valid values:

N Sequence Reset, Ignore Msg Seq Num

Y Gap Fill Message, Msg Seq Num Field Valid

36 NewSeqNo Y SeqNum New sequence number.


2.2.6. Reject (MsgType = 3)

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.



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 session-level Reject message.



2.2.6.1. 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=20140324-06:19:25|7=12|10=187|

> 8=FIXT.1.1|9=224|35=3|49=ASX|56=ACMECLEARERS|34=42|52=20140324-06:19:25.102|1128=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=108|

2.2.6.2. 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=20140324-06:28:19|7=12|16=|10=105|

> 8=FIXT.1.1|9=216|35=3|49=ASX|56=ACMECLEARERS|34=60|52=20140324-06:28:19.193|1128=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=118|

2.2.7. Logout (MsgType = 5)

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.

Valid values:

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.





If a Logout is sent as a result of authentication failure, ASX will provide a reason in this field.

1409 SessionStatus int Status of FIX session.

Returned by ASX if Logout is sent as a result of authentication failure.

Valid values:

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

2.2.7.1. 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=20140324-06:14:25|10=235|

> 8=FIXT.1.1|9=91|35=5|49=ASX|56=ACMECLEARERS|34=32|52=20140324-06:14:25.481|1128=9|58=Logout acknowledgment|10=010|

2.2.7.2. 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=20140526-04:55:31|108=30|1137=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=20140526-04:55:36.520|1128=9|58=Unable to authenticate user at this time. Please contact the ASX Helpdesk.|1409=7|10=110|

2.3. 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).

2.3.1. 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.




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 TradeReportTransType

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).

Valid values:

0 New

1 Cancel

2 Replace

See the relevant appendix for combining with TradeReportType.

828 TrdType int Type of trade being reported.

Valid values:

2 Exchange for physical (EFP)

856 TradeReportType int Type of trade report - status in the process.

Valid values:

0 Submit

1 Alleged

2 Accept

3 Decline

See the relevant appendix for information on combined use with TradeReportTransType.

1123 TradeHandlingInstr int Model of reporting being used.

Valid values:

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.

Valid values:

0 Compared, matched or affirmed

1 Uncompared, unmatched or unaffirmed

See the relevant appendix for usage of this field in reporting workflow.

1040 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




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.

Valid values:

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 off-market 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 TradeReportRejectReason

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.

Valid values:

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.

1328 RejectText String Description as to why the trade report was rejected. When TradeReportRejectReason is Other (99), this field is then required by the participant. It is included when this message is sent by ASX.

1116 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 > 0.

1118 RootPartyIDSource String Describes what is contained in RootPartyID. Required if NoRootPartyIDs > 0.

Valid values:

G MIC (ISO 10383 Market Identifier Code)

1119 RootPartyRole int The role of the party in the transaction e.g. executing firm. Required if RootPartyID specified.

Valid values:

73 Execution Venue

End of Repeating Group 1116, NoRootPartyIDs

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).

9006 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.

Valid values:

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.

Valid values:

1 or 2

Start of Repeating Group 453, NoPartyIDs

448 PartyID String Identifies the party. Required if




NoPartyIDs > 0.

447 PartyIDSource String Describes what is contained in PartyID. Required if NoPartyIDs > 0.

Valid values:

D Proprietary/Custom code

452 PartyRole int The role of the party in the transaction e.g. executing firm. Required if PartyID specified.

Valid values:

1 Executing Firm

3 Client ID

End of Repeating Group 453, NoPartyIDs

End of Repeating Group 552, NoSides

555 NoLegs NumInGroup Number of legs.

Valid values:

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)

Start of Repeating Group 555, NoLegs

600 LegSymbol String Identifies the instrument.

Valid Values

Future, Option: ASX 24 contract series ID e.g. IRU2015F, YTU2014C0096100

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.

Valid values:

FXXXXX Future

OXXXXX Option

DBXXXX Bond

XXXWXX Swap

OFIXXX XJO (in SPIvsXJO)




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.

9000 Delta float Option only: Delta value.

Valid values:

Decimal number between 0 and 1000, to 2 decimal places.

588 LegSettDate LocalMktDate Bond only: Settlement date.

739 LegDatedDate LocalMktDate Swap only: Start date.

9001 LegMarketYield Percentage Bond only: Market yield.

615 LegCouponRate Percentage Bond only: Coupon rate.

9004 LegSwapFloatingRate

Percentage Swap only: Optional. Floating rate of swap contract.

9003 LegSwapFixedRate Percentage Swap only: Fixed rate of swap contract.

2164 LegCouponFrequencyUnit

String Bond: Time unit of the bond’s coupon payment frequency.

Valid values:

Mo = Month

2163 LegCouponFrequencyPeriod

int Bond: Number of LegCouponFrequencyUnit periods between bond coupon payments.

Valid values:

1 monthly

2 every 2 months

3 quarterly

6 twice yearly

12 annually

9002 LegSwapFrequencyPeriod

int Swap: Number of months in swap periods.

Valid values:

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).

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.

1358 LegPutorCall int SPIvsXJO only: Type of XJO option.

Valid values:

0 Put

1 Call

9005 ASXCleared Boolean Swap only: Optional. True if swap is cleared by ASX.

End of Repeating Group 552, NoLegs


2.3.1.1. 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=20140821-00:53:01.499 |571=acmeefp3549 |487=0 |828=2 |856=0 |1123=3 |207=XSFE |75=20140821 |60=20140821-00: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=1000 |566=97.3 |600=CGL |608=DBXXXX |685=10000000 |588=20140821 |9001=1 |615=1 |2163=6 |2164=Mo |611=20150821 |10=004 |

2.3.2. 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 TradeReportTransType

int Identifies the type of trade report transaction - i.e. what the report is being used for (e.g. report a new trade).

Valid values:




0 New

2 Replace

828 TrdType int Type of trade being reported.

Valid values:

2 Exchange for physical (EFP)

856 TradeReportType String Type of trade report - status in the process.

Valid values:

0 Submit

2 Accept

3 Decline

1123 TradeHandlingInstr int Model of reporting being used.

Valid values:

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.

Valid values:

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 off-market 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 TradeReportRejectReason

int Populated if the referenced trade report has been rejected. RejectText (1328) will contain a description.

Valid values:

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)




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.

1328 RejectText String Populated if the referenced trade report has been rejected. Description of why trade report was rejected.

1116 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 > 0.

1118 RootPartyIDSource String Describes what is contained in RootPartyID. Required if NoRootPartyIDs > 0.

Valid values:

G MIC (ISO 10383 Market Identifier Code)

1119 RootPartyRole int The role of the party in the transaction e.g. executing firm. Required if RootPartyID specified.

Valid values:

73 Execution Venue

End of Repeating Group 1116, NoRootPartyIDs

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).

9006 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




54 Side char Side of order. Must be present if NoSides is present.

Valid values:

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.

Valid values:

1 or 2

Start of Repeating Group 453, NoPartyIDs

448 PartyID String Identifies the party. Required if NoPartyIDs > 0.

447 PartyIDSource String Describes what is contained in PartyID. Required if NoPartyIDs > 0.

Valid values:

D Proprietary/Custom code

452 PartyRole String The role of the party in the transaction e.g. executing firm. Required if PartyID specified.

Valid values:

1 Executing Firm

3 Client ID

End of Repeating Group 453, NoPartyIDs

End of Repeating Group 552, NoSides

555 NoLegs NumInGroup Number of legs.

Valid values:

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)

Start of Repeating Group 555, NoLegs

600 LegSymbol String Identifies the instrument.

Valid Values

Future, Option: ASX 24 contract series ID e.g. IRU2015F, YTU2014C0096100

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.

Valid values:

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.

9000 Delta float Option only: Delta value.

Valid values:

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.

9001 LegMarketYield Percentage Bond only: Market yield.

615 LegCouponRate Percentage Bond only: Coupon rate.

9004 LegSwapFloatingRate

Percentage Swap only: Optional. Floating rate of swap contract.

9003 LegSwapFixedRate Percentage Swap only: Fixed rate of swap contract.

2164 LegCouponFrequencyUnit

String Time unit of the bond’s coupon payment frequency.

Valid values:

Mo = Month

2163 LegCouponFrequencyPeriod

int Number of LegCouponFrequencyUnit periods between bond coupon payments.

Valid values:

1 monthly

3 quarterly

6 twice yearly

12 annually

9002 LegSwapFrequency int Swap: Number of months in swap




Period periods.

Valid values:

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.

1358 LegPutorCall int SPIvsXJO only: Type of XJO option.

Valid values:

0 Put

1 Call

9005 ASXCleared Boolean Swap only: Optional. True if swap is cleared by ASX.

End of Repeating Group 552, NoLegs


2.3.2.1. 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=440 |35=AR |49=ASX_FIX |56=ACMECLEARERS |34=2 |52=20140821-00:53:07.299 |1128=9 |571=TAEM63544150756 |487=0 |856=0 |828=2 |572=acmeefp3549 |60=20140821-00:53:01 |555=2 |600=IRZ2014F |608=FXXXXX |685=1000 |566=97.3 |600=CGL |608=DBXXXX |685=10000000 |588=20140821 |9001=1 |615=1 |2164=Mo |2163=6 |611=20150821 |75=20140821 |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 |1040=E17129 |1123=3 |207=XSFE |55=n/a |10=232 |



2.3.2.2. 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=504 |35=AR |49=ASX_FIX |56=ACMECLEARERS |34=7 |52=20140821-00:53:07.448 |1128=9 |571=TAEM63544150761 |487=0 |856=4 |828=2 |572=acmeefp3554 |751=4 |60=20140821-00:53:01 |555=2 |600=IRZ2014F |608=FXXXXX |685=1000 |566=97.3 |600=CGL |608=DBXXXX |685=10000000 |588=20140821 |9001=1 |615=1 |2164=Mo |2163=6 |611=20150821 |75=20140821 |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 |1123=3 |207=XSFE |1328=Must specify a valid TradeReportType (856). Do not recognise 4. |55=n/a |10=087 |



3. Reporting Process

The sections below describe the workflow between ASX, the Seller, the Buyer and the Third Party Platform for 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.

3.1. Bilateral Trade Reporting

3.1.1. 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.



3.1.2. 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.

3.1.2.1. 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=20140918-03:52:11.817|571=efpsys2267|487=0|828=2|856=0|1123=3|207=XSFE|75=20140918|60=20140918-03: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|447=D|452=1|555=2|600=XTZ2014F|608=FXXXXX|685=213|566=96.520|600=CGL|608=DBXXXX|685=2500000|588=20140918|9001=3.4875|615=2.75|2163=6|2164=Mo|611=20240915|10=203|

ASX acknowledges receipt of EFP submission

8=FIXT.1.1|9=444|35=AR|49=ASX_FIX|56=ACMECLEARERS|34=365|52=20140918-03:52:21.410|1128=9|571=TAEM63546645133|487=0|856=0|828=2|60=20140918-13:52:00|555=2|600=XTZ2014F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20140918|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20240915|75=20140918|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|447=D|452=1|1040=E19795|1123=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=20140918-03:52:41.436|1128=9|571=TAEM63546645154|487=2|856=2|828=2|60=20140918-13:52:00|555=2|600=XTZ2014F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20140918|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20240915|75=20140918|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|447=D|452=1|1040=E19795|1123=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=20140918-03:53:21.513|1128=9|571=TAEM63546645194|487=2|856=0|828=2|75=20140918|555=2|600=XTZ2014F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20140918|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20240915|60=20140918-13:52:00|573=0|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|447=D|452=1|1040=E19795|1123=0|207=XSFE|55=n/a|10=142|

3.1.3. 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.

3.1.3.1. 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=20140918-03:52:21.408|1128=9|571=TAEM63546645133|487=0|856=1|828=2|75=20140918|555=2|600=XTZ2014F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20140918|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20240915|60=20140918-13:52:00|552=2|54=2|453=1|448=ACL|447=D|452=1|54=1|453=1|448=RPI|447=D|452=1|1040=E19795|1123=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=20140918-03:52:29.232|571=efpsys1842|487=2|828=2|856=2|1123=3|1040=E19795|207=XSFE|75=20140918|60=20140918-03: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=213|566=96.520|600=CGL|608=DBXXXX|685=2500000|588=20140918|9001=3.4875|615=2.75|2163=6|2164=Mo|611=20240915|10=194|

ASX acknowledges receipt of buyer acceptance

8=FIXT.1.1|9=437|35=AR|49=ASX_FIX|56=REDPLANETINV|34=363|52=20140918-03:52:41.430|1128=9|571=TAEM63546645154|487=2|856=2|828=2|60=20140918-13:52:00|555=2|600=XTZ2014F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20140918|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20240915|75=20140918|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=E19795|1123=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=20140918-03:53:21.511|1128=9|571=TAEM63546645194|487=2|856=0|828=2|75=20140918|555=2|600=XTZ2014F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20140918|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20240915|60=20140918-13: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=E19795|1123=0|207=XSFE|55=n/a|10=036|



3.2. Third Party Trade Reporting

3.2.1. 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.



3.2.2. 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.

3.2.2.1. 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=20150122-05:41:36.181| 571=efptpbond445|487=0|856=0|828=2|75=20150122|555=2|600=XTH2015F|608=FXXXXX|685=213|566=96.520|600=CGL|608=DBXXXX|685=2500000|588=20150122|9001=3.4875|615=2.75|2164=Mo|2163=6|611=20160122|60=20150122-05: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|448=BuyClient|447=D|452=3|1041=thirdpartyid-446|1116=1|1117=XTPF|1118=G|1119=73| 1123=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=20150122-05:41:36.747| 1128=9|571=TAEM63557541696|487=0|856=0|828=2|572=efptpbond445|60=20150122-16:41:00|555=2|600=XTH2015F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20150122|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20160122|75=20150122|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|448=BuyClient|447=D|452=3|1040=E39629|1041=thirdpartyid-446|1116=1|1117=XTPF|1118=G|1119=73|1123=4|207=XSFE|55=n/a|10=156|

3.2.3. 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.

3.2.3.1. Seller Approves Third Party Bond EFP – Example Messages

ASX notifies seller of Third Party Platform submission of the EFP



8=FIXT.1.1|9=473|35=AE|49=ASX_FIX|56=ACMECLEARERS|34=2|52=20150122-05:41:36.751| 1128=9|571=TAEM63557541696|487=0|856=1|828=2|75=20150122|555=2|600=XTH2015F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20150122|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20160122|60=20150122-16: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=E39629|1041=thirdpartyid-446|1116=1|1117=XTPF|1118=G| 1119=73|1123=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=20150122-05:41:36.645| 571=efptpbond8471|487=0|856=2|828=2|75=20150122|555=2|600=XTH2015F|608=FXXXXX|685=213|566=96.520|600=CGL|608=DBXXXX|685=2500000|588=20150122|9001=3.4875|615=2.75|2164=Mo|2163=6|611=20160122|60=20150122-05: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=E39629|1041=thirdpartyid-446|1116=1|1117=XTPF| 1118=G|1119=73|1123=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=20150122-05:41:37.035| 1128=9|571=TAEM63557541697|487=0|856=0|828=2|572=efptpbond445|60=20150122-16:41:00|555=2|600=XTH2015F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20150122|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20160122|75=20150122|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=E39629|1041=thirdpartyid-446|1116=1|1117=XTPF|1118=G|1119=73|1123=4|207=XSFE|55=n/a|10=094|

3.2.4. 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.

3.2.4.1. 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=20150122-05:41:37.030| 1128=9|571=TAEM63557541697|487=0|856=1|828=2|75=20150122|555=2|600=XTH2015F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20150122|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20160122|60=20150122-16: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=BuyClient|447=D|452=3|1040=E39629|1041=thirdpartyid-446|1116=1|1117=XTPF|1118=G| 1119=73|1123=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=20150122-06:27:49.737| 571=efptcr-2895|487=2|856=2|828=2|75=20150122|555=2|600=XTH2015F|608=FXXXXX|



685=213|566=96.520|600=CGL|608=DBXXXX|685=2500000|588=20150122|9001=3.4875|615=2.75|2164=Mo|2163=6|611=20160122|60=20150122-06:27:49|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=E39646|1123=4|207=XSFE|55=n/a|10=086|

ASX acknowledges buyer approval of EFP

8=FIXT.1.1|9=486|35=AR|49=ASX_FIX|56=REDPLANET|34=3|52=20150122-06:27:50.114|1128=9|571=TAEM63557544469|487=2|856=2|828=2|60=20150122-17:27:00|555=2|600=XTH2015F|608=FXXXXX|685=213|566=96.5200000|600=CGL|608=DBXXXX|685=2500000|588=20150122|9001=3.48750|615=2.750|2164=Mo|2163=6|611=20160122|75=20150122|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=E39629|1041=thirdpartyid-452|1116=1|1117=XTPF|1118=G|1119=73|1123=4|207=XSFE|55=n/a|10=195|



4. Session Management and Business Continuity

4.1. Session Management

The gateway (FIX server) to which the participant connects, maintains the FIX session information for the entire trading period of ASX Trade24. Any messages delivered by the server to a FIX session are available for retrieval from the start of the trading period on Monday until midday Saturday. They are available if a FIX session connects to the server in the middle of the period or issues a resend request to retrieve missed messages.

After the end of the ASX Trade24 trading period the FIX sessions are reset and messages are no longer available. That is, after midday Saturday, all messages received from TradeAccept during that calendar week are effectively erased from the gateway’s cache and can no longer be retrieved by the participant. This includes any potential trades reported for Monday that were entered into the TradeAccept system on Friday night or Saturday morning.

4.2. Business Continuity

In order to provide customers with resiliency in the event of technical failures on ASX equipment (such as hardware or network issues), TradeAccept has two gateways; a primary and a secondary. Both gateways are active during the operational period and accept the same connections from the customer.

4.2.1. Primary Gateway

The primary gateway is the standard gateway for day to day operations. The standard FIX session is supported where resends and gap fill requests will be accepted and processed.

4.2.2. Secondary Gateway

The secondary gateway is designed to be used in the event of the primary gateway being unavailable. A customer may remain permanently connected if they require a shorter time in message recovery process.

The first logon to the gateway must be with inbound and outbound sequence numbers set to 1 and ResetSeqNumFlag set to No (141=N). Logon attempts with a sequence number greater than 1 will be rejected. Upon successful logon ASX will send all messages queued prior to the logon time with the PossResend (tag 97) flag set. On subsequent logins the PossResend flag will not be set, even if a resend request is issued for messages that were previously transmitted with the flag set.

Note: If the initial connection to the secondary gateway is made with ResetSeqNumFlag set to Yes (141=Y) all queued messages will be discarded.



Appendix A. Bilateral Workflow - Selling Participant Messages

The following table describes the tags and values used to identify each of these messages between ASX and the Selling Participant for trades submitted bilaterally. Items in the first column correspond to the labels in Figure 1 Bilateral Trade Reporting Workflow.

Item In/Out of ASX

Purpose Msg Type

[35]

Trade Report Trans Type

[487]

Trade Report

Type [856]

Trade Handling Instr [1123]

Secondary Trade ID

[1040]

Comment

S1 In Report trade TCR (AE) New (0) Submit (0) One-Party Report for Pass-Through (3)

n/a

S2 Out Reject from ASX – invalid details

TCR Ack (AR)

New (0) Submit (0) One-Party Report for Pass-Through (3)

n/a TradeReport Reject Reason details why rejected. TradeReportRefID from S1 message.

S3 Out Ack - accepted by ASX for processing

TCR Ack (AR)

New (0) Submit (0) One-Party Report for Pass-Through (3)

Deal number Buying Participant is notified of TCR. TradeReportRefID from S1 message.

S5 Out Rejected by Buying Participant

TCR (AE) Cancel (1) Decline (3) One-Party Report for Pass-Through (3)

Deal number

S6 Out Accepted by Buying Participant – pending ASX confirmation of trade

TCR Ack (AR)

Replace (2) Accept (2) One-Party Report for Pass-Through (3)

Deal number

S7 Out Rejected by ASX – trade is not allowed


Deal number MatchStatus = 1

S8 Out Trade confirm – successful lodgement

TCR (AE) Replace (2) Submit (0) Trade Confirm (0) Deal number MatchStatus = 0



Appendix B. Bilateral Workflow - Buying Participant Messages

The following table describes the tags and values used to identify each of these messages between ASX and the Buying Participant for trades submitted bilaterally. Items in the first column correspond to the labels in Figure 1 Bilateral Trade Reporting Workflow.

Item In/Out of ASX

Purpose Msg Type

[35]


[487]

Trade Report Type [856]


Secondary Trade ID [1040]

Comment

B3 Out Inform of trade – alleged trade

TCR (AE) New (0) Alleged (1) One-Party Report for Pass-Through (3)

Deal number

B4a In Buying Participant rejects trade

TCR (AE) Replace (2) Decline (3) One-Party Report for Pass-Through (3)

Deal number

B4b In Accepted by Buying Participant

TCR (AE) Replace (2) Accept (2) One-Party Report for Pass-Through (3)

Deal number

B5 Out Acknowledge reject TCR Ack (AR) Replace (2) Decline (3) One-Party Report for Pass-Through (3)

Deal number

B6 Out Acknowledge accept – pending ASX confirmation of trade

TCR Ack (AR) Replace (2) Accept (2) One-Party Report for Pass-Through (3)

Deal number

B7 Out Rejected by ASX - trade is not allowed



B8 Out Trade confirm – successful lodgement




Appendix C. Third Party Workflow – Third Party Platform Messages

The following table describes the tags and values used to identify each of these messages between ASX and the Third Party Platform. Items in the first column correspond to the labels in Figure 2 Third Party Trade Reporting Workflow.

Item In/Out of ASX

Purpose Msg Type

[35]


[487]




Comment

T1 In Report trade TCR (AE) New (0) Submit (0) Automated floor order routing (4)

T2 Out Reject from ASX – invalid details

TCR Ack (AR) New (0) Submit (0) Automated floor order routing (4)

n/a TradeReport Reject Reason details why rejected. TradeReportRefID from T1 message

T3 Out Ack - accepted by ASX for processing

TCR Ack (AR) New (0) Submit (0) Automated floor order routing (4)

Deal number Selling Participant is notified of TCR. TradeReportRefID from T1 message



Appendix D. Third Party Workflow – Selling Participant Messages

The following table describes the tags and values used to identify each of these messages between ASX and the Selling Participant for trades submitted by a third party platform. Items in the first column correspond to the labels in Figure 2 Third Party Trade Reporting Workflow.

Item In/Out of ASX

Purpose Msg Type

[35]


[487]

Trade Report

Type [856]


Secondary Trade ID

[1040]

Comment

S9 Out Inform of trade – alleged trade

TCR (AE) New (0) Alleged (1) Automated floor order routing (4)

Deal number

S10a In Selling Participant rejects trade

TCR (AE) New (0) Decline (3) Automated floor order routing (4)

Deal number

S10b In Accepted by Selling Participant

TCR (AE) New (0) Accept (2) Automated floor order routing (4)

Deal number

S11 Out Acknowledge reject TCR Ack (AR)

New (0) Decline (3) Automated floor order routing (4)

Deal number

S3 Out Ack - accepted by ASX for processing

TCR Ack (AR)

New (0) Submit (0) Automated floor order routing (4)

Deal number Buying Participant is notified of TCR.

S5 Out Rejected by Buying Participant

TCR (AE) Cancel (1) Decline (3) Automated floor order routing (4)

Deal number

S6 Out Accepted by Buying Participant – pending ASX confirmation of trade

TCR Ack (AR)

Replace (2) Accept (2) Automated floor order routing (4)

Deal number

S7 Out Rejected by ASX – trade is not allowed



S8 Out Trade confirm – successful lodgement




Appendix E. Third Party Workflow – Buying Participant Messages

The following table describes the tags and values used to identify each of these messages between ASX and the Buying Participant for trades submitted by a third party platform. Items in the first column correspond to the labels in Figure 2 Third Party Trade Reporting Workflow.

Item In/Out of ASX

Purpose Msg Type

[35]


[487]




Comment

B3 Out Inform of trade – alleged trade

TCR (AE) New (0) Alleged (1) Automated floor order routing (4)

Deal number

B4a In Buying Participant rejects trade

TCR (AE) Replace (2) Decline (3) Automated floor order routing (4)

Deal number

B4b In Accepted by Buying Participant

TCR (AE) Replace (2) Accept (2) Automated floor order routing (4)

Deal number

B5 Out Acknowledge reject TCR Ack (AR) Replace (2) Decline (3) Automated floor order routing (4)

Deal number

B6 Out Acknowledge accept – pending ASX confirmation of trade

TCR Ack (AR) Replace (2) Accept (2) Automated floor order routing (4)

Deal number

B7 Out Rejected by ASX - trade is not allowed



B8 Out Trade confirm – successful lodgement




Disclaimer

This document provides general information only and may be subject to change at any time without notice. ASX Limited (ABN 98 008 624 691) and its related bodies corporate (“ASX”) makes no representation or warranty with respect to the accuracy, reliability or completeness of this information. To the extent permitted by law, ASX and its employees, officers and contractors shall not be liable for any loss or damage arising in any way, including by way of negligence, from or in connection with any information provided or omitted, or from anyone acting or refraining to act in reliance on this information. The information in this document is not a substitute for any relevant operating rules, and in the event of any inconsistency between this document and the operating rules, the operating rules prevail to the extent of the inconsistency.

ASX Trade Marks

The trade marks listed below are trade marks of ASX. Where a mark is indicated as registered it is registered in Australia and may also be registered in other countries. Nothing contained in this document should be construed as being any licence or right to use of any trade mark contained within the document.

ASX®, ASX Trade24®

asx tradeaccept fix · pdf fileasx limited asx tradeaccept fix specification v1.1.s25 ... the...

Documents