The regulatory landscape for European agentic commerce

The commercial deployment of AI agents capable of executing consequential transactions, selecting payment instruments, and authenticating to third-party services on behalf of a human principal presents European regulators with a configuration that existing instruments were not designed to address directly. An agentic commerce system differs from a recommendation engine or a fraud-detection model in one critical respect: it acts. The agent does not present options to a human who then clicks; it executes the downstream action autonomously, often within a multi-step orchestration chain in which no individual step crosses a human-approval threshold even though the cumulative financial or contractual outcome is significant.

The European Union has responded to the general challenge of AI governance with a layered legislative programme whose seven principal instruments were developed largely in parallel, under different institutional mandates, and with different definitions of key terms. The AI Act addresses system-level risk classification and transparency obligations [1][2][4]. The DSA allocates liability for intermediary platforms. The DMA imposes interoperability and fair-access obligations on gatekeepers. PSD3 updates the authorisation and strong customer authentication framework for payment services. eIDAS 2.0 establishes the European Digital Identity Wallet and the trust framework for electronic attestations. GDPR governs personal data processing throughout the chain. MiCA establishes a licensing regime for crypto-asset service providers and stablecoin issuers [3].

None of these instruments uses the term 'agentic system' as a defined category. Each therefore applies to agentic commerce only through the mediation of its own definitional framework, producing coverage that is uneven across the functional stack. The purpose of this paper is to make that unevenness precise: to identify, for each layer of the agentic stack, which articles of which instruments apply, where two instruments produce conflicting obligations, where an instrument applies in text but its enforcement mechanism is undefined for agent-generated actions, and where no instrument applies at all.

Section 2 defines the agentic stack as an analytical object. Section 3 maps each instrument to each layer. Section 4 characterises the three categories of regulatory friction. Section 5 presents the operative calendar through 2027. Section 6 offers structural recommendations. Section 7 states the limitations of the analysis.

2.1 Defining the Stack

For the purposes of this analysis, an agentic commerce system is decomposed into five functional layers. This decomposition is not the only one possible, but it tracks the points at which legal obligations are most likely to attach.

Layer 1: Foundation Model. The large language model or multimodal model that generates plans, selects tools, and produces natural-language outputs. The model may be hosted by the deploying operator or accessed via API from a third-party provider. The distinction matters for AI Act obligations, which assign duties differently to 'providers' (those who develop or place on the market) and 'deployers' (those who put a system into use).

Layer 2: Orchestration Logic. The software layer that decomposes a high-level goal into sub-tasks, routes sub-tasks to tools, manages state across steps, and enforces any guardrails the operator has configured. Orchestration logic is frequently proprietary and is the layer at which most commercially sensitive design decisions are made.

Layer 3: Tool and API Integration. The set of external services to which the agent has credentialed access: payment rails, identity verification services, e-commerce APIs, calendar and communication systems, and data stores. This layer is where the agent's actions reach external systems with legally binding effect.

Layer 4: Identity and Credential Management. The mechanisms by which the agent authenticates to external services, presents identity attestations, and satisfies strong customer authentication requirements. This layer intersects with eIDAS 2.0 and PSD3 most directly.

Layer 5: User Interface and Consent Surface. The interface through which a human principal authorises the agent's scope of action, reviews proposed actions, and exercises rights (including GDPR data-subject rights). Obligations under GDPR, the AI Act's transparency provisions, and PSD3's informed-consent requirements concentrate at this layer.

2.2 The Autonomous Execution Problem

The analytical challenge that motivates this paper is that most European instruments operate on a transactional model in which a natural person or legal entity performs a discrete, identifiable action. GDPR's consent mechanism assumes a data subject who, at a defined moment, agrees to processing. PSD3's strong customer authentication assumes a payment service user who, for each transaction, provides at least two authentication factors. The AI Act's transparency obligations assume a user who receives an AI-generated output and can, in principle, evaluate it.

Agentic systems break this transactional model in two ways. First, a single human authorisation event (configuring an agent with a spending limit and a set of permitted merchants) generates an indefinite number of downstream transactions, each of which an instrument written for the single-transaction model may treat as requiring independent authorisation. Second, the agent's decisions are distributed across the orchestration chain: no single actor produces the final output in isolation, making it structurally difficult to assign the legal status of 'provider', 'deployer', 'payment service provider', or 'data controller' to a single entity.

These two structural features, the single-authorisation-to-many-transactions gap and the distributed-decision attribution problem, generate most of the regulatory friction catalogued in Section 4.

3.1 EU AI Act

The AI Act classifies AI systems by risk tier and assigns obligations to providers and deployers accordingly [1][2][4]. For agentic commerce systems, three provisions are most operative.

Article 6 and Annex III (high-risk classification). An agentic commerce system that makes or materially influences credit decisions, creditworthiness assessments, or insurance pricing falls within Annex III's high-risk categories covering AI systems used in access to essential private services and in credit assessment. The classification triggers the full suite of Article 9 (risk management), Article 10 (data governance), Article 13 (transparency and provision of information to deployers), Article 14 (human oversight), and Article 17 (quality management) obligations on the provider.

Article 50 (transparency obligations for certain AI systems). Even for systems below the high-risk threshold, Article 50 requires deployers to inform natural persons that they are interacting with an AI system unless it is obvious from context. In an agentic commerce setting where the agent communicates with third-party merchants or service providers, the deployer must ensure that each counterparty merchant receives disclosure. The 'obvious from context' carve-out has not yet been operationalised through implementing acts, creating interpretive uncertainty.

Articles 51 to 55 (general-purpose AI model obligations). Where the foundation model at Layer 1 is a general-purpose AI (GPAI) model with systemic risk designation (cumulative training compute exceeding 10^25 floating-point operations), the model provider bears additional obligations: adversarial testing, incident reporting to the AI Office, and cybersecurity measures. These obligations sit on the provider, not the deployer, but the deployer's contractual arrangements with the provider determine whether the deployer has access to the documentation needed to satisfy its own Article 13 obligations downstream.

The AI Act's enforcement architecture assigns national market surveillance authorities (MSAs) as the primary enforcement body for high-risk AI systems, with the AI Office retaining direct supervisory competence over GPAI model providers. For agentic systems that cross the GPAI threshold at Layer 1 while deploying a non-high-risk application at Layers 2 through 5, two separate enforcement channels operate simultaneously on different actors in the same stack [4].

3.2 Digital Services Act

The DSA applies to intermediary services, with escalating obligations for online platforms and, at the top tier, very large online platforms (VLOPs) and very large online search engines (VLOSEs). Its relevance to agentic commerce is primarily at Layer 3 (Tool and API Integration) and Layer 5 (User Interface).

Article 26 (online advertising transparency). Where an agent operates within a marketplace platform, and the platform delivers advertising that influences the agent's purchasing decisions, the DSA's advertising transparency obligations apply to the platform. Whether the agent constitutes a 'recipient of the service' for DSA purposes is unresolved. The DSA defines 'recipient' as any natural or legal person who uses an intermediary service; an autonomous agent is neither, creating a definitional gap.

Article 28 (protection of minors) and Article 14 (notice-and-action). These provisions presuppose human recipients; their application to agent-mediated transactions is unclear.

Articles 34 and 35 (systemic risk assessment and mitigation for VLOPs). A VLOP that provides API access to agentic systems must assess whether that access creates systemic risks to fundamental rights, public security, or electoral integrity. Agentic commerce systems that can execute large-scale purchasing operations across a VLOP's marketplace at machine speed present a plausible systemic risk vector that Article 34's risk categories do not explicitly enumerate.

3.3 Digital Markets Act

The DMA's obligations fall on 'gatekeepers': platforms designated by the Commission under Article 3 on the basis of size, intermediation role, and entrenched market position. Its relevance to agentic commerce is concentrated at Layer 3.

Article 5(a) (self-preferencing prohibition). A gatekeeper operating both a marketplace and an AI assistant layer that routes agent-initiated purchases to its own listings violates Article 5(a). The Commission's investigations into gatekeeper practices have begun to surface configurations structurally similar to this, though agentic routing specifically has not yet been the subject of a formal finding.

Article 6(f) (interoperability for ancillary services). Gatekeepers must allow third-party payment service providers to interoperate with their platforms. For an agentic system that prefers a gatekeeper's own payment instrument by default (because the API integration is tighter or the authentication friction is lower), the deployer may be contributing to the gatekeeper's non-compliance with Article 6(f), even though the deployer is not itself the obligated party.

Article 7 (messenger interoperability). For agents that manage communication on behalf of a user, Article 7's messaging interoperability obligations on gatekeepers affect the tools available at Layer 3.

3.4 Payment Services Directive 3 (PSD3) and the Payment Services Regulation (PSR)

PSD3, together with the accompanying Payment Services Regulation, is the instrument most directly operative at Layer 4 (Identity and Credential Management) and the Layer 5 consent surface for payment initiation.

PSD3's legislative status as of 2025 is: Commission proposal issued in June 2023; trilogue negotiations ongoing; the instrument is not expected to enter into force before late 2025 at the earliest, with a transposition period likely extending into 2027. The current PSD2 framework therefore remains operative for the foreseeable near term, and operators deploying agentic payment systems before PSD3 transposition must comply with PSD2's strong customer authentication (SCA) requirements under Regulatory Technical Standard (RTS) on SCA and Common and Secure Communication.

SCA and agent-initiated payments. PSD2 Article 97 requires SCA for electronic payments unless an exemption applies. The exemptions most relevant to agentic commerce are the recurring transaction exemption (Article 14, RTS on SCA) and the trusted beneficiary exemption. An agent that initiates a new transaction to a previously unenrolled beneficiary falls outside both exemptions and, in principle, requires fresh SCA. The practical consequence is that a human principal who authorises an agent to make purchases within a spending limit cannot, under current PSD2 architecture, delegate that SCA obligation to the agent; the agent must trigger a return authentication event to the human principal for each qualifying transaction. This produces a structural incompatibility between the agentic commerce model (continuous autonomous execution) and the PSD2 model (per-transaction human authentication).

PSD3's proposal introduces an explicit framework for 'payment delegation' in recital form, acknowledging that delegated authentication tokens may be issued by a payment service user to a third party. The operative articles have not yet been finalised, and the scope of the delegation framework as it applies to AI agents (as distinct from human third-party payees with a mandate) remains open.

Open banking API obligations. PSD3 strengthens the open banking framework by requiring that banks provide production-quality APIs to third-party providers (TPPs) without degradation. An agentic commerce system acting as a payment initiation service provider (PISP) or account information service provider (AISP) must obtain the corresponding authorisation from its national competent authority. The question of whether an AI agent itself (as distinct from the legal entity deploying it) can hold a PSP licence is answered by reference to the legal personality requirement in PSD2/PSD3: only legal persons can be authorised, so the deploying entity holds the licence, but the agent executes actions under that licence. Liability for agent-initiated transactions that fall outside the scope of the principal's consent remains with the licensed entity.

3.5 eIDAS 2.0

The revised eIDAS Regulation, adopted in 2024, introduces the European Digital Identity Wallet (EUDI Wallet) and a framework for electronic attestations of attributes (EAAs). Its primary relevance to agentic commerce is at Layer 4.

The EUDI Wallet and agent access. The EUDI Wallet is designed as a user-controlled instrument: the holder (a natural person or legal entity) presents attributes to relying parties upon request. The Regulation does not define a mechanism by which an AI agent can present attributes on behalf of a wallet holder without that holder's active involvement in each presentation event. The architecture of the wallet, as specified in the implementing acts for the Architecture and Reference Framework (ARF), contemplates a mobile device in the physical possession of the holder initiating each attribute presentation. An agentic system that needs to present identity attributes to a merchant or financial institution at machine speed, without polling the human principal for each presentation, requires either a delegated credential mechanism or a background presentation flow neither of which is explicitly authorised in the current ARF.

Qualified electronic signatures and agent delegation. eIDAS 2.0 preserves the qualified electronic signature (QES) framework from eIDAS 1.0. A QES is linked to the signatory's personal certificate issued by a qualified trust service provider (QTSP). For an agent to execute contracts on behalf of a principal using a QES, the principal would need to delegate signing authority through a power of attorney registered with the QTSP, or through a qualified electronic seal (which applies to legal persons). Neither mechanism is optimised for the high-frequency, low-value transaction profile characteristic of agentic commerce.

3.6 GDPR

GDPR applies wherever the agentic stack processes personal data relating to an identified or identifiable natural person, which encompasses substantially all commercially deployed agentic systems.

Data controller and processor allocation. Article 4(7) defines 'controller' as the entity that determines the purposes and means of processing. In an agentic stack, the operator of the orchestration layer (Layer 2) determines the purposes (achieve the user's commercial objective) and means (which tools to call, in what order, with what data) of processing personal data. The operator is therefore the controller. The foundation model provider at Layer 1, if processing personal data solely on the operator's instructions, is a processor under Article 4(8), and a data processing agreement (DPA) under Article 28 is required.

Article 22 (automated decision-making). Article 22 grants data subjects the right not to be subject to decisions based solely on automated processing that produce legal or significant effects. An agent-initiated payment, a credit limit adjustment, or a contract execution each produces a legal effect. If the human principal is also the data subject (a consumer using an agent to manage personal finances), the operator must provide either a human review mechanism, an explicit consent basis, or rely on the necessity-for-contract basis, subject to national law restrictions. In B2B deployments where the data subject is a third-party individual affected by the agent's commercial decisions (for example, a vendor whose offer is rejected by an agent), the Article 22 right may vest in that third party, requiring the deployer to implement a mechanism for handling third-party Article 22 requests.

Data minimisation and purpose limitation. Agentic systems operating at Layer 3 through multiple API integrations routinely ingest data beyond what is strictly necessary for the immediate transaction. The orchestration layer's tendency to pass full context windows to each tool call creates a structural data minimisation violation risk under Article 5(1)(c). Operators must architect the tool-calling layer to strip personally identifying fields before passing context to tools that do not require them.

Article 13/14 transparency obligations. Where the agent processes personal data about the user, Article 13 requires disclosure at collection time. Where it processes data about third parties (merchants, counterparties), Article 14 requires disclosure within one month unless disproportionate effort applies. The disproportionate effort exception may apply where the agent processes data about thousands of merchants in the course of price comparison, but the deployer must document the exception.

3.7 MiCA

MiCA applies to the issuance and trading of crypto-assets, including asset-referenced tokens (ARTs) and e-money tokens (EMTs), and to crypto-asset service providers (CASPs) [3][5]. Its relevance to agentic commerce is conditional: it applies where the agent initiates transactions involving crypto-assets or where the agent operates within a DeFi or tokenised payment rail.

CASP authorisation. Article 59 requires entities providing crypto-asset services (custody, exchange, transfer, portfolio management) to obtain authorisation from their national competent authority. An agentic system that autonomously manages a portfolio of crypto-assets on behalf of a user is functionally a crypto-asset portfolio manager. The legal entity deploying the agent must hold the relevant CASP authorisation; the same legal-personality constraint as in PSD3 applies.

EMT issuers and payment agents. Where an agent uses an e-money token as a payment instrument (for example, a euro-denominated stablecoin issued by an authorised EMT issuer), the transaction chain involves at minimum the EMT issuer (regulated under MiCA Title IV), the CASP executing the transfer, and the deployer of the agent. MiCA's allocation of liability between the EMT issuer and the CASP does not address agent-initiated transfers specifically; the operative question of whether the deployer's instruction to the agent constitutes a 'transfer order' under MiCA Article 3(1)(26) is unresolved [3].

Market manipulation and agentic trading. MiCA Article 91 prohibits market manipulation in crypto-asset markets, defined to include transactions that fix prices at artificial levels or that create misleading signals about supply or demand. An agent operating a treasury management function that executes many small buy or sell orders in a tokenised asset market could, even without manipulative intent, produce price signals that fall within Article 91's behavioural definition. The intent standard in Article 91(2) references 'persons' who act with knowledge; whether that standard is satisfied when the behaviour is generated by an autonomous system acting within operator-defined parameters is an open interpretive question.

4.1 Genuine Gaps

Gap 1: Agent legal personality and liability attribution. No European instrument assigns legal personality to an AI agent or establishes a primary liability rule for damages caused by agent-generated actions that cannot be attributed to a single human decision. The Product Liability Directive revision and the AI Liability Directive proposal address some upstream liability questions, but neither instrument was enacted as of early 2025, and neither addresses the specific configuration of a licensed PSP that deploys an agent which initiates payments outside the scope of the user's original authorisation. The result is that liability defaults to the deploying entity under general tort and contract principles, but the procedural mechanisms for the affected party to identify, notify, and pursue that entity are not defined in any of the seven instruments.

Gap 2: Agent-to-agent transactions. All seven instruments are written for transactions between human principals or legal entities. Where one agentic system transacts with another (an AI purchasing agent negotiates with an AI sales agent), no instrument directly governs the transaction-formation process. Contract law governs the enforceability of the resulting agreement, but the identity verification, anti-money laundering (AML), and consumer protection obligations that attach to the human-to-human or human-to-business transaction either do not apply (because no natural person is transacting directly) or apply in ways that make the transaction operationally impossible (because each instrument assumes a human actor at the authentication step).

Gap 3: Orchestration layer transparency. The AI Act's transparency obligations under Article 50 and the GPAI model documentation requirements under Articles 51 to 55 address the foundation model and the output surface. Neither the AI Act nor any other instrument requires disclosure of the orchestration logic that governs how the agent decomposes goals, selects tools, and manages state. The orchestration layer is where operators make the commercially consequential design decisions (risk appetite, vendor preference, data retention), yet it is the layer least addressed by the regulatory framework. The AI Act's technical documentation requirements for high-risk systems (Annex IV) require documentation of the system's purpose, components, and architecture, which would capture some orchestration-layer decisions for high-risk classified systems, but non-high-risk agentic commerce systems carry no equivalent requirement [2][4].

4.2 Overlaps Producing Conflicting Obligations

Overlap 1: AI Act Article 14 human oversight versus PSD3 payment delegation. The AI Act's Article 14 requires deployers of high-risk AI systems to ensure that natural persons can effectively oversee the system and intervene when necessary. For a high-risk agentic payment system, this requires the deployer to maintain a human-in-the-loop mechanism capable of interrupting any transaction. PSD3's proposed payment delegation framework, by contrast, is premised on removing per-transaction human intervention for delegated payment mandates. A deployer that has obtained PSD3 delegation authorisation for a mandate is complying with PSD3 by executing payments without human confirmation, while simultaneously risking non-compliance with AI Act Article 14 if the system is high-risk classified. The two obligations cannot both be satisfied in full without product-level design trade-offs that neither instrument articulates.

Overlap 2: GDPR Article 22 and AI Act Article 14. Both provisions address automated decision-making, but with different scope, different rights, and different obligation-bearers. GDPR Article 22 is a data-subject right exercisable by any natural person against any controller whose automated processing produces a legal effect on that person. AI Act Article 14 is a deployer obligation to maintain human oversight over high-risk AI systems. For a financial decision (credit, insurance, payment authorisation) made by a high-risk AI system, the data subject may invoke Article 22 to obtain human review, while the MSA may simultaneously audit the deployer for Article 14 compliance. The two proceedings address overlapping facts but use different legal tests, different standards of proof, and involve different enforcement authorities (the data protection authority for GDPR; the MSA for the AI Act). A deployer found compliant under one regime may simultaneously be found non-compliant under the other if the human review mechanism satisfies GDPR's 'meaningful human involvement' standard but fails the AI Act's requirement that the overseer have the 'authority, competence and resources' to intervene [2].

Overlap 3: DSA Article 26 advertising obligations and DMA Article 5(a) self-preferencing. Where a gatekeeper's AI assistant steers agent-initiated purchases toward the gatekeeper's own listings, the same behaviour is potentially actionable under DSA Article 26 (as undisclosed commercial influence on a recipient of the service) and DMA Article 5(a) (as self-preferencing). The DSA enforcement route runs through the Digital Services Coordinator in each member state; DMA enforcement is exclusively a Commission competence under Article 26 DMA. A simultaneous national DSA investigation and Commission DMA investigation into the same conduct by the same gatekeeper is procedurally possible and would produce parallel proceedings with no statutory coordination mechanism.

4.3 Enforcement Ambiguities

Ambiguity 1: Which national authority is competent for cross-border agentic stacks. An agentic commerce system may have its foundation model provider established in Ireland (under AI Act, supervised by the Irish MSA), its orchestration layer operated by a company established in Germany (German MSA for high-risk AI; German data protection authority for GDPR), its payment initiation licence held by a UK-incorporated entity passporting into the EU under PSD2 (national competent authority of the EU member state of the passporting-in entity), and its crypto-asset custody provided by a CASP established in France (French AMF). The AI Act's cross-border coordination mechanism (Article 74) provides for cooperation between MSAs but does not address the interaction with sectoral supervisors (financial regulators, data protection authorities). For a compliance failure that propagates through all four layers simultaneously, four separate enforcement proceedings before four different authorities in up to four different member states are possible, with no single authority having a consolidated view of the agentic stack.

Ambiguity 2: The 'user' and 'recipient' definitional mismatch. PSD3 defines the payment service user as the natural or legal person making use of a payment service. The AI Act defines the 'user' as the natural or legal person deploying the AI system (now relabelled 'deployer' in the final text) and separately uses 'affected person' for those subject to the system's outputs. GDPR defines the 'data subject' as a natural person whose data is processed. The DSA defines 'recipient of the service' as any person who uses the service. In an agentic commerce stack, the human principal is simultaneously the PSD3 payment service user, the GDPR data subject, the DSA recipient of the service, and (if they configure the agent) the AI Act deployer. When a compliance failure occurs, identifying which definition controls the relevant right (and therefore which instrument's enforcement mechanism is invoked) requires a case-by-case analysis that the instruments do not guide.

Ambiguity 3: MiCA's market manipulation intent standard applied to agent behaviour. As noted in Section 3.7, MiCA Article 91 references knowledge as an element of the market manipulation prohibition. Where an agent's optimisation objective (minimise transaction costs within a mandate) produces behaviour that, in aggregate, constitutes artificial price fixing, the deployer's intent is likely absent: the operator did not instruct the agent to manipulate prices. Whether absent intent at the operator level exculpates the deployer entirely, or whether a negligence standard applies to the design of an agent known to be capable of affecting market prices, is unresolved. The European Securities and Markets Authority (ESMA) has not yet issued guidance on the application of market integrity rules to AI-generated trading behaviour in crypto-asset markets [5].

The regulatory friction catalogued in Section 4 does not resolve itself through compliance with each instrument individually. An operator that achieves full compliance with each of the seven instruments in isolation may still face enforcement exposure at the interfaces between instruments. The following structural recommendations address those interfaces.

6.1 Establish a Cross-Instrument Compliance Architecture Before August 2026

The August 2026 activation of AI Act high-risk system obligations creates a hard deadline for operators to resolve the Overlap 1 tension between Article 14 human oversight and PSD3 payment delegation. The resolution requires a product-level design decision: either the system is classified as not high-risk (which requires a defensible classification rationale documented in the Article 9 risk management system), or the system is high-risk and the human oversight mechanism is designed to satisfy both Article 14 and any applicable PSD3 delegation framework. This decision cannot be deferred to the legal team at the point of audit; it must be embedded in the system's architecture from initial deployment.

Operators should maintain a single compliance matrix that maps each agentic stack layer to the specific articles of each applicable instrument, documents the design decision taken at each point of conflict, and records the legal basis for that decision. This matrix serves as the foundation for both the AI Act's technical documentation requirement under Article 11 and the GDPR Article 30 records of processing activities, avoiding the duplication of documentation that would result from treating each instrument's documentation requirement independently.

6.2 Resolve Data Controller Attribution Before Deployment

The GDPR controller determination (Section 3.6) is the foundation for all downstream data-subject rights obligations, DPA requirements, Article 22 compliance, and cross-border data transfer rules. Operators who defer the controller determination until a data subject files a complaint face the risk that the determination, when made under adversarial conditions, attributes controller status to the entity with the deepest pockets rather than the entity with the most design authority.

The recommended practice is to conduct a processing activity analysis at the Layer 2 (orchestration) design stage, mapping each data flow to the actor that determines its purpose and means. Where joint controllership under Article 26 GDPR arises (for example, where both the foundation model provider and the orchestration operator co-determine purposes), the Article 26 arrangement should be negotiated and documented before the system processes live data.

6.3 Engage National Competent Authorities on Cross-Layer Jurisdiction Before the Enforcement Calendar Activates

Enforcement Ambiguity 1 (Section 4.3) identifies the absence of a single competent authority with consolidated visibility over the agentic stack. Until the AI Act's Article 74 cooperation mechanisms develop operational practice, operators cannot rely on competent authorities to coordinate between themselves. The prudent approach is for operators to conduct a jurisdictional mapping of their stack, identify the MSA, DPA, financial regulator, and DSA Digital Services Coordinator competent for each layer, and engage each authority proactively where the operator's configuration is novel.

Proactive engagement serves two distinct functions. First, it creates a documented record of good-faith compliance effort that is relevant to the proportionality of any subsequent sanction. Second, it surfaces regulatory interpretations before they are established adversarially: the question of whether a given agentic payment system is high-risk under AI Act Annex III, for example, is better resolved in a pre-authorisation dialogue than in an enforcement investigation.

6.4 Design the Consent Surface for Dual-Instrument Compliance

The user interface at Layer 5 must satisfy, simultaneously, GDPR consent requirements (where consent is the processing basis), AI Act Article 50 transparency obligations, PSD2/PSD3 informed consent for payment initiation, and eIDAS 2.0 requirements for identity attribute disclosure. Each instrument specifies different content, timing, and record-keeping requirements for consent or disclosure. A single consent surface designed to the most demanding specification across all four instruments is more robust than four separate disclosures, but achieving that design requires identifying the most demanding specification for each element (content, timing, format, record retention) and designing to that standard.

For the SCA challenge specifically: until PSD3's payment delegation framework is finalised, operators should implement a consent architecture that supports both per-transaction SCA (as required under current PSD2) and a pre-authorised mandate structure (preparatory for PSD3), with the technical capability to switch between the two without a full re-engineering cycle. The cost of dual-architecture maintenance is lower than the cost of a PSD2 SCA enforcement action followed by a PSD3 re-build.

6.5 Monitor the MiCA DeFi Review and Calibrate Crypto-Asset Tool Integration Accordingly

The December 2027 MiCA DeFi review (Section 5) will be the first authoritative regulatory statement on whether agentic commerce systems operating on decentralised infrastructure fall within MiCA. Operators whose agentic systems use tokenised payment rails, stablecoins, or crypto-asset custody should monitor the Commission's preparatory work for that review, including ESMA consultation papers and national competent authority guidance, and avoid locking in technical dependencies on instruments whose regulatory status is under active review. Where possible, the Layer 3 tool integration layer should be designed with the capability to substitute a MiCA-compliant payment instrument for a non-compliant one without disrupting Layers 1 and 2.

The European regulatory framework for agentic commerce is a structure assembled from instruments designed for distinct purposes, each of which reaches into the agentic stack at specific functional layers without providing a consolidated account of how the layers interact. The analysis presented in this paper identifies the points at which that structure produces genuine gaps, conflicting obligations, and enforcement ambiguities that cannot be resolved through compliance with any single instrument.

The three genuine gaps identified are: the absence of a liability attribution rule for agent-generated actions that do not trace to a single human decision; the absence of any framework governing agent-to-agent transactions; and the absence of transparency obligations at the orchestration layer for non-high-risk systems. These gaps are not artefacts of drafting imprecision; they reflect the structural challenge that autonomous systems present to regulatory frameworks organised around human actors and discrete transactional events.

The three overlaps producing conflicting obligations are: the tension between AI Act Article 14 human oversight and PSD3 payment delegation; the simultaneous application of GDPR Article 22 and AI Act Article 14 to automated financial decisions, enforced by different authorities using different legal tests; and the procedurally uncoordinated intersection of DSA advertising obligations and DMA self-preferencing prohibitions as applied to gatekeeper AI assistants.

The three enforcement ambiguities are: the absence of a consolidated supervisory authority across the agentic stack's multiple regulated layers; the definitional mismatch between 'user', 'recipient', 'deployer', and 'data subject' across instruments, which determines which right and which authority applies to a given compliance failure; and the unresolved application of MiCA's market manipulation intent standard to agent-generated trading behaviour.

For operators deploying agentic commerce systems in EU jurisdictions, the period from early 2025 through August 2026 is the highest-consequence transition window. During this window, the GPAI model obligations, DSA obligations, MiCA obligations, and GDPR obligations are simultaneously operative, while the high-risk AI system obligations and PSD3 payment delegation framework are not yet in force. An operator who designs for the post-August 2026 state from the outset, rather than retrofitting compliance to an already-deployed system, avoids the compounding cost of sequential re-engineering across seven instruments on a compressed timeline.

The longer-term trajectory of this regulatory landscape depends on three institutional developments that this analysis identifies but cannot resolve through the available evidence. First, the AI Office's development of operational practice under Article 74 will determine whether cross-layer coordination between MSAs, DPAs, and financial regulators becomes a practical reality or remains a textual aspiration. Second, the PSD3 payment delegation provisions, once finalised, will either resolve or entrench the Overlap 1 tension with AI Act Article 14 depending on whether the delegation framework is drafted to accommodate high-risk AI system oversight requirements. Third, the MiCA DeFi review, scheduled for December 2027, will determine the regulatory perimeter for agentic commerce operating on decentralised infrastructure, a category of deployment that is growing faster than the regulatory instruments governing it.

The structural incompatibility between instruments designed for transactional human actors and systems that execute autonomously across multiple regulated domains is not a problem that operators can engineer around at the product level alone. It requires legislative and regulatory coordination of a kind that the current European institutional architecture supports in principle, through co-regulation, the AI Act's governance board, and the planned coordination between the European Banking Authority, ESMA, and the AI Office, but has not yet produced in operational terms [1][4][5]. Operators, compliance teams, and technical architects who treat the seven instruments as a coherent system, mapping obligations at the design stage rather than the audit stage, are better positioned to navigate the transition than those who address each instrument's requirements in isolation as enforcement actions clarify their scope.

Several limitations bound the analysis presented in this paper.

First, the legislative calendar presented in Section 5 reflects the state of information available in early 2025. PSD3 trilogue negotiations, AI Act implementing acts, and eIDAS 2.0 Architecture and Reference Framework specifications are all subject to revision, and the operative dates cited should be verified against current official sources before being used for compliance planning.

Second, the layer mapping in Section 3 adopts a five-layer decomposition that tracks legally relevant functional boundaries. Systems deployed in practice will vary in architecture, and some deployments will collapse layers (for example, a vertically integrated operator who controls both the foundation model and the orchestration logic) or multiply them (for example, a multi-agent system where orchestration is itself distributed across multiple specialised agents). The mapping should be adapted to the specific architecture under analysis rather than applied mechanically.

Third, the paper does not address the application of sector-specific financial regulation (the Markets in Financial Instruments Directive, the Mortgage Credit Directive, the Consumer Credit Directive) to agentic commerce systems operating in those sectors. Each of those instruments contains its own automated decision-making, transparency, and suitability obligations that interact with the seven instruments examined here in ways that require separate analysis.

Fourth, the analysis treats EU member state implementation of directives (PSD3, DSA to the extent transposed) as uniform, which will not be the case in practice. National transposition choices in areas where directives permit member state discretion will create compliance heterogeneity across jurisdictions within the single market that the harmonisation project of these instruments is intended, but not guaranteed, to minimise.