Martin Walters
26 July 2017 5:24pm
Hi,
Is there anywhere that documents the use of FIX tags for use with the additional fields required for transparency publishing if the instrument does NOT have an ISIN?
Thanks
Martin
Hello Martin,
Sorry for the delay - I waited for the FPL Website migration to reply.
The is no GTC Gap Analysis or white paper that I know of that maps the additional fields required for identifying the instrument when there is no ISIN to FIX although a number of our FIX clients have attempted to do that based on the DSB requirements. There is a published document from the DSB about how to submit requests for an ISIN and how to subscribe to a stream of published ESMA ISINs: OTC-ISIN FIX API Now Available for Public Distribution.
Regards,
Dean
Martin, do you know which financial instrument types or assets would not have an ISIN? Have there been any exceptions made by ESMA to permit transaction reporting without an ISIN? We can specify the alternative approach using the flexibility of FIX in terms of SecurityID(48) and SecurityIDSource(22), but it would be good to understand the requirement and how instruments or assets would be identified when an ISIN is not available.
Jim,
I’m focussing on transparency reporting, not transaction. See RTS 2 Annex II Table 2 (excerpt below).
“Where Instrument identification code is not an ISIN, an identifier that identifies the derivative instrument based on the fields 3 to 5, 7 and 8 and 12 to 42 as specified in Annex IV and fields 13 and 24 to 48 as specified in the Annex of Delegated Regulation (EU) 2017/585 and the grouping of derivative instruments as set out in Annex III.”
This suggests that various additional fields, some with MIFID specific identifiers in several fields depending on the type of derivative. I’m not an expert on the data but there is concern that ‘packages’ in particular might be struggling to get ISINs. As a techie I’m just trying to prepare my solution to cover the possible occurrence of this.
Rgds
Martin
Dean - Many thanks - I will review the DSB document.
Hi Martin,
there is an upcoming Gap Analysis covering a suggested mapping for RTS 2 Annex IV Table 2 ( and also parts of RTS 23). It has been presented to the FIX Global Technical Committee on July 20 and will be made available for public comment soon.
Regards,
Hanno.
Hanno,
Many thanks for the response. As it stands I will be proposing to use the SecurityXML tag (1185) to define additional fields for ‘non ISIN’ coverage if it is needed. Much akin to the ANNA DSB approach. Seems flexible and expandable. If an alternative comes through then we’ll look at it when it arrives.
(Updated Response) Hanno,
At the moment I’m toying with XML or even JSON but deferring any decision until I really have to make it. IS there an eta for this new gap analysis. As it stands I can’t find suitable tags for some of the ‘basic’ fields, never mind the ‘non-ISIN’ reporting. For example, Type for Emission Allowances, can you recommend the tag to use for that? Perhaps I’m missing something.
Thanks
Martin
Rgds
Martin
Using SecurityXML probably means you would be using a non-FIX XML flavor like FpML or even a non-standard set of XML attributes. What are you planning to do? The native approach with FIX will propose a number of reference data fields such as the following:
AssetClass(1938)
AssetSubClass(1939)
AssetType(1940)
AssetSubType(TBD) - new field
SecurityType(167)
SecurityID(48)
SecurityIDSource(22)
CFICode(461)
PutOrCall(201)
StrikePrice(202)
StrikeCurrency(947)
MaturityDate(541)
SettlMethod(1193)
ExerciseStyle(1194)
ContractMultiplier(231)
CouponRate(223)
…
Obviously I recommend the FIX native version, also to avoid the need for two different parsers for any given message.