On July 26th, ACER published its 3rd Open Letter on REMIT data quality. Despite the fact that the EU wholesale energy market is several years into REMIT transaction reporting, ACER is still noting issues with data quality which prevent it from fully performing its market surveillance activities. Many of these issues result from operational reporting IT systems. All reporting parties are requested to address the issues identified.
On July 26th ACER published its 3rd Open Letter on REMIT data quality (1). ACER uses these Letters as one of its channels to notify the EU wholesale energy markets of any issues it has with data quality that hinders it ability to perform fully its surveillance activities. Although ACER notes that publication of the previous two Letters lead to improvements in data quality, matters are far from resolved, especially at the OMP and RRM levels. It sounds like there will be more Letters to follow, with the threat of enforcement.
At deltaconX, we reviewed the 3rd Letter and were a little surprised about ACER’s statement that seemingly basic errors are often the result of operational system issues, particularly in situations where records of transactions must pass through a series of data management systems before finally being reported to ARIS. In particular, ACER notes inconsistencies in data reported by OMP RRMs compared with data reported by 3rd party RRMs. At this stage in REMIT’s life, we would not expect there to be enough fundamental operational IT glitches to be of concern to ACER, 2018’s introduction of XBID notwithstanding. Obviously, we were wrong!
ACER summarises the key data quality issues in an Annex to the 3rd Letter. They make interesting reading – we’ve focused on four key issues.
(1) Inaccurate reporting of transaction timestamps (Table 1 Field 30). ACER states that that sometimes the reported transaction timestamp does not actually reflect the actual time of occurrence of the underlying business event. Instead, Field 30 is either populated with a reporting IT system-time, or is created retrospectively and artificially by the reporting parties themselves. Inaccuracy in reporting the timestamp adversely impacts ACER’s ability to detect market manipulation, because some abuse cases, e.g. ‘layering’, are acutely timestamp-critical. ACER is able to detect these discrepancies because itself (and the NRAs) are able to match both sides of the trades and rebuild the order book. ACER and the NRAs conclude that for whatever reason, the inability to capture the actual time of the business event in an accurate and consistent manner is an issue that needs addressing as a matter of some urgency.
ACER’s finding is rather surprising in another way, given how many market participants operate physical assets and are thus vulnerable to unscheduled outages. Capturing the time of the outage and the orders and trades that result from it is critical to claiming the exemption for insider trading under REMIT Article 3(4)(b), so one would expect the entire reporting chain of market participant, OMP, and RRM to be consistent in their timestamping.
(2) Inconsistent reporting of lifecycle events, especially Table 1 Field 58. Apparently, some reporting parties are applying the wrong business logic, using Action Type ‘Modify’ to correct wrongly submitted data when they should be using Action Type ‘Error’ followed by Action Type ‘New’ (‘Error’ results in a logical deletion of the erroneous record in ARIS so that it can be replaced by a ‘New’ correct one). ACER state that they are about to issue extended guidance on lifecycle event reporting, but for now reporting parties are directed back to the TRUM, and to the ‘golden rules’ stated in the 3rd Letter.
(3) Inconsistent Beneficiary ID and Trading capacity of the reporting market participant (Table 1 Fields 8 and 10). These are not always being populated correctly or consistently. For example, Beneficiary ID should only be populated when the market participant is acting on behalf of a known third market participant, in which case the Trading Capacity field should be populated with A for Agent. In all other cases, the field Beneficiary ID is to be left empty and the Trading Capacity field should be populated with ‘P’ for Principal.
(4) Timeliness of transaction reporting. This issue presents arguably the biggest surprise. ACER reminds everyone that transactions related to products admitted to trading at OMPs are Standard Contracts, and must be reported on a T+1 day basis, irrespective of whether they are screen-traded or voice-brokered. Non-Standard Contracts are reportable on a T+1 month basis, implying that reporting parties are mis-classifying contract types, or are simply tardy in their reporting timelines.
ACER appeals to the sense of ‘good citizenship’ in the REMIT community, asking all reporting parties to review their systems and data management procedures to ensure data of the required quality. ACER notes that its review of data quality is an ongoing process, as is ACER’s policy of facilitating meetings, webinars, and roundtables to resolve REMIT data quality issues.
deltaconX recommends that all readers consider the Letter and review their transaction reporting systems and data management procedures, especially if they have received a data-quality notice from ACER or their NRA. Important questions to ask in the review include ones about how many different systems and interfaces are involved in the reporting chain, and if it is possible for data to become corrupted as they pass through. Also, all REMIT data need to be validated at both the technical and business levels – just because the file format is correct doesn’t guarantee that the business logic is also correct, and ACER warns that non-rejection by ARIS is not a guarantee of compliance.
The best transaction reporting system is likely to be a single platform where incoming data are subject to technical and business validation before being submitted to ACER, ideally one with few or no interfaces that create additional risk of data corruption. Even if reporting is delegated, the market participant remains responsible for the data’s accuracy and quality, so at a minimum the market participant must implement some kind of data reconciliation system to ensure that what was reported on their behalf was accurate.
Market participants should bear in mind that ACER and the NRAs are becoming increasingly good at building up the ‘entire picture’ of orders and trades from multiple sources – if you are inaccurate in your reporting but others aren’t, ACER will detect the discrepancy and seek the reasons from you. And if you do find inconsistencies or even downright errors, we recommend you fully co-operate with ACER and your NRA, as ACER has stated on many occasions that it would rather help reporting parties to help it fulfil its role, rather than opt for enforcement procedures.
Footnotes
(1) ACER 3rd Open Letter on REMIT Data Quality https://documents.acer-remit.eu/wp-content/uploads/20190726-Third_Open_Letter_on_data_quality.pdf
For more information on how deltaconX can advise you on the management of transaction data under REMIT, and implement a single regulatory reporting platform, please contact our Compliance Help Desk.
