Emir

EMIR Level 2 Validation

On 27^th April ESMA has published the updated Q&As that relates to the second level of the EMIR validation specifications. As ESMA clearly states that a failure to comply with the requirements will trigger a rejection of the trade reports by the TRs. The trade repositories are obliged to apply the rules of the validation to the trade reports and to reject those trade reports that do not comply with the level 2 validation specifications. A table with all of the EMIR level 2 validation rules published by ESMA is available via excel sheet here.

The difference between level 2 validation and level 1 validation is that ESMA now imposes validation on the content of the fields and validation on the basis of correlation between the fields. Another difference is that the level 2 validation covers 84 fields which is more than the first one.

ESMA requires the trade repositories to apply those changes into their systems by 31^st Oct 2015. UnaVista has scheduled the change in their live environment for the week-end of 24^th of Oct 2015. Regis-TR has completed phase one of the implementation into their live environment on the 3^rd of Sept 2015.

The table below represents the correct values of several fields and the connection between the values in different fields. For example if the value in field CD10 Venue is filled with a valid MIC listed on the MiFID database, then the other fields below (Taxonomy used, Product-ID1, Product-ID2, etc.) should contain certain values that would be validated at the time the trade report is being submitted to the relevant trade repository. Otherwise the reports will be rejected.

Other important changes of the EMIR level 2 validation are:

• Date and time fields will require the data to be presented using zero offset from UTC (coordinated universal time) for the fields: field CP1 “Reporting timestamp”: YYYY-MM-DDThh:mm:ssZ; field CP20 “Valuation time”: hh:mm:ssZ; field CD19 “Execution timestamp”: YYYY-MM-DDThh:mm:ssZ; field CD26 “Confirmation timestamp”: YYYY-MM-DDThh:mm:ssZ. The systems should be adjusted accordingly or the time should be corrected prior to submission of the reports.
• Valid LEIs to be populated in: field CP2 “Counterparty ID” (reporting counterparty ID), field CP3 “ID of the other counterparty”; fieldCP8 “Broker ID”; field CP9 “Reporting entity ID”; field CP10 “Clearing member ID”; field CP11 “Beneficiary ID”; field CD31 “CCP ID”. The fields should contain 20 alphanumerical characters and check digit. Although EMSA also allows client code or internal code to be used, some of the trade repositories, for example UnaVista will continue to require LEI only. Another change is that the option for using BIC in the fields above will be removed after 31^st Oct 2015.
• Field CD8 “Trade ID” (UTI) can be up to 52 alphanumerical characters. Four special characters are allowed “:”, “.”, “-“, “_”. Additionally, ” ” (the space) is allowed for the UTIs reported with action type “New” before the end of 31.12.2015. The special characters not allowed at the beginning or the end. Not allowed to change the content of this field once it is reported. Until centralised UTI generation solution/methodology is in place, the uniqueness of the Trade ID shall be preserved at counterparties’ level, i.e. the combination of the field CP2 “Counterparty ID”, field CP2 “ID of the other counterparty” and field CD8 “Trade ID” shall be unique.
• Value “X” is allowed in field CP6 “Corporate sector of the counterparty” only if the Reporting counterparty is CCP, i.e. if the entry in the field CP2 reporting “Counterparty ID” field is matching the field CD31, “CCP ID”. Although this detail is not included in the ESMA excel sheet, UnaVista has announced that ESMA required them to implement it.
• Field CP15 “Directly linked to commercial activity or treasury financing” can only be blank when field CP7 “Financial or non-financial nature of the counterparty” is “F” (for financial counterparties) or NA (“X”) for CCP. When populated, can only contain “Y” or “N” value. Single character allowed only.
• Field CP16 “Clearing threshold” can only be blank when field CP7 “Financial or non-financial nature of the counterparty” is “F” (for financial counterparties) or NA (“X”) for CCP. When populated, can only contain “Y” or “N” value. Single character allowed only.
• Field CP17 “Mark to market value of contract” When populated should be up to 20 numerical characters including decimals. The decimal mark is not counted as a numerical character. If populated, it shall be represented with a dot. The negative symbol, if populated, is not counted as a numerical character.
• Field CD1 “Taxonomy used” can only be “I” for ISIN/AII + CFI or “E” for Interim taxonomy. If field CD10 “Trading venue” is regulated market MIX on http://registers.esma.europa.eu/publication/ or “XOFF”, the value must be “I”. If field CD10 “Trading venue” is populated with an MTF MIC listed in the MiFID database, both values “I” and “E” are allowed. If field CD10 “Trading venue” is populated with non-EEA MIC or “XXXX”, then this field shall be populated with “E”. Note: until a Unique Product Identifier is endorsed in Europe, “U” value cannot be accepted in this field.
• Field CD2 “Product ID 1”. If field CD1 “Taxonomy used” has value “I”, then whether ISIN or Exchange product code is used is determined by: if field CD10 “Trading venue” is “XOFF” or an ISIN regulated marker under MiFID database, then ISIN must be 12 characters with valid check digit. If field CD10 “Trading venue” is an AII regulated market MIC on the MiFID database, then the code can contain up to 12 characters. If field CD10 “Trading venue” is populated with a non-EEA MIC or with “XXXX”, then the value must be CO, CR, CU, EQ, IR or OT.
• Field CD3 “Product ID 2”: if field CD1 “Taxonomy used” is “I”, then the field CD3 “Product ID 2” must be a valid CFI code (6 characters long, the first two characters cannot be “XX”); if field CD1 “Taxonomy used” is “E”, then only “CD”, “FR”, “FU”, “FW”, “OP”, “SW” or “OT” values will be accepted.
• Field CD4 “Underlying” shall be populated in all cases except when field CD1 “Taxonomy used” is “E” and at the same time field CD2 “Product ID 1” is “CO”, “CU” or “IR”. In all other cases the permissible values are: ISIN, LEI, “B” for Basket, “I” for Index and validation rules for LEI will apply.
• Field CD10 “Venue of execution”. ISO 10383 Market Identifier Code (MIC). 4 alphanumerical characters only. Where relevant, “XOFF” for derivatives listed on regulated markets in EEA countries traded off- exchange or “XXXX” for OTC derivatives. If this field is populated with MIC, following validations shall be performed: MIC Code shall be validated against MiFID Database of Regulated Markets and MTFs. If it is a MIC code listed in the MiFID Database, it shall be accepted; If the MIC is not listed in the MiFID database, it shall be validated against the list of MIC codes maintained and updated by ISO and published at: http://www.iso15022.org/MIC/homepageMIC.htm (column “MIC” in table “MICs List by Country” of the respective Excel file. In case the MIC pertains to a venue in a non-EEA country, the report shall be accepted. Otherwise the report shall be rejected.
• Field CD20 “Effective date”. The value of this field shall be greater than or equal to the value of the date part of the field CD19 “Execution timestamp” for all trades where field CD10 “Venue of execution” is populated with MIC code, i.e. not “XOFF” or “XXXX”.
• Field CD21 “Maturity date” when populated the value of this field shall be greater than or equal to the value in field CD20 “Effective date”.
• Field CD22 “Termination date” when populated the value of this field shall be greater than or equal to the value of the date part of the field CD19 “Execution timestamp”. If field CD22 “Termination date” and field CD21 “Maturity date” are both populated, the value of field CD22 “Termination date” shall be less than or equal to the value of the field CD21 “Maturity date”.
• Field CD23 “Settlement date” when populated the date of settlement shall be greater than or equal to the value in field CD19 “Execution timestamp”.
• Field CD13 “Price notation” if it is populated with currency, then it shall contain ISO 4217 Currency Code (official list only), 3 alphabetical characters.
• Field CD17 “Up-front payment” When populated: up to 10 numerical characters including decimals; the decimal mark is not counted as a numerical character; the negative symbol, if populated, is not counted as a numerical character; cannot be “NA”.
• Field CD25 “Master agreement version” if populated 4 numerical digits starting with “19” or “20”.
• Field CD26 “Confirmation timestamp” when populated shall be greater than or equal to the field CD19 “Execution timestamp”. Common input format: YYYY-MM-DDThh:mm:ssZ.
• Field CD30 “Clearing timestamp” shall be populated, only if field CD29 “Cleared” is populated with “Y”. When field CD30 is populated, its value shall be greater than or equal to the value of the field CD19 “Execution Timestamp”. Common input format: YYYY-MM-DDThh:mm:ssZ.
• Field CD31 “CCP” populated if CD29 “Cleared” is “Y” with LEI in all cases (even for non-EEA entities). BIC is not accepted.
• Field CD33 “Fixed rate of leg 1”, field CD34 “Fixed rate of leg 2”, field CD39 “Floating rate of leg 1”, field CD40 “Floating rate of leg 2”. If field CD2 “Product ID 1” is with value “IR”, at least one of the above fields should be populated with up to 10 numerical characters, the decimal mark (a dot) is not counted as a numerical character. The negative symbol, if populated, is not counted as a numerical character. For bond derivatives these fields should be used.
• Field CD35 “Fixed rate day count” and field CD36 ”Fixed leg payment frequency” must be populated if field CD33 “Fixed rate of leg 1” or field CD34 “Fixed rate of leg 2” are populated.
• Field CD37 “Floating rate payment frequency” and similarly field CD38 “Floating rate reset frequency” must be populated if field CD39 “Floating rate of leg 1” or field CD40 “Floating rate of leg 2” is populated.
• Currency fields (depending on whether field CD2 “Product ID1” is populated with “CU” and respectively field CD1 “Taxonomy” is populated with “E”) then: field CD41 “Currency 2” must be populated with ISO 4217 currency code – official list only, 3 alphabetical characters; at least one of fields CD42 “Exchange rate 1” and CD43 “Forward exchange rate” must be populated with up to 10 numerical digits including the decimal; field CD44 “Exchange rate basis” must be populated.
• Commodity fields (depending on whether field CD2 “Product ID1” is populated with “CO” and respectively field CD1 “Taxonomy” is populated with “E”) then: field CD45 “Commodity base” must be populated with “AG”, “EN”, “FR”, “ME”, “IN”, “EV”, “EX”; and field CD46 “Commodity details” must be populated with “GO”, “DA”, “LI”, “FO”, “SO”, “OI”, “NG”, “CO”, “EL”, “IE”, “PR”, “NP”, “WE”, “EM”.
• Energy fields (if field CD46 “Commodity details” is populated with “NG” or “EL”), then: field CD49 “Load type” must be populated with one of the following values: “BL”, “PL”, “OP”, “BH”, “OT”; field CD50 “Delivery start date and time” must be populated with YYYY-MM-DDThh:mm:ssZ; field CD51 “Delivery end date and time” must be populated with YYYY-MM-DDThh:mm:ssZ and the delivery end date and time shall be greater than the delivery start date and time; fields CD52 “Contract capacity”, CD53 ” Quantity Unit” and CD54 “Price/time interval quantities” must be populated.
• Option fields (if field CD3 “Product ID2” is populated with “OP”, or if field CD2 “Product ID1” is a CFI code indicating options) then: fieldCD55 “Option type” can only contain “P” for put or “C” for call value; field CD56 “Option style (exercise)” can only contain the following values: “A” for American, “B” for Bermudan, “E” for European, “S” for Asian; field CD57 “Strike price (cap/floor rate)” must be populated with up to 10 numerical characters including decimals.
• Field CD58, named Action Type. The first report received for given UTI by the reporting counterparty shall have only action type “N”. It would be no longer possible the trade reports to be sent with missing UTI’s. Furthermore only one report with the action type “New” for a given combination of Counterparty ID- ID of the other counterparty-Trade ID (UTI) shall be accepted.

EMIR level 2 validation rules are a challenge for the companies who have already organized in-house their EMIR reporting. EMIR Reporting Ready, Ltd. is able to assist the financial institutions by either organizing the EMIR reporting on their behalf of by consulting them and providing them with the best approach for successful and compliant EMIR reporting.

For further information please check our EMIR reporting Solutions.

Information about Fines for inaccurate EMIR reporting.