Search Results

Many Web3 projects and individuals earn fees for introductions, referrals, and deal sourcing. In the European Union, the legal question is when an “introducer” crosses into regulated intermediation under MiFID II or MiCA. MiFID II: when an introduction becomes an investment service MiFID II Article 5 requires authorisation for investment services. “Investment advice” is a personal recommendation on transactions in financial instruments (Article 4(1)(4)). Annex I lists the key services for introducers. The most relevant are reception and transmission of orders, execution of orders, placing, and investment advice. A referral model enters MiFID II territory when the introducer does more than general marketing. Common trigger points are: taking a client instruction to buy or sell, then passing it onward. negotiating price, size, timing, or settlement for a client. giving a client-specific recommendation on a financial instrument token. arranging placements for an issuer and charging a transaction-linked fee. acting as an external sales channel for an authorised firm. MiFID II also provides a route for “tied agents.” A tied agent acts for one authorised investment firm. The authorised firm bears full responsibility (Article 4(1)(29)). Member States set tied-agent registration and supervision rules (Article 29). MiCA: when an introduction becomes a crypto-asset service MiCA Article 59 prohibits providing crypto-asset services in the Union without authorisation. The provider must be established in a Member State. MiCA defines a list of “crypto-asset services” (Article 3(1)(16)). For introducers, the most sensitive services are: reception and transmission of orders for crypto-assets on behalf of clients. execution of orders for crypto-assets on behalf of clients. placing of crypto-assets. exchange of crypto-assets for funds or for other crypto-assets. advice on crypto-assets. MiCA also covers custody and administration, operation of a trading platform, portfolio management, and transfer services. MiCA uses functional definitions. “Reception and transmission” covers receiving an order and passing it to a third party for execution. “Placing” covers marketing crypto-assets to purchasers on behalf of an offeror. “Advice” covers a personal recommendation to a client. Non-custodial design reduces custody exposure. It does not remove authorisation risk. Order handling, execution, placing, or personal recommendations can still trigger MiCA. Third-country firms and “exclusive initiative” under MiCA An offshore entity does not, by itself, remove EU exposure. MiCA Article 61 allows third-country service only at the client’s own exclusive initiative. Solicitation or promotion in the Union can defeat that route. Article 61 also limits follow-on services to the same type of service and the same provider. Case study: introducer + non-custodial interface A company incorporated offshore runs a crypto-only, non-custodial interface for professional counterparties. Users connect their own wallets. The interface shows third-party protocol yields. Users interact directly with external protocols. The company holds no client keys or fiat. The company earns fees from partner referrals and introductions. It also applies access controls and geo-blocking in selected jurisdictions. If the curated opportunities involve financial instrument tokens, MiFID II becomes primary. A “deal introduction” can become “placing” or “investment advice.” That risk rises with client-specific steering and deal execution involvement. A transaction-linked success fee can support an inference of intermediation. If the activity involves MiCA crypto-assets, the question is whether the company provides a MiCA service. Referral codes and general marketing often sit outside authorisation. This requires no order reception, order routing, execution, placing, or advice. The risk rises where the introducer curates gated dealflow and actively solicits participation. Work delivered in the case study included: mapping the full service flow against MiFID II and MiCA definitions. classifying tokens and activities by regime and perimeter. drafting referral and introduction terms with clear activity limits. reviewing EU targeting signals and third-country “exclusive initiative” controls. preparing a licensing or partnering path where the business model required regulated services. Offshore structuring: what it solves, and what it does not Offshore centres vary. Some impose licensing or registration for digital asset services. Bermuda restricts carrying on “digital asset business” in or from within Bermuda without a licence. The British Virgin Islands restricts providing a “virtual asset service” in or from within the Virgin Islands without registration. The Bahamas’ Digital Assets and Registered Exchanges Act, 2024 sets a registration regime for digital asset businesses. The BVI Act also deems certain BVI companies to be carrying on from within the territory. Offshore incorporation can help with corporate administration and contracting. It does not neutralise EU rules for EU-facing operations. EU supervisors look at where the service is provided and how it is promoted. EU-facing indicators include EU staff, EU-targeted marketing, and EU client onboarding. Indicators also include EU payment rails and EU events. Where these indicators exist, the licensing risk usually remains. The practical options are to stay outside the regulated service definitions, or move regulated functions into an authorised EU entity or partner. Prokopiev Law Group can advise on mapping introducer activity to MiFID II and MiCA, drafting referral and introduction terms, and designing an offshore/EU operating split. Contact us to review your service flow, fee mechanics, marketing footprint, and EU nexus. The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

The legal question: how can a tokenized real‑world asset (RWA) financing program for operating manufacturing facilities be structured so each investor contracts with the specific facility pool that owns and finances the facility assets, while a protocol-level entity coordinates issuance and voting mechanics across multiple facilities? This case study describes an implementation using a Republic of the Marshall Islands decentralized autonomous organization limited liability company (RMI DAO LLC) as the protocol entity, paired with separate SPV LLCs for each investment pool holding EU and Middle East manufacturing assets. “ Platform DAO LLC ” means the RMI DAO LLC that holds protocol IP, runs the on-chain contracts, and provides administrative services, but does not hold facility assets. “ Pool SPV ” means an LLC formed for one investment pool that (i) holds title to defined facility assets (directly or via a wholly owned local asset-holding company) and (ii) is the lender or equity holder that directly funds the facility owner or operator. “ Direct investor–asset privity ” means the investor’s contractual counterparty is the Pool SPV that owns or controls the financed facility asset package, not a protocol treasury or a multi-asset holding company. Deal objective The client’s objective was ring‑fenced, asset-by-asset exposure to operating manufacturing facilities in EU Member State(s) and Middle East jurisdiction(s). Investors required a direct contractual relationship to the specific financed facility pool, with no cross-collateralization across facilities and no reliance on a protocol balance sheet. The operating reality included asset-level diligence (title, permits, equipment registries), facility-level cash flows, and local-law security packages that had to attach to identified assets. Entity stack The structure used four legal layers, each with a single job: Platform DAO LLC (RMI): protocol IP owner and administrator, with on‑chain voting and transfer controls. Pool SPV (LLC): one SPV per investment pool, the investor counterparty and the facility finance counterparty. Local AssetCo / OpCo (EU or Middle East): the local company that holds site permits, runs operations, and employs staff. Security and cash controls: local-law mortgages/pledges and controlled bank accounts tied to each Pool SPV. Platform DAO LLC The Republic of the Marshall Islands DAO Act treats a DAO as a domestic LLC formed under the Marshall Islands LLC statute, with DAO-specific formation and operating requirements. The Platform DAO LLC used that statute to tie the legal entity to its on‑chain control layer. DAO entity law also matters for transfer controls. The company agreement and the on-chain logic were drafted as one system. For a multi‑facility program, that requirement supported a clean separation between the Platform DAO LLC (technology and administration) and the Pool SPVs (asset exposure). Investor identity and beneficial ownership data for a pool lived at the pool level, not in a protocol-level omnibus ledger. Pool SPVs Each investment pool was placed into its own Pool SPV LLC. The Pool SPV, not the Platform DAO LLC, executed the asset purchase and the facility finance documents. Investors subscribed directly into the Pool SPV. The Pool SPV’s operating agreement (or, where used, note terms) governed distributions, reporting, voting on major actions, and liquidation priorities. Facility ownership and financing followed a single rule: the Pool SPV had to be the legal titleholder of the facility asset package or the legal owner of the local company that held title. The choice depended on local restrictions on foreign ownership, licensing, and land registration. Where local law allowed direct foreign ownership, the Pool SPV acquired title to the facility real estate and key equipment and then leased them to the operating company. Where local law required local holding, the Pool SPV owned 100% of a local AssetCo that held title and entered the lease with the OpCo, and the Pool SPV held a share pledge over AssetCo plus a package of contractual covenants. “Direct financing” in this project meant the Pool SPV was the named lender or equity investor on the facility documents, with proceeds wired from the Pool SPV’s controlled bank account to the seller, contractor, or operating company. The security package was asset-specific and recorded under the situs law of the asset. Components typically included: a mortgage over real property, pledges over equipment where registrable, a share pledge over the local holding company, and an assignment of key receivables or insurance proceeds (each subject to local perfection rules). Investor legal connection to the facility The investor signed (i) a subscription agreement with the Pool SPV and (ii) the Pool SPV operating agreement (or note instrument) as the source of economic rights and enforcement rights. The Pool SPV then held the asset title or the shareholding that controlled the titleholder. Investors were not unsecured creditors of the Platform DAO LLC. The structure also separated “protocol participation” from “asset exposure.” The Platform DAO LLC could issue a protocol token for voting on protocol parameters and service fees. The Pool SPV issued a separate pool interest tied to one facility pool. A pool interest transfer required pool-level compliance checks because the pool interest carried the investor’s rights against the asset-holding SPV. Cross-border limits and edge cases Ring-fencing depends on separateness in fact. Each Pool SPV had its own bank account, accounting, resolutions, and service contracts. Intercompany agreements with the Platform DAO LLC were priced and documented. The Pool SPV did not guarantee protocol obligations, and the Platform DAO LLC did not guarantee pool obligations. Series structures were evaluated and rejected for cross-border assets. Many non‑US jurisdictions do not treat a series as a separate legal person for title and insolvency purposes. Separate Pool SPVs give cleaner asset title and cleaner enforcement, at the cost of more entity maintenance. Tokenholder voting has limits. A lender’s decision to accelerate a loan, enforce a mortgage, or replace a plant operator can trigger local-law duties and sometimes court processes. The drafting split voting into (i) investor direction on defined “major decisions” and (ii) day‑to‑day execution by a manager with signing authority, subject to conflicts rules and reporting covenants. Foundation or trust wrapper as an alternative to a DAO LLC A non-DAO top tier can replace the Platform DAO LLC without changing the pool architecture. Two common alternatives are a foundation or a trust. Under a foundation structure, a foundation holds the protocol IP, appoints administrators, and contracts with service providers. The foundation has no shareholders. Control sits with its council (or equivalent organ) and any protector/guardian mechanism the statute permits. Tokenholder voting can be drafted as a direction right or as an advisory input to the council, depending on how much on-chain control the council is willing to accept without violating statutory duties. Under a trust structure, a trustee holds the protocol IP and related rights on trust for defined beneficiaries or for a defined purpose, under an applicable trust statute. Legal title sits with the trustee. Control flows through trustee duties, the trust deed, and any protector or enforcer role. Tokenholder voting can be tied to beneficiary directions if the trust deed allows it, with trustee discretion carved to preserve fiduciary compliance. The foundation/trust choice changes bank onboarding, liability allocation, and enforcement mechanics. A foundation gives a single legal person as counterparty for protocol-level contracts. A trust gives contractual control through trustee duties, but the trustee remains the titleholder. Neither choice changes the core investor protection in this case study because investors still contract directly with the Pool SPV that owns and finances the facility assets. Prokopiev Law Group advises sponsors and operators on RWA manufacturing structures, including RMI DAO LLC formation, SPV pool documentation, cross-border offering controls, and the foundation/trust alternative for protocol ownership and administration. Contact our team to scope an entity stack and document set for a specific facility pipeline. The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

This case study documents the legal-structural implementation we executed for a protocol development client preparing a public token sale contemporaneous with mainnet launch. The engagement objective was to construct a governance-credible and operationally separable architecture in which ecosystem stewardship, sale execution, and commercial development operations were isolated into distinct legal entities, with defined authority boundaries, traceable funds flows, and publication-grade disclosure outputs. Step 1 — Define the system boundary and token functions.  The project defines a public blockchain network and a native Token intended for validator staking within the consensus design, payment of network transaction fees, and participation in protocol change mechanics through validator delegation and client software adoption. The Token is treated as a network utility asset whose operative functions are limited to the protocol’s technical and economic design, with the sale timed near public network launch and delivery planned around launch. Step 2 — Partition stewardship, sale execution, and commercial build work.  The legal architecture separates long-lived stewardship and ecosystem spending from the token sale contracting party and from the employer that builds software. The steward entity holds treasury responsibilities, grants, delegations, and program spending; the seller entity signs the sale documentation and carries sale-specific contractual exposure; the builder entity employs staff, contracts vendors, and performs engineering work under a paid services mandate. Step 3 — Constitute the steward entity as a memberless foundation company.  The project forms FoundationCo as a memberless Cayman Islands foundation company and appoints a board that acts as the decision node for treasury policy, delegation programs, ecosystem incentives, and high-value contractual commitments. The internal rules describe approvals, signatories, conflicts, custody controls, and public communications channels, with the operating intent fixed on network development support, decentralization, security posture, adoption programs, education, and ecosystem outreach. Step 4 — Constitute the seller entity as a controlled subsidiary.  The project forms IssuerCo as a British Virgin Islands company, controlled by FoundationCo, and uses that subsidiary as the contracting counterparty for the exchange-run token sale portal. Control is expressed through corporate governance instruments and board resolutions that allocate signing authority for sale documentation, custody arrangements, and token delivery mechanics while reserving treasury-risk decisions to FoundationCo’s board. Step 5 — Constitute the builder entity as a for-profit operating company.  The project forms or maintains DevCo as a for-profit corporation that hires engineers and contractors, engages auditors and security vendors, and maintains the core client codebase. DevCo runs payroll and standard commercial operations, and it acts as the operational locus for software development, research, documentation, and tooling that support the network’s launch and ongoing maintenance. Step 6 — Fix the intercompany services boundary in a development services agreement.  FoundationCo and DevCo execute a written development services agreement that defines deliverables, milestones, acceptance criteria, payment terms, and termination rights, with compensation described as arm’s-length professional services fees. The agreement assigns responsibility for confidentiality, security controls, incident handling, and dependency management, and it states the IP path for new code contributions and contributor assignments, either into DevCo with a license to FoundationCo or directly into FoundationCo, with one path chosen and applied consistently. Step 7 — Define treasury funding flows between builder and steward.  The structure states how FoundationCo will obtain cash runway for staffing, vendors, and ecosystem programs, including a donation or grant from DevCo or another funding source that covers operating expenditures into a defined period. The funding instrument is documented with scope, permitted uses, reporting expectations, and board approval thresholds, and it remains distinct from any token sale proceeds, which follow sale-specific controls. Step 8 — Specify token non-rights and the separation from equity.  The Token terms state, in plain contractual language, that the Token does not represent equity, ownership, or profit-sharing rights in FoundationCo, DevCo, or any other organization, and it does not confer entitlement to protocol revenue. The structure treats equity in DevCo and the Token’s economic and functional profile as separate instruments with separate value drivers, and the disclosure package keeps that separation explicit and repeated wherever purchaser expectations could drift. Step 9 — Fix the initial token supply map and release mechanics.  The project allocates the initial supply across ecosystem development, team, investors, public sale, builder treasury, and community distributions, with an explicit distinction between tokens that are unlocked at launch and tokens that remain locked under time-based schedules. The lock design can include an initial one-year lock for team and investors, followed by scheduled releases over multiple years, and it can restrict staking for locked balances so early staking rewards flow into public circulation rather than concentrating among insiders. Step 10 — Bind the public sale to the seller entity and the sale portal’s mechanics.  IssuerCo signs the portal agreement, accepts portal eligibility gating, and publishes the sale terms that define the sale window, fixed price, maximum offered tokens, minimum and maximum purchase amounts, allocation mechanics under oversubscription, and delivery timing tied to network launch. The purchaser relationship is formed through the portal’s onboarding and the seller’s sale terms, and the seller document states that the portal operator does not supply or vouch for the seller’s disclosure content. Step 11 — Describe oversubscription allocation as a deterministic procedure.  The sale documentation describes a fill procedure that allocates first to the smallest unfilled requests and iterates upward until supply exhausts, then splits any remainder evenly among still-unfilled purchasers. Step 12 — Define proceeds flow, custody segmentation, and internal controls.  The funds flow specifies that purchasers pay through the portal, the portal remits net proceeds to IssuerCo, and IssuerCo transfers proceeds into FoundationCo under a treasury policy approved by FoundationCo’s board, with defined retention for sale-related liabilities where needed. Treasury operations use segregated wallets for sale inventory, ecosystem allocations, market-maker loan inventory, and operating spend, with multi-signature controls and recorded approvals for transfers, grants, and delegations. Step 13 — Contract for initial liquidity support through token loans and monitoring.  If the project uses professional market makers, IssuerCo enters token loan agreements that define loan size, term, permitted trading conduct, return obligations, and early termination triggers, with a third-party monitoring specialist tracking the use and idle balances of loaned tokens. The documentation can also allow a limited, short-duration provision of initial DEX liquidity from a capped fraction of initial supply, with explicit treatment of those tokens as part of the ecosystem allocation rather than part of the public sale tranche. Step 14 — Publish a disclosure package that matches the legal and operational map.  The seller publishes a disclosure document that covers project information and core contributors, the sale terms and purchaser eligibility gating, token functions and token non-rights, the allocation table and locked/unlocked status at launch, release schedules for locked categories, community distribution mechanics, conflicts statements regarding related-party token transactions, liquidity support arrangements, security posture including audits and open-source repositories, and a risk section that addresses sale execution, entity limitations, token trading liquidity, technology risk, and jurisdictional restrictions. Prokopiev Law Group can implement the same token sale legal structure for your project, or tailor the architecture, documentation stack, and disclosure framework to your specific commercial, technical, and jurisdictional requirements. We coordinate a global network of counsel and service providers to support multi-jurisdiction execution from formation through launch and post-launch governance. The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

Blockchain (a type of distributed ledger) is designed as a distributed, tamper-resistant, and transparent  data structure with no centralized control. Transactions are grouped into blocks cryptographically chained together, and a consensus mechanism  (e.g. proof of work or proof of stake) ensures all nodes agree on the valid state. These properties— decentralization  (many participants replicate data), immutability  (once recorded, data cannot be altered without detection), and transparent access  to ledger data—present novel compliance challenges under the GDPR. For example, once personal data is written to an append-only blockchain, it cannot be individually deleted or modified  without undermining the ledger’s integrity. The lack of a centralized controller  and the presence of numerous independent participants mean there is no single entity that can easily remove or edit data across all copies of the ledger. This immutability conflicts with GDPR requirements like the right to erasure and rectification, and calls into question how to enforce storage limitation  on data that might persist for the life of the blockchain . The decentralized governance  of many blockchains also complicates accountability: participants may be in different jurisdictions and not bound by a common contract, making it difficult to ensure that personal data is used only for the specified purpose and not further processed incompatibly. Additionally, blockchains often make transaction data visible  (at least to participants or even publicly in open chains), so any personal data (or identifiers) stored on-chain are broadly accessible, raising concerns under the principles of confidentiality and transparency. Many blockchains support smart contracts , which are self-executing programs recorded on-chain. Smart contracts can embed personal data in their code or transactions and can autonomously trigger actions affecting individuals. The EDPB notes that execution of smart contracts might amount to solely automated decision-making  with legal effects, thus invoking GDPR Article 22 – requiring human intervention  and contestation rights if such decisions significantly affect data subjects. In summary, fundamental blockchain features like decentralization and immutability provide integrity and availability guarantees  through cryptography and consensus, but they inherently clash with certain GDPR principles and rights. The guidelines stress that these technological traits do not exempt  controllers from GDPR compliance: they must instead be addressed through careful design and governance measures. Controllers should thoroughly assess  whether a blockchain solution is appropriate and can be configured to meet data protection requirements before using it for personal data processing. Personal Data in Blockchain Systems A critical step is determining what data in a blockchain constitutes personal data . Blockchains record transactions that typically include a set of metadata  (e.g. timestamps, cryptographic public keys or addresses, and other technical details) and a payload  (the content of the transaction). Even if the blockchain uses pseudonymous identifiers (like hashed public keys that appear as random strings), these can qualify as personal data if they relate to an identifiable individual . The EDPB confirms that a public key or account address will be considered personal data whenever it can be linked to a natural person by means “reasonably likely to be used” (for instance, by correlation in the event of a data breach or through off-chain data). In many blockchain networks, participants’ addresses are always visible to all nodes  to allow transaction validation, and even if they do not directly reveal a name, they may be indirectly identifiable (especially when combined with external information or if a user reuses an address). Thus, seemingly anonymous on-chain identifiers are often pseudonymous personal data , falling under GDPR scope. Moreover, the payload data  itself can include personal data. For example, a transaction might encode an individual’s name, a contract with personal terms, or references to documents about a person. Smart contract interactions could record details about a user’s activities or assets, and even if the smart contract’s code is public, any personal data written into the contract’s state or logs would be stored on-chain. The guidelines emphasize that any  personal data stored on-chain – whether in transaction fields, smart contract storage, or account balances – is subject to GDPR. Additionally, when individuals interact with blockchain systems, off-chain data processing  often occurs in the surrounding ecosystem. For instance, a user’s blockchain wallet software or a decentralized application (dApp) may collect device identifiers or IP addresses  when connecting to the network, or third-party blockchain explorers may log user queries – all of which can be personal data even though they are not recorded on the chain itself. These auxiliary data flows must also be accounted for by controllers. Storing personal data on-chain is inherently risky  from a data protection perspective. The EDPB’s general rule is that controllers should avoid putting personal data on the blockchain unless strictly necessary , because doing so makes it difficult to comply with core principles. In particular, storing personal data in plaintext (unencrypted) form on a public ledger  is considered highly problematic and “strongly discouraged” due to conflicts with Article 5 principles like data minimization, purpose limitation, and storage limitation. If personal data must  be processed in a blockchain use-case, the guidelines advocate for data protection by design  strategies to minimize on-chain data: e.g. keeping personal data off-chain  and only referencing it via pseudonymous pointers or cryptographic hashes on-chain. By limiting the exposure of personal details on the immutable ledger, controllers can maintain greater control – off-chain data can be modified or deleted when needed, while the blockchain only stores a non-identifying commitment or link. Several advanced privacy-preserving techniques (discussed later) enable this kind of separation. The EDPB also notes emerging zero-knowledge proof  architectures, where cryptographic proofs allow validation of transactions or identities without revealing the underlying personal data  on-chain. Such approaches (often termed “zero-knowledge blockchains”) illustrate that it is possible to leverage blockchain features while drastically reducing on-chain personal data disclosure, though they require complex cryptographic implementations. Roles and Responsibilities of Blockchain Participants GDPR compliance requires clearly defining the roles of all actors  involved in processing. In blockchain networks, the decentralized governance model  leads to a multiplicity of stakeholders (e.g. node operators, miners/validators, developers of a blockchain platform or smart contracts, users submitting transactions, etc.), which makes assigning the traditional roles of controller  and processor  complex. The EDPB reaffirms that using a particular technology or a distributed setup does not remove the need  to identify responsible parties under GDPR. In fact, controllers must perform a careful, case-by-case analysis of who determines the purposes and means of each personal data processing operation on the blockchain. The standard GDPR definitions apply: a controller  is the entity (alone or jointly with others) that decides why and how personal data are processed, whereas a processor  processes personal data on behalf of a controller (under its instruction). These roles must be mapped onto the specific blockchain architecture and governance structure in question. The guidelines stress that this allocation should follow the factual influence and decision-making power  of actors, in line with the accountability principle. Relevant factors include the nature of the service or application using the blockchain, the governance and rules of the blockchain network, the technical capacity of participants to influence data processing, and any contractual arrangements between parties. Permissioned vs. permissionless  blockchain design has a significant impact on roles. In a permissioned blockchain  (closed or consortium network), a designated authority or a consortium of entities controls who can participate as a node. This setup inherently offers a clearer allocation of responsibilities , since the governing entity (or entities) can be identified and held accountable as controllers for the on-chain processing. The EDPB explicitly recommends that organizations favor permissioned blockchains  for personal data use, given that a central managing party can enforce compliance and there is less ambiguity about who is responsible. Only if there are well-justified reasons why a permissioned model is not feasible should controllers explore more decentralized alternatives – and even then, they should question whether using blockchain at all is appropriate if it impedes accountability. By contrast, in public permissionless blockchains , anyone can become a node and the network is maintained by a diffuse community without a single point of control. Here, participants are not all equal in function, and their GDPR roles depend on their activities and influence. The guidelines explain that in some blockchain systems, individual nodes might have a very limited role : for example, merely relaying and validating transactions against fixed rules  without exercising meaningful discretion. If a node simply follows the protocol (e.g. checks digital signatures, ensures transactions meet technical criteria, and includes them in blocks without any preference or purpose of its own), that node might not  be considered a controller of personal data, since it is not deciding the purpose or essential means of processing but acting in a minimal, automatic capacity. (Likewise, such a node is generally not a processor either, because it’s not acting on behalf of a known controller under instructions – it’s just participating in a distributed consensus.) On the other hand, many nodes in permissionless networks do exert influence  over personal data processing. For instance, miners/validators choose which pending transactions to include in a block, can decide to fork the blockchain , or otherwise change how data is processed for their own objectives. In doing so, they may effectively determine how and when  certain personal data is recorded on the ledger (which transactions get confirmed) and potentially even why  (if, for example, they prioritize certain transactions for economic gain or policy reasons). The EDPB states that such nodes can qualify as controllers or joint controllers  if they “exercise a decisive influence” over the purposes and means of the processing. This could be individually (a miner deciding a transaction’s inclusion, affecting that data subject’s processing) or collectively (nodes agreeing to alter the protocol rules, which changes how all personal data is handled). Importantly, in truly decentralized scenarios, nodes are not  acting “on behalf” of another entity; they pursue their own goals within the network, so they cannot be considered mere processors taking instructions. The EDPB strongly encourages that, in such cases, the participating entities formalize their roles through a consortium or similar legal entity  to serve as the identifiable controller for the blockchain processing. By creating an overarching legal structure, the various node operators can share obligations as joint controllers, which helps ensure accountability despite the distributed setup. In summary, the guidelines call for clarity of roles : every blockchain project involving personal data should document who the controller(s) is (e.g. the platform operator, the consortium of participants, and/or application providers using the chain) and which parties, if any, act as processors. Joint controllership arrangements are likely when multiple parties together define the data processing purposes (for example, co-developers of a blockchain service, or consortium members each contributing data and determining its use). All such arrangements remain subject to GDPR Article 26 (joint controller requirements) or Article 28 (controller-processor contracts) as appropriate. Even in permissionless public networks with no formal governance, participants cannot escape GDPR liability simply by pointing to the lack of central control – organizational and contractual measures  should be put in place to allocate responsibilities wherever possible. Lawfulness of Processing and Legal Bases Any processing of personal data on a blockchain must have a valid legal basis  under GDPR Article 6. The EDPB makes clear that there is no blanket legal basis  that automatically applies to all blockchain operations; controllers must determine the appropriate basis for each specific processing purpose  in their blockchain use-case. For example, recording personal data on a ledger for a decentralized identity system might be based on the user’s consent , whereas processing personal data on a supply-chain blockchain might rely on legitimate interests  or contractual necessity , depending on the context. The key is that the choice of legal basis must align with the purpose of processing and meet all the conditions for that basis. If the blockchain processing includes special category data  (GDPR Article 9(1) data, such as health, biometric, or political opinion data), then an Article 9(2) exception is required in addition  to an Article 6 basis. For instance, a blockchain that stores medical records would need an explicit consent of the data subjects or another specific derogation under Article 9(2) to process health data. The guidelines note that multiple legal bases might be available in a given scenario, but controllers must carefully assess which basis is valid and most appropriate  given the context and ensure they can fulfill the obligations that come with it. Consent  (Article 6(1)(a)) is a potential legal basis in blockchain, but the EDPB issues strong caveats about its use. If consent is chosen, it must be fully compliant with GDPR’s definition and standards: truly freely given, specific, informed, and unambiguous , with a clear affirmative action by the data subject. Due to the irreversibility of blockchain entries, a critical issue is the data subject’s ability to withdraw consent . GDPR requires that consent can be withdrawn at any time, and if a processing was based on consent, the data must stop being processed (and ideally be deleted or anonymized) once consent is withdrawn. The guidelines underline that if personal data was stored on-chain under a consent basis, that data “must be deleted or rendered anonymous” if consent is later withdrawn . This presents a serious challenge: since blockchains do not easily allow deletion, any controller relying on consent must have a technical plan to effectively remove or irrevocably anonymize the data upon withdrawal. For example, if personal data was encrypted on-chain with the data subject’s consent, the controller should be prepared to delete the decryption key (rendering the on-chain data unintelligible) if consent is withdrawn. Without such measures, consent would not be considered valid because the data subject wouldn’t have a genuine choice to discontinue processing without detriment. In practice, this means consent is often not  a suitable basis for immutable on-chain processing, unless the system is designed such that consent withdrawal triggers effective erasure (through key revocation, etc.). The EDPB also reminds that consent does not override other GDPR requirements  – even with consent, all principles (data minimization, purpose limitation, security, etc.) and rights must still be respected, and consent cannot be “forced” by making the service conditional unless necessary. Other legal bases may be more appropriate for blockchain solutions. Contractual necessity  (Article 6(1)(b)) could apply if the processing is genuinely required to fulfill a contract with the data subject – for example, using a blockchain to execute a smart contract that a user has entered into. However, this basis is narrowly interpreted and only covers processing that is objectively necessary for the contractual service requested by the data subject. A related basis, legal obligation  (Art 6(1)(c)), might be relevant if a law mandates  using a blockchain for certain record-keeping (though such scenarios are rare; more often, blockchain is a choice of technology rather than a legal requirement). If a blockchain is used to comply with a legal obligation (say, a governmental transparency ledger required by law), that law could also justify restrictions on certain data subject rights under Article 23 GDPR. The guidelines give examples like anti-money-laundering (AML) applications or land registries: if Union or Member State law requires certain data be kept on an immutable ledger, that law may lawfully restrict rights like erasure, as long as the Article 23 conditions are met. In those cases, the legal basis might be Art 6(1)(c) or (e) (public interest or official authority) combined with a statutory restriction on deletion rights. Controllers must ensure any such restriction is provided by law, necessary, and proportionate. A commonly cited basis for blockchain processing is legitimate interests  of the controller or a third party (Article 6(1)(f)). Indeed, many private-sector blockchain uses (e.g. maintaining a distributed ledger of transactions for system integrity or efficiency) might invoke the legitimate interests ground. The EDPB emphasizes that using Art 6(1)(f) requires a careful three-part test : purpose test  (the interest being pursued must be legitimate and lawful), necessity test  (processing must be necessary for that purpose), and balancing test  (the interests of the controller versus the fundamental rights and interests of data subjects). In a blockchain context, controllers must evaluate whether their interest (for example, having an immutable, distributed record) is proportionate to the impact on data subjects (permanent storage of their personal data, global access, potential lack of control). The guidelines refer to EDPB’s earlier guidance on Art 6(1)(f), underscoring that if the detriment to individuals is too great relative to the controller’s aims, legitimate interest cannot be relied on. Notably, data subjects have a right to object  to processing based on legitimate interests (as discussed later), and if they do, the controller must stop processing unless it demonstrates compelling overriding interests. This means that in a blockchain scenario, using legitimate interests as a basis implicitly requires that the controller be able to cease or restrict processing for an objecting individual  if no override applies – a requirement that again forces consideration of how one would stop processing on an immutable ledger. In summary, no matter which legal basis is chosen, it must be supported by the blockchain’s technical design . For instance, if relying on consent, build the system to allow data removal; if relying on legitimate interests, ensure you’ve minimized data use and can honor objections, and so on. The EDPB’s overarching message is that the choice of technology (blockchain) does not justify lowering GDPR standards  – controllers are expected to adapt the blockchain’s use or design to the law, rather than the other way around. Data Protection by Design: Principles, Minimization and Security Measures Under GDPR Article 25, data protection by design and by default  is crucial when implementing blockchain solutions. The EDPB reiterates that controllers must embed data protection principles into the architecture of the system from the outset, especially given that blockchain’s characteristics make some principles harder to enforce. The guideline stresses that GDPR principles are non-negotiable  – even if blockchain is technically complex, controllers are obligated to find ways to comply effectively. This often requires a combination of innovative technical and organizational measures, carefully tailored to the context, to ensure that principles like data minimization, storage limitation, integrity/confidentiality, and purpose limitation are upheld in practice. Importantly, effectiveness  is at the heart of data protection by design: it is not enough to perform a formal check-the-box exercise; the chosen measures must actually result  in a higher level of privacy and protection for data subjects in the real operation of the blockchain. In other words, controllers should be able to demonstrate that their blockchain implementation achieves compliance outcomes  (e.g. no unnecessary personal data is exposed or retained), not just that they attempted some generic precautions. A primary design strategy is data minimization and storage limitation : avoid putting personal data on-chain whenever possible . The guidelines suggest that many use-cases can be accomplished by storing personal data off the blockchain and only writing references or proofs  on-chain. By minimizing on-chain personal data, one limits the risk of immutable, perpetual exposure. For example, rather than recording a user’s name or full document on-chain, the blockchain could store a hash or a cryptographic commitment  of the data, while the actual personal data stays in a traditional database or under the data subject’s control off-chain. If the personal data needs to be later retrieved or verified, the off-chain source can be checked against the on-chain hash. The EDPB details several privacy-enhancing techniques  to implement this: Strong Encryption:  Personal data can be encrypted before  inclusion in the blockchain, so that only those with the decryption key can read it. This protects confidentiality on a public ledger. Notably, encrypting data does not  remove it from GDPR’s scope (encrypted data is still personal data) and doesn’t absolve the controller of obligations. However, encryption can mitigate unauthorized access. The controller should use state-of-the-art cryptography and manage keys carefully. One advantage in context of erasure is that if a data subject invokes the right to deletion, the controller could delete the decryption key , rendering the on-chain encrypted data indecipherable (a form of “cryptographic erasure”). The guidelines caution, though, that encryption’s protection is time-limited: algorithms can be broken or weakened over time (e.g. by future quantum computing), and since blockchains are meant to last indefinitely, there must be a plan to manage algorithm obsolescence. Controllers should periodically assess the strength of the encryption in use and be ready to upgrade to stronger algorithms or migrate data if needed, especially for sensitive data that must remain confidential for many years. Hashing and Pseudonymization:  Instead of storing personal data in cleartext, a controller can store a hashed value  (with a secret salt or key) on-chain. The actual data and the salt/key are kept off-chain. A well-designed salted hash is effectively a pseudonymous identifier: on its own, the hash doesn’t reveal the underlying data unless  one has the secret or can brute-force guess it. The guidelines note the benefit that if the secret salt/key is later deleted, the on-chain hash becomes practically unlinkable to the original personal data. In that scenario, even though the hash remains on the blockchain, it no longer corresponds to an identifiable person (assuming strong hash and secret), which can serve as a means of compliance with erasure requests. Nonetheless, the EDPB warns that hashing is not a panacea: hashes (especially if unsalted or poorly implemented ) can be reversible via dictionary attacks or re-identification techniques, and even salted hashes are considered personal data as long as the original data or keys exist somewhere. Therefore, storing a hash on-chain still counts as processing personal data, and all GDPR obligations apply (plus the off-chain data storage must be secured and governed). The use of unsalted or static hashes is explicitly deemed insufficient  for confidentiality on a public blockchain – robust, secret salts/keys must be used to prevent inference of the original data. Cryptographic Commitments:  A commitment is similar to a hash but typically provides cryptographic guarantees (like being binding  and hiding ) that can be advantageous. The guidelines describe storing a perfectly hiding commitment  on-chain. “Hiding” means that given only the commitment, nothing can be learned about the original data; and if the scheme is secure, even brute-force attempts yield no information. The data (and any randomness used for the commitment) remain off-chain. Once the off-chain data and “witness” (secret randomness) are deleted, the on-chain commitment is computationally useless – it cannot be opened or linked back to personal data. Thus, commitments offer a way to prove that some data existed or was agreed upon, without  ever revealing the data itself on the blockchain, and later the linkage can be destroyed. This technique supports both minimization and eventual erasure (by dropping the ability to resolve the commitment). As with hashing, using commitments still requires an off-chain storage solution for the actual data and careful key management. Off-Chain Storage with On-Chain Pointers:  Rather than placing even derived data on-chain, controllers can store personal data entirely off-chain (for example, in a secure database or distributed file system) and put only a pointer or reference (e.g. a URL, document ID, or Merkle-tree root)  on the blockchain. The on-chain pointer by itself may or may not be personal data (if it’s just a random locator, it might not identify a person). The principle here is that the blockchain is used only to timestamp or validate the existence of data (the proof of existence ), while the data itself resides elsewhere under more flexible control. If the data needs to be erased or modified, it can be done off-chain, and the on-chain pointer could be updated or de-referenced. The EDPB notes that when using such architectures, confidentiality of the off-chain store is vital (the link between on-chain and off-chain must be protected). Off-chain storage shifts some GDPR burdens off the blockchain itself, but the off-chain processing  is fully subject to GDPR (the controller must secure it, have a legal basis, etc., just like any database). Indeed, using off-chain storage means the overall system now has multiple components (blockchain plus off-chain systems), each of which must be evaluated for compliance and security. In practice, a combination of measures  is often advisable. For example, one might hash personal data and store the hash on-chain, encrypt the personal data off-chain, and distribute the encrypted data among trusted parties or keep it with the data subject. The guidelines acknowledge that achieving adequate data protection in blockchain may require layered solutions and novel privacy-enhancing technologies  used in tandem. They also suggest considering “zero-knowledge” architectures  – e.g. using zero-knowledge proofs or other cryptographic protocols so that nodes can validate transactions without seeing personal data in clear. By limiting data visibility and accessibility , controllers address the GDPR principles: Confidentiality/Integrity (Security)  is maintained by encryption and hashing (Article 32), Data minimization  is respected by only recording what is necessary (and in pseudonymized form) on-chain, and Storage limitation  is tackled by enabling effective removal (via key destruction or off-chain deletion) when data is no longer needed. Despite all these measures, the EDPB reminds controllers that “technical impossibility” is not an excuse for non-compliance . For instance, one cannot simply say “we cannot delete data from the blockchain, so the right to erasure does not apply.” Instead, the system should have been designed to avoid that situation (e.g. by not storing data that would later need deletion, or by using encryption that can be nullified). GDPR expects controllers to anticipate and prevent problems by design . If a particular blockchain architecture makes it impossible to meet a fundamental requirement (like deleting personal data on request), the onus is on the controller to re-evaluate the use of that technology  or adjust the architecture so that compliance can be achieved. In fact, the guidelines bluntly state that if a blockchain’s “strong integrity” feature (immutability) conflicts with data protection needs, controllers should consider using other tools or technologies altogether  rather than blockchain. Data protection by design might mean opting for a permissioned chain  where an admin can intervene in exceptional cases, or using shorter-lived sidechains where data can be phased out, etc., if that’s necessary to honor GDPR principles. Purpose limitation  is another principle worth noting: personal data should be collected for specified, legitimate purposes and not further processed in incompatible ways. Public blockchains pose a challenge here because once data is public on the ledger, anyone  might use it for new purposes beyond the original intent (for example, using blockchain transaction data to profile users’ behavior). The disintermediated nature means participants are not all contractually bound to restrict their use of data. To enforce purpose limitation, a private or permissioned blockchain can impose agreements on participants about how data may be used. In public networks, the best approach is to minimize the data  to begin with (so that even if someone repurposes on-chain data, it reveals little), or use technical controls  like encryption such that unauthorized parties cannot interpret the data. In any case, controllers must define clear purposes  for any personal data they put on a blockchain and ensure that the data is not repurposed in a manner incompatible with those purposes. This ties back into governance: if multiple organizations are involved, they should agree on purpose limitations and document them (e.g. in consortium bylaws or smart contract code that limits data use). Finally, security measures  (integrity and availability, as well as confidentiality) are vital given that blockchain data is widely replicated. GDPR Article 32 obligations apply: controllers and processors must implement appropriate technical and organizational security measures. The blockchain’s inherent design gives some security benefits – data integrity and availability are strong due to the consensus and replication (tampering is detectable and data is redundantly stored). However, confidentiality is not inherent in most blockchains (many are intentionally transparent). Thus, as described above, encryption or pseudonymization is needed to prevent unauthorized access to personal data on-chain. Controllers should also secure the off-chain environments : for instance, nodes should have measures against breaches, keys (like private keys controlling identities or decryption keys) must be protected, and any APIs or wallets handling personal data should be hardened. The EDPB points out that encryption keys and algorithms must be managed over time  – since blockchain data may remain for decades, a plan to update cryptographic measures and handle potential future vulnerabilities (like quantum attacks) should be part of the security strategy. Regular risk assessment of cryptographic strength and contingency plans  (such as re-encrypting data with stronger algorithms or migrating to a new platform) are recommended when the data is sensitive and long-lived. Additionally, since blockchains involve networked nodes, network security  (authenticating nodes, preventing Sybil attacks, DDoS protection, etc.) is relevant to protect the availability and reliability of the processing. The guidelines also mention ensuring access control and traceability  in blockchain applications: for instance, in a permissioned blockchain, limit who can view certain personal data fields, and log access to data for audit. While some of these controls might be unconventional for blockchain, creative implementations (like encryption schemes where only certain roles can decrypt certain data) can achieve a form of access control even in a decentralized setting. In summary, security must be comprehensive , covering on-chain data (through cryptography), off-chain data stores, node infrastructure, and even the metadata  and communications in the blockchain ecosystem (since communication metadata could reveal personal info like who communicated with whom and when). The controller should treat any supporting systems (key management servers, off-chain databases, etc.) as part of the overall processing and secure them to GDPR standards. Data Subject Rights in Blockchain Environments GDPR grants individuals robust rights over their personal data, and the EDPB emphasizes that these rights are technology-neutral  – data subjects do not lose their rights simply because their data is processed on a blockchain. All the usual rights (access, rectification, erasure, restriction, objection, data portability, and the right not to be subject to certain automated decisions) must be respected. However, fulfilling these rights requires special consideration in a blockchain context, given the inherent immutability and distributed control. The guidelines consistently urge that mechanisms to honor data subject rights be incorporated at the design stage  of any blockchain system. Transparency and Information (Articles 12–14 GDPR):  Data subjects have the right to be informed about how their data is processed. In blockchain projects, this means controllers must provide clear and easily accessible privacy notices  explaining, among other things, that personal data will be recorded on a blockchain, the nature of that blockchain (public or private, how it works), who will have access to the data (e.g. all node operators globally, if it’s a public chain), and what rights and recourses the individual has. The EDPB specifies that the controller should inform the data subject before submitting their personal data to the blockchain  (e.g. at the time of data collection or before writing a transaction that includes their data). The information must be given in concise, plain language as usual, but also cover blockchain-specific aspects (such as potential international transfers to network nodes, the potential inability to fully delete data, and the measures in place to protect their data). If multiple parties are controllers (e.g. a consortium), they should coordinate so that the data subject isn’t confused by multiple or inconsistent notices. The guidelines also note that transparency is key to fairness  – data subjects should not be surprised by unexpected processing like the public permanence of their data. Therefore, full disclosure of the blockchain’s implications is part of compliant processing. Right of Access (Article 15) and Data Portability (Article 20):  The right of access means an individual can ask the controller to confirm if their data is being processed and obtain a copy of that data and relevant information. On a blockchain, the data subject might already have access to the ledger (if it’s public, anyone can read it), but the controller still has an obligation  to provide an intelligible copy of the data concerning that individual upon request. Fulfilling an access request may involve extracting all transactions or data linked to that person (for example, all entries associated with their blockchain address) and presenting it in a user-friendly format along with explanatory information (purposes, recipients (nodes), storage period, etc.). The EDPB believes that the exercise of access rights is compatible with blockchain  as long as controllers do their part to compile and furnish the information. Indeed, blockchains keep an indelible record, which could even make it easier in some cases to retrieve historical data for a subject – but the controller must ensure the individual can understand it (a dump of raw blockchain entries may not be meaningful without context). As for data portability , if processing is based on consent or contract and is carried out by automated means (criteria for Article 20), the data subject can request their personal data in a commonly used, machine-readable format. Blockchain data is already in a structured format, but the controller should consider providing it in a convenient form (perhaps a CSV or JSON listing of the person’s relevant blockchain entries). One complexity is that blockchains often involve multiple joint controllers; a user might request data from one of them (say, the dApp provider) who then must gather personal data from the chain. The guidelines assert that these rights can  be met in blockchain systems – there is nothing about blockchain that technically prevents giving a user their data or moving it – so long as the controller has procedures to extract the data and not just point to the public ledger. Right to Rectification (Article 16):  This right entitles individuals to have inaccurate personal data corrected or completed. On an immutable ledger, you typically cannot directly change or delete a past entry, which complicates straightforward “correction” of that record. The EDPB notes that fulfilling rectification may require creative solutions  in blockchain. One approach is the use of additional transactions  or data to indicate corrections. For instance, if an incorrect piece of personal data was stored in a blockchain transaction, the controller might publish a new transaction that references the earlier one and states that “the data X in transaction Y is corrected to Z.” This effectively appends a correction on-chain without erasing the original error. Anyone reading the chain would need to be made aware (through the application logic or off-chain means) that the later transaction supersedes the earlier information. In permissioned blockchains, another possibility is that an administrator can flag certain data as deprecated or push a state update that rectifies a value (though the original record remains in history). The guidelines also suggest that if rectification in effect requires erasing the old data (for example, a data subject contests a stored document and the resolution is to remove it), then the same techniques used for erasure requests should be applied to implement rectification . That is, if a piece of personal data is wrong, you might “rectify” by effectively deleting or anonymizing the erroneous data and perhaps inserting the correct data elsewhere. The key point is that controllers must have a plan to address inaccuracies – they cannot respond to a rectification request with “we technically cannot change the blockchain.” By design, they should either avoid recording personal data that might need correction, or enable an overlay system that can mark or nullify incorrect data. Ensuring data accuracy  is part of the GDPR’s principles (Art 5(1)(d)), so blockchain solutions should incorporate validation steps to prevent errors (e.g. verify data before it’s written) and mechanisms to propagate corrections. The EDPB acknowledges this can be “technically demanding” on blockchain, but it must  be tackled in compliance efforts. Right to Erasure (Article 17) and Right to Object (Article 21):  These are particularly thorny in an immutable ledger but are central to GDPR. The right to erasure (“right to be forgotten”)  allows individuals to have their personal data deleted when, for example, the data is no longer necessary, consent is withdrawn, or processing is unlawful. On most blockchains, you cannot literally delete a block or transaction without compromising the chain’s integrity and consensus – nodes deliberately resist alteration of history. The EDPB frankly observes that it might be technically impracticable  to honor a request for actual deletion of on-chain data in many cases. Nevertheless, controllers are expected to design systems to accommodate erasure as far as possible . The guidelines recommend that personal data should never be stored on-chain in directly identifiable form  unless the use case absolutely requires it and all risks have been addressed. If data is stored in a reversible or obscurable form (encrypted, hashed, or off-chain), then an erasure request can be fulfilled by rendering the data inaccessible or anonymized . For example, if a user invokes erasure, the controller could erase the personal data in the off-chain storage and delete any link or key such that the on-chain reference can no longer be tied to the person. The chain record itself might remain, but it would be functionally anonymous – the controller must ensure that neither they nor anyone else  can identify the data subject from the remaining on-chain data. This often entails erasing all related off-chain data  (e.g. mapping tables, identity information) that connected the on-chain entry to the individual. When done properly, what remains on-chain is just an orphaned entry that no longer has personal data context (or is just a random string). The EDPB calls this approach “effective anonymization”  of blockchain data in response to erasure requests. However, they caution that achieving genuine anonymization is difficult and context-dependent – it presupposes that the on-chain data by itself  cannot identify the person (so it was suitably abstracted to begin with) and that all  additional data that could re-link identity is wiped. If a controller cannot meet these conditions – for instance, in a fully public ledger where personal data (like a name or a facial image) was directly embedded on-chain – then they face a serious compliance problem. The guidelines explicitly advise that if the strong immutability of blockchain is not needed for the purpose, controllers should avoid using blockchain for personal data , because otherwise they might not be able to honor erasure and other rights. In other words, do not put data on an immutable ledger unless you have no alternative and  you have robust measures to mitigate the privacy impact. The right to object  (Article 21) gives data subjects the ability to object to processing based on certain grounds (notably, legitimate interests or public interest tasks) and requires the controller to stop or not begin processing that data unless they demonstrate compelling legitimate grounds overriding the individual’s interests. In a blockchain scenario, this means if a person says “I object to you processing my data on this blockchain,” the controller must assess and usually cease further processing relating to that person (unless an exemption applies). If the controller’s legal basis was legitimate interest, an objection typically means the processing should stop for that individual. Therefore, much like erasure, controllers should plan how they would halt processing  a particular person’s data on-chain. In practice, honoring an objection could involve refraining from adding any new data  about that person to the blockchain and possibly taking steps equivalent to erasure for existing data (since continuing to hold it might not be justifiable if the objection is valid). The guidelines bundle the design considerations for objection with erasure, stating these rights “must be complied with by design” in blockchain systems. They highlight that if personal data is stored on-chain, stopping all processing might be hard, hence the preference to limit on-chain personal data from the start. When an objection is received, a controller should at minimum ensure that no further dissemination or use  of that person’s on-chain data occurs under its control. In a permissioned chain, the controller could instruct other nodes not to process that user’s data going forward (or delete it if possible from application-level records). In public chains, the controller may only be able to anonymize  or dissociate the data (similar to an erasure solution) so that processing effectively ceases in relation to an identifiable person. An additional complication is if an objection is made to a particular node’s processing  (say a European data subject objects to her data being processed by nodes outside the EU) – given the distributed nature, it’s difficult to selectively remove one node’s copy. This again underscores why choosing an appropriate blockchain architecture (e.g. limited nodes bound by agreements)  is part of GDPR compliance. Notably, the guidelines mention that data subject rights cannot be waived or contracted away by the data subject either . Even if users consent to certain processing on blockchain, they retain their rights under GDPR. The EDPB also rejects any notion that because a data subject chose  to use a blockchain service, they have implicitly waived the right to erasure or rectification; those rights still apply and must be “fulfilled in accordance with the GDPR” despite technical challenges. Right not to be subject to Automated Decision-Making (Article 22):  This is relevant when blockchains use smart contracts or algorithms that make decisions affecting individuals without human intervention . If a smart contract automatically executes a decision that produces legal effects or similarly significant effects on a person (for example, a decentralized finance protocol automatically liquidating a user’s assets, or an identity blockchain automatically determining eligibility for a service), then Article 22’s protections kick in. The EDPB highlights that smart contract-driven decisions can constitute automated individual decision-making , and thus controllers must ensure they comply with Article 22. Under GDPR, purely automated decisions with significant effects are prohibited unless  they fall under certain exceptions (necessity for a contract, explicit consent, or authorization by law with safeguards), and even when allowed, the data subject has the right to obtain human intervention, to express their point of view, and to contest the decision. Accordingly, if a blockchain application involves such decision-making, the controller should build in safeguards : for instance, there should be a way for a human to review or override a smart contract’s outcome at the data subject’s request. The guidelines explicitly state that when Article 22 applies, the controller must guarantee the possibility of human intervention and the ability for the data subject to contest the decision, even if the smart contract’s outcome is recorded on the blockchain . This may require off-chain processes (for example, a customer support or dispute resolution mechanism that can compensate for or counteract an on-chain decision). It could also mean avoiding fully automated processing of sensitive matters  in blockchain, or seeking explicit consent with awareness of the consequences if using that route. The EDPB’s position is a reminder that “code is law” ethos of blockchains does not override human rights – systems should be designed such that algorithmic decisions are not final and unchallengeable  for the individual. In practice, ensuring compliance here might involve pausing certain smart contract actions until a human approves them in cases that affect individuals, or providing a parallel off-chain method to reverse or mitigate an outcome for the individual if needed. This can be technically difficult (and arguably undermines some benefits of automation), but it is necessary for high-stakes processing to avoid violating GDPR’s prohibition on unchecked automated decisions. Data Protection Impact Assessments (DPIAs) for Blockchain Processing Given the novel and potentially high-risk nature of blockchain processing, the guidelines strongly advise – and often require  – performing a Data Protection Impact Assessment  (DPIA) before deploying blockchain solutions that involve personal data. Under GDPR Article 35, a DPIA is mandatory for any processing likely to result in a high risk to individuals’ rights and freedoms. The EDPB notes that using blockchain can introduce significant new risks  to data subjects, so many blockchain use-cases will trigger the need for a DPIA. In fact, several criteria listed by WP29 (and endorsed by EDPB) for requiring DPIAs are often met by blockchain applications: e.g. use of new technology, large-scale systematic monitoring, matching or combining datasets, data regarding vulnerable individuals, etc. The DPIA should assess the processing as a whole , including both the on-chain and off-chain components and flows of data. The guidelines highlight that blockchain can add distinct sources of risk  that might not exist in traditional systems. When conducting the DPIA, controllers should enumerate these risks, such as: Immutability and Irreversibility:  Risk that personal data cannot be rectified or erased, impacting rights (as discussed, this is a key high-risk factor). Global Data Dissemination:  In public blockchains, personal data is replicated on nodes worldwide, potentially including in jurisdictions without adequate protection. This raises risks of unauthorized access or unlawful international transfers , and loss of control by the controller. Lack of clear control:  The distributed governance means breach response, honoring rights, or making changes may be hard, posing accountability and compliance risks. Additional technical operations:  The DPIA should consider not just data stored on-chain but also ancillary processing inherent to blockchain . For example, the transmission of transactions over a peer-to-peer network (which involves broadcasting personal data to many nodes), the temporary storage of data in mempools or caches awaiting block inclusion, the creation of “orphan” blocks  that might later be abandoned but still contain personal data, and the off-chain storage  of data referenced by the blockchain. Also, the metadata generated  (timestamps, IP addresses of nodes or users, public keys, etc.) and the management of cryptographic keys and seeds are all part of the processing ecosystem. These can introduce risks like profiling of user activity through transaction metadata or exposure if cryptographic secrets are compromised. The DPIA must catalog these elements and evaluate their impact on privacy. In identifying risks, controllers should not limit themselves to on-chain data breaches; they should look at the whole lifecycle and all related processes in the blockchain environment. For instance, if a third-party analytics tool is used to monitor the blockchain network and collects personal info, that’s in scope. The EDPB explicitly lists elements like communication of blocks among nodes, transaction queue handling, off-chain data storage, metadata generation and key management  as aspects that might introduce risks requiring mitigation. All such issues should be documented in the DPIA, along with measures to address them. Crucially, if the DPIA finds that certain high risks cannot be sufficiently mitigated , the controller has a few options: modify the blockchain model or choose a different technology , or ultimately, if high risk remains, refrain from processing or consult with the supervisory authority (as per Article 36). The guidelines encourage controllers to remember that blockchain is not the only solution – if one model (say, a public permissionless chain) is too risky, perhaps a permissioned chain or a non-blockchain database could achieve the goal with less risk. This ties back to necessity and proportionality: the DPIA should question whether using a blockchain is necessary and proportionate  for the intended purpose, or if a less invasive alternative exists. The EDPB suggests a structured approach in the DPIA, highlighting additional aspects to specifically address  for blockchain-based processing. These include: Detailed description of the processing operations involving blockchain:  The DPIA should describe the use-case and how personal data flows through the blockchain system. For example, outline what personal data is written on-chain vs kept off-chain, what the blockchain model is (public/private, permissioned/permissionless), who the participants are, and the roles and responsibilities  of each (identifying the controllers, joint controllers, and processors). It should also describe the governance framework  of the blockchain (how decisions are made about the network or protocol), the data lifecycle  on the blockchain (from data input, propagation, validation, to indefinite storage), and any integration with other systems. Essentially, the DPIA’s systematic description should make clear how and where personal data enters the blockchain, how it is processed there, and who has control over it . This includes listing categories of data subjects and personal data, categories of recipients (e.g. node operators, miners, third-party observers), and any third parties that might receive data (like external oracle services, etc.). If smart contracts  are used, the DPIA should note their function and whether they involve automated inference of personal data or decision-making. Also, mention if personal data is processed off-chain  in parallel (and how linkage is managed), and if there are international transfers  happening due to nodes in third countries. Necessity and proportionality analysis:  The DPIA must evaluate why blockchain is being used  and whether the same goal could be achieved with less data or a different method. Controllers should justify that using a blockchain (and the specific type of blockchain chosen) is necessary for the purpose  and proportionate in terms of data protection. For instance, if the purpose is to ensure data integrity and transparency among a consortium, is a fully public blockchain necessary, or would a private ledger suffice (less exposure)? Could hashing the data instead of storing raw data achieve the purpose? This section should confirm that only the minimum required personal data is processed on-chain and that all GDPR principles (like purpose limitation and data minimization) are respected in the design. If a more privacy-friendly alternative exists to achieve the same ends, the DPIA should acknowledge that and explain why the chosen approach is still justified. Regulators will expect to see that the controller has thought critically about alternatives to blockchain or less extreme configurations  and has adopted blockchain only if needed. Assessment of risks to rights and freedoms:  Building on the earlier identification of risk sources, the DPIA should analyze the potential impacts on individuals  if things go wrong or if rights cannot be exercised. This includes risks like personal data being publicly available and leading to harm (e.g. financial information on a blockchain could expose someone to fraud or profiling), risk of inability to delete erroneous or sensitive data, risk of data breaches (which on a blockchain could mean an attacker obtaining the private key of a user and thus all their on-chain personal data, or a malicious fork that exposes data), and risk of misuse of data by network participants. The DPIA should consider the severity and likelihood  of each risk. For instance, how likely is re-identification of pseudonymous data on this blockchain, and what harm would that cause? It should also consider aggregate risks , like if the blockchain aggregates data from many sources, could that enable intrusive profiling or surveillance. Another specific risk is if multiple copies  of data make breaches harder to contain – e.g. even if one node is secured, another might be compromised. The EDPB also expects an assessment of possible data breach scenarios  in blockchain. A data breach in traditional terms might be unconventional in blockchain (since data is by design shared), but for instance, if an unauthorized party gets access to a normally permissioned ledger, or if someone’s private key is stolen and fraudulent transactions with personal data are appended, these are security incidents to evaluate. The extent of a potential breach (all copies globally could be impacted) should be weighed. Measures to address the risks:  Finally, the DPIA must catalogue the safeguards and controls  the controller will implement to mitigate identified risks. The guidelines indicate many of these in earlier sections: encryption, hashing, off-chain data segregation, strict access controls in permissioned networks, governance measures (contracts among participants), data lifecycle management, etc. For each risk, the DPIA should explain how it is reduced to an acceptable level. For example, “Risk of inability to erase data is mitigated by only storing hashed data on-chain and deleting the salt upon request, rendering data anonymous. Risk of unauthorized access is mitigated by strong encryption of any personal data on-chain. Risk of international transfer issues is mitigated by restricting node locations to EU and contractual clauses with any external nodes,” and so on. The DPIA should also cover how data subject rights can be exercised (detailing the process and technical means for access, erasure, etc., as part of the risk treatment). The EDPB document even provides an Annex with recommendations  (Annex A) that likely serve as a checklist for many of these measures. Controllers can use that as a reference in their DPIA to ensure they have considered all points. The overarching advice is that performing a DPIA is not just a formality for blockchain projects, but a valuable process to identify and resolve privacy issues early . If the outcome of a DPIA is that high residual risks remain (for example, one might conclude “we cannot mitigate the risk that we cannot erase data if needed”), then according to GDPR the controller must consult the supervisory authority  before proceeding. It’s conceivable that certain public blockchain applications might fall into this category, essentially requiring regulatory consultation or else refraining from processing until a solution is found. The guidelines imply that careful design choices (such as choosing a permissioned model, or avoiding on-chain personal data)  can often reduce risks to an acceptable level so the processing can go ahead. If not, the project may need rethinking. International Data Transfers and Chapter V GDPR Compliance Blockchains are borderless by nature  – a public blockchain network typically has nodes (computers maintaining the ledger) in many countries around the world. When personal data is written to such a blockchain, that data is effectively transferred across national borders  to every foreign node that holds a copy or can access the ledger. Under GDPR’s Chapter V , any transfer of personal data from the EEA to a third country must meet certain conditions (adequacy decision, appropriate safeguards like Standard Contractual Clauses, binding corporate rules, etc., or a specific derogation). The EDPB highlights that blockchain technology will “often involve international data transfer” scenarios, especially if the network includes nodes outside the EU/EEA. This raises a compliance challenge: in an open blockchain, every  node acts as a recipient of personal data, yet unlike traditional data export, a European controller typically does not have a direct relationship or agreement with all those foreign nodes. In fact, in permissionless networks, the nodes are “neither necessarily chosen or vetted” by the controller. This lack of control over data flows can conflict with GDPR’s transfer regime, which assumes a defined exporter and importer. Despite these difficulties, the GDPR’s transfer rules still fully apply  – there is no blockchain exemption. Any European controller using a blockchain that causes personal data to be replicated to nodes outside the EEA must ensure that the transfer is lawful under Chapter V. That likely means the controller has to either restrict the network to EEA nodes or implement a transfer mechanism. The guidelines suggest some approaches: for example, in a permissioned blockchain , the controller could require all participating nodes/operators outside the EEA to sign Standard Contractual Clauses (SCCs)  or similar agreements before being allowed to join the network. In such a case, joining the consortium might be conditioned on agreeing to EU data protection safeguards, making each node contractually bound to GDPR-like obligations. This is analogous to how a data exporter might get a foreign data importer to sign SCCs in a traditional transfer. Another approach is to limit node locations to countries with an adequacy decision , ensuring data only flows to jurisdictions deemed by the EU to provide adequate protection. However, in many public blockchains, neither approach is practically enforceable (anyone can set up a node anywhere). The EDPB acknowledges that truly public blockchains (e.g. Bitcoin, Ethereum) create a situation that “may raise compliance concerns” because of these unrestricted international flows. Controllers thus face a tough question: if you cannot prevent or properly safeguard international transfers on a public blockchain, can you use that blockchain for personal data at all?  The guidelines stop short of forbidding it outright but strongly hint that data protection by design must address transfer risks from the start . They note that ensuring proper application of transfer requirements should be “addressed from the design of blockchain activities” . In practice, this might mean designing the solution such that personal data never leaves the EEA  or is never exposed to uncontrolled nodes. For instance, one could use a permissioned blockchain with nodes only in the EU, or encrypt personal data so that even if it reaches foreign nodes, it’s unintelligible (though even encrypted personal data transfer might formally be a transfer if the foreign node can potentially decrypt or if keys could be obtained). Another technique is to store only hashes  or commitments on the global blockchain (which might be considered anonymous data to foreign nodes if they have no access to the original data), and keep the personal data on servers in the EEA. That way, even though something is transferred globally, it may not be considered personal data by itself. These strategies align with earlier points on minimization and encryption, but here the emphasis is on geographical data flow control . If a controller does proceed with using a global network, they should identify in the DPIA  and records of processing that international transfers occur, and specify the transfer mechanism relied upon. For example, they might list the countries of known nodes and cite SCCs or explicit consent (though consent for transfers is rarely practical or sufficient) as the basis. In many cases, explicit consent of the data subject  for transfers (GDPR Art 49(1)(a) derogation) could be a fallback – for example, a DApp could warn the user: “your data will be published on a global network; by proceeding you consent to this international transfer.” However, relying on Art 49 derogations should be limited to occasional, necessity-based transfers, and not regular systematic ones, so it’s not a sound long-term solution for something like blockchain that continuously exports data. Therefore, structural solutions  (like restricting node geography or using EU-based infrastructure) are preferable. The guidelines also remind controllers that Chapter V compliance is part of data protection by design . Article 25 (data protection by design) requires considering all  GDPR requirements in the design, including those about cross-border data flow. This means if a blockchain setup would violate transfer rules, that setup is not compliant with Article 25 – it should be reworked. Designing privacy into the system includes designing legal compliance into the system’s geopolitical footprint. Guidelines 02/2025 on processing of personal data through blockchain technologies (Version 1.1, 08 Apr 2025) are explicitly labelled “Adopted – version for public consultation”, indicating that the text is provisional and non-binding pending further deliberation. The European Data Protection Board has invited all interested parties to transmit written observations via the prescribed online form by 9 June 2025; only after analysing those submissions will the Board adopt a definitive version. https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-022025-processing-personal-data_en?utm_source=chatgpt.com The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

Scope and Objectives of PSD2 vs. MiCA PSD2 – Payment Services Directive (2015) : PSD2 provides the core legal framework for retail payment services in the EU, aiming to foster an integrated EU payments market and enhance innovation, competition, and security in electronic payments. Building on the first Payment Services Directive (2007), PSD2 addressed barriers to new types of payment services (e.g. fintech payment initiation and account aggregation) while improving consumer protection and payment security (notably through Strong Customer Authentication requirements). PSD2 applies to payment service providers (PSPs)  – including banks (credit institutions), electronic money institutions (EMIs), and authorized payment institutions (PIs)  – and governs services like payment account handling, transfers of funds, card issuing, acquiring, money remittance, and online payment initiation or account information services (open banking). Its objectives are to level the playing field for new payment players, ensure consumer rights and security , and harmonize rules across Member States for a single EU payments market. PSD2 is a Directive, meaning each Member State transposed its provisions into national law by January 2018 (with certain measures like Strong Customer Authentication applying from 2019). It amended related laws (including the E-Money Directive 2009/110/EC) to align e-money issuance with the new payments regime. In sum, PSD2 focuses on fiat currency payments and electronic money , not on crypto-assets per se, though it impacts crypto businesses when they perform regulated payment activities (as discussed below). MiCA – Markets in Crypto-Assets Regulation (2023) : MiCA establishes the first EU-wide harmonized framework for crypto-assets not otherwise regulated by existing financial services law. Its scope expressly excludes crypto-assets that qualify as regulated instruments (e.g. financial instruments under MiFID, bank deposits, structured deposits, insurance/pension products), as well as unique non-fungible assets (NFTs). MiCA’s objective  is to support innovation and fair competition in digital finance while safeguarding consumers, market integrity, and financial stability in the crypto-asset sector. It introduces uniform rules for the issuance of crypto-assets  (including token offerings and stablecoins) and for crypto-asset services  such as trading, exchange, custody, and advice. Key provisions mandate transparency and disclosure (e.g. white papers for offerings), prudential safeguards, governance and conduct standards for service providers, and supervision of transactions. Unlike PSD2, MiCA is directly applicable in all Member States (no national transposition needed). Regulatory Applicability to Crypto Business Models MiCA is tailored to crypto-asset activities, whereas PSD2 governs traditional payment services – but certain crypto business models trigger one or both regimes. Below we analyze how each framework applies (or not) to key categories of crypto businesses: Cryptocurrency Exchanges & Trading Platforms : Under MiCA, operating a crypto-asset trading platform  or exchanging crypto-assets for fiat/other crypto is a regulated crypto-asset service  requiring authorization as a Crypto-Asset Service Provider (CASP) . CASPs operating exchanges must implement transparent, non-discriminatory trading rules and ensure resilient systems, fair access criteria, and timely trade settlement (within 24h for on-chain or same-day off-chain settlements). Exchanges using proprietary capital to quote prices (market-making) must disclose pricing methods and comply with post-trade transparency. MiCA thus squarely covers both centralized crypto exchanges and brokers. By contrast, PSD2 generally does not regulate crypto-to-crypto or crypto-to-fiat exchanges  as such transactions are outside the traditional “payment service” definition (which centers on transfers of “funds” i.e. banknotes, scriptural money, or electronic money). If an exchange merely facilitates trades and does not itself execute a payment from a customer’s payment account, PSD2 is not directly engaged. However, when a crypto exchange handles fiat currency deposits or withdrawals  for customers, those fiat operations (e.g. holding client fiat balances or transferring euros to a bank) may fall under PSD2 or E-Money rules. Many crypto exchanges partner with licensed banks/EMIs to hold client fiat or have themselves obtained an EMI or PI license to handle fiat wallet services in compliance with PSD2/EMD2. In summary, MiCA will newly require EU crypto exchanges to obtain a CASP license (with passporting EU-wide), while PSD2/EMD2 obligations may simultaneously apply for any fiat payment aspects (e.g. exchange maintaining euro wallets or processing SEPA transfers). Notably, MiCA Article 81 mandates that if a CASP’s business model requires holding client funds as defined in PSD2 , those funds must be deposited with an EU credit institution or central bank, and payment transactions related to the crypto service may only be executed if the CASP is also authorized as a payment institution under PSD2 . This creates a dual licensing scenario  for exchanges handling both crypto and fiat, as discussed further under overlaps. Custodial Wallet Providers & Crypto Custodians : MiCA brings custodial wallet services  firmly into regulation. Any entity providing custody and administration of crypto-assets on behalf of clients  (holding customers’ crypto private keys or crypto-assets in custody) is a CASP requiring authorization. Such custodians must conclude written agreements with clients specifying the services and maintain a custody policy. MiCA imposes strict duties: custodians must not use client crypto-assets for their own account , must keep client assets unencumbered and segregated , and bear liability for loss  arising from hacks or IT incidents (including cyber-attacks or theft). In addition, MiCA explicitly excludes non-custodial wallet software providers  from its scope: providers of hardware/software for self-hosted wallets (where the user, not a service, controls the keys) are not deemed CASPs. PSD2, on the other hand, has no direct equivalent for crypto custody services . Holding or safeguarding cryptocurrency is not a regulated payment service under PSD2 (which only covers safeguarding of funds  in the sense of fiat/e-money). However, if a crypto custodian also holds fiat payment accounts or e-money  for clients (e.g. to facilitate buying crypto), that aspect would invoke PSD2/EMD compliance. Of note, the EBA now advises that a custodial arrangement for e-money tokens (stablecoins) can be viewed as a “payment account”  under PSD2 if it’s in the client’s name and used to send/receive those tokens. In summary, pure crypto custody is governed by MiCA (new CASP license), while custody of fiat money or stablecoins might concurrently require a PSD2 license depending on the service offered. Decentralized Finance (DeFi) Protocols : Truly decentralized protocols (operating via smart contracts with no central operator or intermediary ) largely fall outside both PSD2 and MiCA. PSD2 does not cover these as it regulates service providers  (firms) rather than autonomous code. MiCA likewise recites that fully decentralised services provided without any intermediary do not fall within the scope of the regulation . For example, a DeFi liquidity pool or DEX with no entity controlling it would not itself be a CASP under MiCA. However, MiCA’s perimeter can capture entities that do engage with DeFi on behalf of users  – e.g. a company offering an interface or “front-end” to a DeFi protocol, or administering aspects of a protocol, could be deemed to be providing a regulated crypto-asset service. MiCA foresees future evaluation of how to handle DeFi and mandates reports on DeFi’s development and potential regulation. PSD2 remains inapplicable unless the DeFi activity somehow involves traditional payment services. In practice, regulatory uncertainty  exists for semi-decentralized arrangements – firms should carefully assess whether any identifiable entity is providing a service that could be captured by MiCA’s definitions (such as operating a trading platform, even if transactions settle on-chain). For now, fully autonomous DeFi systems are an unregulated gray area  – a noted gap which regulators may address in the future. Crypto Asset Issuers (Utility Tokens and Others) : MiCA distinguishes three types of crypto-assets: e-money tokens (EMTs)  referencing a single fiat currency (a subset of stablecoins), asset-referenced tokens (ARTs)  referencing baskets of assets (including currencies, commodities, or crypto), and other crypto-assets  (including utility tokens). Issuers of EMTs and ARTs face the most stringent obligations under MiCA. An issuer of an EMT (fiat-pegged stablecoin)  must be authorized as a credit institution or an electronic money institution  under existing EU banking/e-money law. In fact, MiCA deems EMTs to be “electronic money”  under the E-Money Directive, meaning stablecoin issuers must meet all e-money issuance and redeemability requirements  in addition to MiCA’s crypto-specific rules. For example, an EMT issuer must always honor redemption at par value in the referenced currency at any time, and it may not pay interest  on tokens (to discourage treating them as savings instruments). MiCA Title IV adds further obligations (e.g. white paper, reserve asset custody and investment rules, and if “significant” in scale, higher capital and liquidity requirements). Asset-Referenced Token  issuers (e.g. a stablecoin referencing multiple currencies or assets) likewise need prior authorization and must comply with detailed reserve, governance, and disclosure requirements (Title III of MiCA). Smaller utility token  issuers have lighter requirements: generally they must publish and notify a crypto-asset white paper  with essential information, but no authorization is required to offer simple utility tokens (unless they fall into another category). PSD2 is not directly concerned with crypto asset issuance  unless the activity intersects with payment services. For example, issuing a utility token used for platform access is outside PSD2’s scope. However, issuing a stablecoin might invoke e-money law: under pre-MiCA law, a fiat-pegged, redeemable stablecoin often qualified as “electronic money”  (stored monetary value issued on receipt of funds) under Directive 2009/110/EC, requiring an e-money license. This has now been codified by MiCA (EMTs = e-money). Thus, a crypto business issuing a euro-pegged token needs a dual regulatory footing : compliance with MiCA’s Title IV   and  authorization under the E-Money Directive (which PSD2 references). Issuers that are banks (credit institutions) automatically meet the authorization requirement, while non-bank issuers must obtain an EMI license. PSD2’s consumer protection rules on payment transactions would apply when those tokens are used for payments (similar to how prepaid e-money usage is regulated). Crypto Payment Service Providers : Some crypto businesses provide payment services  such as enabling merchants to accept crypto or stablecoin payments, or offering crypto-based remittances. If such a business facilitates the transfer of funds (fiat or e-money)  on behalf of a payer to a payee, it may perform a regulated payment service under PSD2 (e.g. money remittance or payment processing). MiCA introduces a specific service category for the custody and administration on behalf of clients , meaning if a firm carries out crypto transactions for clients (such as sending crypto to others per user instructions), it requires CASP authorization for that service (akin to a remittance service). In practice, a crypto payments firm often straddles both regimes: the crypto leg of the activity (handling the crypto asset transfer) will be subject to MiCA, and any fiat conversion or involvement of fiat accounts  invokes PSD2. For example, a company that lets users pay merchants in crypto while the merchant receives fiat will need a PSD2 payment institution license (to handle the fiat payment to the merchant) and, separately, a CASP license under MiCA for the crypto-to-fiat exchange service and possibly the transfer of crypto on the payer’s behalf. PSD2’s scope over pure crypto transactions is essentially null  – PSD2 covers transfers of “funds” (which are euros or other official currencies, or e-money). However, once a stablecoin or crypto-asset is involved, MiCA takes over for that portion. One special case is when stablecoins are used as a payment medium : the EBA has recently clarified that transferring e-money tokens (EMTs) for clients is to be viewed as a payment service under PSD2 , since an EMT is electronic money. As a result, a crypto payment provider transacting in euro-stablecoins on behalf of users might technically need a PSD2 license in addition to its CASP registration. This dual coverage is temporary – the EBA has issued a “no-action” position advising national regulators to delay enforcing PSD2 license requirements for CASPs handling EMT transfers until March 2026 , to avoid requiring two separate authorizations immediately. In the long term, regulatory reforms (PSD3) are expected to eliminate such duplicative licensing. For now, crypto payment providers must be cognizant of both frameworks: MiCA will regulate their crypto transaction services (with requirements on disclosures, handling of private keys, etc.), and PSD2 will regulate any fiat payout or stablecoin issuance/redemption piece, including consumer rights and security for those payment transactions. Decentralized Exchanges and Peer-to-Peer Platforms : A decentralized exchange (DEX) with no central operator is akin to the DeFi discussion above – MiCA would likely not directly apply if truly no service provider is present. PSD2 would not apply because no regulated payment service (as legally defined) is being provided to a user by a third-party. However, if a business operates a peer-to-peer trading platform  (even non-custodial) where it intermediates trades between users, it may be considered as operating a “trading platform for crypto-assets”  under MiCA, thus a regulated CASP. The platform provider in that case must be authorized and comply with MiCA’s rules for exchanges (transparency, operational resilience, etc.). PSD2 remains irrelevant unless fiat payment services are bundled (e.g. the platform also facilitates fiat settlement between the parties, in which case those fiat flows require a payment license or partnership with a payment institution). Legal Risks and Compliance Strategies in the New Regime Key legal risks for non-compliance include potential fines, license withdrawal (or inability to obtain required licenses), civil liability to clients, and reputational damage. Below we outline strategies to ensure compliance and mitigate risks: Regulatory Classification & Licensing Strategy:  Every crypto business should map its activities to the legal definitions  in PSD2 and MiCA. Determine which aspects of the business are payment services , which are crypto-asset services , and which involve token issuance . For instance, if you hold customer fiat and execute transfers, you likely need a PSD2 authorization (or partnership with a licensed PSP) in addition to any MiCA authorization. If you operate a crypto exchange/custody, plan to obtain a CASP license by late 2024. Start the application preparations early – authorization requires substantial documentation (business plan, internal procedures, security policies, fit-and-proper assessments, etc. under MiCA Articles 62-63). If you issue a stablecoin, initiate the process to become an EMI or partner with a licensed bank . Where dual licensing is needed (EMI + CASP), engage with both regulators; leverage the EBA’s recommendation  of streamlined dual applications (EBA suggests NCAs use information from the CASP application to ease PSD2 authorizations). Governance and Internal Controls:  Both regimes put emphasis on fit-and-proper management  and robust governance. Crypto businesses should strengthen their governance structures – ensure that board members and key executives have clean compliance records (no AML/fraud convictions), and that they collectively possess the requisite expertise in both crypto technology and financial compliance. Implement or update compliance policies for risk management, conflict of interest, complaints handling, and business continuity  to meet MiCA’s standards. Set up an internal audit and control function  if not already present (MiCA will require effective internal controls). Training staff on new obligations (e.g. treating client crypto fairly, handling of inside information in token markets, etc.) is crucial. Establish clear procedures for client asset safeguarding : segregate on-ledger wallets for clients, keep accurate records of holdings, and conduct regular reconciliations. Prepare to document everything  – regulators will expect comprehensive policies and evidence of their implementation during licensing and inspections. AML/CFT Compliance Upgrade:  With increased regulatory scrutiny, crypto firms must elevate their AML controls to the level of traditional finance. If not already done, implement robust KYC onboarding  compliant with AMLD5 – verify customer identity, source of funds (especially for large crypto-fiat conversions), and screen against sanctions/Pep lists. Enhance transaction monitoring  systems to detect patterns of suspicious crypto transfers (layering, structuring, use of mixers, etc.). Ensure you can comply with the Travel Rule  for crypto transfers: by 2024, CASPs will need to collect and transmit originator/beneficiary information for transfers of crypto-assets, similar to wire transfers. Align with the latest EBA/ESMA guidance  on AML for CASPs once issued. Also, be mindful of MiCA’s requirement for extra vigilance with high-risk jurisdictions – incorporate that into your risk-based approach (e.g. enhanced due diligence for customers from or sending crypto to blacklisted countries). Consumer Protection and Transparency Measures:  To comply with both PSD2 and MiCA spirit, crypto businesses should adopt a customer-centric approach . Provide clear, plain-language disclosures of fees, risks, and terms of service. For example, if you run a trading platform, publish your pricing methodology or firm quotes as required, and have a clear policy on how client orders are executed (best execution). If you custody assets, provide clients with statements of their holdings and inform them of security measures in place (and any risks). Implement a complaints handling process  now (even ahead of formal MiCA RTS on this) – including a designated contact point, log of complaints, and timely resolution process, as this will be mandated. Consider offering voluntary protections  such as insurance or compensation schemes for theft of crypto (as some exchanges do) to bolster confidence – MiCA will hold you liable for certain losses by law, so insurance also protects the firm’s solvency. In anticipation of strong customer authentication  becoming expected for crypto transactions (per EBA’s advice), deploy two-factor authentication and withdrawal confirmation steps for clients. Technical and Cybersecurity Readiness:  Given DORA’s application and MiCA’s ICT risk focus, crypto businesses must invest in IT security. Perform comprehensive penetration testing  and smart contract audits (if applicable). Establish 24/7 monitoring for unauthorized access or unusual transactions. Develop an incident response plan  for cyber incidents – who to alert, how to contain breaches, how to communicate to clients and regulators. MiCA and DORA will require incident reporting  within tight deadlines for significant events, so be prepared to detect and report promptly. Also ensure data protection compliance  – review how customer data (IDs, account info, blockchain addresses linked to identities) is stored and used; conduct a GDPR privacy impact assessment for new data practices (like sharing data with analytics providers). Encryption and secure key management (including multi-signature or hardware security modules for private keys) are fundamental to demonstrate to regulators that client assets are safe. Overlapping Compliance – Streamlining Efforts:  If your business requires compliance with both PSD2 and MiCA (e.g. you operate a platform where users hold euro balances and crypto balances), look for synergies in compliance efforts. For instance, the own funds calculation  you do for PSD2 can inform the capital planning for MiCA’s requirements – coordinate with advisors to ensure the highest required amount covers both. Training programs for staff can cover both anti-fraud (PSD2) and anti-market-manipulation (MiCA) aspects together, fostering a culture of compliance across the board. Where EBA has advised deprioritization of certain PSD2 provisions for CASPs (like not focusing on IBAN and open banking for stablecoin wallets), document that guidance and be prepared to discuss with auditors or examiners why certain PSD2 measures may not be relevant to your model. Essentially, maintain a compliance matrix  mapping each requirement of both regimes to your internal controls, so nothing is overlooked and redundancies are minimized. Prokopiev Law Group, powered by a global partner network, secures MiCA CASP license approvals, resolves PSD3 crypto overlap, delivers stablecoin EMT authorization, implements the EU Travel Rule, hardens DORA resilience, readies DAC8 crypto tax reporting, completes VASP registration, and obtains Dubai VARA license, MAS DPT license, Hong Kong SFC VASP clearance, DAO legal wrapper structuring and other high-demand Web3 mandates, ensuring full compliance across the European Union, United Kingdom, United States, Switzerland, Liechtenstein, Singapore, Hong Kong, UAE (VARA and ADGM), Cayman Islands and British Virgin Islands; write to us at prokopievlaw.com/contact for rapid, execution-ready guidance. Sources Disclaimer The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

Introduction and Official Source The Guiding and Establishing National Innovation for U.S. Stablecoins Act of 2025 , commonly known as the GENIUS Act , is a proposed U.S. federal law to create a comprehensive regulatory framework for payment stablecoins . The bill’s official text (S.1582 in the 119th Congress) is available on Congress.gov . It defines “payment stablecoin” as a digital asset used for payments or settlement that is redeemable for a fixed monetary value  (for example, one token redeemable for $1). The GENIUS Act aims to ensure that only fully-regulated and properly reserved  stablecoins circulate in U.S. markets, establishing requirements for issuers, consumer protections, and oversight mechanisms. This report provides a detailed legal overview of the bill’s text, sponsorship, legislative status, and key provisions, followed by an analysis of its implications for stablecoin issuers, users, and regulators. ( Official Bill Source:  The full bill text and status can be found on Congress.gov .) Key Provisions of the GENIUS Act of 2025 Scope and Definitions The GENIUS Act applies to “payment stablecoins,”  defined as digital assets intended for use as a means of payment or settlement  that the issuer is obligated to redeem for a fixed value  (e.g. one U.S. dollar). The definition explicitly excludes instruments that are already legal tender or bank deposits, that pay interest, or that are securities under existing law. In fact, the Act makes clear that a compliant payment stablecoin “is not a security”  under the Securities Act, Securities Exchange Act, or Investment Company Act. It also later clarifies that stablecoins regulated under this framework are not commodities  for regulatory purposes and are not insured deposits . By carving stablecoins out of securities and commodities definitions, the bill provides regulatory clarity – these digital tokens will be overseen under the new stablecoin-specific regime rather than by the SEC or CFTC as securities or commodities. The Act’s provisions generally cover USD-pegged stablecoins  (though “monetary value” could include foreign currencies), and would require any stablecoin used by U.S. persons in commerce to be issued by an authorized entity under this law (or an equivalent foreign regime, as discussed below). Permitted Issuers and Licensing Requirements One of the cornerstone features of the GENIUS Act is that it restricts stablecoin issuance to regulated entities  termed “permitted payment stablecoin issuers.”  In essence, only a permitted issuer may issue a payment stablecoin for use by U.S. persons  (subject to certain phase-ins and exceptions). The Act defines three categories of permitted issuers: (A) Insured Depository Institution Subsidiaries:  A subsidiary of a federally insured depository institution (i.e. a bank or credit union) that is approved to issue stablecoins. This allows traditional banks (through affiliates) to issue stablecoins under their existing bank regulatory framework. (B) Federal Nonbank Stablecoin Issuers:  A nonbank company  that obtains a new federal license/charter  to issue stablecoins (referred to as a “Federal qualified nonbank payment stablecoin issuer”). These nonbank issuers would be chartered and supervised by the Office of the Comptroller of the Currency (OCC) , the primary regulator for national banks. The OCC is explicitly tasked with regulating nonbank stablecoin issuers under the Act’s federal regime. (C) State-Qualified Stablecoin Issuers:  A nonbank entity  that is chartered or licensed under state law  to issue stablecoins (for example, a state trust company or money transmitter that meets the Act’s standards), termed a “State qualified payment stablecoin issuer.” The Act permits a state-based regulatory option provided the state’s rules are “substantially similar”  to the federal standards . Importantly, the state-based option is limited to issuers with $10 billion or less in outstanding stablecoin liabilities  – larger issuers must operate under federal oversight. All permitted issuers, whether federal or state, must be incorporated in the United States  and be subject to regulation by the appropriate regulatory agency . In practice, this means a nonbank stablecoin provider can choose a regulatory path: either apply for a new OCC license (federal charter) or seek approval under a qualifying state regime (if they will remain relatively smaller in scale). A nonbank issuer that grows beyond $10 billion in stablecoin circulation  will have to transition to the federal regime  (OCC supervision) within a prescribed period, unless granted a waiver by the federal regulator. This ensures that larger stablecoin issuers with potential systemic impact are under federal supervision. The Act lays out a licensing (approval) process  for would-be issuers. An applicant must demonstrate it can meet all prudential requirements (capital, reserves, risk management, etc.). Notably, if a regulator does not act on an application within 120 days, the application is deemed approved by default . Any denial must be accompanied by a rationale, and applicants have the right to appeal denials. This provision is meant to prevent regulators from indefinitely stonewalling new entrants and to promote timely decision-making, thereby encouraging innovation and competition in stablecoin markets. Regulatory jurisdiction:  For bank-affiliated issuers, their existing federal banking regulator (e.g. Federal Reserve, FDIC, or OCC depending on the charter) will oversee stablecoin operations; for nonbank issuers under the federal option, the OCC  is the primary regulator. State-licensed issuers remain under their state regulators , though federal authorities retain certain backup powers as discussed below. No matter the route, all permitted issuers face baseline requirements  on reserves, liquidity, auditing, and consumer disclosure as mandated by the GENIUS Act. Reserve Backing and Capital Standards To protect the value of stablecoins and prevent runs, the GENIUS Act imposes stringent reserve requirements . Every payment stablecoin must be 100% backed by high-quality liquid assets on a one-to-one basis . In other words, for each $1 of stablecoin issued, at least $1 of eligible reserve assets must be held by the issuer at all times. The bill tightly defines “permitted reserves”  to limit them to safe and liquid instruments , including: U.S. coins and currency, balances in insured bank accounts, short-term U.S. Treasury bills , Treasury repurchase agreements (repos) or reverse repos fully collateralized by Treasuries, shares in government money market funds, central bank reserves , and other similar government-issued assets  approved by regulators. Riskier or illiquid assets (e.g. corporate debt, equities, exotic investments) cannot count toward reserve backing , preventing an issuer from backing a stablecoin with volatile or credit-risky instruments. This addresses past concerns where some stablecoins were found to hold risky reserve assets; under GENIUS, reserves must essentially be cash or cash equivalents with minimal credit and market risk. The Act also restricts how reserve assets can be used . Issuers generally cannot leverage or encumber reserves  for speculative investments. Reserves may be used only for specified purposes, such as redeeming stablecoins on demand  or serving as collateral in safe short-term financing transactions (like Treasury repos). This ensures the reserve assets remain liquid and available to meet stablecoin redemptions at all times. Notably, stablecoin issuers would not  be subject to traditional bank regulatory capital requirements  that apply to depository institutions. The rationale is that because stablecoin issuers must hold $1-for-$1 reserves , the usual bank capital ratios (which allow fractional reserve banking) are not applicable – essentially the stablecoin issuer’s own “capital” is the full reserve backing itself. The Act instead directs federal and state regulators to issue tailored capital and liquidity rules  specific to stablecoin issuers (likely ensuring resilience against operational risks or losses unrelated to reserve backing). In sum, the GENIUS framework creates a full-reserve model  for stablecoins to protect coin holders, rather than the fractional reserve model of traditional banking. Disclosure, Reporting, and Audits Every permitted issuer must establish and publicly disclose its redemption policies  (i.e. the terms and procedures for consumers to redeem stablecoins for cash). They are also required to issue regular reports on their outstanding stablecoin liabilities and the composition of their reserves . At a minimum, issuers must publish monthly reports  detailing the total stablecoins in circulation and exactly what assets make up the reserves backing those coins. These reports provide ongoing transparency so that users and regulators can verify that stablecoins are fully collateralized at all times. Crucially, the Act requires that management attestations and independent audits support these disclosures. The periodic reserve reports must be certified by the issuer’s executive officers  (holding management accountable for accuracy) and “examined” by a registered public accounting firm . In addition, any issuer with more than $50 billion  in stablecoins outstanding faces an even higher bar: it must submit annual audited financial statements  to regulators. These audits would likely evaluate the issuer’s financial condition, internal controls, and reserve holdings in depth. The combination of management certification, third-party examination of reserve reports, and annual audits (for large issuers) creates multiple layers of assurance that a stablecoin issuer is honest and solvent. Consumer-facing note:  The Act also requires that consumers be informed that stablecoins are not government-insured  deposits – avoiding any false sense of FDIC protection – and presumably mandates other disclosures to ensure users understand the product they are using. Supervision and Enforcement Powers For federally regulated issuers  (i.e. bank subsidiaries and OCC-chartered nonbanks), the same federal banking agencies that regulate their affiliated bank or that granted their charter will supervise the stablecoin activities . For example, a stablecoin subsidiary of a national bank might be supervised by the OCC alongside the bank, whereas a nonbank stablecoin issuer with an OCC charter will be supervised directly by the OCC (with the Federal Reserve possibly overseeing any holding company). These regulators are tasked with monitoring the issuer’s financial condition, safety and soundness, and risk management systems  in the context of stablecoin operations. All federal-regime issuers must file regular reports and submit to examinations by their regulator , just as depository institutions do. Regulators are also armed with enforcement authority . If an issuer violates any requirement of the Act or any condition imposed in its charter/license, the regulator can order the issuer to stop issuing stablecoins  or impose other enforcement actions  (e.g. fines, cease-and-desist orders). In extreme cases, an issuer could effectively be shut down for non-compliance. This enforcement mechanism ensures that regulators can act swiftly to correct problems – for instance, if an issuer’s reserves fell short or if it engaged in unsafe practices, the agency could halt further issuance until issues are remedied. These powers mirror the kind of prompt corrective action regulators have in banking supervision, adapted to stablecoins. For state-qualified issuers (<$10B) , the Act preserves primary oversight for state regulators : “State regulators would have supervisory, examination, and enforcement authority over all state issuers”. In other words, a company that opts for a state stablecoin license will answer mainly to the state banking or financial authority that chartered it. However, to ensure federal interests (like financial stability and monetary policy) are protected, the Act gives federal regulators certain backup authorities  over state-regulated issuers. Specifically, a state may voluntarily cede supervisory responsibility to the Federal Reserve  for a stablecoin issuer. Even if not ceded, the Federal Reserve or OCC can step in to take enforcement actions against a state issuer in “unusual and exigent” circumstances . This language suggests that if a state-regulated stablecoin were threatening broader financial stability or flagrantly violating the rules, federal authorities could intervene (similar to how the Fed has emergency powers in other contexts). Additionally, if a state-based issuer grows beyond the $10B threshold, it must come under joint federal/state supervision or shift to a federal charter, as noted earlier. Anti-Money Laundering and Financial Integrity Measures Stablecoins raise concerns about illicit finance, so the GENIUS Act contains AML (Anti–Money Laundering) and counter-terrorism finance provisions . All permitted stablecoin issuers would be made explicitly subject to the Bank Secrecy Act (BSA) , which is the primary U.S. AML law. This means issuers must implement know-your-customer (KYC) programs , monitor transactions for suspicious activity, file Suspicious Activity Reports (SARs) and Currency Transaction Reports (CTRs) as required, and comply with anti-money laundering and sanctions laws  just like banks and money services businesses do. The Act in fact requires each issuer to certify that it has implemented an AML and sanctions compliance program  as a condition of being licensed. Failure to maintain an adequate AML program could lead to enforcement action. The law also directs the Financial Crimes Enforcement Network (FinCEN)  (the bureau of the Treasury Department that oversees BSA compliance) to issue “tailored” AML rules for digital assets . FinCEN would be tasked with updating or refining AML regulations to address the unique characteristics of stablecoins and other digital assets, and to “facilitate novel methods…to detect illicit activity involving digital assets.” . This could include guidance on blockchain analytics, informationsharing, or new reporting requirements specific to crypto transactions. In essence, Congress is requiring regulators to modernize AML oversight tools to keep pace with stablecoin technology, recognizing that traditional methods must adapt (for example, leveraging the traceability of distributed ledgers while also managing privacy concerns). Furthermore, the Act imposes bad actor bans : any individual who has been convicted of certain financial crimes is prohibited from serving as an officer or director  of a stablecoin issuer. Custody and Investor Protection Provisions The GENIUS Act contains several provisions addressing the custody of stablecoins and reserve assets , as well as protections for stablecoin holders in the event of issuer insolvency. First, the law would allow regulated financial institutions to custody stablecoins  and their reserves. Banks and credit unions are explicitly permitted to hold stablecoins in custody for customers and to hold reserve assets  on behalf of stablecoin issuers. They are also permitted to use distributed ledger technology (blockchains)  in their operations and even to issue “tokenized deposits”  (essentially bank deposits represented as tokens on a blockchain) if they choose. These clarifications remove any legal doubt that banks can participate in the stablecoin ecosystem, which could foster integration of stablecoins into mainstream banking (e.g. banks offering stablecoin wallets or integrating stablecoin payments). For any entity acting as a custodian of stablecoin assets or reserves  – whether it’s an issuer itself or a third-party custodian – the Act sets rules to protect customers. Notably, custodians are prohibited from commingling customer stablecoin funds with the custodian’s own assets . Customer assets must be segregated, which protects users if the custodian were to fail. (Commingling could put customer funds at risk of being tied up in the custodian’s bankruptcy; segregation ensures they remain identifiable and returnable to customers.) Limited exceptions might apply (e.g. pooling for operational efficiency), but generally segregation of reserves is required . Additionally, any stablecoin custodian must itself be a regulated entity – either a federally or state regulated bank or a registered securities/capital markets entity (like a trust company or broker-dealer) regulated by the SEC or CFTC. This ensures that companies holding the reserves (or the tokens in custody for users) are subject to oversight and examinations regarding their safeguarding of those assets. Perhaps one of the most important consumer protections in the Act is its treatment of stablecoin holders’ claims in bankruptcy . The law provides that stablecoin holders have priority over all other creditors in claims against the issuer’s reserve assets . In practical terms, if a stablecoin issuer were to go bankrupt or be liquidated, the customers who hold the stablecoin tokens get first claim on the reserve funds  backing those tokens, before any other debts of the company are paid. This is a powerful protection: it means the collateral truly belongs to the token holders and cannot be grabbed by, say, the issuer’s other creditors. It greatly increases the likelihood that stablecoin holders can recover their money even if the issuer fails, essentially making them senior secured creditors  with respect to the reserve. The Act also updates the bankruptcy code as needed to enforce this priority rule. By giving stablecoin users a senior claim, the Act addresses the scenario of a stablecoin “run” – users will know they are first in line for repayment, which should reduce panic and run incentives during stress. Finally, as noted earlier, the Act explicitly states that stablecoins are not insured by the federal government . This means if a stablecoin fails and somehow reserves were insufficient (which should not happen under a 100% reserve mandate, but theoretically if there were fraud or losses), holders cannot claim FDIC deposit insurance or other federal insurance – they rely on the issuer’s assets. Requiring disclosure of this fact is an important consumer-awareness measure to prevent any misunderstanding of stablecoins as risk-free insured deposits. Consumers must rely on the regulatory framework, the reserve backing, and the issuer’s soundness for protection, rather than an insurance safety net. Foreign Issuers and International Considerations Recognizing the global nature of crypto markets, the GENIUS Act also addresses foreign stablecoin issuers and cross-border usage . Within three years of the Act’s enactment , it would become unlawful to offer or sell a payment stablecoin to U.S. persons  except by a permitted (U.S.-regulated) issuer. This effectively phases out unregulated stablecoins  from the U.S. market – even foreign-based stablecoins (like those issued overseas) must either become compliant  or exit the U.S. consumer market. However, the Act gives the U.S. Treasury, in consultation with other regulators, authority to establish “reciprocal agreements” with foreign jurisdictions  that have comparable regulatory standards  for stablecoins. If a foreign jurisdiction has a robust oversight regime similar to the GENIUS Act, Treasury can deem it comparable  and set up an agreement to allow that jurisdiction’s regulated stablecoins to be offered in the U.S. without each foreign issuer needing a separate U.S. license. This is akin to passporting  or mutual recognition. Even when foreign stablecoins are allowed, the Act imposes additional safeguards. Any foreign stablecoin permitted for U.S. use must have the technical capability to freeze transactions and to comply with lawful orders . In practice, this means truly decentralized or ungovernable stablecoins would not qualify – the issuer or controlling entity must be able to block illicit transactions or seize tokens  when required by regulators (e.g. to enforce sanctions or court orders). Additionally, foreign issuers that want their stablecoins used in the U.S. must register with the OCC and submit to ongoing supervision , and they must hold a portion of their reserves in U.S. financial institutions sufficient to satisfy U.S. redemption requests. This latter requirement ensures that U.S. holders of a foreign stablecoin can redeem locally without depending entirely on foreign banks. It also gives U.S. regulators some leverage (since those reserves in the U.S. can be overseen or frozen if needed). The Act gives the Treasury Secretary (along with other agencies) flexibility to waive certain requirements for foreign issuers and for digital asset intermediaries that deal in foreign stablecoins , if such waivers are in the U.S. interest. This could allow, for example, transitional arrangements or special cases if a strict application of the rules would disrupt markets. Overall, these foreign issuer provisions aim to extend the regulatory perimeter internationally  – encouraging other countries to implement similar standards and preventing the U.S. from becoming a haven for unregulated stablecoins, or conversely, preventing circumvention of U.S. rules via offshore entities. Other Notable Provisions In addition to the core elements above, the GENIUS Act contains a few other notable legal provisions: Executive Officials and Conflicts of Interest:  Partly in response to concerns about high-level conflicts (the bill’s nickname “GENIUS” drew scrutiny around potential involvement of political figures in crypto ventures), the final Senate version added a provision affirming that existing federal ethics laws prohibit senior government officials (e.g. the President, Cabinet members) from issuing stablecoins . Federal Implementation Timeline:  The Act directs that the regulatory framework be put into effect within one year of enactment . This includes agencies promulgating all necessary regulations through notice-and-comment rulemaking. A one-year implementation deadline is an aggressive timetable, reflecting Congress’s desire to quickly stand up oversight  in a fast-moving crypto market. Regulators would need to coordinate and issue rules on licensing procedures, capital levels, examination guidelines, disclosure formats, etc., by that deadline. Continuation of Existing Authority:  Until the new rules are in place, the Act does not  immediately outlaw existing stablecoin activity. It implicitly allows current stablecoin issuers operating under state money transmitter laws or other exemptions to continue  during the interim. Likewise, the Office of the Comptroller of the Currency’s prior guidance that national banks may handle stablecoins remains effective until superseded. This avoids a disruption where stablecoins would suddenly become illegal before a pathway to compliance exists. The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

ESMA’s new guidelines stem directly from Article 92(3) of MiCA, which obliges the authority to harmonise how national competent authorities (NCAs) combat market abuse in crypto-asset markets by 30 June 2025. The final report, published on 29 April 2025, therefore fills a regulatory gap that MiCA itself created: the regulation outlawed insider dealing, unlawful disclosure and manipulation involving crypto-assets, yet supervisory cultures and data capabilities still vary widely across the EU. 1. Why ESMA issued these Guidelines Legal mandate  – Article 92(3) MiCA instructs ESMA to publish, by 30 June 2025, guidelines that harmonise how national competent authorities (NCAs) prevent and detect market abuse in crypto-asset markets. Regulatory gap  – MiCA extends market-abuse rules to crypto, but supervisory cultures, tooling and data availability still differ widely across Member States. Objective  – Provide a common, risk-based supervisory framework that builds on experience under the Market Abuse Regulation (MAR) while addressing crypto-specific threats such as maximal extractable value (MEV), token-supply manipulation and the outsized role of social-media hype. 2. Scope, status and implementation timetable Element Details Addressees All EU NCAs (Article 3(1)(35) MiCA) Subject matter Supervision of insider dealing , unlawful disclosure  and market manipulation  involving crypto-assets (Title VI MiCA, Arts 86-92) Entry into force 3 months after the multilingual version appears on ESMA’s website Comply-or-explain Within 2 months of publication, each NCA must notify ESMA whether it will (i) comply, (ii) comply later, or (iii) not comply, giving reasons. ESMA will publish the list. Relationship to RTS Complements the forthcoming Regulatory Technical Standards on Suspicious Transaction or Order Reports (STORs) required under Art 92(2) MiCA. 3. Guiding principles and cross-cutting themes Proportionality (Guideline 1)  – Supervisory intensity must reflect the scale, complexity and risk  of local crypto-markets and actors. Risk-based & forward-looking approach (Guideline 2)  – NCAs should continuously scan for emerging  abuse typologies (e.g., on-chain front-running, algorithmic manipulation) and adapt oversight swiftly. Leverage existing MAR know-how (Guideline 3)  – Before inventing new controls, map current MAR surveillance to crypto contexts and plug the gaps (e.g., add MEV detection). Build a common EU supervisory culture (Guideline 4)  – Systematic peer-exchange of cases, data and best practices via ESMA working groups; potential ESMA convergence tools where divergent practices persist. Adequate & specialised resources (Guideline 5)  – Dedicated crypto teams, data scientists and bespoke tooling; tap initiatives such as the EU Supervisory Digital Finance Academy for staff up-skilling. Stakeholder dialogue (Guideline 6)  – Maintain open channels with industry, academia, tech providers and public-interest groups to anticipate new threats and co-design solutions. Market-integrity outreach (Guideline 7)  – NCAs should run public-education campaigns, issue Q&As and encourage voluntary best practices (e.g., issuer insider-lists, platform user warnings). 4. Operational supervision and enforcement tools Area Key expectations Market monitoring (Guideline 8) Adopt data-driven  surveillance combining on-chain, off-chain and cross-market feeds; supplement automated scans (pattern/keyword) with human analysis; include social-media, blogs, newsletters and podcasts where they influence prices. Oversight of PPAETs * (Guideline 9) Ensure Persons Professionally Arranging or Executing Transactions maintain effective, continuously reviewed  abuse-detection systems; apply proportionate intensity (e.g., full trading-venue vs. order-transmission CASPs). STOR handling (Guideline 10) Put in place clear internal workflows that assign responsibilities, grade severity/recurrence, and ensure timely follow-up; response must be proportionate to the threat detected. ESMA coordination (Guideline 11) Seek ESMA-led joint inspections/investigations in cross-border cases involving multiple NCAs, risk of conflicting actions, or undue burden on firms. Third-country obstacles (Guideline 12) Alert ESMA and peers when non-EU trading flows, legal barriers or uncooperative foreign authorities hamper abuse detection; strive for a common supervisory stance toward such obstacles. *PPAET = firms (often CASPs) that professionally arrange or execute crypto transactions. 5. Crypto-specific risk considerations woven into the Guidelines MEV & front-running  – Recognised as potential insider dealing/market manipulation vectors that require bespoke detection logic. Token mechanics  – Sudden changes in supply, reserve backing (for asset-referenced/stablecoins) or governance decisions can be exploited for price manipulation. Social-media virality  – Higher risk of pump-and-dump or misinformation campaigns; NCAs are urged to monitor high-reach accounts and coordinated posting patterns. Cross-border trading & DeFi  – Surveillance must cover platforms and liquidity venues outside the EU; data-gathering may depend on blockchain analytics and cooperation agreements. 6. Stakeholder feedback and ESMA’s adjustments Securities & Markets Stakeholder Group (SMSG)  broadly endorsed the draft but asked for stronger emphasis on NCA staffing, training and consumer-protection links. ESMA’s response (Annex II)  – Added explicit encouragement for dedicated crypto resources  and ongoing training (Guideline 5). Suggested voluntary dialogue with other authorities (consumer-protection, AML) under Guideline 4, while noting legal-basis constraints. Reaffirmed proportionality so smaller markets are not over-burdened. 7. Next steps for NCAs and industry Translation & publication  – ESMA will release the final Guidelines in all EU languages. NCA notices  – Within 2 months, each NCA must file its comply/intentions statement. ESMA will disclose any non-compliance publicly. Practical adoption  – NCAs integrate the Guidelines into national frameworks; market participants (especially PPAETs and trading-venue CASPs) should align internal surveillance and STOR processes accordingly. 8. Key take-aways for market participants Expect more uniform and data-intensive surveillance  across the EU, including scrutiny of your social-media communications. STOR obligations  will soon follow detailed RTS templates; start enhancing your detection logic now (on-chain & off-chain reconciliation, MEV scenarios, cross-asset signals). Prepare for dialogue with supervisors —NCAs will actively seek feedback on new risks and may issue guidance or best-practice checklists. Cross-border models  (routing flow to non-EU venues, DeFi aggregators) may attract heightened attention where they frustrate EU supervision. Prokopiev Law Group is a forward-thinking Web3 legal consultancy that bridges breakthrough blockchain ideas with the world’s fast-moving regulatory frameworks. Operating from Kyiv yet connected to a network that spans more than 50 jurisdictions, the firm delivers end-to-end support—from incorporating and structuring crypto ventures to drafting DAO governance, token-sale and data-protection documentation, and securing the licences and cross-border compliance investors expect under regimes such as MiCA. Its lawyers pair deep, specialised expertise with clear, business-oriented advice, letting founders and funders focus on building while PLG shoulders the legal heavy lifting. The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

The Guidelines apply to competent authorities, financial market participants, and any individual or entity engaged in crypto-asset activities. They seek to clarify how Article 2(5) of MiCA should be applied when determining whether a crypto-asset qualifies as a financial instrument. They come into force sixty days after their publication in all official EU languages on ESMA’s website, happened on March 19, 2025. Legislative References, Abbreviations, and Definitions Underpinning these Guidelines are several core pieces of legislation. The most central of these are MiFID II (Directive 2014/65/EU), AIFMD (Directive 2011/61/EU), MiCA (Regulation (EU) 2023/1114), UCITSD (Directive 2009/65/EC), the Money Market Fund Regulation (2017/1131/EU), and the ESMA Regulation (Regulation (EU) 1095/2010). They also make reference to DLTR (Regulation (EU) 2022/858), which governs pilot regimes for distributed ledger technology.Relevant abbreviations include AIF for Alternative Investment Fund, ART for Asset-Referenced Token, CASP for Crypto-Asset Service Provider, DLT for Distributed Ledger Technology, EMT for Electronic Money Token, and NFT for Non-Fungible Token. Classification of Crypto-Assets as Transferable Securities (Guideline 2) To determine whether a crypto-asset qualifies as a transferable security, it is important to verify whether the crypto-asset grants rights equivalent to those attached to shares, bonds, or other forms of securitised debt. The text of MiFID II (Article 4(1)(44)) underpins this assessment. According to the Guidelines, three main criteria must be cumulatively fulfilled. First, a crypto-asset must not be an instrument of payment, so if its sole use is as a medium of exchange, it would not qualify as a transferable security. Second, the crypto-asset must belong to a “class” of securities, meaning that it confers the same rights and obligations to all holders or else belongs to a distinct class within the issuance. Third, it must be “negotiable on the capital market,” which generally means that it can be freely transferred or traded, including on trading platforms equivalent to those covered by MiFID. If all these points are satisfied, then the crypto-asset should be classified as a transferable security and treated under the same rules that govern traditional instruments. Classification as Other Types of Financial Instruments Money-Market Instruments (Guideline 3) A crypto-asset that would be considered a money-market instrument must normally be traded on the money market and should not serve merely as an instrument of payment. The crypto-asset should exhibit features akin to short-term negotiable debt obligations, such as treasury bills or commercial paper, and typically have a short maturity or a fixed redemption date. An example might be a token representing a certificate of credit balance repayable within a short timeframe, though it must be clearly distinguishable from mere payment tools. Units in Collective Investment Undertakings (Guideline 4) A crypto-asset qualifies as a unit or share in a collective investment undertaking if it involves pooling capital from multiple investors, follows a predefined investment policy managed by a third party, and pursues a pooled return for the benefit of those investors. The focus is on whether participants lack day-to-day discretion over how the capital is managed and whether the project is not purely commercial or industrial in purpose. An example would be a token representing ownership in a fund-like structure that invests in a portfolio of other digital or traditional assets; if it meets the criteria from existing definitions in AIFMD and UCITSD (excluding pure payment or operational tools), it may be deemed a collective investment undertaking. Derivative Contracts (Guideline 5) The Guidelines recognize two broad scenarios for derivatives: crypto-assets can serve as the underlying asset for a derivative contract, or they can themselves be structured as derivative contracts. In both cases, reference must be made to Annex I Section C (4)-(10) of MiFID II, which identifies features such as a future commitment (forward, option, swap, or similar) and a value derived from an external reference point, such as a commodity price, interest rate, or another crypto-asset. Whether the derivative settles in fiat or crypto is not decisive if the essential characteristics of a derivative are present. This includes perpetual futures or synthetic tokens that track an index or basket of assets, provided they fit into one of MiFID II’s derivative categories. Emission Allowances (Guideline 6) A crypto-asset may be considered an emission allowance if it represents a right to emit a set amount of greenhouse gases recognized under the EU Emissions Trading Scheme, in line with Directive 2003/87/EC. If the token is interchangeable with official allowances and can be used to meet compliance obligations, it should then be regulated under MiFID II as an emission allowance. On the other hand, self-declared carbon credits or voluntary offsets that are not recognized by EU authorities do not fall under this category. Background on the Notion of Crypto-Assets Classification as Crypto-Assets (Guideline 7) The Guidelines reiterate that a crypto-asset, in general, is a digital representation of value or rights, transferred and stored via DLT. If it cannot be transferred beyond the issuer or if it is purely an instrument of payment, it typically falls outside the scope of these financial-instrument rules. Moreover, the fact that a holder anticipates profit from a token’s appreciation is not by itself sufficient to qualify the token as a financial instrument. Crypto-Assets That Are Unique and Non-Fungible (NFTs) (Guideline 8) Non-fungible tokens, which are unique and not interchangeable with each other, are excluded from MiCA provided they genuinely fulfill the requirement of uniqueness. This means having distinctive characteristics or rights that cannot be matched by any other asset in the same issuance. Merely assigning a unique technical identifier to each token is not enough to establish non-fungibility if the tokens effectively grant identical rights and are indistinguishable in economic reality. Fractionalizing an NFT into multiple tradable pieces typically renders those fractional parts non-unique unless each part has distinct attributes of its own. Hybrid Crypto-Assets (Guideline 9) Some tokens combine features typical of multiple crypto-asset categories, such as partial investment features (like profit participation) alongside a utility function (like access to a digital service). If, on closer assessment, any component of the token fits the definition of a financial instrument under MiFID II, the financial instrument classification applies, taking precedence over other labels. The Guidelines thus underline that hybrid tokens must be evaluated under a substance-over-form approach, with a focus on their actual rights, obligations, and economic features rather than how the issuer labels them. Conclusion Taken as a whole, the Guidelines demonstrate ESMA’s intention to ensure that all tokens conferring rights equivalent to conventional financial instruments are appropriately supervised under MiFID II. Although labels such as “utility” or “NFT” may be used by issuers, the ultimate question is whether the token’s real-world function and associated rights align with those of a security, a derivative, or another regulated category. By following this approach, authorities and market participants can maintain consistent, technology-neutral regulation in the fast-evolving crypto-asset space. Prokopiev Law Group stays at the forefront of Web3 compliance and regulatory intelligence, offering strategic support across NFT legal solutions, DAO governance, DeFi compliance, token issuance, crypto KYC, and smart contract audits. Leveraging a broad global network of partners, we ensure your project meets evolving regulations worldwide, including in the EU, US, Singapore, Switzerland, and the UK. If you want tailored guidance to protect your interests and remain future-proof, write to us for more information. Reference: Guidelines on the conditions and criteria for the qualification of crypto-assets as financial instruments The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

How do electronic money (e-money) and electronic money tokens (EMTs) differ, and what are the regulatory frameworks governing them within the European Economic Area (EEA)? Definition and Regulation of E-Money Tokens (EMTs) E-Money Tokens (EMTs): EMTs are a specific type of crypto-asset, their value typically pegged to a single fiat currency such as the Euro or US Dollar. These crypto-assets represent digital value or rights that can be transferred and stored electronically through distributed ledger technology (DLT) or similar systems. DLT operates as a synchronized information repository shared across multiple network nodes. Regulatory Framework: The Markets in Crypto-Assets Regulation EU 2023/1114 (MiCA) outlines stringent conditions for the issuance of EMTs. Key points include: EMTs can only be issued by credit institutions or Electronic Money Institutions (EMIs) regulated by an EEA regulator. MiCA came into effect in June 2023 and will be fully applicable from December 30, 2024. Issuer Obligations Under MiCA: Prudential, Organizational, and Conduct Requirements: Issuers must adhere to specific prudential standards, organizational requirements, and business conduct rules, including: Issuing EMTs at par value. Granting holders redemption rights at par value. Prohibiting the granting of interest on EMTs. White Paper Requirements: Issuers are mandated to publish a white paper with detailed information such as: Issuer details: Name, address, registration date, parent company (if applicable), and potential conflicts of interest. EMT specifics: Name, description, and details of developers. Public offer details: Total number of units offered. Rights and obligations: Redemption rights and complaints handling procedures. Underlying technology. Associated risks and mitigation measures. Significant e-money tokens (EMTs) are subject to higher capital requirements and enhanced oversight by the European Banking Authority (EBA). Significant EMTs are defined as those which can scale up significantly, potentially impacting financial stability, monetary sovereignty, and monetary policy within the EU. The EBA mandates that issuers of significant EMTs hold additional capital reserves. Specifically, significant issuers must maintain capital that is the higher of either €2 million or 3% of the average reserve assets. The EBA monitors these issuers closely, requiring detailed reports on their financial health and risk management practices. Issuers of significant EMTs must also adhere to comprehensive reporting obligations. They need to provide regular updates on their liquidity positions, stress testing results, and compliance with redemption obligations. Definition and Regulation of Electronic Money Electronic Money (E-Money): E-money is defined as electronically or magnetically stored monetary value representing a claim on the issuer. Its characteristics include: Issued upon receipt of funds for the purpose of payment transactions. Accepted by entities other than the issuer. Not excluded by Regulation 5 of the European Communities (Electronic Money) Regulations 2011 (EMI Regulations). Exclusions Under Regulation 5: The EMI Regulations exclude monetary value stored on specific payment instruments with limited use and monetary value used for specific payment transactions by electronic communications service providers. Electronic Money Institutions (EMIs): An EMI is an entity that has been authorized to issue e-money under the EMI Regulations, which is necessary for any e-money issuance within the EEA. Comparative Analysis of E-Money and EMTs Definition: E-Money:  Electronically stored monetary value represented by a claim on the issuer. EMTs:  Crypto-assets whose value is usually linked to a single fiat currency. Issuers: E-Money:  Issued by EMIs upon receipt of funds for making payment transactions. EMTs:  Issued by EMIs and/or credit institutions. Legal Regime: E-Money:  Governed by the European Communities (Electronic Money) Regulations 2011. EMTs:  Governed by MiCA. Status: E-Money:  Not necessarily an EMT, but can be depending on how it is transferred and stored. EMTs:  All EMTs are also considered e-money. To ensure compliance with the latest regulations and navigate the Web3 legal landscape, please contact Prokopiev Law Group. Our expertise in cryptocurrency law, smart contracts, and regulatory compliance, combined with our extensive global network of partners, guarantees that your business adheres to both local and international standards. The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

The Cyprus Securities and Exchange Commission (CySEC) has initiated a preliminary assessment phase for Crypto-Asset Service Providers (CASPs)  applying under the forthcoming EU Markets in Crypto-Assets Regulation (MiCA). Effective today, November 13, 2024 , CASPs in Cyprus can submit applications to CySEC in preparation for MiCA’s full implementation on December 30, 2024. This step by CySEC aligns with the MiCA framework, a regulation setting standardized rules for crypto-asset markets across the EU. As part of this preliminary phase, CySEC has made application and notification forms accessible on its website for CASPs and other financial entities authorized under Article 60 of MiCA, including investment firms, UCITS managers, and alternative investment fund managers, to submit notifications or seek authorization under Article 63. Important Points for this Preliminary Phase: During this phase, CySEC will receive applications from both entities currently regulated under Cyprus’ national crypto-asset laws and new market entrants aiming for MiCA compliance. While accepting applications early, CySEC retains the discretion to prioritize applications, particularly for entities already regulated under existing Cyprus’ crypto-asset rules. Submissions during this preliminary phase will be officially considered upon completion of formalities, including fee payment and verification of information accuracy by December 30, 2024. CySEC will make final decisions on granting/refusing authorization, as well as on the completeness of submitted notifications, after MiCA officially applies to CASPs on December 30, 2024. Reminder of Transitional Measures and Applicability Dates CySEC also reminds interested parties of a recent announcement  regarding MiCA's phased applicability. MiCA became effective for issuers of Asset-Referenced Tokens (ARTs) and E-Money Tokens (EMTs) on June 30, 2024, and will extend to CASPs on December 30, 2024. Under MiCA’s transitional measures, CASPs registered under National Rules before December 30, 2024, may continue to provide their services until July 1, 2026, or until CySEC grants or refuses authorization per Article 63, whichever is sooner. Additionally, as of October 17, 2024, CySEC ceased accepting any CASP applications for registration under National Rules in view of MiCA becoming applicable to CASPs on 30 December 2024. So that, CySEC’s early application phase for MiCA is helping crypto service providers in Cyprus get ready for new EU rules, making the transition easier and clearer for everyone involved. The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

The EU's Markets in Crypto-Assets Regulation (MiCA) came into full effect on 30 December 2024 , following its initial entry into force on 29 June 2023. MiCA establishes the EU as the first major jurisdiction to regulate crypto-assets comprehensively. It creates a harmonized framework for crypto-asset issuance and services, covering various types of crypto-assets such as asset-referenced tokens (ARTs), electronic-money tokens (EMTs) and other crypto-assets (this blanket category covers utility tokens and other crypto-assets that don't qualify as ARTs or EMTs). This regulation also introduces a pan-European licensing and supervisory system for issuers, platforms, and crypto-asset service providers (CASPs). Notably, Titles III and IV, dealing with ARTs and EMTs, were applied from 30 June 2024.   As of 30 December 2024, the European Securities and Markets Authority (ESMA) is empowered under Articles 109 and 110 of the MiCA Regulation to maintain and publish a central register of crypto-asset white papers, authorized crypto-asset service providers (CASPs), and non-compliant entities. This register will be sourced from the relevant National Competent Authorities (NCAs) and the European Banking Authority (EBA).   To meet the legal deadline, ESMA has created an interim MiCA register , which will be updated and republished regularly. This interim register, accessible on the MiCA webpage and the Databases and Registers page, will be available as a collection of CSV files until mid-2026, when it will be formally integrated into ESMA’s IT systems. The interim register includes five CSV files, which cover:   ·      White papers for crypto-assets other than asset-referenced tokens (ARTs) and e-money tokens (EMTs)  (Title II) ·      Issuers of asset-referenced tokens (Title III) ·      Issuers of e-money tokens (Title IV) ·      Authorized crypto-asset service providers  (Title V) ·      Non-compliant entities providing crypto-asset services   Although four of the five files in the interim MiCA register are currently empty, the file related to issuers of EMTs contains crucial information. As of January 06, 2025, this file lists companies that have obtained authorization to issue e-money tokens under MiCA . Companies like: Membrane Finance Oy; Circle Internet Financial Europe SAS; Société Générale – Forge; Banking Circle S.A.; Quantoz Payments B.V. and Fiat Republic Netherlands B.V. are included in this file, showcasing their official approval status and providing access to their relevant white papers, authorization dates, and other key details.   ESMA will update the register on a monthly basis , and while information will be reported by competent authorities on a rolling basis, it will not appear in the register immediately. Records in the interim MiCA register will reflect the information provided by the relevant authorities. If an authorization is withdrawn by a competent authority, the record will remain in the register, noting the date when the withdrawal took effect.   With the establishment of the interim MiCA register and its regular updates, the European Union continues to lead the way in creating a transparent and compliant digital finance environment. We will continue to monitor and report on further updates to the MiCA framework and its impact on the crypto industry. The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.

The European Commission (the ‘Commission’) issued the Guidelines on the definition of an artificial intelligence system under Regulation (EU) 2024/1689 (“AI Act”). The AI Act entered into force on 1 August 2024; it lays down harmonised rules for the development, placing on the market, putting into service, and use of artificial intelligence (‘AI’) in the Union. The Guidelines focus on clarifying Article 3(1) AI Act, which defines an “AI system” and therefore determines the scope of the AI Act. They are meant to help providers and other relevant persons (including market and institutional stakeholders) decide whether a specific system meets the definition of an AI system. They emphasize that the definition took effect on 2 February 2025 , alongside relevant provisions (Chapters I and II, including prohibited AI practices under Article 5). The Guidelines are not legally binding ; the ultimate interpretation belongs to the Court of Justice of the European Union. Key Elements of the AI System Definition AI System Article 3 (1) of the AI Act defines an AI system as follows:‘“AI system” means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments;’ According to the Guidelines, this definition comprises seven main elements: A machine-based system; Designed to operate with varying levels of autonomy; That may exhibit adaptiveness after deployment; For explicit or implicit objectives; Infers, from the input it receives, how to generate outputs; Such outputs include predictions, content, recommendations, or decisions; Which can influence physical or virtual environments. These elements should be interpreted with an understanding that AI systems exhibit machine-driven functionality, some autonomy, and possibly self-learning capabilities, but always within a context of producing outputs that “can influence” their surroundings. Machine-Based System The term ‘machine-based’ refers to the fact that AI systems are developed with and run on machines… The hardware components refer to the physical elements of the machine… The software components encompass computer code, instructions, programs, operating systems, and applications…” The Guidelines  clarifies that “All AI systems are machine-based…” to emphasize computational processes (model training, data processing, large-scale automated decisions). This covers a wide variety of computational systems, including advanced quantum ones. Autonomy The second element of the definition refers to the system being ‘designed to operate with varying levels of autonomy’. Recital 12 of the AI Act clarifies that the terms ‘varying levels of autonomy’ mean that AI systems are designed to operate with ‘some degree of independence of actions from human involvement and of capabilities to operate without human intervention’. Full manual human involvement excludes a system from being considered AI. A system needing manual inputs to generate an output can still have “some degree of independence of action,” making it an AI system. Autonomy and risk considerations become particularly important in high-risk use contexts (as listed in Annex I and Annex III of the AI Act). Adaptiveness “(22) The third element… is that the system ‘may exhibit adaptiveness after deployment’. … ‘adaptiveness’ refers to self-learning capabilities, allowing the behaviour of the system to change while in use.” The word “may” means adaptiveness is not mandatory for a system to be classified as AI. Even if a system does not automatically adapt post-deployment, it may still qualify if it meets the other criteria. AI System Objectives “(24) The fourth element… AI systems are designed to operate according to one or more objectives. The objectives… may be different from the intended purpose of the AI system in a specific context.” Objectives are internal to the system, such as maximizing accuracy. The intended purpose (Article 3(12) AI Act) is external, reflecting the practical use context. Inferencing How to Generate Outputs “(26) The fifth element of an AI system is that it must be able to infer, from the input it receives, how to generate outputs. …This capability to infer is therefore a key, indispensable condition that distinguishes AI systems from other types of systems.” The capacity to derive models, algorithms, and outputs from data sets AI apart from simpler software that “automatically execute[s] operations” via predefined rules alone. AI Techniques that Enable Inference “(30) Focusing specifically on the building phase… ‘machine learning approaches that learn from data how to achieve certain objectives, and logic- and knowledge-based approaches that infer from encoded knowledge or symbolic representation of the task to be solved.’ Those techniques should be understood as ‘AI techniques’.” Machine Learning  approaches: Supervised  (e.g., spam detection) Unsupervised  (e.g., drug discovery) Self-supervised  (e.g., predicting missing pixels, language models) Reinforcement  (e.g., autonomous vehicles, robotics) Deep Learning  (e.g., large neural networks) Logic- and Knowledge-Based  approaches: Use encoded knowledge , symbolic rules, and reasoning engines. The Guidelines cite examples such as classical natural language processing models based on grammatical logic, expert systems for medical diagnosis, etc. Systems Outside the Scope “(40) Recital 12 also explains that the AI system definition should distinguish AI systems from ‘simpler traditional software systems or programming approaches and should not cover systems that are based on the rules defined solely by natural persons to automatically execute operations.’” Systems aimed at improving mathematical optimization (e.g., accelerating well-established linear regression methods, parameter tuning in satellite telecommunication systems) remain outside if they do not “transcend ‘basic data processing.’” Basic data processing (sorting, filtering, static descriptive analysis, or visualizations) with no learning or reasoning also does not qualify. “Systems based on classical heuristics” (experience-based problem-solving that is not data-driven learning) are excluded. Simple prediction systems, employing trivial estimations or benchmarks (e.g., always predict the mean) do not meet the threshold for “AI system” performance. Outputs That Can Influence Physical or Virtual Environments “(52) The sixth element… the system infers ‘how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments’. … The capacity to generate outputs… is fundamental to what AI systems do and what distinguishes those systems from other forms of software.” The Guidelines  detail four output categories: Predictions Content Recommendations Decisions Each type represents increasing levels of automatic functionality. Systems that produce these outputs from learned or encoded approaches generally fit the AI criteria. Interaction with the Environment “(60) The seventh element of the definition of an AI system is that system’s outputs ‘can influence physical or virtual environments’. That element should be understood to emphasise the fact that AI systems are not passive, but actively impact the environments in which they are deployed.” Influence may be physical (like controlling a robot arm) or digital (e.g., altering a user interface or data flows). Concluding Remarks “(61) The definition of an AI system encompasses a wide spectrum of systems. The determination of whether a software system is an AI system should be based on the specific architecture and functionality of a given system…” “(63) Only certain AI systems are subject to regulatory obligations and oversight under the AI Act. …The vast majority of systems, even if they qualify as AI systems… will not be subject to any regulatory requirements under the AI Act.” This underscores the risk-based approach in the AI Act: most AI systems face no or minimal obligations, while high-risk systems come under stricter prohibitions (Article 5), conformity requirements (Chapter II, Article 6), or transparency rules (Article 50). The Guidelines  highlight that general-purpose AI models also fall under the AI Act (Chapter V), but detailed distinctions between them and “AI systems” exceed the scope of these Guidelines. Overall, these Guidelines precisely delineate what qualifies as an AI system. They serve as a structured reference for developers, providers, and other stakeholders to assess whether a given solution falls under Regulation (EU) 2024/1689. Link: Guidelines on the definition of an artificial intelligence system established by Regulation (EU) 2024/1689 (AI Act) If you need further guidance on AI compliance, DeFi compliance, NFT compliance, DAO governance, Metaverse regulations, MiCA regulation, stablecoin regulation, or any other web3 legal matters, write to us. Prokopiev Law Group has a broad global network of partners, ensuring your compliance worldwide, including in the EU, US, Singapore, Switzerland, Hong Kong, and Dubai. The information provided is not legal, tax, investment, or accounting advice and should not be used as such. It is for discussion purposes only. Seek guidance from your own legal counsel and advisors on any matters. The views presented are those of the author and not any other individual or organization. Some parts of the text may be automatically generated. The author of this material makes no guarantees or warranties about the accuracy or completeness of the information.