Streamlining EU’s EMIR – MiFIR – SFTR reporting, ESMA call for evidence
Introduction On the 23rd of June 2025 ESMA issued a call for evidence “On a comprehensive approach for the simplification of financial transaction reporting”. ESMA requests input from interested stakeholders on its proposals for eliminating inefficiencies duplications and other such encumbrances that emanate from disparate reporting rules such as EMIR, MiFIR, SFTR. Transaction reporting under the aforesaid regimes, cost reporting entities between 1- 4 billion EUR per year, as per a 2019 study by the EU Commission. As the focus of the EU Commission has shifted towards simplifying and streamlining rules across the board, the Commission in January 2025 has set as its goal to reduce reporting burden for all companies across the board . Aligning with the Commission’s goals ESMA considered 2 thematic categories for the simplification of reporting and for each thematic category, ESMA presented 2 reporting options. It should be noted that for both options ESMA considers important to: Preserve information scope, Decrease reporting overlap, Ensure alignment with global reporting standards, Balance Cost and Burden. To wit, while ESMA acknowledges that reporting regimes (SFTR, MiFIR, EMIR and others) serve different purposes e.g. MiFIR reporting provides NCA’s with a view of market activities and assists in the detection of instances of Market Abuse, EMIR provides a measure of risk buildup (especially counterparty default risk) as well as insights on how that risk is managed (clearing, collateral exchanges, risk reduction exercises etc.) and are triggered by different events there is substantial overlap between them in terms of information provided. Option 1- Removal of Duplications For this option ESMA is suggesting 2 different approaches to reducing reporting burden. Delineation by Instrument Type As most reporting entities are aware, in the EU (and the UK) derivatives reporting also captures derivatives listed on Regulated Markets and OTC derivatives. In other jurisdictions such as Canada, Australia and Singapore, only OTC derivatives are captured by the aforesaid obligation. As such for this proposal, ESMA is considering limiting the perimeter of EMIR reporting for OTC derivatives only. Currently an ETD listed on e.g. Eurex is doubly reported under both EMIR and MiFIR. ESMA is asking for feedback whether transaction reporting of such ETDs could be carried out under MiFIR only, while post-transaction events (valuations/collateral) for ETDs should be sourced from the Clearing Houses (CCPs) of the Regulated Market where the ETD was executed. In such a case OTC derivatives remain unaffected. Similarly, SFTR obligations are also unaffected. Delineation by Events ESMA is proposing to report all transactions (whether EMIR, MiFIR, SFTR) under MiFIR while post trade events such as valuations, collateral updates etc would be EMIR reportable (for derivative trades) and SFTR (for SFT trades). This implies that all new transactions whether they are on bonds, shares, margin lending, repos, CFDs, forwards, swaps etc. would be reported as new trades under MiFIR, while Valuation Updates, Collateral Updates, Novation events, Compressions, etc. would be reported under EMIR (for derivatives). SFTR reporting (similar to EMIR) will only be focusing on post trade events (e.g. valuation, margin updates etc.). Option 2- Report Once Principle ESMA is considering the creation of a unified reporting template i.e. collapse all reporting obligations into a single report reported via a unified channel. For this option ESMA is proposing 2 (very similar) approaches, one is to collapse EMIR/MiFIR/SFTR into a single report, while the other approach includes a scenario whereby non-ESMA reporting (i.e. reports not under ESMA’s mandate) could be included in the unified template e.g. Energy reporting REMIT (currently under ACER’s mandate) or Solvency II reporting (EIOPA). Of the 2 options (each with 2 approaches), ESMA recognises that the Report once Principle would be the most cost effective in terms of reducing the overall reporting burden. Nevertheless, ESMA also acknowledges that such a radical approach may incur additional costs for affected parties as they would need to reconfigure reporting processes, including investing in IT, training staff, merging siloed data and so on. Moreover, the Authority further acknowledges that such an approach may require substantial amendments to legal texts and time till it is finally implemented. Other Issues Dual Sided Reporting For both options ESMA is asking for input on the possible revision of the dual sided reports, i.e. where both counterparties to a trade/SFT will need to report and reconcile said reports. ESMA acknowledges that if the requirement for dual-sided reporting is abolished NCAs may need to take additional steps to dispense their supervisory duties, such as performing full audits on firms. Reporting at Position Level For a few of the proposals ESMA is also suggesting abolishing the allowance for position level reporting (applicable for EMIR/SFTR but not for MiFIR) and, instead, the position is calculated based off the transaction reports. ESMA acknowledges that such a move may be difficult given that for ETDs as well as some OTC derivatives and some SFTs risk, collateral, valuations are always calculated at a position level. Next Steps ESMA will consider feedback/input it receives by 19 September 2025 and expects to publish at the beginning of 2026 a final report, outlining the key areas and the preferred simplification option/approach. ESMA has further indicated that it will not put forward any new suggestions for changes to MiFIR transaction reporting for which it has consulted in 2024 (refer to our blog here for an overview) pending the outcomes of this Call of Evidence. ESMA has nonetheless produced a final report on the issue in which they record respondents’ preferences and comments (MAP FinTech participated in that consultation). As ESMA notes, irrespective the outcome of this exercise it will be years before any changes come into effect. Characteristically for option 1 (which is the easiest of the 2 to implement) ESMA expects that implementation timeframes would be approximately up to 5 years. MAP FinTech, in the spirit of assisting its clients to comply with their reporting obligations accurately and with cost efficiency, intends to constructively participate in the Call for Evidence.
Crypto assets: An overview of transaction reporting obligations under securities laws
On January 3rd 2009 the Bitcoin network came into existence with the elusive Satoshi Nakamoto mining the so called genesis block of bitcoin (block number 0) which had a reward of 50 bitcoins. Initially brushed off as another iteration of E-Gold, a rather popular digital currency from the internet’s early years that was shut down by US authorities, Bitcoin was not seriously considered as a viable asset. Bitcoin however, and the multitude of other crypto assets launched since, followed a different trajectory. Now, Investment Firms, Funds and other financial intermediaries allow their clients to invest in crypto assets. In this blog we will explore reporting obligations of such firms that emanate from trading cryptos. Definitions It is prudent to flesh out a few terms associated with the crypto-space which are relevant to the issue of transaction reporting obligations. Distributed Ledger Technologies (DLT) A decentralised database which is managed/distributed by various participants. There is no central authority to act as the administrator, with the ability to unilaterally make changes to the database without other participants accepting or condoning. As this database is distributed to all participants it may allow for greater transparency making the entire system more resilient to manipulation by bad actors. Blockchain A specific type of Distributed Ledger Technology that organises data into blocks, each block is closed and opened with a specific cryptographic signature called hash. This signature verifies that the data contained within the block have not been manipulated and seals them from further alterations. I.e. once data have been recorded into a blockchain they cannot be undone. Take home message, all blockchains are DLTs, but not all DLTs are blockchains. Crypto-Coins/Currencies A coin is created with the so-called mining process whereby a block is added on a blockchain (see above), the process of creating a block involves solving a cryptographic puzzle which increases in complexity as more blocks are added to the chain. This increase in complexity requires vast amounts of computing power. A lot of participants attempt to solve the puzzle, the first to get to the solution adds another block to the chain and is rewarded with a coin, which can then be traded with other participants. A key characteristic of this coin is that it can only exist on its native blockchain and cannot be used on other DLTs as is. I.e. Bitcoin/DOGE can only be mined on their native blockchain and cannot be traded on e.g. Ethereum’s blockchain as is. Crypto Tokens Tokens are created on an existing DLT that allows such programmability, e.g. Ethereum blockchain allows for the creation of such tokens, but Bitcoin’s blockchain does not facilitate this. Usually such tokens are pre-mined, i.e. the developer decides how many tokens they intend to create and distribute them to interested parties. In this case the mining process described for Crypto coins does not apply. Moreover, and more importantly, tokens may be coded with different functions (unlike coins) and can exist across different DLTs (e.g. a Token can exist on both Ethereum’s and Solana’s blockchains). Examples of tokens include Tether and NFTs. Tokenisation In layman’s terms, it’s the process of representing an asset in digital form. E.g. a title deed of a property, ownership of a car, or more relevant to the topic at hand, a financial instrument. The token is recorded on a programmable DLT which can then be traded across participants. Tokenisation promises to deliver reduced trading costs, reduction of counterparty risk and peer to peer trading. In a traditional exchange when trading e.g. shares, once execution is triggered, the order is processed by different functions within the exchange, such as e.g. the Central Clearing House that interposes between buyer and seller in order to verify that they have the monies and the assets to trade, the Central Securities Depositary that registers the change in ownership of the asset etc. Such functions may be rendered redundant if trading is done using a DLT. In fact several exchanges have launched DLT trading platforms such as, Switzerland’s SIX – Group with the SDX Exchange and Japan’s Osaka Stock Exchange Osaka Digital. At the same time major financial organisations have introduced DLT solutions, such as JP Morgan’s Kinexys (formerly known as Onyx) as a platform for trading major currencies and tokenised securities. Roundup of relevant Crypto asset rules USA In the early days of crypto-assets’ existence there was an incoherent framework on how securities regulators would be treating them, then in 2018, a landmark court ruling in the US brought some much needed clarity on the issue. The Commodity Futures Trading Commission brought charges against an entity alleging that cryptocurrencies are commodities and as such any security referencing them is under CFTC purview. The courts adjudicated in favour of the CFTC and this created a legal precedent for crypto-coins, categorising them as commodities. The USA has yet to formulate a comprehensive legislation package at a federal level, although federal bodies such as the Securities and Exchanges Commission, the CFTC and FDIC have enacted policies towards better regulating the crypto space. E.g. the SEC is accepting feedback from interested parties as part of its own rulemaking for crypto assets under the umbrella of the Crypto Task Force and the process is ongoing as of the date of publication of this blog. EU In 2020, the European Commission communicated its intention to develop a framework for digital finance across the EU which included crypto-assets. This spurred the European Supervisory Authorities -ESAs (ESMA, EIOPA, EBA) and the ECB to begin preparatory work on the said package. This eventually led to the adoption of the MICA package in 2022. The said package came into effect in 2024. The ESAs have produced additional guidance such as ESMA’s criteria for the qualification of crypto assets as financial instruments. UK In 2018 the UK government launched the crypto assets Taskforce consisting of HM Treasury, the FCA and the Bank of England. The Taskforce in its final report identified trends in the ecosystem and set a path
Canada’s Revised Trade Repositories and Derivatives Data Reporting Rules
In 2018 when the Committee on Payment and Market Infrastructures (CPMI) and the International Organization of Securities Commissions (IOSCO) issued the Technical Guidance for the Harmonisation of critical OTC derivatives data elements (the CDE), one by one securities commissions from across the world began implementing the CDE in their derivatives reporting rules. In July 2024 the Canadian Securities Administrators announced that the Canadian implementation of the CDE will begin to apply from the 25th of July 2025. In this blog we will present a few of the major changes the revised spec introduces. Reporting format Unlike other jurisdictions such as the EU, UK, Australia and Singapore, the revised Canadian specs do not require a specific reporting format (e.g. xml, csv, json etc.) as such the TRs will be presenting to their end clientele their preferred submission method. Additional validations The current Canadian reporting spec did not mandate many reporting validation rules for TRs to implement prior to accepting a given submission. The revised rules introduce a host of validation rules e.g. several data points are either conditional, or mandatory, optional, or not required at all, subject to how other data points within the report are communicated. This creates a much more rigid reporting framework where reporting entities will need to consider the conditions for each data value reported. Position Level Reporting The Canadian implementation of the CDE also introduces the possibility (under specific circumstances) for reporting entities to report derivatives at a position level. In simple terms derivatives, which are fungible, with the same counterparty can be netted into a single derivative report, for which the counterparties will report collateral and valuation messages. The conditions/what instruments are eligible for position reporting are laid out in the CSA Derivatives Data Technical Manual. Unique Product Identifier – UPI As we have mentioned in previous blogs (see here for a brief overview and an explanation on the UPI’s technical aspects) the UPI is being deployed for the revised Canadian reporting. The UPI is a unique code that identifies the OTC derivative that the counterparties will be trading with. Upon coming into effect, the revised Canadian reporting rules will require the UPI for all derivative classes except for commodities. Canadian authorities will require the UPI for commodities at a later stage. It should be noted that where the UPI denotes as its underlying OTHER due to the fact that the underlying reference value is not included in ANNA DSB’s UPI enumeration lists, additional data elements must be reported. Transaction Identifier – UTI The Canadian reporting revised spec endorses the ISO 23897:2020 spec regarding the Unique Transaction Identifier (UTI). Counterparties will need to construct the Unique Trade Identifier in accordance with the technical specs of the said ISO as established by the Regulatory Oversight Committee. The UTI will have a length of up to 52 characters, where characters 1-20 will be the LEI of the Generating Entity, followed by unique code assigned by the same entity. Action and Event Types Similar to other jurisdictions’ implementation of the CDE the revised Canadian reporting specs introduce different Events applicable to different Action Types. Consider the following examples: Compression Where 2 counterparties proceed with a portfolio compression exercise whereby they terminate some, or all, outstanding derivative trades between them and replace the terminated trades with another derivative(or derivatives) whose combined notional value is equal or less than the combined notional value of the terminated trades then the termination (TERM) and new action (NEWT) types should be accompanied by a compression (COMP) event. Exercise A counterparty decides to exercise an American Put Option before its expiry date. This triggers an obligation to report a termination to the TR, the said termination message must be accompanied by the exercise event type (EXER). Allocations A counterparty trading on behalf of clients, executes a bulk trade with another derivatives dealer and then allocates to each client its portion of the bulk trade. The counterparty will report a new trade with each client with the combination action type new (NEWT) and event type allocation (ALOC). The allocation reports will be linked to the trade with the derivatives dealer by reporting the Prior Unique Trade Identifier (PriorUTI) value. The PriorUTI value should be the same UTI as the one used to report trade between the counterparty-derivatives dealer. Derivative reports outstanding as at the go live date of the revised Canadian rules. Derivatives that were reported under the existing Reporting Regime and which are still outstanding (i.e. non-terminated) should be updated to the new data requirements with the Action-Event combination Modification – Update after the revised go live date. It should be noted that the Transaction Identifier code for these outstanding derivatives will not be updated to the new standard. MAP FinTech is in process of updating its systems and processes to assist clients who have an obligation to report in any Canadian jurisdiction. Contact our team of experts for more information or any assistance you may require. Disclaimer: The above blog was written by MAP FinTech’s internal teams and under no circumstance does it replace advice or guidance by Firms’ compliance and/or risk management functions. Firms affected by the Canadian rewrites should consult with their compliance/risk management personnel and or consultants for specific guidance and must not rely on the information contained herein.
Virtual Power Purchase Agreements – EMIR (EU/UK)
As the global focus on reducing carbon emissions and the transition towards renewable energy sources, Virtual Power Purchase Agreements (VPPAs) or Financial Power Purchase Agreements (FPPAs) have emerged as a mechanism for companies aiming to meet sustainability targets and mitigate energy price volatility. This blog explores these instruments, their regulatory reporting obligations, and how MAP FinTech can assist clients in navigating this complex landscape What Are Virtual Power Purchase Agreements A Virtual Power Purchase Agreement is a formal multiyear agreement between an energy producer and a consumer (corporate), for the sale of electricity at a prefixed price. Unlike physical power purchase agreements, there is no physical delivery of electricity, but the contract is financially settled. I.e., the energy producer (seller) supplies its electricity output to the electricity grid and the consumer’s (buyer) supply of electricity is independent from the VPPA. The financial settlement process may differ from VPPA to VPPA, but the most common form is as follows. The Parties to the contract agree that each billing cycle, if the fixed price is above the prevailing market price for electricity (as published by a third party such as power exchanges like Nord Pool) the seller (energy producer) will pay to the buyer (consumer) the difference between fixed contract price and prevailing market price (adjusted for the output as defined in the contract). If the prevailing market price is above the contract fixed price, the buyer (consumer) will pay the difference to the seller (energy producer). Moreover, in several VPPAs the energy producer will deliver to the consumer a so-called Energy Attribute Certificate (EAC). The said EAC is evidence that the energy the consumer bought comes from renewable sources. EACs are tradeable and transferable in many jurisdictions, as countries from around the world are scrambling to offer incentives towards transitioning to clean energy sources. As such, the consumer may also stand to gain from trading EACs obtained under the VPPA. EACs come in many flavours such as the EU’s Guarantee of Origin (GoOs) harmonising the EAC system of EU member states, the US’s Renewable Energy Certificates (RECs) and the UK’s Renewable Obligation Certificates (ROCs). Finally, it is worth noting that the financial settlement process of the VPPA allows for such contracts to be cross-border, e.g. the producer may be established in a different country than the consumer. Why are Virtual Power Purchase Agreements subject to EMIR reporting As we have analysed in the previous paragraph VPPAs are complex, usually long-term commodity (electricity) contracts which are financially settled. Therefore, such contracts fall under the perimeter of a derivative financial instrument. Moreover, given the bilateral nature of such contracts these are OTC unlisted and, in most cases, uncleared (by Central Clearing Counterparty) derivatives. Additionally, depending on the terms of the agreement, VPPAs may have the characteristics of a forward , a contract for difference, a swap, or even a swaption. Considering all of the above, the said contracts fall under the scope of the EU’s and/or the UK’s EMIR rules that capture all derivative financial products. As such, both the energy producer and the consumer, upon entering a VPPA become subject to the provisions of EMIR which include, inter-alia, a reporting obligation. How can MAP FinTech assist At MAP FinTech we understand that in many cases producers and consumers cannot set up by themselves the necessary processes for EMIR reporting, as such, we offer various options for parties to a VPPA including a service whereby, we take upon ourselves to: Analysing the VPPA agreement, either bespoke contracts or standardised master agreements (e.g. ISDA, EFET) in order to identify the commercial aspects. Mapping the commercial aspects of the VPPA to the values required under EMIR. Enriching the EMIR report with other requisite data such as interconnection points, delivery zones, electricity load types. Creating and submitting reports on behalf of such clients to an EU or a UK Trade Repository. Providing the end client with the relevant files (e.g. TR responses, submitted files) for their records. Contact our team of experts for more information or any assistance you may require.
FCA Discussion Paper – Improving the UK transaction reporting regime
As we have already noted in a previous blog post, with the departure of the UK from the EU, it was expected that at some point the transaction reporting regimes of both jurisdictions would begin to diverge. Now it appears that this process is picking up steam, as the FCA and ESMA are consulting for changes to the MiFIR transaction reporting regime. See our blog post on ESMA’s MiFIR consultation here. On the 15th of November 2024 the FCA published a discussion paper proposing changes to the aforesaid transaction regime. MAP FinTech has already drafted its responses and intends to submit its views to the FCA’s consultation. The FCA is considering the inclusion of additional fields, but the Authority has not provided an exhaustive list for the new inclusions, nevertheless MAP FinTech understands that the proposals as set forth by the FCA imply that any new additions will be less than what ESMA is proposing. See below a non-exhaustive list of changes that FCA is proposing to make. AIFMs and UCITS Management Companies to become subject to the MiFIR reporting requirements UK AIFMS and UCITS Management companies that offer the non-core services of the management of portfolios of investments in accordance with mandates given by investors on a discretionary client-by-client basis, investment advice; safe-keeping and administration in relation to shares or units of collective investment undertakings; and reception and transmission of orders in relation to financial instruments. Will be required to submit MiFIR transaction reports in relation to the aforesaid services if they trigger a MiFIR transaction obligation. Including the UPI for instruments of UK MiFIR Articles 26(2)(b) and 26(2)(b) The FCA is considering to mandate the inclusion of the UPI for securities captured by the UK MiFIR reporting obligation and may be issued with a UPI, refer to our blog post on the UPI for an overview. Alternatively the FCA is considering the implementation of a modified version of the UPI (UPI+). New Identifiers for Distributed Ledger Technology – DLT securities and for securities whose underlying assets are crypto-assets The FCA is proposing to adopt ISO 24165 Digital Token Identifier standard for DLT securities and underlying financial instruments to identify tokenised securities or similar. For a brief overview of the ISO refer to our earlier blog on ANNA-DSB’s adoption of DTIF codes for derivatives on crypto assets. If the FCA’s proposal is accepted firms that trade with DLT securities or securities whose underlying are crypto assets and under the assumption that the aforesaid securities are captured by the MiFIR reporting obligation, reporting firms will need to source the aforementioned ISO code. Reporting client/counterparty categories The FCA proposes the addition of a new field that will capture the category of the clients/counterparty. The said field will be allowed 2 values – Retail Client, Professional. For every trade where the firm submits a report it will need to assign a category to its counterparty in accordance with the aforementioned. Reducing reporting costs for small firms and request for feedback to remove duplication with other reporting regimes The FCA has asked for feedback on steps it could take to remove duplication with other reporting regimes e.g. a firm reporting a MiFIR captured derivative is always required to report it under EMIR as well. Moreover the FCA recognises that some small firms who are infrequently captured by the MiFIR reporting obligation are finding it difficult and costly to comply with the reporting regime. The FCA has requested feedback on how to alleviate the burden on small firms. Request for Feedback on messaging standards/new technologies The FCA is asking from respondents to provide feedback on whether new technologies or alternative messaging standards could improve transaction reporting. The FCA provided as an example of these alternative messaging standards the JSON format. The Consultation paper contains many more proposed amendments to MiFIR’s reporting requirements. The FCA is accepting feedback from market stakeholders till the 14th of February 2025. How can MAP FinTech Assist MiFIR Transaction Reporting is our service that allows clients to report their transactions in Financial Instruments as per the requirements of the Markets in Financial Instruments Regulation (MiFIR, Article 26) to the National Competent Authority (NCA), either directly or through an Approved Reporting Mechanism (ARM). Transaction data received on our Polaris Platform is processed, enhanced, validated and subsequently submitted in the format prescribed by each NCA. Contact our team of experts for more information or any assistance you may require.
ESMA Consultation Paper – Review of RTS 22 on transaction data reporting under Art. 26 and RTS 24 on order book data to be maintained under Art. 25 of MiFIR
As we have already noted in a previous blog post, with the departure of the UK from the EU, it was expected that at some point the transaction reporting regimes of both jurisdictions would begin to diverge. Now it appears that this process is picking up steam, as the FCA and ESMA are consulting for changes to their respective MiFIR transaction reporting regime. The FCA is also consulting on changes to its MiFIR reporting regime, see our blog post here. On the 3rd of October 2024 ESMA published a consultation paper proposing changes to the aforesaid transaction regime. MAP FinTech has already drafted its responses and intends to submit its views to ESMA’s consultation. See below a non-exhaustive list of changes that ESMA is proposing. Increase the total number of reportable data points by 48 new values and renaming existing data points ESMA is proposing to include additional fields that in some cases aim to better align MiFIR with other reporting regimes such as EMIR Refit. To this end, ESMA is proposing to include data points such as: Option Premium, Receiver of Leg1/2, Floating Rate, Spreads, Effective date, Reference period of the floating rate, Term of floating rate. These fields are fields EMIR reporting entities are familiar with, as ESMA is proposing to align (to the extent possible) MiFIR with EMIR reporting. MAP FinTech notes that not all 48 data points will be applicable to all trading scenarios. Further to the above ESMA is also proposing to change the definition and/or naming of some data points to align with the definitions/naming given under either SFTR or EMIR. Identifiers linking all transactions in off-exchange trading For any off-venue transaction ESMA is proposing the inclusion of a new field, the Transaction Identification Code (TIC). If ESMA’s proposals are accepted, all firms in a transmission chain will be required to report the same TIC code, liking all reports. For Example assume a chain where the Client submits an order to Broker1 then Broker1 further submits the order to Broker2 then Broker2 to Broker3 and so on. Each of the aforesaid Brokers if they have a MiFIR reporting obligation in the EU will be required to report the same TIC in their respective reports. ESMA proposes that the “Market Facing” firm should be the firm responsible for the TIC’s generation and dissemination further down in the transmission chain. Moreover ESMA is also proposing to standardise the TIC which will consist of elements such as Instrument Identifier, Date Time, LEI of generating entity. New Identifiers for Distributed Ledger Technology – DLT securities and for securities whose underlying assets are crypto-assets ESMA is proposing to adopt ISO 24165 Digital Token Identifier standard for DLT securities and underlying financial instruments to identify tokenised securities or similar. For a brief overview of the ISO refer to our earlier blog on ANNA-DSB’s adoption of DTIF codes for derivatives on crypto assets. Should ESMA’s proposal be accepted firms that trade with DLT securities or securities whose underlying are crypto assets and under the assumption that the aforesaid securities are captured by the MiFIR reporting obligation, reporting firms will need to source the aforementioned ISO code. Extending Art.4 of RTS 22 to include firms trading on Dealing on Own Account Under the current RTS 22 regime, firms trading under trading capacity DEAL cannot make use of the reporting exemption afforded under Article 4 of RTS 22. ESMA proposes extend the applicability of Art.4 to such firms. Reporting client/counterparty categories ESMA proposes the addition of a new field that will capture the category of the clients/counterparty. The said field will be allowed 4 values – Retail Client, Elective Professional Client, Professional Client and Eligible Counterparty. For every trade where the firm submits a report it will need to assign a category to its counterparty/client in accordance with the aforementioned. Proposal to switch from XML to JSON ESMA is requesting feedback on the issue of switching MiFIR reporting format from XML to JSON. As per the consultation paper ESMA is considering the gradual switch of various reporting regimes from an XML format to JSON. ESMA is asking respondents for their views on the proposed switch, including indications on costs, timelines of implementation and potential benefits. The Consultation paper contains many more proposed amendments to MiFIR’s reporting requirements. ESMA is accepting feedback from market stakeholders till the 17th of January 2025. Once the consultation phase ends, ESMA will proceed to analyse the responses and adjust the proposals accordingly, then it will submit the amended RTS for approval by the EU commission. How can MAP FinTech Assist MiFIR Transaction Reporting is our service that allows clients to report their transactions in Financial Instruments as per the requirements of the Markets in Financial Instruments Regulation (MiFIR, Article 26) to the National Competent Authority (NCA), either directly or through an Approved Reporting Mechanism (ARM). Transaction data received on our Polaris Platform is processed, enhanced, validated and subsequently submitted in the format prescribed by each NCA. Contact our team of experts for more information or any assistance you may require.
Webinar on Demand: Lessons for UK EMIR REFIT from EU REFIT Rollout
As the UK prepares for the launch of the EMIR REFIT on September 30th, MAP FinTech hosted an informative webinar featuring key industry experts. The focus was on lessons learned from the EU EMIR REFIT rollout earlier this year and how these can be applied to ensure a smooth transition in the UK. The webinar was hosted by Luis Parra, Director at MAP FinTech UK, with presentations from James Hardie, Director of Regulatory Reporting Product at the London Stock Exchange Group (LSEG), and George Markides, Senior Manager Market Infrastructure Reporting at ComplyMAP Group. Luis Parra set the tone for the webinar by emphasising the importance of preparing for the UK EMIR REFIT, drawing on lessons from the EU experience. He highlighted that the FCA’s version of the regulation aligns closely with the EU’s, making the EU rollout a valuable reference for firms navigating the UK changes. James Hardie: Lessons from the EU Rollout James Hardie provided detailed insights into the EU EMIR REFIT experience, particularly focusing on Transaction Reporting Rejections. He noted that on day one of the EU rollout, 40% of trades were rejected, primarily due to schema and lifecycle issues. Within two weeks, this rate halved, and after one month, it fell to 9%, which was seen as acceptable by regulators. Testing and Preparation: Hardie stressed that the high initial rejection rates were largely due to insufficient User Acceptance Testing (UAT). He expressed concern that UK firms were following a similar pattern, with lower UAT engagement than expected. Rejection Reasons: He highlighted that the two main rejection reasons—schema errors and lifecycle issues—mirrored the EU experience. He emphasized the need for more comprehensive uplift testing, especially regarding XML schema and lifecycle transitions. Reconciliation Breaks: Hardie also discussed reconciliation breaks, where firms failed to match transaction data across different platforms. He observed that while these issues were also prevalent in the EU, the UK is showing similar trends, signalling that more effort is required to resolve these problems ahead of the go-live date. Hardie concluded by stressing that regulatory collaboration would be essential to reduce rejection rates and that pre-launch engagement with the FCA would be crucial. George Markides: Practical Considerations for UK Firms George Markides reinforced many of the points made by James Hardy but added further technical insight. His presentation focused on the complexities of schema validation and data dependencies that contributed to high rejection rates in the EU. Schema and Validation Rules: Markides pointed out that firms struggled with increased dependencies between fields in the new schema. These challenges were compounded by discrepancies between what ESMA’s documentation stated and what was required in practice, particularly regarding fields like the strike price. Unique Product Identifier (UPI) Issues: Markides delved into the confusion surrounding the use of UPIs, noting that firms often misapplied them in trade reports. He cautioned that this issue persists in both the EU and UK, with firms failing to accurately match UPIs to the correct instruments. Cross-Border Reporting Challenges: Markides emphasised that while the UK EMIR REFIT schema is similar to the EU’s, subtle differences could lead to rejection of reports. He warned that firms relying on EU experience without understanding the nuances of UK-specific requirements could face significant issues. Markides ended his presentation by urging firms to revisit the guidance provided by both the FCA and ESMA and to ensure that their systems are aligned with the latest schema updates to avoid validation issues. Trust MAP FinTech as your RegTech Provider To navigate the complexities of the UK EMIR REFIT, MAP FinTech offers the expertise, cutting-edge technology, and customized solutions needed for success. Our team provides expert guidance, helping you understand the regulatory implications while delivering advanced reporting solutions that ensure both accuracy and efficiency. With personalized support and ongoing assistance, we are equipped to help you adapt swiftly and confidently in this evolving regulatory environment. Moreover, our extensive experience with the EU EMIR REFIT gives us a unique advantage. We have gained a deep understanding of potential challenges and best practices, enabling us to anticipate issues and provide proactive solutions. By leveraging our insights from the EU framework, we can help ensure a smoother, more informed transition for UK firms, minimising disruptions and enhancing compliance processes. Contact our team of experts for more information or any assistance you may require.
Unique Product Identifier: Modalities and Technicalities
In our previous blog post we briefly mentioned when a UPI will be necessary to comply with the EU EMIR-REFIT. Here we will show you how to generate or retrieve a UPI from the ANNA-DSB. This article goes beyond EU EMIR – REFIT as the same modalities presented below can be applied to all jurisdictions that have endorsed the UPI, including, but not limited to, the USA, the UK, Australia, the EU, Singapore, etc. UPI inputs In order to achieve harmonisation across jurisdictions and streamline inputs, the UPI standard has adopted variable standards widely used in the financial industry. A few of these inputs include: ISDA’s taxonomy ver.2 for the categorisation of products; CFI codes ISO standard 10962 ver.2015 for the classification of products; ESMA’s Transparency Calculations (TTC) for equity indices; ISDA’s FpML for commodity definitions and interest rates; Etc. To correctly generate or retrieve the UPI code, market participants need to familiarise themselves with these inputs to avoid generating or retrieving incorrect UPI code ANNA-DSB has produced a library of product definitions for the UPI where market participants will find all necessary information contained therein. UPI generation/retrieval In order to be allowed to generate UPIs, the ANNA DSB requires interested parties to sign up to its service and pay a fee correlated to the amount of UPIs said parties need to generate on a yearly basis. In the case where the interested party is only looking to retrieve already issued UPIs, the ANNA DSB service offers a free registration option that has some limitations. The UPI, as we shall see, is issuer agnostic. That means that the UPI is not attached to the entity that generated it. Hence, where an entity has generated a UPI with specific attributes, for example, a Non-Deliverable Forward on EURUSD where the settlement currency is the EUR, another entity offering the same deliverable forward with the same attributes can retrieve the UPI previously issued for its reporting needs. The UPI request template describing the various attributes that the interested party needs to provide to issue the correct UPI can be found in the product libraries linked above. In our example, we will show you what values need to be inserted for a NDF on the EURUSD and settled in EUR. The ANNA-DSB systems will request the following items in order to generate the UPI. Therefore the system will require to identify the following parameters, in parenthesis the source for each input. Asset Class = Foreign_Exchange (ISDA Taxonomy); Instrument type = Forward (ISDA Taxonomy); Product = NDF (ISDA Taxonomy); Level = UPI (ANNA DSB); Underlier ID = EUR (ISO 4217 – currency 3 letter code); Underlier Source = CCY (ANNA-DSB); Other Underlier ID = USD (ISO 4217 – currency 3 letter code); Other Underlier ID Source = CCY (ANNA DSB); Settlement Currency = EUR (ISO 4217 – currency 3 letter code). The system will generate the UPI. The UPI will contain the inputs the generating entity inserted but will also contain derived values generated from ANNA DSB such as the instrument’s name, the CFI, and other characteristics. As we can see from the output, the instrument is issuer agnostic, i.e. there is nothing in the UPI that ties this specific UPI with the entity that issued it. Where another entity trades with NDFs on EURUSD settled in EUR, they can use this previously issued UPI for their reporting needs. Moreover, the above record will be publicly available to all registered users to the UPI service, including, but not limited to, regulators who can cross check the reported values (e.g. CFI, instrument name, settlement currency, etc.) with the UPI contained values used to verify a correct submission. Attention From the above example we would like to draw the attention of UPI generating or retrieving entities to the following: Ensure familiarity with the mentioned inputs When using an already issued UPI, ensure that the product you intend to trade matches 100% all the UPI attributes relevant to the product. Familiarise yourself with ANNA-DSB’s production and testing environment for UPIs. How is MAP FinTech going to assist? MAP Fintech offers the UPI Link Service that helps retrieving companies match their products’ attributes precisely to those already issued UPIs, ensuring that reporting companies use the correct UPI Code. MAP FinTech’s UPI Link Service boasts essential functionalities, including: Automated identification of UPIs using reference data provided by the reporting entity and the latest issued UPIs supplied by the ANNA-DSB. UPI enrichment of reported files prior to submission to the TR. Error identification where UPIs cannot be mapped against the ANNA-DSB’s issued UPI records. Inline editing capability for on-the-fly amendments on the UPI. Advanced search function from within Polaris portal which can pinpoint the exact UPI based on enhanced search criteria.
UPI: A new data element for OTC derivatives reporting
One of the many changes that EU’s EMIR REFIT usher in is the UPI, or Unique Product Identifier. The UPI will be deployed across many jurisdictions including, but not limited to, Australia, Singapore, Europe (the EU and the UK) as well as the USA. The road towards a globally endorsed UPI The UPI was introduced under EMIR version 1, but at the time Securities Commissions/Central Banks and other interested parties had yet to agree on a global standard. In fact, in the current EMIR RTS under Product classification, pundits will notice that the UPI exists as an option but as per the specs “For products for which ISIN or AII are not available, endorsed Unique Product Identifier (UPI) shall be specified. Until UPI is endorsed those products shall be classified with CFI code.” At an international level, the International Organisation of Securities Commissions (IOSCO) and the Committee on Payments and Market Infrastructures (CPMI) set to work on the UPI and in 2017, they published the Technical Guidance (to authorities) on the Harmonisation of the Unique Product Identifier. The Financial Stability Board (FSB) following the issuance of the aforesaid guidance assigned the Derivatives Services Bureau (DSB), a subsidiary of the Association of National Numbering Agencies (ANNA), as the sole issuer of the UPI codes, while the Regulatory Oversight Committee (ROC) was appointed as the International Governance Body for the UPI Standard. See below a brief video prepared by ANNA DSB on the UPI When do you need a UPI in the EU? With the advent of EMIR REFIT and given that the preparatory work was finalised for the adoption of a global UPI standard, UPIs will be required for instruments which do not have an ISIN and are not listed on an EU Trading Venue (meaning a Regulated Market, Multilateral Trading Facility, or Organised Trading Facility) or, not executed with a Systematic Internaliser (SI) or, not listed on third country organised trading platforms. The new rules are very specific that instruments should be identified either with an ISIN or with a UPI (there will not be a situation where both identifiers will be required). However, as mentioned in ESMA’s validation rules, ISINs are required where the Venue of Execution data field is populated with a MIC code of EU Trading Venues, or SIs, or with the value XOFF. XOFF signals that the instrument in question is listed on a Trading Venue but the transaction did not take place on said venue, or with an SI or, on organised trading platforms outside the EU. We should note here, that all instruments listed on EU (and UK) trading venues are required to be identified with an ISIN since 2018, with the advent of MiFID II/ MiFIR package and more specifically, mandated under Regulation EU 2017/585 supplementing MiFIR. Moreover, for instruments listed on third country venues exclusively (which should be identified in the EMIR REFIT report with their MIC code, where the said execution took place on the third country venue) and where those third country venues do not identify their instruments with an ISIN, both the ISIN and UPI field can be left blank (UPI in this case is marked as optional). Invariably, from the above it is evident that the following classes of non-listed derivatives are likely to be captured by the UPI requirement, the below list is not exhaustive: Forward contracts (e.g. NDFs on various assets traded between FCs and/or NFCs, Virtual Power Purchase Agreements between Wholesale Energy Producers – Consumers); Options (e.g. Stock option programmes some firms offer as part of employee remuneration packages, digital or binary options); Contracts for Difference; Swaps (e.g. Total Return Swaps, Fixed-For Floating Swaps, Currency Swaps); Etc. In our next blog post on the UPI, we will deep dive into the technical documentations of the UPI code, in order to assist the market participants understand how to generate or retrieve the UPI as necessary. How is MAP FinTech going to assist? MAP Fintech offers the UPI Link Service that helps retrieving companies match their products’ attributes precisely to those already issued UPIs, ensuring that reporting companies use the correct UPI Code. MAP FinTech’s UPI Link Service boasts essential functionalities, including: Automated identification of UPIs using reference data provided by the reporting entity and the latest issued UPIs supplied by the ANNA-DSB. UPI enrichment of reported files prior to submission to the TR. Error identification where UPIs cannot be mapped against the ANNA-DSB’s issued UPI records. Inline editing capability for on-the-fly amendments on the UPI. Advanced search function from within Polaris portal which can pinpoint the exact UPI based on enhanced search criteria.
Additional Instruments Captured by updated EU MiFIR – an overview
Instruments captured by EU MiFIR reporting, divergence from UK MiFIR requirements With the departure of the UK from the EU it was expected that at some point, the EU and the UK regulatory regimes will start diverging. With Regulation 2024/791 amending MiFIR, the EU has introduced new asset classes which are now captured by the MiFIR reporting obligation. The amended rules came into effect on the 28th of March 2024. The new instruments captured under EU-MiFIR are not, currently, subject to the UK’s MiFIR reporting obligation. As per the amended MiFIR, the obligation to report transactions (Article 26.2) has been amended and applies as follows: financial instruments which are admitted to trading or traded on a trading venue or for which a request for admission to trading has been made, irrespective of whether such transactions are carried out on the trading venue, with the exception of transactions in OTC derivatives other than those referred in Article 8a(2), to which the obligation shall apply only when carried out on a trading venue; financial instruments where the underlying is a financial instrument that is traded on a trading venue, irrespective of whether such transactions are carried out on the trading venue; financial instruments where the underlying is an index or a basket composed of financial instruments that are traded on a trading venue, irrespective of whether such transactions are carried out on the trading venue; OTC derivatives as referred to in Article 8a(2), irrespective of whether such transactions are carried out on the trading venue. While points (a) through to (c) introduce nothing new, the inclusion of (d) adds 2 additional types of OTC derivatives. Types of instruments captured by the new MiFIR reporting obligation As per Article 8a(2) of EU MiFIR the following types of instruments denominated in EUR, JPY, USD or GBP are now captured by the MiFIR reporting obligation. Type 1: OTC derivatives declared by the EU as subject to the clearing obligation under EMIR, and where those derivatives are interest rate derivatives have specific tenors (years till maturity); Type 2: OTC derivatives – Credit Default Swaps that reference a Global Systematically Important Bank (G-SIB) and that are centrally cleared or, that reference an index comprising G-SIBs and that are centrally cleared. For illustration purposes, please see below select Asset Class and Instruments captured (indicative and non-exhaustive). [table id=8 /] For the list of G-SIBs, refer to the Financial Stability Board (FSB) as of November 2023. For the instruments subject to clearing, under EU EMIR, refer to ESMA’s registry section 1.1. *Disclaimer the above is for information purposes only. For an up-to-date list of instruments captured consult with the applicable regulation, lists of instruments subject to clearing, FSB announcements and your compliance risk management teams. How is MAP FinTech going to assist Our MiFIR Transaction Reporting service allows clients to seamlessly report their transactions in Financial Instruments as required by the Markets in Financial Instruments Regulation (MiFIR, Article 26). Clients can report to National Competent Authorities either directly or through an Approved Reporting Mechanism using our award-winning Polaris Platform. Transaction data is seamlessly processed, validated, and submitted in the required format through our fully automated service. Solution includes consolidated data feeds, automatic checks, a robust reconciliation engine and continuous regulatory updates. Clients enjoy optimised technology, cost savings, expert training, and transparent monitoring of their reporting via the Polaris dashboard. For more information or to schedule a demo, please contact our team of experts.