A stable, well-functioning financial market for allA stable, well-functioning financial market for allFAQ TRS 2
- Who must submit transaction reports according to Article 26 of MiFIR?
- Does an investment firm with authorisation to conduct discretionary portfolio management that manages investment fund(s) on behalf of a fund management company need to report transactions it executes on behalf of the funds under a mandate?
- Can I report transactions without an LEI (Legal Entity Identifier)?
- Is LEI needed to identify clients who trade in endowment insurance?
- Is LEI required to identify a client in conjunction with a compulsory sale?
- When should the transactions be reported?
- To which country's authority should branches submit their reports?
- Where do I find the XML Schema for transaction reporting?
- What is the file format/interface used for TRS 2 reporting?
- How do I access the TRS 2 reporting system?
- Is there a limit on the number of transactions or files that may be submitted per day?
- What is an Approved Reporting Mechanism (ARM)?
- How do I change a transaction that has been submitted but is incorrect?
- Is there any time limit on when revisions can be made?
- We are getting the status RJCT on our report with an error message CON-412 ("Instrument is not valid in reference data on transaction date"). Why is this happening and what should we do?
- What happens if the ISIN code is missing when a transaction is reported?
- To whom do I direct questions related to reference data?
- Is it possible to submit information about reference data in the transaction report?
Who must submit transaction reports according to Article 26 of MiFIR?
The rules regarding transaction reporting affect all firms that conduct securities business, including those that offer discretionary management on behalf of a client. Firms that transmit orders do not need to report transactions if they have entered an agreement with the executing firm that the executing firm will report the transactions (Article 4 of RTS 22).
Trading venues/market operators shall report information about transactions with financial instruments that are traded on their platform and that are conducted through their system by a firm not subject to MiFIR/MiFID II.
Does an investment firm with authorisation to conduct discretionary portfolio management that manages investment fund(s) on behalf of a fund management company need to report transactions it executes on behalf of the funds under a mandate?
According to the rules for transaction reporting, UCITS and AIF managers are exempted from the reporting requirements. This also applies to fund managers who have authorisation to conduct portfolio management. However, in the scenario in question, it is the investment firm that makes investment decisions with a discretionary mandate given by a client pursuant to Article 3(1)(d) of Commission Delegated Regulation (EU) 2017/590* (RTS 22) and thus is considered to execute a transaction for which it is subject to a reporting obligation. The fact that fund management company calls this an outsourced fund operation does not affect the assessment that it is an investment service that the investment firm provides to the fund management company under a mandate.
When submitting its report, the investment firm (Investment Firm A) should use the examples of reporting for a discretionary assignment presented in Section 5.27 of ESMA's Guidelines on transaction reporting. In these examples, "Client" should be exchanged for "Fund Management Company" (underlying funds should not be reported).
When Investment Firm A transmits an order to the executing investment firm (Investment Firm B), Example 5.27.2 in the guidelines shall be applied if all conditions in Article 4 of RTS 22 are met. If the conditions for transmission of orders pursuant to Article 4 of RTS 22 are not met, Example 5.27.1 in the guidelines shall be applied instead.
* Commission Delegated Regulation (EU) 2017/590 of 28 July 2016 supplementing Regulation (EU) No 600/2014 of the European Parliament and of the Council with regard to regulatory technical standards for the reporting of transactions to competent authorities.
ESMA's Guidelines on transaction reporting
Return to menu
Can I report transactions without an LEI (Legal Entity Identifier)?
All legal entities that report transactions to FI must have an LEI. Where applicable, an LEI also needs to be provided for other parties in the transaction chain, such as the decision-maker, client and counterparty.
The European Securities and Markets Authority (ESMA) published a statement on 20 December 2017 specifying the new requirements on investment firms to identify their (legal) clients with LEIs in the transaction reporting.
This statement was published because of indications from the market that many investment firms are experiencing difficulties in meeting the new identification requirements by the entry into force of MiFID II/MiFIR on 3 January 2018. The statement contains an interim solution that applies for six months from the entry into force and in brief entails that investment firms may offer their clients the opportunity to trade without identification via LEI at the given point in time, assuming that the investment firm undertakes and receives a mandate to apply for an LEI on behalf of the legal client. The application must then occur immediately, and the transactions must be reported as quickly as possible.
In a document published on 20 June 2018, ESMA clarifies that the final date for the aforementioned interim solution is 2 July 2018. For reports with a transaction date of 3 July or later, the transaction date must fall on the same day or later than the initial registration date for the client's LEI code.
ESMA's statement on the final date for the interim solution
Is LEI required to identify a legal person who trades in endowment insurance?
In order for Finansinspektionen to be able to use transaction data in an effective manner to conduct investigations into suspected market abuse, it must be possible to identify the end client in the transaction report.
If the client has not made the investment decision, it must also be possible to identify the decision-maker. This means that legal persons trading in endowment insurance need to be identified through LEI as the decision-maker for the transaction. The same applies for a legal person trading in pension insurance.
The insurer is the official owner of the financial instruments invested in the endowment insurance, and the insurer's LEI must still be provided to identify the buyer/seller in these reports.
Is LEI required to identify a client in conjunction with a compulsory sale?
In the event a client is a legal person who does not have a valid LEI and a third party takes the initiative to conduct a compulsory sale (for example in conjunction with distraint or bankruptcy proceedings), the LEI of the legal person who took the initiative for the transaction should be provided to identify the buyer/seller (for example investment firm, bankruptcy administrator, Swedish Enforcement Agency).
When should the transactions be reported?
Information about the transaction must be submitted to FI as quickly as possible and no later than the following business day (11:59 PM), T+1 (Article 26 of MiFIR).
To which country's authority should branches submit their reports?
Transactions executed in full or in part by Swedish securities companies' foreign branches shall be reported to the parent company's/securities company's home Member State. Therefore, a Swedish securities company reports transactions executed by foreign branches to FI.
Where do I find the XML Schema for transaction reporting?
ESMA's XML Schema can be found in the file XML Schema TRS2.zip
What is the file format/interface used for TRS 2 reporting?
An encrypted SFTP connection is used to connect to the system. This means that each submitting entity that connects to the system needs an FTP client that supports SFTP. Note that the earlier online interface for previous transaction reporting system (TRS 1) is no longer available as an alternative.
How do I access the TRS 2 reporting system?
In order to be able to connect to and report via the TRS 2 system's production environment, FI needs to gather some information about the submitting entity via an application form. Based on this information, FI creates an account and sends the account information that is needed to connect to FI's FTP server to the contact person specified on the application form.
An encrypted SFTP connection is used to connect to the system. This means that each submitting entity that connects to the system needs an FTP client that supports SFTP. If the submitting entity is reporting on its own behalf, the form Application for authorisation for TRS 2 reporting is used
If your firm's transaction reporting will be submitted by an approved reporting mechanism (ARM), your firm does not need to send an application for authorisation to FI. The ARM applies for an account in the production environment to report on behalf of your firm.
There is also a different application for authorisation for market operators of a trading venue that need to report transactions in accordance with Article 26(5) of MiFIR.
Is there a limit on the number of transactions or files that may be submitted per day?
The maximum number of transactions per file is 500,000. There is no limitation on the number of files you may submit per day, but we would like to receive large "grouped" files, i.e. no individual transactions in real time.
What is an Approved Reporting Mechanism (ARM)?
An Approved Reporting Mechanism (ARM) according to Article 4(54) of MiFID II is "a person authorised under this Directive to provide the service of reporting details of transactions to competent authorities or to ESMA on behalf of investment firms", i.e. a third party that an investment firm engages to report the transactions on its behalf. It has nothing to do with the actual transaction reporting system itself, but if you will report transactions on behalf of an investment firm, you must apply for authorisation to be an ARM.
What status can be assigned to a transaction?
| Name | Activity | Deadline |
| T | Transaction execution (trading day) | |
| R | Submitting Entity submits a transaction report for trading day T to FI on | T+1 business day |
|
Submitting Entity receives a response file from FI for the transaction report for trading day T |
R+1 calendar day |
Example 1: A transaction is reported on trading day T. Because reference data from ESMA is not available in the system on day T (it is published first on day T+1), the transaction will be assigned the status RCVD (Received) on day T (the number with status RCVD is shown in the FF file).
The validation of such a transaction is done the following day, T+1, when updated reference day for day T is available:
- The transaction has no errors -> is assigned the status ACPT on day T+1 (and is shown as ACPT in the FD file);
- The transaction contains errors -> is assigned the status RJCT on day T+1 (and is shown as RJCT in the FD file);
- The transaction has no errors, but instrument data is still not available on day T+1-> the transaction is assigned the status PDNG (Pending) and no FD file is created. Validation will be repeated against the updated reference data every day for up to seven calendar days from the date the transaction report was received. An FD file will be generated first when the status for the transaction changes from PDNG to ACPT or RJCT. If the reference data is still missing after seven days from the date the transaction report was received, the transaction will be assigned the status RJCT (shown as RJCT in the FD file).
Example 2: A transaction is reported on day T+1 before reference data for day T is available in the system. The transaction is assigned the status RCVD (Received) on day T+1 (the number of RCVD is shown in the FF file). The validation of such a transaction is done the later the same day, T+1, when updated reference day for day T is available.
- The transaction has no errors -> is assigned the status ACPT (and is shown as ACPT in the FD file);
- The transaction contains errors -> is assigned the status RJCT (and is shown as RJCT in the FD file);
- The transaction has no errors, but instrument data is still not available on day T+1-> the transaction is assigned the status PDNG and no FD file is generated. Validation will be repeated against the updated reference data every day for up to seven calendar days from the date the transaction report was received. An FD file will be generated first when the status for the transaction changes from PDNG to ACPT or RJCT. If the reference data is still missing after seven days from the date the transaction report was received, the transaction will be assigned the status RJCT (shown as RJCT in the FD file).
Example 3: A transaction is reported on day T+1 after reference data for day T has been made available in the system. Validation of such a transaction is done immediately.
- The transaction has no errors -> is assigned the status ACPT (the number of transactions with the status ACPT is shown in the FF file on day T+1);
- The transaction contains errors -> is assigned the status RJCT on day T+1 (is shown as RJCT in the FF file);
- The transaction has no errors, but instrument data is not available on day T+1-> the transaction is assigned the status PDNG (shown as PDNG in the FF file);
- Validation will be repeated against the updated reference data every day for up to seven calendar days from the date the transaction report was received. An FD file will be generated first when the status for the transaction changes from PDNG to ACPT or RJCT. If the reference data is still missing after seven days from the date the transaction report was received, the transaction will be assigned the status RJCT (shown as RJCT in the FD file).
How do I change a transaction that has been submitted but is incorrect?
It is necessary to first submit a recall report before changing an incorrect transaction report. The following fields must be filled in in the recall:
- Transaction ID, the same as for the incorrect transaction that was submitted earlier (Field 2)
- Executing Entity LEI (Field 4)
- Submitting Entity LEI (Field 6)
A new, correct transaction report needs to be sent in after the recall, even this with the same transaction ID. Note that the Transaction ID for the incorrectly reported transaction and the recall may only be reused when correcting incorrect transaction reports that have already been submitted.
To ensure that the recall and correction is handled by the system in the right order, the notifier needs to wait for ACPT for the recall before sending in the correction. If the recall and correction are sent in at the same time (via the same or different TR files) there is a risk that they will be handled in the wrong order. What happens then is that the correction is processed first and interpreted as a double of the first submitted incorrect transaction report (error code CON-023). Thereafter the recall is processed, and if it is approved CANC becomes the transaction report's most recent and current status.
Is there any time limit on when revisions can be made?
FI encourages firms to revise previously reported information without undue delay if there has been a change.
We are getting the status RJCT on our report with an error message CON-412 ("Instrument is not valid in reference data on transaction date"). Why is this happening and what should we do?
If a transaction report is rejected with the error code CON-412, this may be because the transaction is not related to an instrument subject to a reporting obligation or that the stated trade date falls prior to the date of admission to trading or date of first trade for the instrument in ESMA's database. In some cases, there can also be a problem in the transfer of reference data from ESMA to FI, which causes problems in the validation of transactions in the instrument.
In Sweden, instrument reference data is reported directly to ESMA by trading venues (TV) and systematic internalisers (SI). If the entity submitting the transaction suspects that submitted reference data from a Swedish actor is incorrect, we recommend first contacting the TV/SI in question to check the information, and then FI, which can contact the TV/SI. If the reference data is submitted by a foreign TV/SI, FI should be contacted. FI then contacts the competent authority in the foreign country in question, which in turn contacts the concerned TV/SI. For contact with FI regarding such matters, contact Reporting at rapportering@fi.se.
If the submitting entity notes that the information in the transaction report agrees with the data in FIRDS but the report is still denied with the error CON-412, contact FI since there may be problem in the transfer of data from FIRDS to FI. FI publishes updated information on a regular basis regarding transaction reporting.
What happens if the ISIN code is missing when a transaction is reported?
The transaction is validated against reference data every day for seven days. If there is no ISIN after seven days, the transaction is rejected and is given the status RJCT (Rejected).
How do I gain access to reference data from ESMA?
Reference data subject to the MAR and MiFID/MiFIR regulations and that is available for the moment is searchable in ESMA's Financial Instruments Reference Data System (FIRDS). Information on how reference data files can be downloaded in ESMA's instructions.
Financial Instruments Reference Data system (FIRDS)
To whom do I direct questions related to reference data?
If you do not find the information you are looking for in the reference data at fi.se, you should first contact ESMA at mifir.support@esma.europa.eu.
Is it possible to submit information about reference data in the transaction report?
Yes, this is done in fields 42-56 in the transaction report. Fields 42-56 do not apply when the transactions are executed on a trading venue or with an investment firm that acts as a systematic internaliser or when an ISIN code that is included in ESMA's Financial Instruments Reference Data System (FIRDS) is entered into Field 41.
Last reviewed: 2023-10-09
