Reports EU Regulations REMIT Reporting Services & Solution | Page 39

REMIT Reporting Services and Solutions - July 2015 updated March 2016 6.2.6.1 Data acquisition The software will have different mechanisms for acquiring the data. The mechanisms fall into different categories: - - - - Data load – the software will permit data in different forms (e.g. a table on a database, XML file in a specific format, csv or excel file) to be loaded. Usually the system will specify the format in which the data is to be sent to the system, although many products on the market have a great deal of flexibility in how data is presented to the software. The system will have a variety of mechanisms to “pull” the data in, either in real time or in batch, and where in batch pulled in at regular intervals or when a specific event occurs (for example a file being placed in a directory). For REMIT, it is expected that most systems should be able to “read” ACER XML. Adapter – special adapters can be written into specific commercial systems, such as an ETRM system this is different to the “ETRM” adapter outlined above, since this type of adapter will pull data from an ETRM system into the stand-alone software. This type of adapter will be used in a variety of circumstances instead to a direct one: Firstly it would be used when the ETRM is one of many systems from which data needs to be pulled. Secondly, the direct adapter, or source ETRM may not have the required base data or enrichment capability required by the regulatory destination. Connection to trading venue – many standalone packages will have connections to trading venues. For REMIT these will be OMPs, and the systems will have different capabilities as to which sort of data they can pull, i.e. just trade data or order data too. Some system will pull data directly from OMPs. Others may use an aggregated feed that is commercially available; some will utilise existing feeds and enrich them. Direct – Some systems will permit manual entry of data straight into them, although this is the exception rather than the rule. 6.2.6.2 Data enrichment Data enrichment takes two key forms: - Code substitution Completion of data Most reporting regimes require certain data items to be in a certain form. For example. Data about entities will often need to be reported in a standard form such as the LEI (Legal Entity Identifier) or in the case of REMIT the ACER code. Other examples include product codes, trade identifier and codes for specific types of contract. A standalone reporting system will substitute codes that are imported into the system with the correct code for the appropriate destination. This is usually accomplished by aliasing i.e. the process of mapping the code in one system to another: Copyright 2016 – ETR Advisory Ltd and Commodity Technology Advisory LLC 38