Transaction Reporting How-to Guide: ‘Venue’ Field
On the face of it, the ‘Venue’ field in transaction reporting seems to be fairly straightforward – as the RTS states, it is simply the “identification of the venue where the transaction was executed.” Unfortunately, it is not quite as simple as it first seems and we detect a large number of errors with this field in our ReportShield™ Accuracy Testing.
Why is the ‘Venue’ field so important?
Every field is important to the regulators and Article 26 of MiFIR demands complete and accurate reporting. However, accurate population of the Venue field is particularly important for firms due to the impact it has on the population of associated fields. If it is populated incorrectly, it could result in a ‘CON 412’ error from the regulator and your report will be rejected. It also impacts how ‘TVTIC’, ‘Trading date time’, ‘Country of branch membership’ and fields 41-56 need to be populated. So it is essential that you fully understand the intricacies of this field and don’t fall into any of the following traps.
‘Segment’ versus ‘Operating’ level MICs
The Market Identifier Code (‘MIC’) used to be a straightforward standard – you had one exchange and one four character code to identify it. For example, ‘XLON’ was the sole identifier for the London Stock Exchange. However, this was far too easy and exchanges are increasingly moving to a segment level structure resulting in a MIC for each segment. For example, the London Stock Exchange has ‘XLON’ as its ‘operational level’ MIC, but also has the following ‘segment level’ MICs:
- AIMX – London Stock Exchange, AIM MTF
- XLOD – London Stock Exchange, Curve Global Markets
- XLOM – London Stock Exchange, MTF,
- XLON – London Stock Exchange
Golden Rules:
- Use the segment level MIC for transactions executed on a trading venue, systematic internaliser or non-EEA trading platform.
- Only use the operational level MIC where the segment level MIC does not exist.
This is so important because if you used the operational level MIC by mistake, it will sail through ARM validation, but will probably result in a CON 412 error from the regulator. This is because the ISIN you have used in field 41 doesn’t only have to be on FIRDS on the trading date – it also has to be with the correct segment level MIC. So if you have traded an AIM stock, populated the ISIN correctly but have populated the Venue field with ‘XLON’ rather than ‘AIMX’, it will be rejected.
The ‘XOFF’ versus ‘XXXX’ conundrum
Another common error made by firms is in the use of ‘XOFF’ instead of ‘XXXX’ and vice versa. This is understandable as they sound similar and are both used for off market trades. In an effort to be precise, some of the language in the RTS can also appear confusing. It is absolutely essential that you understand the difference between the two as it can have a major impact on whether you need to populate the instrument identifier.
Golden Rules:
- Use ‘XOFF’ for instruments that are tradeable on an EEA trading venue but where the trade has been made off market (i.e. not executed on a trading venue, SI or non-EEA platform).
- Use ‘XXXX’ for instruments that are not tradeable on an EEA trading venue and are traded off market (i.e. not traded on a non-EEA platform).
Exchange MIC or ‘XOFF’/’XXXX’
Another thorny issue we’ve discovered is the use of an exchange MIC when the trade was actually made off market. The Venue field should only be populated with the exchange MIC if the transaction was executed on a Trading Venue. Section 5.4 in the ESMA Guidelines document is a little complicated, but the key statement is “Where an Investment Firm is not the direct market facing entity the Investment Firm is not regarded as executing on the Trading Venue for the purposes of transaction reporting.” So if you are making a transaction against a broker and that broker makes a trade on the London Stock Exchange to facilitate the trade, you should populate the venue field with ‘XOFF’ rather than ‘XLON’ as you are not the direct market facing entity.
How we help
Firstly, if you are unsure about any of the reporting standards, or just need a refresher, we would heartily recommend our core training course which will help ensure you are interpreting the MiFIR transaction reporting details correctly.
If you have any doubt about whether you have been reporting correctly, this is what our Accuracy Testing is designed for. We can take all the transaction reports you have submitted over any given period and apply multiple tests for each data field that comprises a report. As many firms have discovered to their cost, there is no point hoping for the best when it comes to reporting. You need to have total confidence that your reporting is complete and accurate to avoid costly remediation and regulatory scrutiny.
Please contact us for further details on our quality assurance, reconciliation, governance and training services.
