SERVICE & TECHNICAL DESCRIPTION
Non-Member OTC Trade Reporting
CONTENTS
1. Service Description ... 3
1.1.1 Monitoring...6
1.1.2 Correction Process ...7
1.1.3 Publication Delay...7
1.1.4 Trade Reporting Responsibility ...8
1.2 Market data ...9
2. Technical Description ... 11
2.1 INTRODUCTION... 11
2.1.1 Readership ...11
2.2 SUMMARY OF TECHNICAL CHANGES ... 11
2.3 SERVICE ACCESS... 13
2.3.1 Network Access...13
2.3.2 Business Hours ...13
2.4 TRADE REPORT MAPPING ... 13
2.4.1 Message Level Mapping...13
2.4.2 Field Level Mapping ...14
2.5 TESTING REQUIREMENTS ... 28
1. Service Description
Service Summary
The Exchange will provide a pan-European OTC trade reporting service to
allow non-member firms to meet their post-trade transparency obligations.
The service will support publication for any unregulated trades executed
away from the Exchange’s markets.
Key features:
• ‘One stop shop’ pan-European service available from 07:15 to 17:15
UK time / 08:15 to 18:15 CET. Reports received outside these hours
will be stored and then forwarded for publication once the system
opens
• Open on all EU business days for the European Markets. The LSE
Markets (including the UK and International trading services) will be
open on all UK business days
• Designed for customers to meet their requirement for immediate
real-time trade reporting with a backstop of three minutes
• Fully automated management of any publication delays applicable
under MiFID
• Real-time price monitoring to uphold data integrity
• Venue ID displayed for each trade
• Publication to over 100,000 terminals, displayed in over 100
countries, and to over 150 vendors
• Delivered on the Exchange’s next generation trading technology
offering the highest levels of availability
• Global publication via our website showing delayed data free of
charge
1Trade Types & Venue ID
Trade types will be used to demonstrate that a trade has been executed
OTC rather than on Exchange. Customers will need to select the suitable
trade type and report the transaction to the Exchange.
The table below shows the trade types that will be offered for reporting
OTC trades and the Venue ID that will be shown per trade type. We will
automatically populate the Venue ID field on the published trade report
based on the selected trade type. Our current understanding is that the
Venue ID should be a suitable Market Identifier Code (MIC)
2.
Non-members reporting inter-fund crosses will be able to use a specific
trade type to notify the market.
Customers will automatically receive any applicable delay to their trade
report.
On Exchange or OTC TradElect Trade Type Description Venue IDOTC OT OTC trade immediate publication XOFF
OTC TK OTC delayed publication XOFF
OTC IF Inter fund cross publication XOFF
Please note these trade types are only applicable to trade reports in
European Regulated Market (EURM) securities.
Subscription
Non-member firms wishing to use the OTC reporting service will need to
subscribe. The relevant form will be available via eContracts:
http://www.londonstockexchange.com/en-gb/products/eContracts/
FIX Connectivity
The FIX Gateway is the Exchange’s electronic messaging network for both
buy and sell side firms. It is based on FIX 4.2 and is vendor and network
neutral supporting connections via TNS, BT Radianz and Extranex, the
Exchange’s own network.
The Gateway will be linked into TradElect for trade reporting purposes only
and will support additional tags from FIX 4.4 and other industry standards to
support the required information to enable a report to be fully populated.
Testing will be available from mid-August and the service will go live during
October 2007.
Using the FIX Gateway in this manner allows non-member firms to take
advantage of standardised FIX connectivity to access the Exchange’s OTC
trade reporting service via TradElect and take advantage of the same
technological and data integrity surveillance benefits as offered to any on
Exchange reports.
Please contact your account manager if you are an existing customer and/or
for further information and the
relevant documentation.
Stock Coverage & Other Features
We estimate approximately 10,000-15,000 new securities will be traded on
this service. The scalability of the Exchange’s next generation trading
technology means that this incremental service can be accommodated
within system capacity.
The table below sets out the segmentation of the stocks as set up in the
Exchange’s systems:
OFF EXCHANGE OTC Trade Reporting Stock Coverage Timezone* (MiFID securities only)
SETS FTSE All Share & some Fledgling UK (GMT / BST)
9
SETSqx Remaining Fledgling & non-indexed equities on Main Market UK (GMT / BST)
9
ITBB International securities including Japan, Hong Kong & some EURM UK (GMT / BST)
9
IRS Major European and US blue chip
securities & some EURM UK (GMT / BST)
9
EuroSETS Dutch Liquids and all equities in AMX and
AEX indices CET
9
EQS EURM Liquid equities (non-UK / Dutch) CET
9
ITR Remaining EURM, non-Liquid equities CET
9
NOTES
* The trade time populated in a trade report must be specified in the applicable timezone ** Available for only the few MiFID securities / EURM securities which are in segment UK
European International
All EURM stocks
The ETR off Exchange service supports trade reporting in all EURM securities
and is available in the securities on the trading services (SETS, SETSqx, EQS,
EUROSETS) as well as the MiFID regulated market segment of the
International Bulletin Board (ITBB) and the International Retail Service (IRS).
In addition, a new trade reporting only segment (International Trade
Reporting ‘ITR’) will be introduced for the remainder of EURM securities not
traded on the above services.
• Market Segments & Sector Structure: the market segment structure
is available at
MiFID Servicewhich contains full details on all these
• Currency: the currency of trading for the respective securities will
be determined on a security-by-security basis and will follow the
Home Market. Due to the broad geographical spread of securities on
the market, a wide range of international currencies will be
represented. Trades executed in currencies that are not the Home
Market currency will be converted by the reporting party into the
Home Market currency for reporting purposes.
• Stock Suspension in the Home Market: where a stock is suspended
on the Home Market for regulatory reasons, the FSA will ordinarily
require all UK markets to also suspend trading, “unless
this would
damage the interest of investors or the orderly functioning of the
financial markets” [Article 41(2) of MiFID]. Where trading is halted
in the Home Market owing to technical reasons or pending news
announcements, we will continue to operate our service unless
instructed to do otherwise by the FSA.
The most important distinction is between those securities that are UK
listed (“UK” and a few in the “International” segments) and the European
securities that are not listed on a UK market. A trade must be reported in
the local time relevant to each security.
UK securities (including those trading on an International service)
• Time Zone: the market operates on GMT / BST - 07:15 to 17:15.
• Business Calendar: the market will be open each weekday with the
exception of days that are public holidays within UK. The business
calendar will be kept under review and will be published annually in
Q4.
European securities
• Time Zone: the market operates on CET - 08:15 to 18:15.
• Business Calendar: the market will be open each weekday with the
exception of days that are public holidays within the entire EU. The
business calendar will be kept under review and will be published
annually in Q4. The public holidays for the European Market for the
remainder of 2007 will be 25 and 26 December.
1.1.1 Monitoring
The Exchange has supported the FSA and the EU in their efforts to seek an
effective approach that maintains and promotes data integrity and identifies
an effective way of enabling data to be consolidated. Our investment in a
pan-European service means the level of quality can be achieved across all
equities and will ensure we can comply with both MiFID’s regulatory
standards and the FSA’s Trade Data Monitor (TDM) guidelines for OTC
reporting
3.
OTC trade reports will be monitored in line with MiFID and the FSA’s TDM
guidelines. Monitoring will consist of at least the activities shown below.
• Real time price monitoring. TradElect rejects any outlier trade
reports to prevent ‘fat finger’ errors being published to the market.
• Published trades will be monitored by our surveillance system to
ensure data integrity, with firms disseminating corrections as
required.
1.1.2 Correction Process
Where a correction to a trade report is to be submitted within three days of
publication of the trade report or, where the trade report will not be
published within three days of submission of the trade report, the correction
shall be effected by:
• cancelling the trade report (which will prevent an incorrect trade
report publishing if this is done before a delayed report’s delay has
expired); and
• if correcting an error in the trade report, submitting a new trade
report.
1.1.3 Publication Delay
Post-MiFID, the Exchange’s service will be enhanced to offer a fully
automated publication delay regime for all EURM securities. The delay will
be calculated as per the regime specified in MiFID using the Average Daily
Turnover (ADT) (see appendix B for further details). This regime will be
used in MiFID and non-MiFID securities with the exception of Gilts and Fixed
Interest securities which will continue to operate as today. Gilts will
continue to publish only if the consideration is less than £50,000 and risk
trades in Fixed Interest securities will publish with a one-day delay.
When a trade type offering delayed publication is used the system will
check whether there is any applicable delay and apply this.
The delay will follow the Business Calendar for the trading service on which
the security is traded.
EURM securities whether traded on the Exchange’s Regulated Markets or as
an MTF will have the ADT set by the relevant competent authority (e.g.
FSA). Non-EURM securities traded on our markets will have the ADT
calculated and set by the Exchange. This information will be included in the
Exchange’s reference data.
Publication thresholds will be translated into the trading currency of the
relevant security. These will be reviewed on an at least an annual basis and
will be rounded to provide a suitable number of shares.
The Exchange will use MiFID’s methodology for publication delay in all
equity markets (including the Main Market and AIM). For non-EURM
securities, the Exchange will set parameters that are relevant for that
specific market. These will be published in due course.
1.1.4 Trade Reporting Responsibility
Where the transaction is executed outside the rules of a regulated market
or an MTF, one of the participating investment firms shall, by agreement
between the parties, arrange to make the information public.
In the absence of an alternative agreement, the information shall be made
public by the investment firm determined by proceeding sequentially from
point (a) to point (d) until the first point that applies to the case in
question.
(a) the investment firm that sells the share concerned;
(b) the investment firm that acts on behalf of or arranges the transaction
for the seller;
(c) the investment firm that acts on behalf of or arranges the transaction for
the buyer;
1.2 Market data
The Exchange OTC market data service offering will be as follows:
• We will include the relevant and appropriate trade reports within
existing UK and International on Exchange data channels for ease of
implementation and use amongst current subscribers. New
European OTC data will also be disseminated via the existing
European channels. There will be no additional charge for receiving
this OTC data within these existing data channels.
• In addition, we will offer a new service package (consisting of two
core service channels: S21 and S22 in the diagram below) that is
purely for off book trades data, covering existing UK, International,
EUROSETS and new European off book trade reports. This will
include both on Exchange and OTC trade reports.
Note that we are renaming the “DTS” data service to “European” as it will
not only include the EUROSETS (DTS) data as it does today but also the new
European data generated in EQS and ITR.
The new channels will be disseminated via the Exchange’s highly reliable
and resilient market data system, Infolect, and will be fully integrated
within our feed to minimise the impact on customers wishing to take this
additional data set.
The diagram below shows the service channels which will disseminate off
book trade reports in EURM securities post-MiFID. “On Exchange Trade
Data” refers to off book trades regulated by the Exchange’s Rules.
TradElect
Infolect
New UK / Intl Data
New European Data UK OTC Trade Data
Intl. OTC Trade Data
New European OTC Trade Data
UK On Book Trade Data
UK On Exchange Trade Data
UK OTC Trade Data
S05 International Level 1
Intl. On Exchange Trade Data International On
Book Trade Data
Intl. OTC Trade Data
S21 Off Book Trade Data
UK On Exchange Trade Data
UK OTC Trade Data
Intl. On Exchange Trade Data
Intl. OTC Trade Data
S01 UK Level 1
S09 European Level 1
New European OTC Trade Data New European On
Exchange Trade Data EUROSETS On Book
Trade Data
EUROSETS On Exchange Trade Data
EUROSETS OTC Trade Data
S22 European Off Book Trade Data
New European OTC Trade Data New European On
Exchange Trade Data EUROSETS On Exchange Trade Data
EUROSETS OTC Trade Data EUROSETS OTC
Trade Data
TradElect
Infolect
New UK / Intl Data
New European Data UK OTC Trade Data
Intl. OTC Trade Data
New European OTC Trade Data
UK On Book Trade Data
UK On Exchange Trade Data
UK OTC Trade Data
S05 International Level 1
Intl. On Exchange Trade Data International On
Book Trade Data
Intl. OTC Trade Data
S21 Off Book Trade Data
UK On Exchange Trade Data
UK OTC Trade Data
Intl. On Exchange Trade Data
Intl. OTC Trade Data
S01 UK Level 1
S09 European Level 1
New European OTC Trade Data New European On
Exchange Trade Data EUROSETS On Book
Trade Data
EUROSETS On Exchange Trade Data
EUROSETS OTC Trade Data
S22 European Off Book Trade Data
New European OTC Trade Data New European On
Exchange Trade Data EUROSETS On Exchange Trade Data
EUROSETS OTC Trade Data EUROSETS OTC
Trade Data
2. Technical Description
2.1 INTRODUCTION
This section describes the technical aspects of the London Stock Exchange’s FIX Trade Reporting Service that maps FIX “Trade Report” messages to the equivalent TradElect “Trade Report” messages.
FIX Trade Report messages are routed to and from the London Stock Exchange’s TradElect trading system via the existing London Stock Exchange FIX Gateway. The mapping information is based on the formats defined in the Exchange’s Technical Specifications that are available at the link detailed in section 2.1.1..
2.1.1 Pre-requisites
This section is aimed at readers requiring an understanding of the London Stock Exchange FIX Gateway, technical details of which are available on our website at:
http://www.londonstockexchange.com/en-gb/products/membershiptrading/tradingservices/Fix+Gateway+1/
A basic understanding of the FIX Protocol specification is also required, and these can be found at the FIX Protocol website at:
http://www.fixprotocol.org/specifications/
It is assumed that readers are familiar with TradElect and the Exchange’s Technical Specifications that are available on our website at:
http://www.londonstockexchange.com/en-gb/products/membershiptrading/techlib/techspecs.htm
Readers who want a more general understanding of the changes described below should refer to the service description section of this document.
2.2 SUMMARY OF TECHNICAL CHANGES
A summary of the service that we are introducing is detailed below. Where possible, the Exchange has sought to leverage existing infrastructure and message types to minimise disruption and development cost for firms.
The service is based on the Exchange's FIX Gateway product which uses a 4.2 FIX Session plus two custom FIX 4.4 messages to support Network Status Request. The service uses two FIX 4.4 messages to support Trade Reporting: the Trade Capture Report message (MsgType = AE) and the Trade Capture Report Ack (Msg Type= AR).
• A FIX Trade Report message is sent to the FIX Gateway and received by this service.
• The equivalent TradElect Trade Report message is created and sent to the TradElect trading system.
• TradElect will acknowledge this Trade Report and send the appropriate response message back to the FIX Gateway..
• The equivalent FIX Trade Report acknowledgment message is created and sent to the originator of the FIX Trade Report from the FIX Gateway.
The service supports ‘Over The Counter’ (OTC) business only. As a result, only the following trade types can be submitted using this service:
FIX TrdType (828) TradElect Trade Type Description
1 0 OT OTC trade immediate publication
2 1 TK OTC delayed publication
2 42 IF Inter fund cross delayed publication
For further information on these trade types, please refer to Section 1 Service Description.
The diagram below shows the message flow through the services used by the FIX Trade Reporting Service.
FIX Gateway
Supporting FIX Message Types AE and AR
TradElect
FIX
Interface TradElect Interface
Trade Report Customer #1 Trade Report Customer #2 Trade Report Customer #3 4.2 FIX Session, Msg Types AE / AR 4.2 FIX Session, Msg Types AE / AR Level 1 Multicast Msg Type 5OZ Map FIX Trade Capture
message to SETS Trade Report
Map SETS Response to FIX Trade Capture Ack message AE AR 5ET / 5CN 5AT / 5PH / 5IC Infolect FIX Trade Reporting Service
2.3 SERVICE
ACCESS
2.3.1 Network Access
Connectivity to the FIX Gateway is currently available via the Exchange’s own network (Extranex), or via third party Network Providers (such as Radianz or TNS). For the test service participants can also use the Internet.
Extranex access to the FIX Gateway is via an address range allocated by the
Exchange as part of the enablement process. For third party network providers, this will be allocated by the provider. Customers using Extranex can either use the native addressing scheme or use their own devices to network translate to and from the allocated addresses. For further information regarding the enablement process and the Exchange’s Extranex service, please contact the Client Technology Group (see section 1.6 Contact Details).
2.3.2 Business Hours
Market Segment Rules determine the times during which trade reports may be entered on the trading system (07:00 to 17:15 UK time / 08:00 to 18:15 CET). TradElect system hours are from 07:00 to 20:00 UK time.
The FIX Gateway operates 23.5 hours a day, 5 days a week. The FIX Gateway is closed for maintenance daily between 22:30 and 23:00 UK time. As a result, the FIX Trade Reporting “session” will open as soon as this service is started and any Trade Report messages received while TradElect is unavailable will be stored by this service for passing on to TradElect when it becomes available.
Please note that all trades should be submitted with a trade time specified in UTC. This service will be responsible for any conversion to local time.
2.4 TRADE REPORT MAPPING
This section describes the FIX and TradElect messages that require mapping, and the specific field mappings that have been identified.
2.4.1 Message Level Mapping
There are 2 FIX messages and 5 TradElect messages involved with this service. These are listed in the table below.
From Message Description To Message Description
1 FIX AE Trade Capture Report for “New Trade”
TradElect 5ET (AD) Enter Trade Report 2 FIX AE Trade Capture
Report for “Cancel Trade” TradElect 5CN (AB) Cancel Trade Report
3 TradElect 5AT (AB) Acknowledge Trade Report
FIX AR Trade Capture
Report Ack 4 TradElect 5PH (AB) Acknowledge
Cancel Trade Report
FIX AR Trade Capture
Report Ack 5 TradElect 5IC (AA) Invalid
Command
FIX AR Trade Capture
Report Ack
2.4.2 Field Level Mapping
This section describes the field mapping between the FIX and TradElect messages. This document uses the term “primary key” to mean the message field(s) that uniquely identifies a Trade Report. On the FIX side, the “primary key” that uniquely identifies a Trade Report is the following pair of FIX fields, both of which are set by the sender of the FIX Trade Report message: “CompID” and “TradeReportID” where “CompID” is the original sender. Duplicate detection is carried out on incoming Trade Report messages by comparison of these two FIX primary key fields.
Please note that the TradeReportID that is sent in by the customer should always be unique. This uniqueness should last forever. If a duplicate TradeReportID is
provided, the Acknowledge Trade Report message that is returned will be the same message that was returned for the initial Trade Capture Report with the same TradeReportID (even if it’s contents are different).
On the TradElect side, the “primary key” that identifies a Trade Report is the “Trade Code”.
In TradElect, all instruments are uniquely identified by the use of a 4 way key consisting of:
Tradable Instrument Code Currency Code
Segment Code Country of Register
Any Trade Report sent to TradElect must provide all of these fields.
Ideally, a FIX customer would supply each of them; however, the minimum that the FIX customer will need to supply is the ISIN and currency code. Customers should use Exchange reference data to guarantee accurate use of the 4 way key,
specifically Segment Code and Country of Register. Customers who would like to know how they can obtain Exchange reference data should contact the Client Technology Group (see section 1.6 Contact Details for further information).
2.4.2.1 FIX AE Trade Capture Report for “New Trade” → TradElect 5ET
‘Enter Trade Report’
The table below outlines the field mappings required for submitting a Trade Report to TradElect via the FIX Gateway.
Note that grey fields indicate that there is no corresponding field on the FIX or TradElect side. An Arrow indicates that the field is part of a group. The “Mand” column indicates mandatory FIX fields.
FIX Field (tag)
Req’
d
Usage
TradElect
Field
Source
Service
Code
Set to “T04”.
TradingSessionID (336)
N
To contain
LSE
Segment
Code (if
known)
Segment
Code
Obtained from
TradElect
reference data.
Trader
Group
From database
lookup by
CompID.
Message
Type
“5ET”
Message
Version
“AD”
Trader
Group
Sequence
Number
Unused, set to
blank
Trader ID
Set to blank
Unsolicited
Connection
Status
Set to blank.
TradeReportID(571) Y
Together
with
CompID,
this field
uniquely
identifies
an
incoming
trade
report.
ExecType(150)
Y
Must be “0”
(zero) for
“New
Trade”
PreviouslyReported
(570)
Y
‘N’ if not
previously
reported,
‘Y’ if this is
this report
is a repeat.
Message
Reference
Number
Generated by
this service.
Unique value
FIX Field (tag)
Req’
d
Usage
TradElect
Field
Source
per Enter
Trade Report.
SecurityID(48) Y
ISIN
of
security
Tradable
Instrument
Code
Must be an
ISIN.
SecurityIDSource(22) Y
FIX
always
sets code
“4”
meaning
ISIN
4AgreementCurrency(918) Y ISO
4217
code
Currency
Code
ISO 4217 code
copied from
FIX field.
LastPx(31) Y
Format
is
‘Float’
Trade
Price
Format is 18.8
LastQty(32) Y
Format
is
‘Float’
Trade Size Quantity:
signed
numeric, 13
chars.
Trade Date Format
CCYYMMDD.
Extracted from
FIX
TransactTime
TransactTime(60) Y
Datetime
in
YYYYMMDD
-HH:MM:SS
format
Trade
Time
Format
HHMMSS.
Extracted from
FIX
TransactTime
CountryOfIssue (470)
N
ISO 3166
code of
issuing
country (if
available)
Country of
Register
Country of the
instrument.
ISO 3166
code.
If not supplied,
lookup via
reference data
NoSides (552)
Y
May be 0,
1 or 2. See
“Buy/Sell
Member
IDs”.
Î Side (54)
Y
Value 1 =
Buy, 2 =
Sell
Î OrderID (37)
Y
Original
order id for
FIX Field (tag)
Req’
d
Usage
TradElect
Field
Source
the side
Î NoPartyIDs (453)
Y
Always 1
for each
side
Î Æ PartyID (448)
Y
LSE
Member ID
Î Æ PartyIDSource
(447)
Y Always
code ‘C’ =
Exchange
supplied
Î Æ PartyRole (452)
Y
Always
value 27 =
buyer/selle
r
Î AccountType
(581)
1
=
“Client”,
3 =
“House”
Settlement
Account.
Set to ‘C’ for
“Client” or ‘H’
for “House”.
Obtained from
reference data
if not supplied
In FIX
message.
Î OrderCapacity
(528)
Y ‘A’
=
agency, ‘P’
= principal,
‘R’ =
riskless
principal
Capacity
Code ‘A’ is
“Agent”
‘P’ is “Principal”
‘S’ is “Riskless
Principal”.
Obtained from
reference data
if not supplied
In FIX
message.
Member ID
Buy
See “Buy/Sell
Member IDs”.
Member ID
Sell
See “Buy/Sell
Member IDs”.
TrdType (828)
Y
42=”Portfol
io Transfer”
Trade
Type
Indicator
‘IF’ is
“Interfund”
SettlDate (64)
Y
Format
YYYYMMD
D
Settlement
Due Date
Format
CCYYMMDD,
the date that
the transaction
is due to settle.
Converted
Price
Indicator
Set to ‘N’.
Settlement Set to ‘ ‘ (3
FIX Field (tag)
Req’
d
Usage
TradElect
Field
Source
Venue.
blanks)
Trade
Request
Status
Set to ‘ ‘
(blank) for
“single sided”.
Reason
2.4.2.2 TradElect 5AT ‘Enter Trade Report Acknowledgment’ → FIX AR
Trade Capture Report Ack
A TradElect 5AT ‘Enter Trade Report Acknowledgment’ message will be mapped to a FIX “Trade Report Capture Ack” message (message type “AR”).
TradElect Field Usage FIX Field (tag) Source
Application Advisory Code Non-blank to indicate an error condition. See error mapping description below.
Trade Code Code allocated to the trade by TradElect
Trade Status ‘S’ indicates a
single sided trade
TradeReportID (571) Sourced from database. ExecType (150) ‘0’ (zero) TrdRptStatus (939) ‘0’ (zero) for
success or ‘1’ for rejection TradeReportRejectReason
(751)
Error number (if this is a
rejection) SecurityID (48) ISIN of Security SecurityIDSource (22) Code “4”
meaning ISIN
Text (58) Error message
(if this is a rejection) The FIX message is routed to the FIX CompID that sent in the original Trade Report. If the Trade Report has been successfully entered into TradElect, the ‘TrdRptStatus’ field is set to ‘0’ (zero) and the ‘Text’ field is empty.
If a failure has occured, the ‘TrdRptStatus’ field is set to ‘1’ and the
‘TradeReportRejectReason‘ and ‘Text’ fields contain an error number and error message according to the TradElect “Application Advisory Code”.
2.4.2.3 FIX AE Trade Capture Report for “Cancel Trade” → TradElect 5CN
‘Cancel Trade Report’
A FIX message indicating a cancel trade will be mapped to a TradElect 5CN ‘Cancel Trade Report’ message.
This Trade Code (required by TradElect) will be obtained by using a combination of the “TradeReportID” and “CompID” fields.
FIX Field (tag) Req’d Usage TradElect
Field Source Service Code Set to “T04”. Segment Code Sourced from the database row that was populated for the original “5AT” Trader Group From reference data. Message Type “5CN” Message Version “AB” Trader Group Sequence Number Unused, set to blank
Trader ID Set to blank Unsolicited Connection Status Set to blank. TradeReportID(571) Y Together with CompID, this field uniquely identifies an incoming trade report. ExecType(150) Y Must be “H” for “Cancel Trade” Message Reference Number Generated by this service. Unique value per Cancel Trade Report. Trade Code Sourced from the database row that was populated for the
FIX Field (tag) Req’d Usage TradElect Field Source Tradable Instrument Code Sourced from the database row that was populated for the original “5AT” Country of
Register
Sourced from the database row that was populated for the original “5AT” Currency
Code
Sourced from the database row that was populated for the original “5AT” Reason
Text Set to “Cancelled by FIX customer”
2.4.2.4 TradElect 5PH ‘Acknowledge Cancel Trade’ → FIX AR Trade
Capture Report Ack
This TradElect message results in a FIX “AR” message and is mapped in the same way as for a 5AT ‘Enter Trade Report Acknowledgment’ TradElect message.
2.4.2.5 TradElect 5IC ‘Invalid Command’ → FIX AR Trade Capture Report
Ack
In certain circumstances, for example if an invalid segment is provided in a Trade Capture Report for “New Trade”, a TradElect 5IC ‘Invalid Command’ message will be returned by TradElect to the FIX Gateway.
This TradElect message contains only the Architecture and Business Headers and the cause of the error is indicated by the “Session Error Code” field.
Handling will be the same as a TradElect 5AT ‘Enter Trade Report Acknowledgment’ message but based on this “Session Error Code” field value rather than the
“Application Advisory Code” field.
2.4.2.6 Error Handling
In the event that the original FIX message contained missing or incorrect values, the FIX customer will be informed of the error by use of the “TradeReportRejectReason” and “Text” tags in the returned “AR” message. They should take the appropriate action and then re-enter the trade report.
Note in the event that a Trade Report is sent to the FIX Gateway at a time when the TradElect system is unavailable, this will not result in an error message being returned to the FIX customer since this service stores the details from the FIX
message and passes them on at a later time when the TradElect system becomes available.
In this scenario an “interim” acknowledge will be sent and will show the FIX customer that the Trade Report has been received but not acknowledged (positively or
negatively) by TradElect yet.
If the TradElect connection is available, this interim FIX acknowledge is not sent to the FIX customer.
It will consist of a FIX “Trade Report Capture Ack” message (message type “AR”) as in section “
TradElect 5AT ‘Enter Trade Report Acknowledgment’ → FIX” but with the following differences:
The ‘ExecType’ field is set to ‘A’ meaning “Pending New”. The ‘TrdRptStatus’ field omitted, as it is optional.
If this service is not available for any reason but the FIX Gateway is up, then
standard FIX Store&Forward functionality will be used to hold on to the message until the Trade Report Service returns.
If the service does not return before the end of the day, then the trade report will be returned using a Business Reject message. Customers will be able to see this happening because they will not receive any ack for the trade report (interim or otherwise).
Note Store&Forward will depend on individual customer settings. If a customer has requested that Store&Forward not be configured for them, then trade reports will be immediately returned if the Trade Reporting Service is off-line. Customers can confirm this through the Network Status Message or using the Network Status Web Site. Please see the FIX Gateway Technical Guide for further information on these services.
If an error occurs internally before the incoming FIX Trade Report is committed, a FIX “Trade Report Capture Ack” message will be sent to the FIX customer with a “reject” status indicating the reason as an internal problem.
For each error, the possible handling implications are:
• Client error indicating that the original FIX message contained missing or incorrect values that were mapped, unchanged, to the TradElect message. In this case, the submitter will be informed and should re-enter the trade report. • Internal error indicating that the mapping itself failed. An error message is
sent to the submitter, who should then contact the Service Support team for further information as to what the problem is.
• Availability error indicating that the TradElect system is unavailable at the present time. Note that this does not actually cause an error message return of any kind to the FIX customer since the service stores the details from the FIX message and passes them on at a later time when the TradElect system becomes available.
Error Code
Meaning Notes Handling
Method Example Client Error Message Reject Reason Number Q002I Period authorisation failed Exchange system is closed Availability Error
Q008I Segment does
not match
Incorrect segment Internal error
Q104I Participant
suspended in
Internal error
segment Q107I Participant not
found in segment Internal error Q112I Inst/seg/curr combination invalid Could be a customer or mapping problem Internal error/Client error Security and currency do not match 4009 Q113I Mandatory fields not specified Internal error
Q115I Numeric fields
contains non-numeric Internal error Q134I Message contains invalid field Internal error
Q137I Field must be
blank
Internal error
Q156I Participant sell not in segment Incorrect sell member code. Internal error/Client error 4010 Q157I Participant buy not in segment Incorrect buy member code. Internal error/Client error 4011 Q189I Trade date/time invalid Internal error
Q197I Invalid trade type indicator
Internal error
Q203I Size must be
greater than zero
Internal error
Q217I Not in trade
reporting period
Availability error
Q218I Rules prevent
participant trade message Internal error Q219I No trade report exists for trade code
Internal error
Q244I Trade report
cannot be cancelled
Client error Trade report can no longer be cancelled
4002
Q248I Trade date
invalid
Internal error
Q249I Trade time
invalid Internal error Q250I Buy participant equals sell participant Values must be different Internal error
invalid error Q327I Client ref must
be entered
Internal error
Q328I Client ref sell must be entered Internal error Q330I Converted price indicator invalid Internal error Q331I Settlement due date invalid
Invalid date. Internal error
Q430I Segment code
not equal to original segment code
Internal error
Q448A Segment does not exist Internal error Q452I Inst/seg/curr combination does not match Instrument/currency mismatch Internal error/Client error Security and currency do not match 4003 Q460I Tradable instrument not enabled for capacity Internal error
Q461I Participant not enabled for capacity Internal error Q462I No unsuspended role for segment Internal error
Q468I Trade request
status invalid Internal error Q469I Tradergroup invalid for member Internal error Q470I Settlement venue/account invalid Internal error
Q471I Trader ID not
populated
Internal error
Q472I Trader ID not
valid for tradergroup Internal error Q477I Trader ID suspended Internal error
Q479I Trade size
invalid
Client error LastQty is invalid 4004 Q481I Consideration invalid Internal error
Q482I Trader group
ID suspended
Internal error
for member
Q483I No role for
trade type Internal error Q491I Consideration must be greater than or equal to minimum
Client error LastQty is invalid 4005 Q500I Settlement venue suspended for security
Client error Settlement
venue suspended
4006
Q503I Trade price
outside threshold
Client error LastPx is outside threshold
4007
Q505I Trade date
outside allowable range
Client error TransactTime
is outside allowable range 4008 Q508I Settlement venue, account, capacity invalid for tradergroup
Client error (to be confirmed) Q509I Settlement venue, account, capacity suspended for tradergroup
Client error (to be confirmed) Q510I Invalid capacity for trade type in segment Internal error
For the user of this service, the following behaviour would be observed for each error handling method:
Handling Method Behaviour
Availability error No immediate visibility. The TradElect connection is logged-off. The submitter will have received an interim acknowledge. When the TradElect connection is re-established, the Trade Report is sent again.
Client error A “Trade Capture Report Ack” message (msgType “AR”)
is received by the submitter. The value in the “Text” field of the message is sourced depending on the TradElect error code. The user is then expected to correct the error.
Internal error A “Trade Capture Report Ack” message (msgType “AR”)
is received by the submitter. The value in the “Text” field of the message is “Internal error”. The FIX customer can contact the Service Support desk if further information is required.
2.4.2.7 Buy/Sell Member IDs
The “Member ID Buy” and “Member ID Sell” fields in an “Enter Trade Report” message to TradElect cannot be blank and must have values entered.
If the incoming FIX message has one or both of these values present, that value will be used. They are supplied in nested fields within a “Party” block which, in turn, is nested within a “Side” block. The FIX message may contain 0, 1 or 2 “Side” blocks each of which should have a single “Party” block containing a “PartyID” field. The PartyID field (tag 448) should contain the Member ID as defined by the London Stock Exchange. (The “PartyIDSource” field (tag 447) should be value ‘C’ indicating that the PartyID code is an “Exchange-supplied” code).
The TradElect MemberID, Settlement Account and Capacity resolution for the three differing combinations of sides (0, 1 or 2 present) are processed as below.
Zero Sides supplied in Fix Trade Report message
A lookup by CompID is used to determine Member ID, AccountType and OrderCapacity.
The MemberID found there is used as the Member ID for the seller side of the trade report - this follows the MiFID standard.
"NONMEMBER01" is used as the Member ID for the buyer side of the trade report. One Side supplied in Fix Trade Report message
The base assumption is that the trade report is one where the report has the same member on both sides (as implemented when zero sides are supplied).
If a single side is supplied then it could be for one of two reasons:
1. The submitter wishes to submit a non-default value for AccountType and/or OrderCapacity, or the submitter wishes to indicate that they were the buyer, not the seller
a. In this case the PartyID (if present) will match MemberID will be the value mapped from the CompID. This case is also assumed if no PartyID is present in the FIX side. The values for AccountType and OrderCapacity in the side are used, if one or both is present. If not present, then the value(s) looked up by the CompID are used. The MemberID Buy/Sell should match the Side of the trade report.
b. "NONMEMBER01" is used as the Member ID for the other side of the trade report
2. The submitter wishes to report a trade with someone else
a. In this case, the PartyID on the side will be different from the one associated with the CompID. This MemberID is used in the appropriate side of the trade report, but the AccountType and
OrderCapacity must be the default ones associated with the CompID, which will also provide the MemberID for the other side of the Trade Report.
Two Sides supplied in Fix Trade Report message
The "normal case" here is that the CompID is trying to report a trade with another entity and that when the sides are reviewed, one will be for the MemberID associated
with the CompID and one will be for another MemberID. The two
PartyIDs/MemberIDs from the sides should be used as appropriate in the trade report and the AccountType and OrderCapacity should be taken from the side where the MemberID matches the one associated with the CompID - if they are present, and from the default if they are not.
There are two error conditions where 2 sides are supplied:
1. Both sides hold the same MemberID. This is invalid, irrespective of whether it is the one associated with the CompID. The correct approach is to report just 1 side as shown above.
2. Neither of the MemberIDs from the Sides is for the MemberID associated with the CompID. This means that the trade report did not involve the reporter. This is not the normal model and so returns an error since valid (or even default) values for AccountType and OrderCapacity cannot be established.
2.5 TESTING REQUIREMENTS
In order to connect to the FIX Gateway a participant will need to undergo a small amount of testing to confirm connectivity prior to going live.
All Customers will be required to demonstrate that their FIX Gateway applications can connect successfully to the Exchange over the Third-Party Infrastructure (or via the Internet, for the Customer Development Service - CDS only) by undergoing a FIX Connectivity Testing (FCT). No customers will be enabled for access to the
Production FIX Gateway environment without passing a FIX Live Connectivity (FCON) test.
FIX Connectivity Testing (FCT) is designed to give customers the opportunity to resolve any network or application level issues with direct Exchange and Third-Party Network support. Connectivity testing is carried out using the FIX Gateway Test Service.
The FIX Live Connectivity (FCON) testing follows exactly the same format as the FCT and is designed to demonstrate that customers can connect to the Production FIX Gateway service without any issues that may impact live service.
Customers will also be required to perform functional testing against the FIX Gateway CDS environment to demonstrate that they can send and receive Trade Capture Reports without experiencing any issues.
Testing can be arranged by contacting Service Support (see section 2.6 for details).
2. 6 CONTACT DETAILS
The Exchange recognises the importance of supporting a customer throughout the implementation of the service detailed in this document. The current support mechanisms will continue to be available to provide assistance throughout your design, development through to live service.
Client Technology Group (CTG)
CTG would provide technical support during an implementation, and can be contacted via:
The Technical Information Desk - Tel: +44 (0) 20 7797 3939, STX 33939 E-mail Client Technology Group at: [email protected]
Questions regarding of a technical nature may also be raised directly through your Technical Account Manager.
Client Implementation Team (CIT)
CIT are responsible for co-ordinating the implementation of a customer’s FIX Gateway enablements and may be contacted via:
Client Implementation Team - Tel: +44 (0) 20 7797 3232, STX 33232 E-mail Client Implementation Team at:
Implementation queries may also be raised directly through your Client Implementation Consultant.
Other key contacts
Please contact the following people directly for all other queries of a commercial and/or business nature.
Business Manager
• Tom O’Brien
• Tel: +44 (0)20 7797 4135
• Email: [email protected]
Investment Management Sales • David Letton • Tel: +44 (0)20 7797 4390 • Email: [email protected] Broker Sales • Nirosh Wijewardene • Tel: +44 (0)20 7797 1466 • Email: [email protected] Other non member firm queries
• Alex Dalley
• Tel: +44 (0)20 7797 2134
Service support
Live Service Support for the FIX Gateway is available 24/7 via the London Stock Exchange Helpdesk on +44 (0)20 7797 3100.