MiFiR reports
Under the revision of MiFID I the regulatory framework expanded to two segments: MiFID II and MiFIR (Markets in Financial Instruments Regulation). Transaction reporting upon MiFIR applies from 3rd of January 2018 and will strengthen the protection of investors by both introducing new requirements and reinforcing existing ones. Transaction reports are submitted to the EU Member States National Competent Authorities (NCAs).
Transaction reporting
Transactions executed on day T are reported no later than the close of the following working day, i.e. T+1. The incoming reports are run through mandatory validations, the first validation verifies compliance of the file with the XML schema (syntax of the whole file and specific transaction reports). If the file is not compliant, the whole file (all transactions included in the file) is rejected. If first validation is approved the file goes further to a second validation that is a set of validation rules that are executed for each transaction report and verify the content of specific fields. Incorrect transaction reports are rejected whereas correct transactions are processed in further steps. These validation rules include validations dependent on instrument reference data.
FA's transaction reporting process
To report MiFIR via FA, there are certain pre-required fields that needs to be populated. There are also optional fields available for extended information reporting needed for more advanced securities or instruments. Information about this can be found further down under Pre-required and Optional Reporting Fields in FA”.
The transaction reporting can be done either manually or automatically. The manual version will only create the report files, and delivering of the files is left to the customer to handle. The automatic version will create the files, send them to authorities using SFTP, and also process any response files. In case of an automated version, the process will add a tag to the transaction once it moves between different stages of the process - see the transitions and tags in the graph below. Read more in Manual reporting and Automated reporting below.
Automated reporting
Automatic version will generate the report file, send it to the NCA using SFTP, and also process any feedback file received from the NCA. The transactions’ tags are automatically updated depending on their state in the reporting process, and based on status updates from the NCA’s feedback file(s).
Every delivered file will get a response message that will create a task in the Tasks view with the title "MiFIR response received". If there are things that require actions (rejected transactions), title will get a suffix "CHECK" and the task will not be completed, otherwise task is completed. If some transactions require updates later, there will also be an update response. Processing of status response will create task with title "MiFIR update received". If there are actions required, suffix "CHECK" is used here as well to show that the task is not yet completed.
Manual reporting
Manual version will create the report files, however delivering of files will be left to the client to do manually. Tags will be changed manually by user, however first tag MiFIR-Report is added in manual version.
Reporting details
MiFIR tags
In case of an automatic setup, each reportable transaction will receive a tag before and when entering the MiFIR transaction process. The exact names of the tags are configurable, but conceptually the used ones are listed below.
MiFIR - Report | Indicates that the transaction matches the criteria of being reported to the NCA |
MiFIR - Sent | Indicates that the transaction has been sent to the NCA |
MiFIR - Received | Indicates that the transaction have been received by the NCA and is awaiting validation |
MiFIR - Pending | Indicates that the transaction have been received by the NCA and is pending validation due to missing instrument reference data |
MiFIR - Accepted | Indicates that the transaction has been accepted by the NCA |
MiFIR - Rejected | Indicates that the transaction has been rejected by the NCA |
Modifications
When a modifications is done, the transaction will receive a modification tag. The cancellation route (on the far-right, in table “MiFIR Process Scheme”) is technically the same as "modification". The only difference is that FA automatically tag modified transactions for re-sending (separating transactions which we wish to modify vs. those we wish to simply cancel).
Modifications should be done BEFORE tagging the transaction with MiFIR - pendingModify. Modification cannot be used if modifying executing party or submitting party of the transaction, which are used to uniquely identify the transaction. In this case, the unmodified transaction should be cancelled, and the modified transaction should be sent as a new one.
MiFIR Modification | Used when there is a need of modifying transaction(s). To modify reported transactions, you need to tag them with two tags; MiFIR - report and MiFIR – modification. |
MiFIR Cancellation | Used when there is a need of cancelling transaction(s) or a sent report. To cancel reported transactions, you need to tag them with two tags; MiFIR - report, and MiFIR – cancellation. |
Views to track transaction reporting
It is recommended to save search views in FA to track the transactions in their different states of the reporting process. The views are fetching transactions by their tags, and (optionally) other criteria. Choose "Show extended search criteria" in the Transactions view to define the search criteria for the saved view.
For example, if the need is to build a view to show all accepted transactions, the tag MiFIR-accepted should be added in the “Tags” field. The defined search criteria then needs to be saved. This is done pressing the + sign in the top right corner. The view with the search criteria that was added will now appear as a tab on the top of the window. It will show all transactions with the tag chosen in the search criteria settings. Now repeat for all views wanted to follow the whole transaction reporting flow.
Pre-required and optional reporting fields
Transaction reporting process requires you to set up certain Contact, Portfolio, Security and Transaction information, and relevant fields needs to be populated accurately for the file to go through to authorities. This can be done using FA's general mapping tool. Contact FA support to set this up. To ease up the reporting process, rules can be utilized to modify transactions to report.
1) Required information on contacts
Data under Contact window -> MiFIR tab is required for all contacts related to the transaction.
- LEI
LEI (Legal Entity Identifier) is the submitting entity ID and is required if it is a company reporting)
- First name
First name of person
- Last name
Last name of person
- Birth date
Birth date (YYYY-MM-DD)
- Identification code
The person needs to be identified by a national ID number, passport number, tax or national insurance number. In the absence of these, a concatenated code consisting of Date of birth in the format YYYYMMDD + First five characters of first name + First five characters of surname can be used. In this case it is possible to write CONCAT in the Identification Code field and FA can set up accurate mapping via FA's mapper. For required first hand priority reporting on identification code per country read more in attached "COMMISSION DELEGATED REGULATION (EU) 2017/590" (p.447-8).
- Country code
The persons nationality. If multiple nationalities the first nationality in alphabetic order applies if member nation of the European Union, if not a member nation person should be ignored and next person in alphabetic order that is a member nation should be added.
- SchmeNm - Cd & Value
(Optional, required if SchmeNm is selected). If national identifier is used, it should be restricted to a passport number (use of code CCPT in the SchmeNm/Cd tag) other national identifier as defined in RTS Annex 2 (use of code NIDN in the SchmeNm/Cd tag) or CONCAT (use of proprietary with value CONCAT in the SchmeNm/Prtry tag.
SchmeNm - Cd
Value
CCPT
Is reported with the actual passport number
NIDN
Other national identifiers as defined in RTS Annex 2 (mifir-rts-22-annex_en.pdf attached in this article)
PRTRY (CONCAT)
Concatenation of nationality, DOB and name abbreviation. Can be mapped with FA's mapper from Contact window.
- Issr (optional)
This field is ignored by authorities and therefore not needed)
2) Required information on portfolios
Data under Portfolio window -> MiFIR tab.
- Customer
Customer (if multiple, separate with comma)
- Transaction decision makers (can have multiple)
Whether an individual or a group of people make the decision to trade, the firm must report the one person considered to have primary responsibility for the transaction but the field can handle multiple decision makers. The field should be populated with Contact ID, if multiple decision makers contact ID is added and separated with a comma.
- Executing party
The company that sends the file
- Executing party is investment company
Checkbox that is checked if executing party is Investment company
- Trading capacity
As set out in the Commission Delegated Regulation (EU) 2017/590 (Field 29), there are three different trading capacities that may be reported: "dealing on own account" (DEAL), "matched principal" (MTCH) and "any other capacity, ie Agency" (AOTC). The reported trading capacity should reflect the capacity in which the Investment Firm actually traded and should be consistent with the rest of the information in the Investment Firm’s transaction report(s).
- Decision maker type (optional)
If Investment company, who is the decision maker: Person (Prsn) or Algorithm (Algo)
- Decision maker value (required if "Decision maker type" is selected, provide contactId if type is persn)
Code used to identify the person or algorithm within the investment firm who is responsible for the execution. Field should be populated with ContactId if type is person.
- Execution maker type
Specify rather execution maker type is a Person, Algorithm or Client
- Execution maker value
ContactID for person
3) Required information on securities.
Data under Security window -> MiFIR tab
- ISIN
Insert ISIN for relevant security
- Id ISIN
Security ID
- Security Name
Full name of the security
- Classification (CFI)
- Classification of Financial Instruments (CFI). Taxonomy used to classify the financial instrument. A complete and accurate CFI code shall be provided.
- Notional Currency
- Currency in which the notional is denominated
- Maturity Date
Date of maturity of the financial instrument (YYYY-MM-DD). Field only applies to debt instruments with defined maturity.
- Expiry Date (yyyy-mm-dd)
Expiry date of the financial instrument. Field only applies to derivatives with a defined expiry date.
- Price Multiplier
Number of units of the underlying instruments represented by a single derivative contract. Monetary value covered by a single swap contract where the quantity field indicates the number of swap contracts in the transaction. For a future or option on an index, the amount per index point. For spreadbets the movement in the price of the underlying instrument on which the spreadbet is based.
- Underlying Instrument(s)
To be populated when the MiFIR identifier is a securitised derivative - listed in rutan
- Option Type
Indication as to whether the derivative contract is a call (right to purchase a specific underlying asset) or a put (right to sell a specific underlying asset) or whether it cannot be determined if it is a call or a put at the time of execution, then field should contain OTHR.
- Strike price
Predetermined price at which the holder will have to buy or sell the underlying instrument, or an indication that the price cannot be determined at the time of execution. Options are Price or No Price
- Price
If price, then field options are; Monetary value, Percentage, Yield and Basis points.
- No price
If no price, the filed options are Pending (where price is currently not available) or Not Applicable (strike price is not applicable).
- Option exercise style
Indication as to whether the option may be exercised only at a fixed date (European, and Asian style), a series of pre-specified dates (Bermudan) or at any time during the life of the contract (American style). This field is only applicable for options, warrants and entitlement certificates.
- Delivery type
Indicates whether the transaction is settled Physically or in Cash. Where delivery type cannot be determined at time of execution, the value shall be Optional.
- Asset class specific attributes - Type
Interest Foreign exchange
4) Required information on transactions
Minimum requirements to report for each transaction for them to go through reporting validation. Read more about Transaction Window here.
- Transaction date and time
Time is required with seconds - UTC time conversion is done by using server time zone).
- Importing
- Amount
- Price
- Market place (MIC)
(can be empty if the same values are set in IntInfo)
- Counter-party
(can be empty if the same values are set in IntInfo)
- Security
- IntInfo
General settings for MiFIR Reporting. Customer field can have only one value. Field is used to override customer, which by default is the portfolio primary contact. Used for example in insurance portfolios.