FREQUENTLY ASKED QUESTIONS (FAQ)
Questions and answers are divided into the following categories:
 Regulations – questions 1-18
 Transactions reporting to KDPW_TR – questions 19-42
 Fees – questions 43-45
 Ids used in the reporting process – questions 46-51
 Data reconciliation – questions 52-54
Questions related to regulations
1.
What regulations lay down the derivative trade reporting obligation?
The obligation to report details of each derivative contract follows directly from Article 9 of Regulation (EU) No 648/2012
of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties and trade
repositories (EMIR). The full text of the Regulation is available on the websites of EUR-Lex and ESMA.
Links:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2012:201:0001:0059:PL:PDF
http://www.esma.europa.eu/page/European-Market-Infrastructure-Regulation-EMIR
The website www.knf.gov.pl includes a section devoted to EMIR:
http://www.knf.gov.pl/o_nas/wspolpraca_miedzynarodowa/unia/regulacje_i_dokumenty_powiazane/EMIR.html
2.
In addition to EMIR, is there any other legislation which governs the scope and mode of reporting?
Yes, the regulations ITS/RTS, i.e., the implementing and regulatory technical standards which define the scope and format
of the key data to be reported. The reporting obligation is defined in detail in Commission Delegated Regulation
No 148/2013 and Commission Implementing Regulation No 1247/2012.
3.
When did the reporting obligation take effect?
The reporting obligation for all classes of derivatives took effect on 12 February 2014.
The valuation and collateral reporting obligation took effect on 11 August 2014.
4.
Which entities are required to report trades?
The reporting obligation applies to all entities which carry out economic activities in whatever form which are parties
to trades in derivative contracts defined in EMIR.
5.
Does the reporting obligation apply to natural persons who carry out economic activities?
According to the position of the European Commission presented in “EMIR: Frequently Asked Questions” of 18 December
2013, the obligations under Article 9 of EMIR apply also to natural persons who carry out economic activities.
6.
Which entities are exempted from the reporting obligation?
According to Article 9 of EMIR, natural persons who do not carry out economic activities are exempted from the reporting
obligation. Furthermore, non-financial counterparties below the clearing threshold set under Article 10(3) of EMIR are
exempted from the valuation and collateral reporting obligation.
7.
Does the reporting obligation cover derivative trades on the regulated market?
Yes. The reporting obligation covers all derivative trades regardless of the trading market.
8.
Does the reporting obligation for the regulated market apply to a brokerage house?
Yes. According to the ESMA guidelines published in “Questions and Answers” of 20 December 2013, a brokerage house
is required to report derivative trades including both its own trades and clients’ trades. A brokerage house may delegate
the reporting obligation to KDPW_CCP or another party which provides delegated reporting services.
9.
Which derivatives are covered by the EMIR reporting obligation?
The EMIR Reporting obligation covers all financial instruments listed in points (4) to (10) of Section C of Annex I to Directive
2004/39/EC (MiFID) (according to the definition of derivative/derivative contract as set out in Article 2(5) of EMIR)
10. When did the valuation and collateral reporting obligation take effect?
The valuation and collateral reporting obligation took effect 180 days after the effective date of the reporting obligation for
a class of instruments. This means that the effective date of the reporting obligation is 11 August 2014 and first reports are
required no later than 12 August 2014, indicating valuation and/or collateral as at the end of day on 11 August 2014.
11. Who has the valuation and collateral reporting obligation?
The valuation and reporting obligation applies to financial counterparties (FC) as well as non-financial counterparties above
the clearing threshold (NFC+).
12. Who is exempted from the valuation and collateral reporting obligation?
The valuation and reporting obligation does not apply to non-financial counterparties below the clearing threshold (NFC-).
13. Is reporting of OTC trades different from reporting of regulated market trades?
Yes. According to the ESMA guidance published in the “Questions and Answers”, reporting to a trade repository differs
depending on the trading market. While all reports include the same scope of information required under EMIR and the
technical standards, the categories of entities which have the reporting obligation differ. Detailed scenarios and categories
of entities understood as counterparties can be found in the “Questions and Answers”, sections IV and V.
14. Is trade repository participation mandatory?
No. Entities which have the reporting obligation may report trade directly to a selected ESMA-authorised trade repository
or send reports via a reporting participant (delegated reporting).
When reporting to KDPW_TR, direct reporting of derivative trades requires GUR or ZUR participation status.
15. Can the reporting obligation be delegated to KDPW_CCP?
Yes. KDPW_CCP may act as an intermediary in reporting of trades cleared by the clearing house. In that case, all details
necessary for the service will be required by KDPW_CCP. This includes the trade party details set out in RTS/ITS as well as
the clearing account whose trades are to be reported by KDPW_CCP. More information about delegating the reporting
obligation to KDPW_CCP are available online at the website KDPW_CCP.
16. What is the reporting deadline for contracts?
According to Article 9(1) of EMIR, details of each derivative contract and of any modification or termination of the contract
shall be reported no later than the working day following the conclusion, modification or termination of the contract.
17. What is backloading?
Backloading is the reporting of trades made before the reporting start date. The criteria of identification of such trades and
the time limits for reporting to the trade repository are as follows:
 trades made before 16 August 2012 and outstanding on that date and still outstanding on the reporting start date
should be reported within 90 days after the reporting start date;
 trades made on or after 16 August 2012 and outstanding on the reporting start date should be reported to the trade
repository without delay, i.e., they should be reported on the reporting start date as at the previous day (11 February
2014);
 trades made on or after 16 August 2012 and no longer outstanding on or after the reporting start date should be
reported to the trade repository within 3 years of the reporting start date for the class of derivatives.
According to the ESMA guidelines (TR question answer 4 (a)), trades which expired before the reporting start date should
be reported in the final state, i.e., as at the trade reporting date.
18. Can the same trade be reported twice with the same UTI?
No, it is not possible to resend details using the same UTI. Even if previously submitted report was annulled.
This follows directly from the ESMA requirements.
Questions related to transactions reporting
19. How does reporting to a trade repository work in practice?
Reporting means that all details of a derivative trade (or details of any change of the trade terms/characteristics, valuation,
etc.) are provided to the trade repository system in an XML message. Depending on the choice of the reporting entity,
report messages are submitted via an online application (U2A) or directly from server to server (A2A).
20. How to become a KDPW_TR participant?
In order to obtain the KDPW Trade Repository participant status (GUR, ZUR or PUR), the first step is to file
an application for participation according to the template form available on the website www.kdpw.pl. The documents
listed in the KDPW_TR Rules must be attached to the application. After approval of participant status (pursuant to a
Resolution of the Management Board of KDPW SA), in order to report trades, users need to download at least one U2A
certificate necessary to access the KDPW_TR application. Users can download certificates online: U2A request form.
21. What is GUR?
General Reporting Participant (GUR) is authorised to report contracts to the trade repository on its own behalf or on behalf
of another counterparty, including reports of contracts to which GUR is not a party. GUR is authorised to:





report trades to the trade repository;
view trades reported by the GUR to the trade repository (whether or not the GUR is a party to such trade);
view all own trades reported to KDPW TR (whoever has reported them);
declare correction to reports considered to be erroneous (whoever has reported them);
build relations with KUR in order to make available details of trades to which the participant is a party.
22. What is ZUR?
Ordinary Reporting Participant (ZUR) is authorised to report trades to which it is a party, which means that it may also
report for the other counterparty to such trades. ZUR is authorised to:





report trades to the trade repository;
view trades reported by the ZUR to the trade repository
view all own trades reported to KDPW TR (whoever has reported them);
declare correction to reports considered to be erroneous (whoever has reported them);
build relations with KUR in order to make available details of trades to which the participant is a party.
23. What is PUR?
Indirect Repository Participant (PUR) is not a reporting participant. PUR’s trades are reported by ZUR or GUR.
PUR is authorised to:



view all own trades reported to KDPW TR by reporting participants;
declare correction to reports considered to be erroneous;
build relations with KUR in order to make available details of trades to which the participant is a party.
24. What is KUR?
Commercial Repository User (KUR) gets access to trades to which KDPW_TR participant is a party under authorisation from
this participant. KUR is required to sign an agreement concerning access to contract details and non-disclosure.
25. Which classes of instruments can be reported to KDPW TR?
Trade in all classes of derivative instruments regardless of the trading market (regulated and OTC) can be reported
to KDPW_TR:






Commodity derivatives (CO);
Credit derivatives (CR);
Currency derivatives (CU);
Equity derivatives (EQ);
Interest rate derivatives (IR);
Other derivatives (OT).
26. What access channels are available for the KDPW_TR service?
Two channels are available for communication with the trade repository:
 U2A (User to Application) - offers access to an online application with a graphical user interface (templates)
and the functionality of uploading messages from files saved locally by the user;
 A2A (Application to Application) - based on a message queue (MQ) and supports automatic exchange of XML files.
27. Who are U2A and A2A dedicated to?
U2A is the basic access channel which gives all entities the opportunity to report derivative contracts in two ways:
 through the graphical interface, where counterparty and trade details are entered,
and
 by uploading existing XML files containing counterparty and trade details.
The solutions are dedicated to entities which report relatively few transactions as well as entities preparing to process XML
files or using manual processing of XML files.
A2A is a direct channel for the exchange of XML messages between systems dedicated to entities which report bigger
quantities of data. The configuration and use of the channel requires a KDPW_TR participant to make additional efforts
in order to build an application infrastructure and a dedicated VPN channel.
28. For communication with KDPW_TR over A2A, can existing VPN channels be used?
KDPW recommends to provide separate communication with KDPW TR through a dedicated VPN channel set up over
the internet. At the same time, it is possible to use existing digital channels for communication with KDPW_TR; however,
IP addresses and the message queue of such communication will be different.
29. Does KDPW_TR provide secure access?
Yes, the KDPW_TR application is secure. Access to the system is only allowed to participants who hold an electronic
certificate required to log in the application.
30. Do all users get the same access to the application?
The scope of access to the application may be diversified depending on the individual (U2A) access rights granted
in a certificate.
31. What are KDPW_TR’s reporting hours/days?
Reports are accepted 24/7 with the exception of technical maintenance breaks.
IT support is available from 06:00 to 20:00.
The Trade Repository Department hours are 08:00 to 17:00 on business days.
A business day is any day of the week other than a bank holiday, Saturday, Sunday or any other day defined by the KDPW
Management Board as a holiday.
32. What is dual-sided reporting?
In dual-sided reporting, a trade is reported on behalf of both counterparties by one reporting entity in a single report. Two
counterparty details sections and/or valuation or collateral sections and one trade details section must be completed
in such a report. Dual-sided reporting is recommended in regulations (see Article 1(3) of RTS 148/2013). However, each
counterparty may report a trade individually. Such report should include sections 1 and 2 completed only once.
33. Is it possible to report multiple trades in a single message to KDPW_TR?
Yes. Up to 10,000 trades can be reported to KDPW TR in a single message.
34. What are KDPW_TR collective reports and who can use them?
Collective reports are dedicated for the reporting of change of valuation, collateral, counterparty details, or termination
of a portfolio/financial instrument for multiple reports.
35. What is the sequence of the processing of reports sent to KDPW_TR?
The processing of reports and the sending of feedback messages with the report status in the Trade Repository follow
the FIFO principle (first in first out). This means that reports are processed in the same order as they are received
in the message queue (MQ).
36. What if two trading counterparties (in individual reports) use a different Trade ID?
If this happens, KDPW_TR will read such reports as relating to different trades. As a result, they will not be paired in data
reconciliation. It should be noted that the ESMA regulations explicitly require counterparties to agree and use the Trade ID.
37. How are eligibility dates checked in different kinds of reports?
Data field checks depend on the validations published by ESMA as well as KDPW_TR application system requirements.
In addition to validations according to table VL2, the following date checks are implemented for different action types:
 AT = N
Eligibility date must be equal to Execution timestamp.
 AT = N Back
Eligibility date must be equal to Termination date
 AT = V (valuation update)
Eligibility date must be equal to Valuation date.
 AT = C and Z (termination and compression)
Eligibility date must be equal to Termination date.
38. What validations are used by KDPW_TR in substantive checks of reports?
According to the ESMA requirements, substantive checks of reports use Level 1 and Level 2 validations, as well as additional
checks required by the system architecture, e.g., checks of eligibility dates for different action types (AT=N, AT=V, AT=Z and
AT=C).
39. How to report values in field 22 ‘Collateralisation’?
Collateralisation is always reported from the perspective of the counterparty to the reported trade in relation to the other
counterparty. The collateral fields are completed when a counterparty provides collateral to the other counterparty:
PC – partial collateralisation; OC – single-sided full collateralisation; U – uncollateralised; FC – dual-sided full
collateralisation. For additional guidance on reporting, see the Q&A - TR question 33.
40. How is timely reporting checked?
Timely reporting is checked by comparing reporting dates with a specific date or dates depending on the action type.
Derivative contract reports flagged as late are included in a summary late trade report available to the competent
supervision authorities.
41. How are XML messages processed if they are incorrect (do not match the schema or fail a check)?
Those messages which do not match the XSD schema or fail a check are rejected. In response to an incorrect report,
the KDPW_TR system generates a feedback error message:
 admi.err.001.01 if the message does not match the schema
or
 trar.sts.003.01 with the status ERRO and the error code indicating the incorrectly completed/void field.
If a message reports more than one trade, only the incorrectly reported trade is rejected.
42. What is Level 1 Validation and Level 2 Validation?
Validation is a set of rules necessary to check the completion of fields in reports as defined by the European Securities and
Markets Association (ESMA).
Level 1 Validation (L1V) was published on 24/10/2014, implemented by trade repositories on 01/12/2014, and defines
whether specific data are mandatory (or optional) and whether fields can be completed as ‘NA’ (not available).
Level 2 validation (L2V) was published on 27/04/2015, implemented by trade repositories on 01/11/2015, and defines
allowed data formats for fields as well as dependencies/conditionality of fields for trades in different derivative classes.
The validation table is published on ESMA’s website: Validation table.
Questions related to KDPW_TR fees
43. What fees are charged to reporting participants?
KDPW_TR charges three kinds of fees from reporting participants:
 participation fees
 trade reporting fees
 trade maintenance fees.
Participation fee:
An annual participation fee is charged depending on participant status as follows: GUR – PLN 40 thousand per year;
ZUR – PLN 10 thousand per year; PUR – PLN 2 thousand per year.
If an entity becomes a participant in the second half of a year, the fee is charged at ½ of the amount. In case of termination
of participation due to change of the participation type in the first half of a calendar year, the fee for the year is charged
at ½ of the amount due for the previous participation type and ½ of the amount due for the new participation type.
Trade reporting fee:
 reporting of an ETD (exchange-traded derivative) trade: PLN 0.05 (ca. EUR 0.01) per trade;
 reporting of a non-ETD trade: PLN 0.15 (ca. EUR 0.03) per trade.
Trade maintenance fee:
The monthly fee for maintenance of a trade in the trade repository: PLN 0.05 (ca. EUR 0.01) per active trade.
44. Does the TR apply any discounts or rebates?
No. According to the TR Rules, no discounts or rebates apply.
However, the TR Rules provide for a CAP, i.e. the maximum amount of fees.
The cap is a maximum amount of total fees for:
 reporting of trades to the repository, and
 maintaining of contract information in the repository.
The cap is set at PLN 250 thousand per year for fees on contracts of a counterparty reported by a reporting participant. This
fee cap only applies where a reporting participant reports no more than 25 million trades for a counterparty within a year.
The cap is determined individually for each pair: reporting participant + counterparty.
If a pair reports more than 25 million trades, KDPW_TR restarts the calculation of fees for reporting of trades
to the repository and for maintaining of contract information in the repository up to the next cap (PLN 250 thousand);
the fees are no longer charged up to 50 million trades reported by the pair: reporting participant + counterparty.
45. How are trade reporting and maintenance fees calculated?
Example 1
An entity reports 10,000 OTC trades every month, each trade is terminated at the end of the month in which it was
concluded. The fees are charged as follows:
month
number of reported
trades
number of active
trades
reporting fee
maintenance fee
(monthly)
total
cumulative
total
Jan
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
2 000
Feb
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
4 000
Mar
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
6 000
Apr
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
8 000
May
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
10 000
Jun
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
12 000
Jul
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
14 000
Aug
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
16 000
Sep
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
18 000
Oct
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
20 000
Nov
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
22 000
Dec
10.000 OTC
10.000 OTC
10.000 *0,15=1.500
10.000 *0,05=500
2 000
24 000
The total fees charged in the year are PLN 24 thousand.
Example 2
An entity reports 100,000 ETD trades and 100,000 OTC trades every month, each trade is a trade on its own account,
concluded for three months and then expired. The fees are charged as follows:
month
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
number of reported
trades
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
100.000 ETD
100.000 OTC
number of active
trades
100.000 ETD
100.000 OTC
200.000 ETD
200.000 OTC
300.000 ETD
300.000 OTC
300.000 ETD
300.000 OTC
300.000 ETD
300.000 OTC
300.000 ETD
300.000 OTC
300.000 ETD
300.000 OTC
300.000 ETD
300.000 OTC
300.000 ETD
300.000 OTC
300.000 ETD
300.000 OTC
300.000 ETD
300.000 OTC
300.000 ETD
300.000 OTC
reporting fee
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
100.000 * 0,05 +
100.000 * 0,15= 20.000
The total fees charged in the year are PLN 250 thousand.
maintenance fee
(monthly)
100.000 *0,05+
100.000 * 0,05=10.000
200.000 *0,05+
200.000 * 0,05=20.000
300.000 *0,05+
300.000 * 0,05=30.000
300.000 *0,05+
300.000 * 0,05=30.000
300.000 *0,05+
300.000 * 0,05=30.000
300.000 *0,05+
300.000 * 0,05=30.000
300.000 *0,05+
300.000 * 0,05=30.000
300.000 *0,05+
300.000 * 0,05=30.000
300.000 *0,05+
300.000 * 0,05=30.000
300.000 *0,05+
300.000 * 0,05=30.000
300.000 *0,05+
300.000 * 0,05=30.000
300.000 *0,05+
300.000 * 0,05=30.000
total
total
cumulative
30 000
30 000
40 000
70 000
50 000
120 000
50 000
170 000
50 000
220 000
50 000
250 000 CAP (!)
50 000
-
50 000
-
50 000
-
50 000
-
50 000
-
50 000
-
Questions related to Ids used in the reporting process
46. What is UPI?
The UPI (Unique Product Identifier) is a global product identifier. The identifier is currently not in use. Work is underway
to develop the UPI standard, headed by CPMI-IOSCO Harmonization Group.
47. What is UTI?
The UTI (Unique Trade Identifier) is a global trade identifier. In its recommendations on the UTI generation and structure,
ESMA expects that the UTI should be arranged between the parties to a trade. In its “Questions and Answers”,
ESMA published guidelines on the rules of building UTIs by counterparties for use in reporting (see TR questions 18 and 19).
Work is underway to develop the UTI standard, headed by CPMI-IOSCO Harmonization Group.
48. What is LEI?
The LEI (Legal Entity Identifier) is a global identifier of 20 alphanumeric characters which clearly identifies a party. An LEI is
issued to counterparties being legal persons under ISO 17442. As LEIs are broadly available and used, LEIs are required to be
used in the reporting of trades by all counterparties eligible to obtain an LEI in order to identify the trading parties, the
reporting entity, the trade beneficiary, the broker, and the clearing member.
49. Is an LEI mandatory in reporting to trade repository?
Yes, ESMA has identified the LEI as the identifier to be used in reporting by all entities which have the reporting obligation
and can obtain an LEI. However, entities which have the reporting obligation, but hold no LE,I can be identified in reporting
with a client identifier, which is accepted as correct. Reports which identify the counterparty or other counterparty with
an identifier other than the LEI are not included in data reconciliation (pairing and comparing of reports).
50. How to upgrade an entity’s identifier from OTHR to LEI?
While ESMA has published guidance on modification of client identifiers to LEI (TR question 40), ESMA and trade
repositories are still discussing the details. KDPW_TR has suggested that client identifiers are upgraded to LEIs using
a dedicated collective message trar.ins.006.01. However, in view of the current discussions with ESMA, the functionality has
been suspended.
51. Are both counterparties required to use the same UTI?
Yes. The UTI (Trade ID) is a unique trade identifier agreed and generated jointly by the counterparties. It is used in order
to pair and compare reported details in single-sided reporting, especially where reports are sent individually by both
counterparties. Both counterparties must use the same UTI.
Questions related to data reconciliation
52. What is data reconciliation by trade repositories?
Reconciliation is a process performed in co-operation of all trade repositories authorised under EMIR which involves
the pairing and comparing of reports individually sent by parties.
A detailed description of the process and the status codes and their meaning are available online:
Description of Reconciliation.
53. How does the TR notify participants of the outcome of reconciliation?
KDPW_TR provides the outcome of reconciliation in the message trar.rcn.001.02 including the reconciliation status. Those
reports which contain no errors or contain only category 3 errors have the status MACH. Those reports which contain
category 2 or 3 errors have the status ERR2. Those reports which contain category 1 errors have the status ERR1. Those
reports which contain incorrect counterparty identifiers or codes have the status ERCD.
54. What is the reporting entity required to do after receiving the report status in message trar.rcn.001.02?
The status of a reported trade provided in the message trar.rcn.001.02 is one of the following: {ERCD; ERR1; ERR2; MACH;
NPAR}.
 MACH means that pairing and comparing is successful. The participant is not required to do anything.
 NPAR means that the other counterparty report has not been found. It is recommended that the entity contacts the
other counterparty to clarify whether it has reported the trade to a trade repository and whether the other report has
the same trade identifier.
 ERR1 and ERR2 mean that reports have been paired but there are differences between the reports of both
counterparties.
 The report lists the differently reported fields. The counterparty should contact the other counterparty to agree the
details or modify its report by accepting the details reported by the other counterparty.
 ERCD means that details must be modified to successfully pair the reports:
 E003 means that the ‘Counterparty side’ fields in the reports do not match.
The participant should modify the report details to make sure that the counterparties report the opposite sides.
 CPCT means that the field ‘Non-EEA counterparty’ (tag NonEEACtrPty) does not match the other counterparty’s
report.
The participant should modify details reported in the field ‘Non-EEA counterparty’.
 ERL1 and/or ERL2 means that the LEI of the counterparty/other counterparty is incorrect (invalid identifier or
identifier not found in the GLEIF database)
The participant should check the LEI used in reporting and, if it is found to be incorrect, cancel the report and then
report the trade again using the correct counterparty identifiers;
 ERUT means that the report contains an incorrect trade identifier (as a result, the trade will not be included in
reconciliation).
The error codes and summary descriptions are available online in the ‘Error codes generated by KDPW_TR’ document.