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.
Return to menu
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
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 and additional details on what this interim solution entails from a purely technical perspective
ESMA's statement on the final date for the interim solution
Return to menu
Is LEI needed to identify clients who only trade in endowment insurance?
A legal person does not need to obtain an LEI only because it has an endowment insurance account. The insurance company is the official owner of the financial instruments invested in the endowment insurance. When reporting executed transactions in the endowment insurance account, the insurance company's LEI should be provided to identify the buyer/seller.
However, if the policyholder is a natural person or already has an LEI, this person should be identified as the buyer/seller instead of the insurance company.
Return to menu
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).
Return to menu
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).
Return to menu
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.
Return to menu
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.
Return to menu
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?
||Transaction execution (trading day)
||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
Max R+7 if the instrument does not have reference data
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).
Return to menu
How should responses to submitted transactions be interpreted?
We recommend that TR files be submitted after 12AM on day T+1, where day T is the trading date/execution date, in order to avoid difficulties in the response mapping.
Examples of difficulties in the mapping between TR files and FF and FD files that may arise if a TR file is submitted on day T (trading date/execution date) or day T+1 before 10AM:
8:00 AM, day T+1
Submitting Entity submits a TR file containing two transactions: TX-A and TX-B.
9:00 AM, day T+1
FF file is received. The FF file shows 1 ACPT transaction and 1 RCVD transaction. Only the number of ACPT and the number of RCVD are shown. No Transaction IDs are shown for either ACPT or RCVD. Transaction IDs are only shown in FF files if the transaction status is RJCT.
12:00 AM, day T+1
Reference data arrives at Finaninspektionen.
23:00 AM, day T+1
All transactions with the status RCVD are validated against updated reference data and the validation creates an FD file. The FD file – which is received day T+2 – shows that an earlier RCVD transaction has become ACPT (the status has changed from RCVD to ACPT) and the Transaction ID for this transaction (TX-B) is shown. No information about TX-A is shown in the FD file.11:00 AM, day T+1
The Transaction ID for TX-A will never be shown anywhere, in neither the FF file nor the FD file.
Return to menu
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. 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.
Are there any limitations on when revisions can be made?
FI encourages firms to revise previously reported information without undue delay if there has been a change.
Return to menu
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?
Finansinspektionen (FI) retrieves the instrument reference data from ESMA's database, FIRDS. 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 email@example.com.
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.
Return to menu
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 the ISIN is missing after seven days, the transaction will be rejected.
Which companies must report reference data?
Reference data is reported by systematic internalisers (SI) and trading venues.
Where should reference data be submitted/reported?
Reference data is submitted to ESMA and must be reported by trading venues and systematic internalisers (SI). SIs register with FI following the instructions here. ESMA will then contact the SI to establish reference data reporting. Separate reporting instructions are available for ESMA here.
Return to menu
How do I gain access to reference data from ESMA?
ESMA has published instructions on how to gain access to the reference data subject to the MAR and MiFID II/MiFIR regulations. The instructions that ESMA has published contain details about the reference data files that will be published weekly (full files) and daily (delta files) as well as steps for how to download the files.
Financial Instruments Reference Data System (FIRDS) – Instructions on access and download of full and delta reference data files
The reference data that is currently available can be searched for in ESMA's register Financial Instruments Reference Data System (FIRDS), which can be reached via the authority's website.
Financial Instruments Reference Files (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 firstname.lastname@example.org.
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 list of reference data is entered into Field 41.
Return to menu