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.
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.
Unique Product Identifier: Crypto-asset identifiers
Unique Product Identifier: Crypto-asset identifiers As we had discussed in previous blog entries regarding the UPI and the technical data on how to generate the UPI, we now turn our focus on a specific aspect of the UPI. UPI for derivatives on crypto-assets. As mentioned in our January blog entry, ANNA-DSB has adopted various standards widely accepted by industry stakeholders. E.g. ANNA DSB adopted the following standards: for currencies the three letter ISO 4217 code; for Securities their ISIN, or SEDOL, or CUSIP, or FIGI; for Equity Indices, their ISIN or official name as published by the index administrator; etc. Crypto assets represent a particular problem, due to their nature they are not standardised nor are they issued with any unique identifier. As such, crypto-asset jargon widely used to identify such assets is not standardised nor unique, e.g. bitcoin is sometimes referred to BTC or XBT, while Ethereum Ether, is sometimes referred to as Ether, ETH or with Greek letter Xi Ξ. In order to avoid duplication pitfalls, for crypto-asset identifiers, ANNA-DSB has decided to adopt the identifiers issued by the Digital Token Identifier Foundation – DTIF. The code is a unique 9 letter code that characterizes each crypto asset maintained and issued by the aforesaid foundation. See below a non-exhaustive list of crypto-assets with their corresponding DTIF code. [table id=Token_DTIFs /] As such entities that want to generate or retrieve UPIs on crypto-assets derivatives, they should, be aware of the appropriate identifier of the underlying reference value (the crypto asset) in this case the crypto-asset DTIF code. For a comprehensive list of the DTIF codes that ANNA DSB has included in its libraries refer to the link here. See also a short list of issued UPIs on the basis of the above. [table id=Token_DTIFS_UPI /] *Disclaimer, the DTIF codes and the Unique Product Identifiers in this blog are presented for information purposes only, for an up-to-date list of DTIF codes and/or UPIs consult Digital Token Identifier Foundation and/or ANNA – DSB resources. 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.
MAP FinTech Webinar – In anticipation of the EU EMIR REFIT launch
MAP FinTech hosted a webinar with its EMIR-obliged clientele a few days before the REFIT go-live date to better prepare reporting entities. MAP FinTech staff reiterated to reporting entities that, when reporting on a delegation basis on behalf of other financial institutions (such as investment firms, credit institutions, funds etc.) defined under EMIR as Financial Counterparties (FCs), they need to furnish their Trade Repositories (TRs) with the LEI and a contact email for the said FCs. Trade Repositories need to obtain explicit authorisation by delegating parties As per the requirements of EMIR REFIT, TRs will need to directly contact delegating parties asking them to confirm in writing that they have authorised the reporting entities to submit EMIR reports on their behalf. Failure by the delegating parties to provide explicit confirmation will result in the rejection of reports submitted by report-submitting entities on their behalf. TRs have begun reaching out to delegating parties from early April 2024 and urged reporting entities to inform all those concerned to take prompt actions. Finally, for non-financial counterparties for whom the reporting entities are liable to submit EMIR reports on their behalf, the reporting entities can self-certify that they have received the authorisation to report without the need for the TR to directly obtain the explicit confirmation. UPI population status update On the issue of generating UPIs, MAP FinTech informed reporting entities that as per ANNA-DSB, the authority issuing UPIs, as of early March 2024 about 1,148,000 UPI records were generated. However, from an analysis conducted by ANNA-DSB, only 300,000 were generated by Market Participants; the rest were populated by ANNA-DSB themselves from the record they have of OTC unlisted derivatives that were issued with an ISIN. It was emphasised to webinar attendees that a UPI must be available on the reporting day. Therefore, attendees must examine their OTC derivatives’ offerings and try to identify the suitable UTI from ANNA-DSB’s database. In cases where the necessary UPI does not exist, reporting entities need to generate it. You can refer to MAP FinTech’s blog on the technical aspects regarding the generation of a UPI. Testing of the new regime MAP FinTech readiness and troubleshooting MAP FinTech informed the audience that it has carried out extensive testing of the new reporting regime and has identified discrepancies and inconsistencies in the XML schema and ESMA’s validation rules that caused reporting breaks. These were addressed to the TRs and ESMA who have provided intermediate guidance on how to overcome these issues. Furthermore, MAP FinTech informed clients that, as of the beginning of April the overwhelming majority of its clientele had already provided the necessary additional data for the REFIT reporting regime and those were successfully incorporated into the new reports and were tested in a UAT TR environment. New tools for EMIR-REFIT In closing, participants were reminded that MAP FinTech offers new tools to assist its clientele, namely the UPI Link search tool that identifies issued UPIs from ANNA-DSB’s database, and XMLCon.Vert service that allows clients to convert .csv files to the requisite REFIT XML format. MAP FinTech: your trusted RegTech Provider Looking ahead, MAP FinTech pledges continuous monitoring and support post-launch, anticipating an adjustment period and committing to random reconciliation checks to uphold data integrity. Clients are urged to vigilantly monitor submissions and report any anomalies during the initial weeks. As the countdown to this pivotal milestone accelerates, the synergy between MAP FinTech, clients, and TRs assumes paramount importance. With unwavering dedication to facilitating a seamless transition, MAP FinTech expresses gratitude for the collective effort of all stakeholders, confident that this complex undertaking will ultimately yield more efficient reporting processes under the new EMIR REFIT standards. At MAP FinTech, we offer more than just cutting-edge technology; We provide expert knowledge and unwavering support to guarantee a seamless transition to the new reporting requirements. Contact our team of experts today and experience a smooth transition.
How will the new EMIR REFIT reporting requirements impact the EU and the UK markets?
In a recent article published by FinTech Global, George Markides, Senior Manager of the Compliance Support Department at MAP FinTech, highlights key aspects of the new EMIR REFIT reporting regime and how it will impact the EU and UK markets. The rules come into effect on April 29, 2024, in Europe and September 30, 2024, in the UK. According to Markides, the regime introduces several novelties that will impact the way reporting counterparties operate and exchange information with each other, inviting increased scrutiny from regulators. Notably, Markides writes that one of the most significant changes is the additional data points and values reported that will be subject to reconciliation for dual-sided reports submitted by counterparties in the EEA or UK. The reconciliation takes place at the trade repository (TR) level with results shared with reporting entities and regulators. Crucially, valuations of derivative contracts under EMIR will also be subject to reconciliation. Markides emphasises the establishment of the Unique Product Identifier (UPI), a concept introduced in EMIR V1 but now required from day one of the new reporting regime. UPI serves as an identifier for non-listed OTC derivatives and is issued by ANNA Derivatives Services Bureau (ANNA-DSB), though new issuances will incur fees. Additionally, EMIR REFIT introduces more detailed outgoing messages from TRs, sharing data such as number of submissions, number of rejections, outstanding positions, and trades with outdated or no valuations or collateral information, reconciliation status, or abnormal values reported. These reports aid reporting entities in correcting their submissions and provide regulators with a more immediate and comprehensive view of compliance with the reporting regime. In conclusion, Markides stresses that these changes necessitate reporting counterparties to enhance oversight and monitoring to minimise potential lapses in compliance. Read the full article here. MAP FinTech can fully assist any firm under EMIR Reporting to seamlessly adapt to the evolving reporting requirements brought on by EMIR REFIT. Contact our team of experts and learn how you can benefit from our innovative and comprehensive regulatory reporting solutions.
EMIR reporting 101 – Collateral Updates
Did you know that Investment Firms, Banks, and Funds must report collateral received from clients including retail clients, or posted to other counterparties? Under EMIR’s risk mitigation techniques, Counterparties that do not clear their derivatives trades with a Clearing House, are required to exchange collateral to manage default/counterparty risk. This exchange of collateral must be reflected in the EMIR reporting that Counterparties submit to the TRs. Collateral is split under EMIR in three broad categories: Initial margin (received from clients/other counterparties or posted to other counterparties) Variation margin (received from clients/other counterparties or posted to other counterparties) Excess collateral Whereby Initial margin is the collateral collected to cover current and potential future exposure in the interval between the last collection of margin and the liquidation of positions or hedging of market risk following a default of the other counterparty Variation margin is the collateral collected to reflect the results of the daily valuations of outstanding contracts (either marked to market or marked to model) Excess collateral is additional collateral posted or received separately and independently from initial and variation margins At MAP FinΤech we can help create and submit on-time accurate collateral reports reflecting your trading data, with our dedicated support and compliance teams we can help counterparties navigate successfully and with ease the requirements under EMIR. Say goodbye to the hassle and hello to peace of mind with MAP FinTech. Contact us today to learn more!
UK EMIR Derivatives Reporting Framework: FCA update
On 24th February 2023, the FCA issued an update regarding changes to the UK EMIR derivatives reporting framework. The joint FCA/Bank of England Policy Statement (PS 23/2) announced that the new rules will come into force from 30 September 2024, as well as publishing draft versions of EMIR Validation Rules and Incoming/Outgoing XML schema. Firms can submit feedback for technical specification documents until the 24th of March 2024, with the final versions expected to be released shortly after this date. Although the UK rewrite remains largely in line with ESMA, there are some differences to be aware of: Dual Reporting Obligations Dates: With the ESMA deadline date on 29th April 2024, separate to the FCA 30 September 2024 date, firms with dual reporting obligations will need to provide two versions of EMIR reporting. Delegated Reporting: Regarding cross-jurisdiction reporting, EU entities currently providing delegated reporting to customers in the UK will continue to provide this in the existing format for clients but will need to use the updated Refit version internally. There is also additional pressure on UK firms providing delegation to EU firms, as they will need to be compliant by the earlier ESMA date of 29th April 2024 rather than the September deadline. Field and Validation Discrepancies: ‘Execution Agent’ is an additional field allowing third parties to be tagged by firms on their behalf. Various validations have been amended in the XML Schema Definitions (XSD) as well as a number of additional slight changes by the FCA. As the EU and UK frameworks continue to be updated in the future, it may become more difficult for firms to manage these discrepancies and requirements. Get in touch today to find out how we can assist your firm with the upcoming changes. How MAP FinTech may assist MAP FinTech is a leading award-winning global regulatory technology provider, highly regarded for its proprietary reporting technology and exceptional client-centric after-sales support. As one of the first providers in Europe to report under the European Market Infrastructure Regulation (EMIR), with billions of transactions reported successfully so far, we have built a reputation for excellence, coupled with the necessary regulatory expertise and technological innovation to assist firms in navigating their respective regulatory obligations. Contact our team of experts to find out how you can benefit from our innovative and comprehensive regulatory reporting solutions.
EMIR Refit RTS/ITS: reporting under the new standards
The EMIR Refit technical standards (RTS and ITS) were published in the Official Journal of the EU on October 7th 2022. With the compliance date now set on 29 April 2024, counterparties will need to report under the new standards, including upgrading outstanding derivatives to the new reporting standards. Some of the key differences that the EMIR Refit package brings are: New ISO 20022 XML Data Format. Unique Product Identifier (UPI) to be used where an ISIN is unavailable. Position-level reporting will be selected over transaction level where the conditionalities of the RTS/ITS are met. Additional details and values to be included in the report regarding, collateralisation, the reporting of corporate events and the direction of the transaction etc. New data points, for example, Post Trade Risk Reduction (PTRR), events (e.g., Compression), identifiers for crypto derivatives, additional points on asset characteristics, information on delta values etc. Delegated Reporting – Report Submitting Entity (RSE) must provide the Entity Responsible for Reporting (ERR) with transparency to the records reported on their behalf, and to any data quality issues encountered. Introduction of an Errors and Omissions notification to NCAs. A new provision by ESMA, that would require the counterparties to have in place written internal procedures to resolve any reconciliation break identified by the Trade Repositories (TRs). Increase in the number of reconcilable fields to be reconciled from the date when the new RTS/ITS package begins to apply with several more fields becoming reconcilable 2 years after the go-live date. ATTENTION Valuation becomes a reconcilable field. This means that where 2 EEA counterparties to a derivative contract respectively mark-to-market the valuation amount of said contract, if those values are outside tolerance level, this field will not reconcile, and the transaction will not be matched. Trade Repositories in case of a paired report between 2 EEA counterparties that have not been reconciled (matched, field by field) will stop attempting to reconcile the derivative 30 calendar days after the derivative ceases to be outstanding. MAP FinTech is a leading award-winning global regulatory technology provider, highly regarded for its proprietary reporting technology and exceptional client-centric after-sales support. As one of the first providers in Europe to report under the European Market Infrastructure Regulation (EMIR), with billions of transactions reported successfully so far, we have built a reputation for excellence, coupled with the necessary regulatory expertise and technological innovation to assist firms in navigating their respective regulatory obligations. Contact our team of experts to find out how you can benefit from our innovative and comprehensive regulatory reporting solutions.
EMIR/MiFIR Efficient Transaction Reporting Monitoring: What Does Your Organisation Need to Do?
Did you know your transaction reporting obligations don’t end when the necessary information has been submitted to the authorities? Besides providing the relevant data, you still need to confirm that the transaction reporting occurred in a timely and accurate manner as it’s required by the regulation. This, in turn, raises another crucial question: What exactly does “timely and accurate” mean, and how does this play a role in the efficient monitoring process? Timeliness of Reporting Generally speaking, Transaction Reporting must be done on a T+1 basis. T+1 means that the reporting must take place by the end of the next (local) business day from the execution of the transaction. To achieve this, you need to ensure that: Any reporting data is provided at a designated time that is agreed with the Competent Authority (CA) /Service Provider (SP). Processing of the data from the CA/SP is performed on time so that you may have enough time to react in case of negative feedback. Any resubmissions that need to be done must be submitted as early as possible. The above steps will ensure that you have reported and handled any rejections within T+1 and, ideally, within your working hours. Data Accuracy Accurate data is critical when it comes to reporting. The obligation is not only to carry out the reporting (i.e. submit the data to the authorities) but to do it in the right way. Therefore, it is important to automate this process as much as possible. The less human intervention applied to the data, the fewer potential mistakes that might occur. Monitoring of the Reporting When the reporting has been performed, it would be prudent to perform, on a daily basis, a reconciliation that follows some specific checks. Then, a more in-depth reconciliation should be carried out on a weekly or monthly basis. Daily reconciliation should be performed once the reporting has been finalised and, ideally, you should check on the following: The timeliness of the reporting. Has the reporting been done within T+1? The number of transactions reported. Does the number match the number of transactions in the trading system? Ideally, you should also check the number of different reporting messages (new, termination, modification, valuation, etc.) vs the relevant actions on the trading system (openings, closings, modifications, transactions that remained open overnight, etc.) If any rejections have been received, you need to take corrective measures within the day to meet your T+1 obligations. Weekly or monthly reconciliation will allow you to go deeper into the reporting process and identify possible errors. This process would include the following: Performing a health check of the process you have in place, mainly on the data extraction. This will ensure that the data is provided on time and that you do not have any unexpected or unattended internal issues. Checking that the source data provided to the service provider or used for reporting is accurate and in line with your trading setup. Some core fields you could check are price, execution time (in UTC), notional amount, counterparties, and side of the trade (buy or sell). Making sure that procedures are up to date when it comes to adding new financial instruments in your trading setup and, subsequently, to your reporting, and that you avoid underreporting or overreporting. This also relates to any new clients, especially NFCs within EEA and other broker clients that need to be identified within the reporting using their corresponding LEIs. Performing reconciliation in case you delegated your reporting to other counterparties to make sure that the transactions they report on your behalf are in line with what you have in your trading system, as well as the data reported is accurate. All of the above assist in the efficient monitoring of your transaction reporting. The sequence in which you perform these steps depends solely on your own preferences. However, you need to keep in mind that this process is critical in making sure that you have met all your reporting obligations. Monitoring is an ongoing process and, given the latest Data Quality Reviews performed by the regulators, ensuring that all goes well is of paramount importance. To achieve this, a structured monitoring process must be in place. MAP FinTech is one of the earliest innovators in the RegTech space, being highly regarded for its Regulatory Transaction Reporting Technology and exceptional client-centric after-sales support. If you are having difficulty implementing the above, you can contact our team of experts here.
How Can We Maximise Regulatory Technology & Avoid Its Potential Pitfalls? What recent results from the European Banking Authority and ESMA reports show
The European Banking Authority (EBA) has recently published an analysis looking into the RegTech landscape in the EU. The report assesses the many benefits, challenges and risks of the use of RegTech in the EU and lays out the steps to be taken to support the sound adoption and scale-up of solutions in this sector. The study also proposes actions designed to enhance the knowledge and skills of the competent authorities (CAs). ESMA has also published a report on Trends, Risks and Vulnerabilities of the Financial sector dedicating a part on RegTech and SupTech and the change for Markets and authorities. This report highlights that market participants are increasingly using new automated tools in a variety of areas, while potential applications of new tools for regulators include greater surveillance capacity and improved data collection and management. When technology is used for compliance, it is called Regulatory Technology or ‘RegTech’. Regtech is defined as any range of applications of technology‐enabled innovation for regulatory, compliance and reporting requirements implemented by a regulated institution – with or without the assistance of RegTech provider. RegTech solutions in Financial Institutions (FIs) and Investment Firms (FI’s) are currently evident in: Anti-Money-Laundering and Countering the Financing of Terrorism (AML/CFT) – for example, providing solutions for sanction screening or remote onboarding of customers. Fraud prevention – through automated behaviour and transaction monitoring. Prudential reporting – supporting institutions in their regulatory submissions. ICT security – providing detection mechanisms for an institution’s operations security. Creditworthiness assessments – providing new capabilities for assessing the creditworthiness of clients. Regulatory Reporting – supporting institutions in their trade reporting. Risk Management Benefits According to financial organisations using RegTech solutions, their key benefits are improved risk management, better monitoring and sample capabilities, and a reduction in human error. At the same time, RegTech providers place heavy emphasis on their ability to increase efficiency and effectiveness and quell the impact of ongoing regulatory change. Some of the increasing disparities in perspective between financial institutions (FIs) and RegTech providers suggest that further research of the benefits afforded by RegTech solutions is required. ESMA also believes that the move towards a more data-driven and pro-active approach will enhance monitoring of the financial sector and help ensure better outcomes for market participants and consumers. The continual push for efficiencies and cost savings, particularly for back-end and legacy systems as well as for labour-intensive processes will increase the use of RegTech in the foreseeable future. Risks EBA highlighted that when not implemented correctly, RegTech solutions may also generate risks for FIs that would need to be identified, monitored and managed. These risks may relate to, for example, compliance, concentration, business continuity, ICT and security, reputational issues, internal governance, conduct and consumer protection, and/or technology. RegTech may also create new risks for CAs supervising FIs. These include potential difficulties in assessing the effectiveness and reliability of the technological solutions used by FIs, and a potential lack of skills and tools needed to supervise the use of technology enabled RegTech solutions and, say, audit the underlying algorithms. ESMA focused on the risks and challenges for regulators and market participants in the areas of data collection and management, digital transition and failure on the part of market participants to adapt to the new digitalised infrastructure and the need from regulators to invest in the technological tools and human skills that will allow them to effectively analyse the results, operational risks and the risks from strategic incentives such as developing expertise in RegTech. Challenges The EBA report suggests that the majority of challenges to RegTech market development involve internal factors within the FIs and providers. Likewise, ESMA considers most of those challenges to apply for FIs. However, a lack of common regulatory standards across the EU could also constitute a barrier to the wider market adoption of RegTech solutions. The main challenges from the FI perspective are summarısed as follows: Data-related challenges and cybersecurity threats: FIs often indicate data quality, data privacy and protection, lack of data integration, data availability, and lack of data standardisation and harmonisation as issues. Interoperability and integration with the existing legacy systems: FI legacy systems and processes have too many silos, making RegTech adoption difficult, and this is further compounded by doubts about the ICT capacity of FIs to support FinTech, RegTech, and InsurTech solutions. Changes to regulation: changes with national or international regulations and other regulatory challenges can be another key barrier to RegTech adoption. Costs and procurement process: RegTech solutions seen as part of compliance and usually treated as a back‐office function may be at risk of underinvestment. Lack of necessary skills and training: when working with either in‐house or external RegTech solutions, FIs need specialists, e.g. data scientists and engineers, to be able, where relevant, to scout, assess, operate, and maintain updated RegTech solutions. Perceived immaturity of RegTech providers’ solutions: FIs that see RegTech as a potential competitive advantage often cite the lack of available and mature RegTech solutions as a challenge. Challenges from the RegTech provider perspective include: Lack of technological capabilities – the lack of some clients API capabilities and lack of standardisation are perceived as obstacles for technical integration. Security, data privacy and protection issues – privacy regulation may be one of the key constrains for FIs from sharing datasets with RegTech providers. Changes of national and international regulation – complex and continuously evolving regulatory landscape is perceived as a challenge, in particular on prudential reporting, fraud prevention and AML/CFT. Cost of user acquisition – a challenge, especially for recently established and smaller RegTech providers. Lack of FI understanding of RegTech solutions –it appears to RegTech providers that FIs may not be fully aware of all advantages that RegTech solutions may bring. Lack of harmonised legal and regulatory requirements – RegTech providers perceive the lack of harmonisation of regulatory requirements across the EU and the lack of regulatory data standards to be obstacles for wider market adoption of RegTech solutions. Clarity of regulatory/supervisory guidance – RegTech providers consider the lack of regulatory/supervisory