Initial meeting

Category: blog EN

Feb 24, 2025

News on Financial Entities as ICT Third-Party Service Providers and on Subcontracting under DORA

The EU Regulation 2022/2554 (DORA) has come into force and financial firms must comply with the new requirements. The regulation focuses on addressing the challenges posed by digital transformation and growing interconnectedness in the financial industry, which will intensify in the future. DORA aims to further reduce risks arising from cyber-attacks and business interruptions, for example. Specific obligations that DORA places on financial entities are complex. The bureaucratic burden that DORA places on financial entities should not be underestimated. At the same time, however, DORA helps to promote appropriate minimum standards in the area of digital operational resilience. DORA is supplemented by regulatory technical standards (so-called RTS), which are regularly drafted by the ESAs (EBA, EIOPA and ESMA) in cooperation with the national supervisory authorities and adopted by the Commission in accordance with the relevant requirements. Most RTS have already entered into force in this way. The RTS are intended to provide financial entities with specific guidelines on how the requirements of the DORA are to be understood and implemented in the areas regulated by the RTS. Although DORA and almost all RTS are already applicable, there is still some uncertainty regarding the interpretation of DORA in individual cases. EIOPA has now provided interpretation notes via the ESA’s joint Q&A on one of the major questions concerning DORA – namely, when a financial entity is to be classified as an ICT third-party service provider in relation to other financial entities. There is also uncertainty regarding the outsourcing by ICT third-party service providers of critical or important functions or significant parts thereof to subcontractors. The draft RTS on this from the ESA is still at the drafting stage despite the fact that the DORA has already come into force, and now the Commission has announced its intention to partially reject the draft. The following comments address these issues surrounding DORA.

Clarification: When Financial Entities May Be Qualified as Third-party ICT Service Providers

One of the most pressing questions for many financial companies is whether DORA applies when a financial entity provides digital services to another financial entity. At what point are the services between financial entities classified as ICT services? If the services are ICT services within the meaning of DORA, a financial entity can also be considered an ICT third-party service provider within the meaning of DORA. This is explicitly clarified in recital 63 of the DORA. On behalf of the ESAs, EIOPA is now providing legal practitioners with an interpretative guide. In EIOPA’s view, financial services may also include an ICT component. If financial entities provide ICT services to other financial entities in connection with their financial services, the financial entity receiving the ICT services should check whether, firstly, the services constitute an ICT service as defined by DORA and, secondly, whether the financial entity providing the services and the financial services it offers are regulated under EU law or the national law of a member state or a third country. Should both tests be passed, the ICT service in question should be considered predominantly a financial service and not an ICT service within the meaning of Article 3 subsection 21 DORA. If the service is provided by a regulated financial entity offering regulated financial services, but the service is unrelated or independent of such regulated financial services, the service should be considered an ICT service for the purposes of Article 3 subsection 21 DORA. This interpretation is to be endorsed as it is in line with the objectives of the DORA, is consistent with the guiding principles of recital 79 and avoids additional red tape in the area of ICT third-party risk management between financial entities, each of which is already subject to the requirements of the DORA.

Further Uncertainty Regarding RTS on Subcontracting

On January 21, 2025, the European Commission rejected the draft regulatory technical standards (RTS) related to subcontracting of ICT services supporting critical or important functions. These RTS are urgently needed, among other things, so that financial entities know how far-reaching contractual agreements with third-party ICT service providers need to be with regard to subcontracting. The Commission considers that the requirements in Article 5 of the draft RTS go beyond the powers granted to the ESAs by Article 30 subsection 5 DORA. In particular, it concerns the conditions for monitoring the chain of ICT subcontractors that are not specifically linked to the conditions for subcontracting. The Commission is asking for the removal of Article 5 and associated Recital 5 from the draft RTS to ensure that the draft is consistent with the mandate. The corresponding article will therefore no longer be part of the rules to be observed by financial entities. Unfortunately, this also delays the binding adoption of the RTS, and financial entities are still only able to work with the draft. At least the Commission is only proposing editorial changes that are intended to improve the quality of the legal act without affecting the substance of the act. The ESAs have six weeks to revise the draft based on the proposed amendments by the Commission and resubmit it. If the ESAs do not amend the draft in line with the Commission’s suggestions or do not submit a revised draft within this period, the Commission may adopt the RTS with the amendments it has proposed or reject them altogether. It is therefore clear that more legal certainty will probably soon prevail. Until then, financial entities should use the existing draft and refrain from the requirements in Article 5 of the RTS.

FIN LAW

I.  https://fin-law.de

E. info@fin-law.de

The lawyer responsible for questions relating to DORA and IT law at our law firm is Attorney Lutz Auffenberg LL.M.

subscribe to Newsletter

    Contact

    info@fin-law.de

    Feb 17, 2025

    Token Sale in the MiCAR Era – How Can a Token Issuance be Advertised?

    Since the new Regulation on Markets in Crypto Assets (MiCAR) came into full legal force at the end of last year, the regulatory requirements for token sale events and initial coin offerings have also expanded considerably. This applies in particular to issuers of e-money tokens (EMT) and asset-referenced tokens (ART), but also to issuers of other crypto assets. Provided that no exemptions provided for by MiCAR can be utilized, the provider of the crypto assets must prepare and publish a detailed crypto asset whitepaper prior to the public offering via a token sale event. In addition, providers of new crypto assets must now meet compliance requirements and, in particular, identify, avoid and disclose any conflicts of interest. MiCAR also requires providers to draft their marketing communications for a public offering in compliance with certain minimum requirements and publish them on their website prior to the launch of the token sale. Marketing communications must be clearly recognizable as such and must contain a specific reference, pre-formulated in MiCAR, to the fact that they have not been reviewed or approved by an authority and that the provider bears sole responsibility for their content. In any case, any marketing communications must be consistent with the details and information in the underlying crypto asset whitepaper. But what exactly are marketing communications within the meaning of MiCAR?

    What Constitutes a Marketing Communication Under MiCAR?

    Modern marketing for token sale events is difficult to compare with advertising measures that issuers and distribution service providers carry out for traditional capital market issues. The usual marketing measures prior to MiCAR coming into force took place almost entirely online and ranged from content marketing via articles placed in specific portals, community building on social media channels or the provision of digital giveaways such as NFTs. Under MiCAR, the question therefore arises as to whether these marketing measures also qualify as marketing communications and are therefore subject to the corresponding labeling and publication obligations under MiCAR. However, MiCAR itself does not contain an independent definition of the term marketing communication. However, it can be inferred from the recitals preceding the text of the regulation that marketing communications should at least also include advertising messages and marketing materials that are disseminated via social media platforms. According to this statement, not only text messages would be covered by the term marketing communication, but possibly also other modern advertising measures such as memes or images. The term must be further substantiated by interpretation. In this respect, for example, recourse can be made to the definition of advertising in securities law, which in any case requires a certain promotion of the willingness to subscribe through a measure that relates to a specific public offer of securities. This objective could also be used for the interpretation of the marketing communication within the meaning of MiCAR.

    How Can Providers Label Memes and NFTs as Marketing Communications?

    The more modern and unconventional the individual advertising measure, the more difficult it becomes to comply with the MiCAR requirements for the labeling of marketing communications. In particular, the affixing of the provider’s unambiguous and clearly recognizable declaration of responsibility in accordance with the textual requirements of MiCAR causes difficulties where only a very limited number of characters may be possible or even where communication is to take place exclusively via an image. Ultimately, BaFin or ESMA would have to clarify whether short links or asterisk references may be used in this respect, as long as such aids do not restrict the clear recognizability of the declaration. In individual cases, such reference solutions could even be conducive to the visibility of the markings required by supervisory law if, for example, a presentation in small font size or in a less conspicuous color design could be avoided in this way. As long as there is no official administrative practice on the details of the design of marketing communications under MiCAR, the provider will have to assess for each individual advertising measure for token sales if it constitutes a marketing communication and how specifically the applicable design obligations are to be implemented.

    Attorney Lutz Auffenberg, LL.M. (London)

    subscribe to Newsletter

      Contact

      info@fin-law.de

      Feb 10, 2025

      AiaaS – Proven Solution for New Breakthrough Technologies

      Artificial intelligence (AI) is already revolutionizing numerous areas of society and the economy. It opens up new opportunities for growth and innovation by automating processes, using resources more efficiently and enabling completely new business models. Accordingly, the demand for AI is high. Developing and operating your own AI models is costly and time-consuming, and requires high initial investments and extensive specialist knowledge. To meet the demand for cost-effective alternatives, the market has found a solution that has been used in the IT sector for a long time. Under the catchy name Software-as-a-Service (SaaS), software and hardware resources are offered as cloud-based solutions. This means that resources can be provided to users in a scalable and cost-effective way. The new star in the sky of cloud-based services is called AI-as-a-Service (AIaaS). This service allows companies to use predefined or self-trainable AI models that run on the infrastructure of large cloud providers via API. The advantages in terms of cost, time, scalability and access to the latest AI technologies are immense. This means that even small or medium-sized companies can implement AI projects that would otherwise only be available to large technology companies. Although it is similar to SaaS solutions, AIaaS raises a number of legal issues that need to be addressed before AIaaS projects can be implemented.

      A Fresh Take on Old Favorites

      A range of different AI applications are already on the market, serving a variety of functions. These range from chatbots to document processing and innovative investment tools. As with SaaS, the right contract design plays a crucial role in AIaaS. The contract must meet the requirements of the respective application. In particular, the contractual parties’ performance obligations must be regulated. The contractual parties should take the time to clearly describe the services in order to avoid misunderstandings and to create clarity for the interpretation and legal classification. Service level agreements should be concluded to ensure sufficient availability and quality of the AIaaS service, maintenance times and response times in the event of disruptions. Another important topic is the correct handling of data protection in accordance with the GDPR, since personal data is usually processed. Often, the use of cloud-based AIaaS solutions also involves a transfer of personal data to a third country, which is only permitted under the strict conditions of the GDPR. It must be clarified who is the responsible party, whether there is joint responsibility or order processing. Also, it needs to be clarified whether the use of the AIaaS is to be regarded as an outsourcing from the own company to the AIaaS service provider and whether this results in specific legal obligations. IT security also plays an important role. This applies in particular to financial companies that are subject to Regulation (EU) 2022/2554 (DORA). AIaaS providers are likely to regularly qualify as third-party ICT service providers within the meaning of DORA, which is why the far-reaching requirements of DORA must be observed. The requirements for contract design, project organization and monitoring can be high in individual cases, but there are also many design options that can best be used for a successful implementation of the project through careful planning and close exchange between the parties involved.

      New Territory: Artificial Intelligence Act

      In addition to the aspects mentioned above, the Regulation (EU) 2024/1689 (AI Act) is another piece of legislation that has been introduced recently at the European level and that the parties involved in an AIaaS relationship must comply with. In some cases, the requirements can be very extensive. For example, the AI Act prohibits certain practices in the field of AI. It also defines special risk management requirements for high-risk AI systems and obligations for actors in relation to such systems. It also imposes transparency requirements on certain AI systems and requires providers and operators of AI systems to take measures to ensure to the best of their ability that their personnel and other persons involved in the operation and use of AI systems on their behalf have an adequate level of AI competence. This may also mean that appropriate training is necessary. In most cases, the requirements for companies that integrate AIaaS solutions into their business are limited and do not present any significant obstacles. It is also a stated aim of the regulation to promote innovation and employment and to give the Union a leading role in the introduction of trustworthy AI.

      FIN LAW

      I.  https://fin-law.de

      E. info@fin-law.de

      subscribe to Newsletter

        Contact

        info@fin-law.de

        Jan 20, 2025

        DORA Is Live – When Do the First Reports Have to Be Made to BaFin?

        The time has come: the two-year transitional period since the entry into force of DORA on 16 January 2023 has expired and DORA is applicable since 17 January 2025. The financial firms and ICT third-party service providers affected must now meet the new requirements introduced by DORA. Financial firms must measure their digital operational resilience against the provisions of DORA. DORA comprises 64 articles, which are supplemented by a series of Regulatory Technical Standards (so-called RTS). The RTS create uniform standards across the EU, so that all affected financial firms throughout the Union must meet the same requirements. This is intended to strengthen the freedom of establishment and the digital operational resilience of the entire European financial market. DORA addresses ICT risks by setting out specific requirements for ICT risk management capabilities, incident reporting, operational resilience testing, and monitoring of risks associated with the use of third-party ICT service providers. BaFin has already stated on several occasions that there will be no further transition period after the two-year transition period. This means that financial companies must already fulfill the DORA requirements. But what about specific reporting and notification requirements that financial companies must submit to BaFin? The main focus here lies on the Register of Information, which refers to all contractual agreements for the use of ICT services provided by third-party ICT service providers and must be maintained by financial companies as part of their ICT risk management.

        What is the DORA Register of Information?

        An important part of the DORA regulation is the requirement for financial firms to establish sound management of third-party ICT risk. This includes, for example, a strategy for managing ICT third-party risk and, optionally, a strategy for using multiple ICT providers. In addition, guidelines must be created for the use of ICT third-party services, in particular for ICT services that support critical or important functions. The Register of Information is also a key component of ICT third-party risk management. Financial companies must maintain this register of information for all contractual agreements for the use of ICT services provided by third-party ICT service providers. A distinction must be made between ICT services that support critical or important functions and those that do not. The requirements for the Register of Information (RoI) are specified in detail by the Regulation on implementing technical standards with regard to standard templates for the Register of Information (ITS RoI). Financial undertakings must provide the competent authority – in Germany BaFin – with the complete Register of Information or, upon request, certain parts of this register, together with all information deemed necessary for the effective supervision of the financial undertaking. BaFin has now announced that it will require financial companies to submit the Register of Information to BaFin for the first time by 11 April 2025 at the latest. To this effect, BaFin published a series of articles on its website just a few days ago. The background to this is that BaFin must transmit the Registers of Information to the European Supervisory Authorities by 30 April 2025 so that they can classify the third-party ICT service providers requiring supervision as critical ICT service providers within the meaning of the DORA, which are subject to special supervision under the DORA.

        How Should the Register of Information be Submitted in Accordance with the Regulation?

        For financial companies that have already completed the implementation of DORA, submitting the Register of Information to BaFin should not pose a problem. Financial companies that have not yet fully adapted to the DORA requirements should not panic either, but should quickly start creating the Register of Information so that it is ready as soon as BaFin requests it. In a recently published article, BaFin also called on the financial companies concerned to prepare to submit the Registers of Information to BaFin for the first time by no later than 11 April 2025. However, the authority also promised to provide the companies with close support until then and to try to clarify as many open questions as possible. BaFin has published detailed information on its website. The Registers of Information are transmitted to BaFin via BaFin’s reporting and publication platform (MVP). When creating the registers, financial companies must follow the guidelines of the European Supervisory Authorities (ESAs). The registers are to be submitted as structured files that correspond to the taxonomy specified by the ESAs. In order to make the conversion easier for smaller finance companies in particular, BaFin plans to provide a special Excel template on its website in the near future. This template can then be used by financial companies instead of a structured file, provided that the given structure of the Excel template is strictly adhered to. As an alternative to submitting the Register of Information as a structured file, financial companies should be able to submit the completed Excel template via the MVP. It is also essential for companies that plan to apply to BaFin for a license to operate as a financial service provider in the near future to ensure that the requirements of DORA have been implemented. This is the best way to avoid delays in the processing of the license application. The requirements of DORA are very complex. However, they do not fundamentally differ from the requirements that BaFin has already placed on financial companies prior to the entry into force of DORA. Provided that a solid information security management system (ISMS) already exists within the company, the adjustments should be able to be implemented quickly in most cases.

        FIN LAW

        I.  https://fin-law.de

        E. info@fin-law.de

        subscribe to Newsletter

          Contact

          info@fin-law.de

          Dec 16, 2024

          Interoperability Through Token Bridges – Are Wrapped Tokens Crypto Assets under MiCAR?

          Blockchain technology has established itself as a promising technical infrastructure for numerous applications since the emergence of the smart contract economy. Investment products and capital market issues in particular are now increasingly being mapped and processed via smart contracts implemented on blockchains. The tokenization of so-called real-world assets (RWA tokens) or rights is also increasingly being implemented to enable the digital transfer of the underlying assets. One of the biggest challenges of blockchain-based projects, however, is the fact that blockchains are essentially closed networks that are not compatible with each other. The use of bitcoins or their equivalent value to interact with a smart contract implemented on the Ethereum blockchain, for example, is not technically possible at first glance. So-called token bridges can provide a remedy in such cases. These are smart contracts that enable their users to use value units from other blockchain infrastructures on other blockchains. Technically, this works by users transferring cryptocurrencies of a certain type to a blockchain address managed by the token bridge in order to receive wrapped tokens in return, which are generated on the target blockchain and can therefore be used there. Wrapped tokens usually represent the value of the deposited cryptocurrency at a ratio of 1:1.

          Can Wrapped Tokens Represent Asset-Referenced Tokens?

          Under MiCAR, digital representations of values or rights that can be transferred and stored electronically using distributed ledger technology or similar technology are regulated as crypto assets. Wrapped tokens certainly meet these very broadly formulated requirements. However, MiCAR also recognizes special forms of crypto assets that may be associated with further obligations for issuers and providers of crypto services. An asset-referenced token (ART) exists, for example, if a crypto asset attempts to maintain a stable value by referring to another asset or another right or a combination thereof, including one or more official currencies. As wrapped tokens usually represent the value of another crypto asset on a 1:1 basis, they will in most cases qualify as ART. For the issuer of the wrapped token, this may mean in particular that the wrapped token may not be issued without the necessary authorization under MiCAR. In addition, the issuer of ART is obliged to create an asset reserve, which must be held in accordance with the specific requirements set out in MiCAR. Furthermore, depending on the design of the underlying smart contracts, providers of token bridges may trigger licensing obligations under MiCAR. For example, the safekeeping of deposited crypto assets may constitute crypto custody subject to authorization. The retransfer of deposited crypto assets may also be subject to authorization under MiCAR if it is to be carried out to a different blockchain address than the one from which the crypto assets were originally transferred to the token bridge.

          Can Token Bridge Models Also Be Realized in an Unregulated Way?

          Providers of token bridges and issuers of wrapped tokens may therefore be subject to far-reaching regulatory obligations. One way to avoid these considerable administrative burdens may be to decentralize the token bridge and the issuance of wrapped tokens to such an extent that there is no sufficiently responsible person for the operation of the token bridge and the issuance of wrapped tokens. In this respect, it would be necessary for the token bridge to function in a completely decentralized manner and for no identifiable person to have control or influence over the operation or issuance of wrapped tokens. In this case, there would be no addressee for the regulatory obligations provided for under MiCAR and the token bridge would be able to operate outside the scope of MiCAR.

          Attorney Lutz Auffenberg, LL.M. (London)

          I.  https://fin-law.de

          E. info@fin-law.de

          The lawyer responsible for questions relating to the qualification of tokens under MiCAR at our law firm is Attorney Lutz Auffenberg, LL.M. (London).

          subscribe to Newsletter

            Contact

            info@fin-law.de

            Dec 02, 2024

            Getting Ready for DORA (Part VII) – Which Financial Companies Benefit From the Simplified ICT Risk Management Framework?

            From 17 January 2025, affected companies will have to comply with the new requirements introduced by DORA. The main objective of DORA is to fully and consistently harmonize digital operational resilience and ICT security. The need for this arises, among other things, from the fact that legal differences and varying national regulatory and supervisory approaches to ICT risk create obstacles to the functioning of the internal market for financial services. This makes it considerably more difficult for financial companies operating across borders to exercise their freedom of establishment and freedom to provide services without hindrance. Furthermore, competition between the same types of financial companies operating in different member states has also been severely distorted by these differences. DORA addresses ICT risks through targeted requirements for ICT risk management capabilities, incident reporting, operational resilience testing, and monitoring of ICT third-party risk. When dealing with DORA, the principle of proportionality must be taken into account. This means that the size, overall risk profile, nature, scale and complexity of the financial services must be taken into account when implementing the requirements. This is also reflected in the requirements for ICT risk management: DORA provides for a so-called simplified ICT risk management framework for certain financial firms. But to whom exactly does this apply?

            Which Companies Can Implement a Simplified ICT Risk Management Framework?

            The simplified ICT risk management framework is significantly scaled back compared to the general framework otherwise provided by the DORA and places fewer specific requirements on the implementation of ICT risk management. To put it bluntly, ICT risk management is reduced from fifteen articles to one. This simplified framework applies exclusively to the financial institutions explicitly named by DORA. These include, for example, small and non-interconnected investment firms, small institutions for occupational retirement provision, and institutions excluded under the Capital Requirements Directive (CRD IV). These exclusions are particularly welcome in light of the considerable effort involved in implementing the DORA requirements. Smaller companies that fall under the exemption can thus operate an ICT risk management system that is appropriate in relation to their size and overall risk profile. An adequate level of protection is ensured by the requirements of the simplified ICT risk management framework in conjunction with the regulatory technical standards (RTS RMF). These standards define the tools, methods, processes and guidelines for ICT risk management and for the simplified framework. The simplified ICT risk management framework should also apply to payment institutions and e-money institutions that have been excluded from the respective member states’ implementation under the Payment Services Directive (PSD2) or the E-Money Directive. However, there is inconsistent implementation here by the individual member states.

            Unequal Requirements for Payment Institutions in Different Member States

            Despite DORA’s harmonization efforts, gaps still exist. These are particularly evident in the case of payment institutions and e-money institutions. This is because the member states had a certain amount of leeway when implementing the PSD2 and the E-Money Directive. It is therefore possible that when transposing the directive into national law, the option of “exempting” certain payment institutions or e-money institutions and subjecting them to simplified requirements in national law will be used. Consequently, in these cases, the DORA refers to an exemption that only applies to financial companies if the respective member state has implemented this exemption in its national law. However, this is in strong contrast to the DORA’s objective of creating a level playing field for all market participants. Recital 42 of the DORA shows that the European legislator has recognized this problem and ultimately accepted the unequal treatment of comparable financial companies. One example of this is that a payment institution regulated in Germany must comply with the general ICT risk management framework, while a comparable payment institution in another member state that has made use of the exemption may apply for the simplified ICT risk management framework. It is therefore necessary to check in each individual case whether and to what extent the simplified ICT risk management framework can be applied for. Even if this is not the case, the general ICT management framework must still be implemented proportionately.

            FIN LAW

            I.  https://fin-law.de

            E. info@fin-law.de

            The lawyer responsible for questions relating to DORA and IT law at our law firm is Attorney Lutz Auffenberg LL.M. (London).

            subscribe to Newsletter

              Contact

              info@fin-law.de

              Nov 25, 2024

              No Tied Agents Under MiCAR – How Do Liability Umbrellas and Contractually Tied Agents Have to Prepare for MiCAR?

              From 30 December 2024, the provisions of the Markets in Crypto Assets Regulation (MiCAR) will be legally effective throughout the European Union. From that date, crypto-asset service providers within the scope of the new regulation will no longer be allowed to provide their services without the required MiCAR authorization. MiCAR does not recognize the tied agent model, a concept known from other areas of financial market regulation, in which activities requiring a license can be provided under the responsibility of a sufficiently authorized institution without a license of one’s own. In this regard, ESMA already clarified in September 2024 that crypto-asset services under the MiCAR may only be provided by companies that are either authorized as crypto-asset service providers or that have successfully completed a notification procedure in accordance with the MiCAR as a credit institution or securities institution that is already supervised. Since, under the current regulation in Germany according to the Investment Firm Act (WpIG), crypto securities are considered financial instruments and the law allows liability umbrella solutions for business models in which companies in Germany exclusively provide investment brokerage, investment advice or placement services, the transition to the MiCAR regime for correspondingly tied agents potentially represents a real showstopper. What can tied agents and their liability umbrellas with crypto-related business models do before 30 December 2024 to seamlessly continue business under MiCAR?

              Can Tied Agents be Covered by the MiCAR Transitional Provision?

              MiCAR provides for a transitional regime for providers of crypto-asset services that have provided their services in accordance with the law applicable to them, i.e. in accordance with the applicable national provisions. Such providers may continue to provide their services after 30 December until 1 July 2026, or until a MiCAR license is granted or refused, whichever event occurs first. However, member states have the option of shortening the timeframe until 1 July 2026. The German legislator has not yet enacted any implementing legislation for MiCAR, so a shortening of the timeframe is not to be counted in for the time being. According to the wording, tied agents would in principle be able to make use of the transitional regulation, since they have legally provided crypto value services prior to 30 December 2024 under the applicable national regulations. However, it must be taken into account in any case that the permissibility under supervisory law of the provision of services by tied agents is derived from the investment firms acting as a liability umbrella. In view of this, it can be assumed that reliance on the transitional regulation for tied agents can only be considered if the liability umbrella solution used continues to exist under the applicable law from 30 December 2024 and the liability umbrella continues to fulfill the relevant requirements. In contrast, BaFin has contacted the institutions under its supervision that have tied agents and pointed out that the involvement of tied agents will be inadmissible under MiCAR. Tied agents who therefore wish to invoke the transitional provisions of MiCAR should in any case clarify this approach in advance with their liable institution and BaFin.

              The Alternative to the Liability Umbrella is Either an Outsourcing Solution or a MiCAR Authorization

              If tied agents are not eligible or unwilling to rely on the MiCAR transitional provisions, they need an alternative solution. It is possible to apply to the competent authority for an own MiCAR license, but such an application requires thorough and time-consuming preparation, as well as patience until the BaFin approval process is complete. A so-called outsourcing solution can be implemented more quickly, in which the previous tied agent acts as an outsourcing company for the provider authorized to provide crypto-asset services. As in the liability umbrella model, the provider of crypto-asset services is then responsible under supervisory law. The outsourcing company then provides technical services to the provider, such as the provision of a technical platform, support services and distribution. However, caution is advised with regard to outsourcing solutions in which outsourcing to crypto companies from non-EU countries is to take place. In ESMA’s view, outsourcing must not lead to a situation in which the third-country company ultimately provides crypto-asset services in Europe without an own authorization through a European special-purpose entity, while the service itself is actually provided in a third country.

              Attorney Lutz Auffenberg, LL.M. (London)

              I.  https://fin-law.de

              E. info@fin-law.de

              The lawyer responsible for all questions relating to the regulation of tied agents under MiCAR at our law firm is Lutz Auffenberg, LL.M. (London).

              subscribe to Newsletter

                Contact

                info@fin-law.de

                Nov 11, 2024

                MICAR Transition Without National Framework Legislation – What Happens if the German Parliament Does Not Pass the KMAG by the End of the Year?

                The governing coalition in the German Parliament consisting of the SPD, the Green Party and FDP is history. All that is left of the so-called “traffic lights coalition” that started about three years ago is a pedestrian light without a yellow phase. For the federal government, this means that majorities must be sought and formed in parliament for all legislative proposals still to be passed. The support of the opposition parties in the parliament, which have not themselves helped to shape draft legislations that are ready to be voted on, is likely to be granted only in a few cases, particularly in view of the election campaign that began immediately after the end of the governing coalition. The fate of the draft legislation under the Financial Markets Digitization Act (FinmaDiG), which has been on the table for many months, and the associated draft regulations on the MiCAR transition, namely the MiCAR Application Regulation and the MiCAR Transit Regulation, is therefore more than uncertain. It seems very unlikely that the proposals can still be adopted by 30 December 2024. From this date, the provisions of MiCAR will have direct legal effect in their entirety in EU member states. For companies with crypto-related business models, this means that they must have an authorization or notification under the new Regulation on the basis of which they are allowed to provide their crypto services. But what is the legal situation for the German crypto industry if the German legislator does not manage to enact national framework legislation by the time the new regulatory regime under MiCAR comes into force?

                Draft of the KMAG is to Create a Legal Basis for the Application for Approval in Accordance with MiCAR

                With the Crypto Markets Supervision Act (KMAG), the German legislator plans to create the national legal framework for the implementation of the MiCAR regulations. In particular, the KMAG is intended to define BaFin’s responsibility for supervising compliance with the provisions of the new regime. In particular, BaFin is to be responsible for processing applications for authorization under MiCAR and the ongoing supervision of crypto-asset service providers. Additionally , the KMAG is to establish BaFin’s competence for, e.g. acquisition control proceedings under the new regime and the prosecution of crypto services operated without required authorization under MiCAR. The draft legislation also contains a number of other special rules, such as supplementary provisions to the regulations set out in MiCAR and a comprehensive catalogue of administrative offenses for cases in which it or the KMAG are violated. However, the actual procedures for submitting an application for a MiCAR license or for using the notification option for existing institutions with an existing license under national financial supervisory law are defined by the MiCAR itself, with the exception of a few detailed questions. It is therefore only imperative that the German legislator legally regulates which national authority will be the competent authority within the meaning of MiCAR by the time it comes into force. Without this definition, there will be no legal basis for submitting applications to BaFin under MiCAR, with the result that BaFin will not be able to process such applications.

                What Applies to Existing Institutions and Institutions with a Provisionally Granted License in Accordance with Section 64y KWG?

                If the German Parliament does not pass the KMAG in time before 30 December 2024, only the MiCAR will apply to existing institutions and crypto service providers already operating legally. The transitional provisions therein stipulate that providers of crypto-asset services that provided their services under current law before 30 December 2024 may continue to do so until 1 July 2026 at the latest or until the date on which they receive an authorization or denial under the provisions of MiCAR. The starting point for the deemed approval is therefore solely the question of whether the company in question provided crypto-asset services under applicable law prior to 30 December 2024. In particular, the wording makes no distinction as to whether a company had a provisional or final license to provide crypto asset services before 30 December 2024. As a result, if the German legislator fails to act on national framework legislation for the MiCAR transition, crypto custodians with a provisional KWG license could also continue to operate their business for the time being. It is true that MiCAR provides national legislators with the option of deciding not to make use of the transitional regulation for crypto asset service providers. However, such a decision is likely to require an active legislative act, which has not yet taken place and is unlikely to be adopted by 30 December 2024.

                Attorney Lutz Auffenberg, LL.M. (London)

                I.  https://fin-law.de

                E. info@fin-law.de

                The lawyer responsible for questions relating to MiCAR, the transition to the MiCAR regime and related transitional provisions at our law firm is Attorney Lutz Auffenberg, LL.M. (London).

                subscribe to Newsletter

                  Contact

                  info@fin-law.de

                  Nov 04, 2024

                  Getting Ready for DORA (Part VI) – Only a Financial Company or Already ICT Third-party Service Provider?


                  From 17 January 2025, companies will be required to comply with the new requirements introduced by DORA. This regulation specifically addresses the challenges of digital transformation and increasing interconnectedness in the financial industry. In this context, DORA aims to minimize risks such as cyberattacks and operational disruptions. Financial institutions and their ICT service providers must take comprehensive measures to improve their digital resilience and thereby promote the security and stability of the entire industry. DORA is an extremely complex set of rules. The regulation comprises 64 articles, which are supplemented by a series of Regulatory Technical Standards (so-called RTS). The RTS are intended to create uniform standards throughout the EU, so that all affected financial institutions throughout the Union must meet the same requirements. RTS specify and clarify the general requirements of DORA. They are being developed jointly by the relevant European Supervisory Authorities (ESA), EBA, EIOPA and ESMA. Even though many of these RTS have now been published or are available as drafts, DORA still raises a number of questions of interpretation. This is particularly precarious as the time until DORA comes into force is getting shorter and shorter and the affected companies need to prepare for the regulation. One of these questions concerns the applicability of DORA to a financial company that provides services for another financial company. When can we assume that this is an ICT service that makes the providing financial company an ICT third-party service provider within the meaning of DORA? Do the requirements of DORA now also have to be met between two companies that are already regulated by the supervisory authorities? This question has significant consequences, since classifying a financial company as an ICT third-party service provider would, among other things, have far-reaching consequences for the contractual relationship between the ICT third-party service provider financial company and the client financial company.

                  Unclear Provisions in DORA Regarding the Term ICT Third-Party Service Provider

                  DORA defines ICT third-party service providers as companies that provide ICT services. In addition, recital 63 states that financial institutions that provide ICT services to other financial institutions should also be considered ICT third-party service providers under the regulation. Thus, it is clear that financial institutions can in principle also be ICT third-party service providers if they provide ICT services to other financial institutions. According to the DORA, third-party ICT services are digital and data services that are provided on a permanent basis to one or more internal or external users via ICT systems, including hardware as a service and hardware services, which also includes technical support provided by the hardware provider by means of software or firmware updates, with the exception of traditional analog telephone services. This definition is, as intended by the regulator, very broad. This is clarified in recital 35 of the DORA, which emphasizes that it is intended to address all risks arising from all types of ICT services. To this end, the definition of ICT services in the context of DORA should be interpreted broadly to include digital services and data services provided on an ongoing basis to one or more internal or external users via ICT systems. Furthermore, recital 79 mentions examples of ICT services as the use of cloud computing services, software solutions and data-related services. Assuming that a financial company regulated under MiFID II or MICAR provides a regulated financial service to another financial company and makes the financial service available to it on a permanent and digital basis, this raises the question of whether the requirements of DORA would have to be met in addition to the existing requirements for the financial service. The definition would readily allow for such a view, which would mean increased bureaucracy and additional costs for financial companies – all for the benefit of the digital operational resilience of the financial market. However, it remains questionable whether traditional financial services should automatically be classified as ICT third-party service providers just because they are provided digitally.

                  The Industry Calls for Binding Clarification

                  In their FAQ as part of the “DORA 2024 Dry Run Exercise on Reporting of Registers of Information”, the ESAs comment on the interpretation of ICT services to the effect that if a financial entity requires authorization, licensing or registration as a financial entity to provide a service, then that service is a regulated financial service and not an ICT service for the purposes of DORA. This interpretation would make it possible to exclude purely financial services that are not traditional cloud computing services, software solutions or data-related services from the scope of the DORA. On October 1, 2024, the trade and interest associations FIA, AFME, EACH, ECSDA and FESE issued a joint statement on this topic in which they call on the ESAs to adhere to the view from the Dry Run for the upcoming DORA and to determine as quickly as possible that financial services should not be treated as ICT services for the purposes of the DORA. They also call for clarification that regulated financial services include all services and activities subject to the supervision of a financial services regulator, including any ancillary or delegated services. This call is to be welcomed. Clarification is urgently needed to create legal certainty in the implementation of DORA. Regulated financial firms are already subject to extensive obligations and meticulous supervision with regard to their supervised business activities. Any application of DORA going beyond this would mean additional work and expense, with only a negligible added value in terms of financial market security. However, it remains to be seen how the ESAs will position themselves.

                  I.  https://fin-law.de

                  E. info@fin-law.de

                  The lawyer responsible for questions relating to DORA and IT law at our law firm is Attorney Lutz Auffenberg LL.M. (London).

                  subscribe to Newsletter

                    Contact

                    info@fin-law.de

                    Oct 28, 2024

                    MiCAR and Non-EU CASPs – How Can Crypto Service Providers from Third Countries Do Business in Europe?

                    The European market is also interesting for crypto service providers that are not based in the European Union. Market-leading crypto trading venues from the US or Asia in particular cannot afford not to offer their services to European customers if they do not want to lose their dominant position in the global crypto market in the future. Against this background, crypto service providers from the USA and Asia, but also from Switzerland and the UK, are faced with the question of which opportunities arise for them to be able to offer their crypto services to European customers in the future under MiCAR. In the summer of this year, the European Securities and Markets Authority (ESMA) commented on this topic and further narrowed down the options for crypto exchanges from third countries in particular. Unless a pure reverse solicitation business is to be conducted, in which the crypto service provider must not take any initiative to initiate a business relationship, ESMA recommends to the competent supervisory authorities of the EU member states – in Germany BaFin – that trading platforms for crypto assets from third countries should be required to establish independent European companies under MiCAR, apply for MiCAR authorization with these companies and then run the entire European business through these companies. It shall not be allowed that crypto services be offered in such a way that the European entity merely acts as an intermediary between European customers and companies from a country outside the European Union and the actual service is ultimately provided outside the EU.

                    MiCAR License Not for Mere Brokerage Entities of Crypto Service Providers from Third Countries

                    According to the MiCAR regulations, only applicants from the EU that are based in the European Union can receive authorization for crypto asset services. In this way, the legislator aims to ensure that crypto services in Europe can only be provided in compliance with the MiCAR rules. In this respect, ESMA sees the risk that crypto service providers from third countries could set up a mere shell company in Europe in order to use this company to apply for MiCAR authorization for brokerage services such as the execution of orders for crypto assets for clients or the acceptance and transmission of orders for crypto assets for clients. This company would then broker or transmit business with European clients to a trading venue for crypto assets for clients operating outside the scope of MiCAR once the requested MiCAR authorization has been granted. The strict compliance obligations for trading platforms for crypto assets under MiCAR could thus be circumvented, which in ESMA’s opinion would have significant disadvantages for consumer protection in the European Union’s crypto market. ESMA therefore advises BaFin and the competent supervisory authorities to examine in the MiCAR authorization procedure whether such a constellation exists and, if necessary, not to grant the requested authorization.

                    ESMA Advises Careful Case-by-Case Examination and Cites Indications of Unlawful Client Solicitation

                    Ultimately, ESMA advises the competent national supervisory authorities, including BaFin, to carry out a careful case-by-case examination to clarify whether a case constellation should ultimately be interpreted in such a way that crypto services subject to authorization under MiCAR are ultimately offered to European clients from a third country. However, it must be taken into account in this examination that MiCAR itself does not prohibit crypto service providers from executing customer orders on trading platforms or other traders in third countries. Only if the overall design suggests that the provider from the third country is targeting European customers in violation of the MiCAR authorization requirements in order to circumvent the strict supervisory obligations of MiCAR should, in ESMA’s opinion, a refusal of authorization be considered. Even if it is always a case-by-case assessment, ESMA formulates a number of constellations that may indicate an unlawful arrangement in individual cases. In particular, competent national supervisory authorities should examine whether a broker authorized in the EU systematically routes client orders to a company outside the EU for execution. It should also be taken into account whether an EU broker analyzes client orders before forwarding them and checks whether other suitable execution venues could be considered. According to ESMA, a further indication may exist if an EU broker uses the brand of a non-EU provider to attract clients, provided that it is difficult for clients to differentiate that the broker’s services are being used and not those of the non-EU provider. Finally, according to ESMA, it is an indication of an abusive arrangement if the broker authorized in the EU receives remuneration for its services that is not in line with the market and is too low.

                    Attorney Lutz Auffenberg, LL.M. (London)

                    I.  https://fin-law.de

                    E. info@fin-law.de

                    The lawyer responsible for the application for MiCAR authorization and opportunities for crypto service providers from third countries to enter the European market in our law firm is Attorney Lutz Auffenberg, LL.M. (London).

                    subscribe to Newsletter

                      Contact

                      info@fin-law.de

                      Oct 21, 2024

                      Cyber Resilience Act – What Obligations Will Manufacturers of Products with Digital Elements have in Future?

                      The topic of cybersecurity is increasingly becoming the focus of European legislators. On 10 October 2024, the Council of the European Union adopted the Regulation on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020. This so-called Cyber Resilience Act (CRA) is intended to establish a uniform legal framework for basic cybersecurity requirements for placing products with digital elements on the Union market. To this end, vulnerabilities resulting from a low level of cybersecurity and the inadequate provision of security updates are to be remedied. It also aims to address users’ lack of understanding and limited access to information to enable them to select and safely use products with appropriate cybersecurity features. Unlike other directives and regulations that have recently been adopted to strengthen IT security – such as the DORA Regulation – the Cyber Resilience Act is not sector-specific in its scope of application, but horizontal and is intended to cover all products with digital elements. The regulation will apply from November 2027. Reporting obligations for vulnerabilities and security incidents will already apply from August 2026. The obligations imposed on manufacturers, importers and retailers are extensive and the penalties for non-compliance with the legal requirements are severe. According to the motto ‘trust is good, control is better’, market participants will be forced by the GDPR, as they were years ago, to initiate all measures necessary to comply with the obligations under the CRA. What should the addressees of the regulation, such as manufacturers, be prepared for?

                      Who is Considered a Manufacturer Under the CRA?

                      A manufacturer within the meaning of the CRA is a natural or legal person who develops or manufactures products with digital elements or who has products with digital elements designed, developed or manufactured and markets them under his own name or brand, whether in return for payment or free of charge. A product with digital elements is a software or hardware product and its remote data processing solutions, including software or hardware components, which are to be marketed separately. This includes products with digital elements whose intended or reasonably foreseeable use involves a direct or indirect logical or physical data connection to a device or a network. This can be anything from software, PCs and smartphones to robotic vacuum cleaners that can communicate with other devices or networks. For the manufacturers of such products, the range of new obligations is extensive and can therefore only be mentioned in part here. Among other things, before placing a product with digital elements on the market, they must prepare technical documentation in accordance with the CRA and carry out a conformity assessment procedure or have one carried out in accordance with the requirements of the regulation. An EU declaration of conformity must then be issued and a CE marking affixed to the product. After placing the product on the market and during the expected lifetime of the product or for a period of five years from placing a product with digital elements on the market, whichever is shorter, manufacturers must ensure that the product remains CRA compliant (updates). In addition, the manufacturer must notify the European Union Agency for Cybersecurity (ENISA) of any actively exploited vulnerability contained in the product with digital elements without undue delay and in any event within 24 hours of becoming aware of it.

                      What Sanctions do Manufacturers Face if they Violate the CRA?

                      For the imposition of sanctions, the CRA provides that member states must adopt provisions on sanctions and take all measures necessary for the enforcement of the sanctions. The fines provided for by the CRA range from EUR 15,000,000 or – in the case of companies – up to 2.5% of the total worldwide annual turnover of the previous financial year, whichever is higher, for non-compliance with essential requirements or the above-mentioned producer obligations. Fines of up to EUR 10,000,000 or, in the case of companies, up to 2 % of the total worldwide annual turnover in the preceding financial year, whichever is higher, may be imposed for infringements of other obligations under this Regulation. If false, incomplete or misleading information is provided to notified bodies and market surveillance authorities in response to their request for information, fines of up to EUR 5,000,000 or – in the case of companies – up to 1% of the total worldwide annual turnover of the previous financial year, whichever is higher, will be imposed. It is therefore strongly advisable to comply with the requirements of the CRA and to implement them in a timely and conscientious manner.

                      FIN LAW

                      I.  https://fin-law.de

                      E. info@fin-law.de

                      The lawyer responsible for questions relating to the Cyber Resilience Act, DORA and IT law at our law firm is Attorney Lutz Auffenberg, LL.M. (London).

                      subscribe to Newsletter

                        Contact

                        info@fin-law.de

                        to top