EMIR reporting uses an XML file structure, replacing the previous CSV format.
XML uses an embedded schema and validation system sourced from XSD schema/files. An XSD schema/file defines the structural and data-type rules that every EMIR XML submission must conform to, specifying which elements are required, their permitted values, correct ordering, and allowed formats.
When an XML file is submitted, it is validated against a set of formatting and data rules in the XSD schema. If the file fails any rule, a validation error is generated and the submission is rejected. Understanding the most common categories of error is essential for maintaining a smooth reporting process.
Here are the 9 most frequent XML errors TRAction see, with examples and corrections for each.
1. Element ‘<XYZ>’ is not allowed at this location
This error occurs when an element is placed in a position not permitted by the XSD schema. This typically happens due to incorrect element ordering or nesting.
Example: Consider the derivatives report where all action types (NEWT, MODI, VALU, TERM, POSC, EROR, CORR, REVI) must include three specific elements in a precise order according to the XSD schema-
| This is the first element and contains counterparties’ specific data. It is a complex type, meaning it has nested elements within it. | |
| This is the second element and includes common trade data such as contract data and transaction data. It is also a complex type with nested elements. | |
| This is the third element and indicates the level of the trade. It is a simple type, containing only a single value, either PSTN (Position level) or TCTN (Transaction level). |
If these elements are not in the correct order, such as if <Lvl> appears before <CtrPtySpcfcData> or <CmonTradData>, this error will occur. Additionally, if there is an unexpected element, say <XYZ>, inside the action type’s nested structure, the error will be triggered.
| Incorrect order XML example | |
| Unexpected element XML example | |
| Correct XML example |
TRAction’s XML generator is coded strictly based on the XSD schema to ensure elements are always produced in the correct order and no unexpected elements can appear in the output XML.
2. Element ‘<XYZ>’ has a missing child element ‘<ABC>’
This error occurs when an element does not contain all the required child elements as specified by the XSD schema. This typically happens due to missing data from TRAction’s client’s input files (from their trading platform or back office system).
Example: Consider a derivative report where the <TxData> (Transaction Data element) is expected to include a specific child element <SbsqntTxId> (Subsequent Position UTI). This error will be generated if <SbsqntTxId> is missing from the XML output.
For instance, if the client’s input data is incomplete, it may result in missing elements in the XML output. In such cases, TRAction’s XML generator has a missing elements flagger to alert us when this error occurs.
| Example XSD | |
| Incorrect XML Example | … … |
| Correct XML Example | … … |
3. Invalid Boolean Value for an Element
This error occurs when an element’s value does not conform to the expected XSD Boolean values. XSD defines Boolean values as lowercase true or false only. Uppercase variants such as TRUE, FALSE, True, or False are not valid and will trigger a validation error.
Example: Reporting Obligation must have lowercase ‘true’/’false’; when it is populated with an uppercase ‘TRUE’/’FALSE’, it generates an error.
| Incorrect XML example | |
| Correct XML example |
4. Invalid Decimal value scientific notation
This error occurs when an element with a decimal type contains an invalid value, often due to scientific notation being present in the element. It typically happens when our client’s input data is truncated or improperly formatted.
Example: Consider an XML element <Amt> representing an amount, which is defined as a decimal type. If the input data contains a value in scientific notation, it will result in an error.
| Incorrect XML example | |
| Correct XML example |
5. Pattern Constraint Violation
This error occurs when an element’s value does not match the pattern specified in the XSD schema. It is often encountered in fields like the UTI (Unique Transaction Identifier), where specific patterns must be adhered to.
Example: The UTI must follow a specific format: up to 52 alphanumeric characters and only the upper-case alphabetic characters A–Z and the digits 0–9 are allowed.
| Invalid UTI XML example | |
| Correct UTI XML example |
6. Enumeration Constraint Violation
This error occurs when an element’s value is not one of the predefined values specified in the XSD schema. Enumeration constraints restrict values to a specific set of options. Any value outside that set will fail validation, including values that may have been valid under a prior reporting regime.
Example: The ‘Valuation Method’ field allows only three predefined values: CCPV (Central counterparty valuation), MTMA (Mark To Market valuation), and MTMO (Mark To Model valuation). Any other value will result in an error.
| Incorrect XML example | … … |
| Correct XML example | … … |
7. Missing Required Attribute
This error occurs when an element is missing an attribute that is required by the XSD schema. Attributes provide supplementary data attached to an element. The XSD schema can mandate that certain attributes must always accompany certain elements.
This is commonly seen in amount or price fields where specific attributes must be included.
Example: In EMIR reporting, all price fields, such as Price, Strike Price, Notional Amount, etc., require the ‘Ccy’ (Currency) attribute when the price is represented as a monetary value (not in percentage or basis points). If the amount is provided but the currency attribute is missing, an error will occur saying: ‘Amt’ element is missing the required attribute ‘Ccy’.
| Invalid XML example | |
| Correct XML example |
8. Invalid Date/Time format
This error occurs when a date or time value does not conform to the expected format specified by the XSD schema. The xs:dateTime type in XSD requires a specific format, such as YYYY-MM-DDTHH:MM:SSZ (e.g., “2024-05-03T06:00:00Z”). Any deviation from this format will result in an error.
Example: In the example below, the space separator and absent timezone suffix both violate the xs:dateTime pattern.
| Incorrect XML example | |
| Correct XML example |
9. Exceeding Maximum Length Constraint
This error occurs when the length of a string element or attribute exceeds the maximum length specified in the XSD schema. The maxLength facet is used to define the maximum number of characters allowed.
Example: In the EMIR XSD schema, the element <UTI> (Unique Transaction Identifier) is restricted to a maximum length of 52 characters. The incorrect example below contains 59 characters while the correct example (31 characters) sits well within the constraint.
| Incorrect XML example | |
| Correct XML example |
Summary
XML and the associated XSD validations have added a level of complexity to trade reporting. Errors can originate from the schema structure itself, from data quality issues, or from format mismatches introduced during data processing. Identifying the root cause quickly is critical to maintaining timely and accurate submissions.
Firms that lack dedicated XML expertise often find value in working with a specialist reporting partner to manage this complexity on an ongoing basis.
Contact TRAction if you think you could benefit from support with your reporting needs.
