PCI Watch

Tracking changes across the Payment Card Industry

EMV® Agentic Payments Specification - Technical Framework v1.0 DRAFT: Disposition of Comments

v1.0 Framework

Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026

of 52 2.3, 4.2.2, 4.2.3, 6.7.2 Sec 2.3 / 4.2 / 6.7.2 te (MAJOR) The framework states that how the Consumer is authenticated is out of scope, but the referenced verifiable mechanism (Verifiable Intent, Sec 6) is built on Consumer-held FIDO/WebAuthn holder- binding keys (Layer 1 binds the Consumer public key; Layer 2 is signed with the Consumer private key; FIDO is listed in the abbreviations). No fallback is described for Consumers who authenticate by another method. Small businesses reach their agent from a wide range of devices (shared back-office PCs, kiosk devices, terminal devices, SMS/voice), many of which cannot perform a WebAuthn ceremony. Making a Consumer-held private key the de facto delegation root would exclude a meaningful share of small businesses from autonomous flows and make the issuer unable to choose an authentication method appropriate to device and risk context. Add explicit language (Sec 2.3, 4.2.2/4.2.3) that the Payment Credential Provider (issuer) MAY support multiple, interchangeable Consumer authentication methods to establish Layer 1/Layer 2 authority, including but not limited to FIDO/WebAuthn passkeys, issuer-app out- of-band approval, 3-D Secure challenge, OTP, or server-/cloud-custodied keys, with verifiability guarantees defined at the layer boundary rather than at the authentication- method level. Clarify in Sec 6.7.2 that holder binding to a Consumer-held key is one delegation model and that custodial/server-side signing on the Consumer's behalf (with issuer attestation of a non-WebAuthn authentication event) is also accommodated. Reject The Framework does not prescribe or require a specific Consumer authentication methods, including FIDO/WebAuthn. Section 6 of the EMVCo Framework is derived from a then current version of verifiable intent v0.1. Proposals for expansion, redesign and additional details should be referred to FIDO as custodian of the Verifiable Intent Specification. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026

of 52 6.2.1, 6.2.2, 6.3.1, 6.5, 6.7.5 Sec 6.2.1 / 6.3.1 te (MAJOR) The checkout mandate and its constraints rely on clean, resolvable identity and catalog data: a stable merchant identifier with name, web domain and logo (6.2.1); a stable payee identifier (6.2.2); merchant allowlists and line-item/product allowlist entries used for constraint evaluation and selective disclosure (6.3.1, 6.5); and a merchant-signed cart record whose hash anchors the checkout-payment binding (6.7.5). Nothing accommodates sellers whose catalog lacks structured product identifiers (GTIN/UPC/SKU) or a stable, independently verifiable merchant/domain identity. Small businesses frequently have limited data (limited functionality on website, no logo uploaded, and non- standard catalog data), so agents that can only build verifiable line-item constraints or resolve products against well-identified catalogs will systematically favor large merchants with clean product feeds and disadvantage small merchants trying to sell through agentic channels. 1) Explicitly support degraded-identity modes: allow checkout mandates and line- item constraints to reference free- text/merchant-local product descriptors and a platform-attested merchant identity where standard identifiers (GTINs, etc.) and independently verifiable domains are absent, so constraint evaluation and binding do not require high-quality catalog data. 2) Explicitly support ‘agent-native’ shopping channels (not just websites) such as Universal Commerce Protocol (UCP) profiles. 3) Allow a platform/acquirer to vouch for merchant identity and cart integrity on behalf of small sellers rather than assuming each merchant self-produces a stable identifier and signed record. 1. Reject 2. Reject 3. Accept 1. Any new specific constraints or types that can be defined to support degraded identity modes is possible to be included in the VI specs. Current list is not in- exhaustible. Section 6 of the EMVCo Framework is derived from a then current version of verifiable intent v0.1. Proposals for expansion, redesign and additional details should be referred to FIDO as custodian of the Verifiable Intent Specification. 2. The current VI specs, which section 6 is derived from is defined to work together with AP2 that integrates directly on UCP as an extension 3. The framework describes roles versus entities. We will provide language that Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026

of 52 clarifies that an entity may perform the functions associated with multiple roles. 4.1.1, 6.2.2, 6.7.5 Sec 4.1.1 te (MINOR) Immediate Mode is defined around a fixed final amount ('an exact amount'; 'the Intent contains consumer approved values for cart, payment and final values'), and enumerates taxes, shipping and discounts but not tips or gratuity. The closed Payment Mandate carries a single amount (6.2.2) and the checkout-payment hash binding is deliberately brittle (6.7.5: any modification after signing breaks the binding). The draft contains no concept of tip, gratuity, incremental authorization, capture tolerance or overcapture. This does not fit many small business verticals (local and home services, salons, F&B, delivery), where a tip is added at/after service and the captured amount routinely exceeds the authorized cart, and where auth-then-capture-higher is normal. Autonomous Mode has amount-range constraints (6.3.2) but Immediate Mode has no equivalent tolerance. 1) Add a bounded, Consumer-consented tolerance/gratuity allowance to the Immediate Mode closed mandate (approved base amount plus a tip/adjustment ceiling, percentage or absolute) so final capture can exceed the signed cart within pre-consented bounds without breaking the binding. 2) Clarify how the checkout-payment binding tolerates a capture amount that differs from the authorized amount (auth vs capture is a first-class card-payments reality). 3) Explicitly enumerate tips/gratuity alongside taxes/shipping/discounts in Sec 4.1.1. Accept The framework may be updated to include gratuities/tips as an example component of a final amount where applicable. However, the framework does not define authorisation/capture processing rules, gratuity tolerances, over capture limits, or incremental authorisation behaviour. Immediate Mode is intended for consumer-approved amounts, while payment processing and settlement variations remain subject to existing payment system and merchant implementation rules. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026

of 52 4.2, 1.2.2, 6.5, 6.2.3, 6.4.3 Sec 4.2 (participan t list) te (MINOR) Sec 4.2 states the 'Merchant may use the Intent to ensure the Checkout Context matches the Payment Mandate and may provide a Mandate Pair to complement the Intent.' This assigns the merchant two non-trivial jobs (validate cart against the cryptographically bound Payment Mandate, and possibly produce a Mandate Pair). 1) Clarify the merchant's role in autonomous mode: is the merchant a verifier of the checkout mandate only, or is it also expected to validate against the Payment Mandate and/or produce a Mandate Pair? 2) Reconcile Sec 4.2's requirement that the merchant ensure the Checkout Context matches the Payment Mandate with Sec 1.2.2's exclusion of merchant checkout validation logic; if merchants must validate, provide at least a conceptual validation contract. 3) Explicitly allow a platform/acquirer to perform mandate validation and Mandate Pair production on the merchant's behalf so the capability requirement does not fall on individual small sellers. 1. 1. Accept 2. Reject 3. Accept 1. Accepted. We will review Section 4.2 to clarify the merchant’s role and ensure it does not imply that the merchant is required to receive or validate the Payment Mandate or produce a Mandate Pair. 2. Clarification. Section 4.2 provides illustrative examples of capabilities that are technically possible within the Intent flow and is not intended to define merchant checkout validation requirements. Merchant checkout validation logic remains outside the scope of this Framework. 3. Already addressed. The Framework describes Merchant and Acquirer roles together and allows either to interact with Intent artefacts as appropriate. The Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026

of 52 Framework does not prescribe which participant must perform implementation-specific mandate validation or Mandate Pair production.

4.1.2 Autonomou s Mode; also relevant to 4.3.2 and 6.2.4 Paragraph beginning “The interaction between the Consumer and the agent…” te — MAJOR The statement that the Consumer authorises the agent to make the purchase using the Consumer’s “default or selected payment method” may imply that a specific payment instrument must be selected and bound to the Intent at the time of delegation. This may unnecessarily restrict autonomous use cases in which the Consumer wishes to authorise the agent to select from among multiple eligible payment instruments at execution time. The most appropriate instrument may depend on information that is not available when the Intent is created, including merchant acceptance, transaction value, currency, availability of funds, fees, benefits or other Consumer-defined preferences. Requiring a specific instrument to be selected at delegation time may also embed payment- system or routing choices before the merchant, transaction and acceptance context are known. This is particularly relevant where a credential or account supports multiple payment options. Clarify that an autonomous Intent may authorise:

  • a specific payment instrument;
  • a bounded set or category of eligible payment instruments; or
  • selection of an eligible payment instrument by the Agent at Fulfilment time, subject to Consumer-defined Constraints. The framework should not require the final payment credential or payment system to be determined before the execution context is known. Reject The current scope of the Framework assumes that a specific payment card has been selected by the Consumer and associated with the authorised Intent. Selection by an Agent among multiple eligible payment cards or payment credentials is not within the scope of this version of the Framework. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 4.2.2 Layer 1 — Trust Establishm ent;

6.4.1 Layer 1: Identity Root and Trust Establishm ent;

6.4.2 Layer 2 Layer 1 description and reference to the DPC Card credential te — MAJOR The framework should avoid implying that a separate Layer 1 credential and separate Consumer interaction are necessarily required for each payment instrument that may be used under an Intent. A Consumer may hold several payment instruments in the same Wallet and may wish to authorise an Agent to select between them within defined Constraints. Requiring the Consumer to separately authenticate or establish a separate delegation chain for every eligible instrument could create significant friction and undermine the customer experience benefits of agentic commerce. The draft states that Layer 1 may bind the Consumer’s public key to a payment credential or identity, while identifying the DPC Card credential as one potential implementation. It would be helpful to clarify whether the trust root could instead be established through an identity-based, Wallet-level or other payment- instrument-neutral credential, with the specific payment instrument selected and validated later in the flow. This comment is not intended to prescribe the authentication or credential mechanism, which may sit outside EMVCo’s scope. However, the framework should preserve the ability for a single Consumer authorisation experience to support a bounded set of eligible payment instruments, subject to the applicable issuer, payment-system and risk requirements. Clarify that:

  • the DPC Card credential is illustrative and Layer 1 need not be bound exclusively to one individual card;
  • Layer 1 may be rooted in a verified Consumer identity, Wallet relationship or another appropriate trust credential;
  • the framework may support delegation over a bounded set of payment instruments; and
  • implementations should not require repeated Consumer interaction solely because more than one eligible payment instrument is available. Reject The current scope of the Framework assumes that a specific payment card has been selected by the Consumer and associated with the authorised Intent. Selection by an Agent among multiple eligible payment cards or payment credentials is not within the scope of this version of the Framework. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 General / 1.1 / 5.9 Framework objective; Section 5.9 ge The framework is well placed to provide a common foundation around existing and future payment-system-specific agentic payment propositions. However, Section 5.9 could be read as allowing materially different implementations provided they use similar terminology. Common semantics will not reduce integration complexity if agents, wallets, merchants and acquirers must still implement separate, non-portable artefacts and interfaces for each payment system. Clarify that the intended outcome is convergence around common payment-layer semantics and portable artefacts and identifiers. Existing and future proprietary propositions should be expected to map to, and where necessary adjust to conform with, the common framework, while payment systems retain autonomy over risk, rules and commercial implementation. Accept Language will be considered that clarifies that the intended outcome is convergence around a common framework without being prescriptive on risk, rules and commercial implementation. 4.1.2 / 4.3.2 / 6.2.2 / 6.4.2 / 6.9.2 Autonomous Mode; Payment Mandate and credential reference te (MAJOR) In Autonomous Mode, the Consumer may approve a default or selected payment method before the merchant is known, and the Payment Mandate contains a payment credential reference. For a co-badged or multi-network debit card, a network-specific credential reference could determine the payment system at delegation time. This would occur before merchant acceptance and routing information is available and could remove a routing decision that would otherwise occur at execution. State a requirement that selection of a funding credential or card does not necessarily select the payment system used for execution. The framework should support route-neutral or multi- network credential references and allow the execution network to be selected once merchant and acquirer context is available, subject to any explicit Consumer network choice or override. Reject Given the document is published as an informative framework, it does not lay out requirements for any participant. The framework as currently written does not preclude multi-network funding credentials. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 4.2.2 / 6.4.1 Layer 1 trust establishme nt; DPC Card candidate te (MAJOR) Layer 1 is described as a long-lived card-level trust credential, with the DPC Card credential identified as a potential candidate. The framework does not make clear how Layer 1 represents a card that is eligible to transact over more than one payment system. If Layer 1 is issued or interpreted as network-specific, it may fragment the delegation chain or embed exclusive network selection before the transaction context exists. Clarify that Layer 1 may represent an issuer-level, co-badged or otherwise multi-network payment credential and may be verifiable by each eligible payment system. Layer 1 trust anchors and credential-provider roles should not require an exclusive association with one payment system. Reject The framework is intended to support payment credentials that may be accepted across one or more payment systems, including co-badged credentials. However, payment system selection, routing, consumer choice, merchant choice, and related processing rules are outside the scope of this framework. These considerations do not alter the Layer 1 trust establishment model and remain governed by the applicable payment systems, issuers, merchants, and regulatory requirements. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 6.2.2 / 6.5 Payment Mandate recipients; role-based visibility te (MAJOR) The separation of checkout and payment data supports privacy, but the visibility model should also account for payment acceptance and routing. For a multi-network credential, a merchant or acquirer may require limited information about eligible payment systems or credential capabilities to make an execution- time acceptance or routing decision. A strict interpretation that the merchant sees no payment-related information could prevent this without improving privacy materially. Clarify that role-based visibility is based on data minimisation rather than a binary separation. The model should permit selective disclosure of the minimum payment-system eligibility, acceptance or routing attributes required by the merchant or acquirer, without disclosing the full Payment Mandate. Reject This is in the scope of Verifiable Intent. Section 6 of the EMVCo Framework is derived from a then current version of verifiable intent v0.1. Proposals for expansion, redesign and additional details should be referred to FIDO as custodian of the Verifiable Intent Specification. 2.4 / 2.5 / 5.1-5.3 / 5.7-5.9 / 6.8 Intent Services and interoperable references te (MAJOR) The framework appropriately calls for stable references and interoperable identifiers, and allows payment systems or issuers to operate Intent Services. Identifier interoperability alone will not provide operational interoperability where multiple services exist. Participants must also be able to discover the responsible service, resolve a reference and obtain authorised access without separate bilateral integration with each service provider. Record as a requirement for future specification work that independently operated Intent Services support common discovery, resolution and authorised retrieval mechanisms, together with portability or federation sufficient for an Intent reference to be used across payment systems and implementations. Accept Language will be considered that indicates that future EMVCo Intent Service documentation will account for interoperability across Intent Service operators. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 5.5 / 6.3.2 / 6.7.6 Shared state; budget caps and stateful Constraints te (MAJOR) The draft indicates that cumulative budget state is typically maintained by the payment system. This assumes that all Fulfilments under a Mandate Pair are visible to one payment system. A multi-network credential, or an Intent fulfilled using more than one payment method, may result in transactions being processed by different systems. Fragmented state could permit cumulative limits to be exceeded, while assigning state to one system could itself preselect the execution network. Explicitly identify cross-payment-system state as an unresolved interoperability requirement. Future work should define an authoritative or coordinated state model for budgets, recurrence, single-use controls and replay protection that does not depend on all Fulfilments being routed through a preselected payment system. Reject The current scope of the Framework assumes a single payment credential for execution of an authorised Intent and does not contemplate Fulfilments under that Intent being executed across multiple payment credentials or payment systems. For the current Framework, where coordination across systems would be required, that coordination is expected to be managed by the Agent rather than defining a cross-payment- system state model. 2.5 / 5 / 5.8 / 6.10 Figures 3 and 5 te (MAJOR) Figures 3 and 5 place "Validate + execute payment" and "Execute payment" in the Intent Service Provider lane. This conflicts with Sections 2.5, 5 and 5.8, which state that an Intent Service is a registry and lifecycle coordinator and does not make payment authorisation decisions or act as an execution engine. The diagrams therefore blur separate roles even where one entity may perform both. Revise the figures to show payment validation, authorisation and execution in the appropriate Payment System, issuer, acquirer or PSP role. Limit the Intent Service Provider lane to registration, retrieval, lifecycle and state functions, or clearly separate the two roles where one entity performs both. Accept These figures will be updated prior to the next publication. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 4.1.2 / 4.2.1 Figure 2, steps (7)-(8) te (MINOR) Figure 2 is labelled as an Autonomous Mode flow but requires final Consumer approval of the cart and approval by signing the Intent at execution. This is inconsistent with Section 4.1.2, under which the Consumer is absent at execution and the Agent produces the final Layer 3 artefacts within the previously approved Layer 2 Constraints. Either revise Figure 2 to show Consumer approval of open Constraints during setup and Agent- signed Layer 3 Fulfilment at execution, or relabel the diagram as an Immediate or hybrid flow where the Consumer returns to approve final values. Accept These figures will be updated prior to the next publication. 3 KYA interoperable identification and future concepts te (MAJOR) The recognition of stable, interoperable agent identifiers is supported. Future KYA work should avoid requiring agents to acquire unrelated payment-system-specific identities that cannot be recognised elsewhere. At the same time, a common identifier should not imply common acceptance: each payment system and merchant may still apply its own qualification, risk and participation criteria. Add an explicit principle separating interoperable agent identity and baseline metadata from payment-system-specific trust and decisioning. Future registry or registry-reference models should support cross-system recognition, lifecycle updates and resolution without requiring a single central accreditation or acceptance model. Accept The task force will consider future guidance supporting interoperable agent identification and baseline agent information within future KYA and Agent Trust ecosystem models. Interoperable identification should not be interpreted as automatic trust, qualification, or acceptance. Trust, participation, and risk decisions remain ecosystem and implementation specific and are outside the scope of this framework. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 7 / 8 / 8.1 / 8.2 Agentic transaction indicators and future EMV/industr y messaging te (MAJOR) The inclusion of interoperable agentic transaction indicators is supported. A single binary "agentic" flag is unlikely to be sufficient for risk, dispute and operational use. Participants may need to distinguish immediate from autonomous execution, agent-assisted from agent-executed activity, and Consumer- signed from Agent-signed mandates, while correlating the transaction to stable Agent and Intent references across EMV and downstream payment messages. Retain and expand this section to establish minimum semantic requirements for future indicators and references, including end-to-end preservation through SRC, 3DS, tokenisation and relevant ISO 8583 or ISO 20022 messages. The indicators should be payment-system-neutral and usable in multi-network processing environments. In Progress This additional detail will be taken into consideration on the potential development of the role of EMVCo in agentic indicators. EMVCo is progressing with other standards bodies to determine ecosystem requirements for Agentic indicators. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 General; Sections 5, 5.1, 5.4– 5.7 and 5.9 Intent Services and Orders as Units of Fulfilment ge The framework is, understandably, expressly focused on card payments. However, the proposed role of an Intent Service - as a durable, interoperable anchor supporting registration, lifecycle coordination, shared state and multiple Orders - appears potentially relevant beyond a single payment method or payment system. A complex Consumer Intent may involve multiple merchants and multiple Fulfilments. Those Fulfilments may not all use the same payment instrument or payment rail. For example, an Agent could use a card payment for one Order and an account-to-account payment for another, while both form part of the same Consumer-authorised Intent and overall budget. If Intent Services are designed only around card-specific credentials and payment events, the same Consumer Intent may need to be fragmented across separate services and lifecycle models. This could make it difficult to maintain consistent cumulative budgets, recurrence limits, revocation, replay controls and overall Intent status across the complete fulfilment journey. This may extend beyond the specifications that EMVCo would itself develop. Nevertheless, it would be valuable for the framework to preserve cross-payment-method extensibility and to avoid architectural assumptions that prevent non-card payment systems from referencing or participating in the same Intent. Clarify whether the common Intent, Order, lifecycle and reference concepts are intended to be capable of accommodating Fulfilments using different payment methods or payment systems. Where card-specific Payment Mandates or execution mechanisms are defined, these should be clearly separated from the broader Intent Service and lifecycle concepts so that non-card payment methods could be supported through complementary standards without requiring the underlying Consumer Intent to be recreated or fragmented. Reject The current scope of the Framework assumes that a specific payment card has been selected by the Consumer and associated with the authorised Intent. Selection by an Agent among multiple eligible payment cards or payment credentials is not within the scope of this version of the Framework Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 General; Sections 1.1-1.2 Framewor k scope and boundarie s ge The framework should allow payment participants to consume independently governed agent identity and attestation evidence without creating a payment- specific identity credential or registry. A clear boundary will enable interoperability while allowing identity protocols to serve broader web, API, and non-payment use cases and evolve outside payment- network release cycles. Add a framework principle that EMVCo defines payment-layer interpretation, provenance requirements, and extension points for externally produced agent identity evidence, while credential issuance, presentation, privacy, and identity-trust governance remain outside this framework. In Progress EMVCo’s focus is on Agentic Payments in the context of card payments and does not intend to define general-purpose agent identity, credential issuance, or identity-trust governance. As external standards and solutions for agent identity, trust, verification and KYA evolve, EMVCo expects to consider how those capabilities are interpreted and used within the card- payment layer and whether additional payment-specific requirements or principles are needed. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 Section 2 Participant roles and responsibil ities te The participant model does not explicitly identify the Wallet, Agent Platform, Agent Identity/Attestation Issuer, Evidence Verifier, or authoritative lifecycle-state owner. It is therefore unclear who holds and uses the consumer key, who attributes or vouches for an agent, who consumes one-time evidence, and who owns state transitions. Add these functional roles and clarify that the consumer approves while the Wallet signs Layer 2 with the Layer 1-bound key. Distinguish merchant acceptance, acquirer transport, payment-network processing, issuer authorization, evidence verification, and authoritative Intent-state ownership. State that one entity may perform multiple roles without merging their trust assertions. Accept We will provide language that clarifies that an entity may perform the functions associated with multiple roles. Additional roles may be clarified in future use cases. Payment network processing, issuer authorisation and related implementation aspects are outside the scope of EMVCo, and may be addressed by ISO and other standard bodies Intent-state ownership can be defined as owned by the Intent Service providers associated with Card Payments. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 Section 3 Proposed Know Your Agent text te KYA currently combines several different subjects and assurances. Request-key possession, platform attribution, software/runtime attestation, principal attestation, principal disclosure, delegated authority, and payment authorization are not equivalent and may have different issuers, audiences, scopes, lifetimes, and revocation behavior. A single stable Agent Identifier would also introduce unnecessary cross-participant correlation. Decompose KYA into typed evidence categories. For each category, define its subject, issuer/producer, audience, scope, lifetime, revocation, provenance, and policy status. State that KYA is not a KYC- equivalent program and does not itself establish delegated authority or payment authorization. Require identifiers to be typed and scoped rather than globally stable by default. In Progress The framework addresses KYA at a conceptual level we will consider the comments and suggestions while developing additional revisions of the framework and specifications. General; Sections 3, 5, 6 and 8 Identifier, trust and privacy treatment te Cryptographic validity is different from deciding to trust an issuer, platform, or evidence producer. Stable identifiers, metadata classes, registries, receipts, Intent references, and payment records also create correlation even when an underlying credential is privacy- preserving. Require privacy and correlation analysis for every stable identifier and evidence field. Separate evidence validity from qualification/trust policy. Define signed trust- list freshness, emergency removal, retention, and distinct unknown, invalid, distrusted, and unavailable outcomes. In Progress The task force will consider additional guidance on privacy, trust, and accountability within KYA and Agent Trust ecosystems, including clarifying that validation of information is distinct from establishing trust. Detailed governance, operational processes, and trust- management requirements remain outside the scope of this framework. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 Section 8 Agentic Transactio n Indicators te A boolean agentic or trusted-agent indicator would combine involvement, evidence validity, trust policy, consumer presence, and authority into one ambiguous signal. Downstream parties need to know who evaluated which evidence, under which policy, and when. Indicators must not imply consumer authentication, SCA, consent, authorization, or liability shift unless independently established. Define a versioned, authenticated indicator structure that separates involvement (assisted, agent_initiated_consumer_present, autonomous) from evidence categories. Include producer, evaluation time, policy/profile version, scoped evidence reference, and explicit verified, failed, unknown, not_evaluated, unavailable, and not_established states. Prohibit raw identity credentials and globally stable agent- instance identifiers in payment messages. In Progress The current informative framework does not define specific indicator formats, data elements or message structures. As relevant sections are being developed, EMVCo will consider how the nature of agent involvement can be represented accurately. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 2 (2.1– 2.6) 2.4, 2.6 te The participant model distinguishes the Payment System, Acquirer, and Merchant, but does not explicitly identify the processing entity that, in current agentic payment deployments, performs execution-time functions distinct from both network-level processing and traditional acquirer transport. These include: evaluating constraint satisfaction against the payment mandate at transaction time, maintaining delegated-credential lifecycle state and propagating revocation, mediating authentication challenges between the payment system and the agent on behalf of the consumer, and verifying mandate fulfilment before submission to the payment system. These responsibilities are particularly pronounced in agentic flows where the consumer is absent and the agent requires a processing intermediary to relay authentication requirements or enforce real-time constraint checks. Clarifying where these functions sit in the participant model would help implementers understand accountability boundaries and would support the authentication-evidence and indicator semantics discussed elsewhere in the framework. Explicitly identify the execution-time processing participant, with responsibilities covering constraint evaluation at transaction time, delegated-credential lifecycle management and revocation propagation, authentication mediation between payment system and agent, and mandate-fulfilment verification. Clarify its relationship to the Payment System and Acquirer roles, and note that one entity may perform multiple roles. Reference this participant in the Intent Services (state coordination) and authentication evidence sections (as a candidate producer of authentication evidence to the payment system). In Progress The Framework describes Agentic Payments at a role and function level and avoids defining explicit actors that will perform the functions of the defined roles. We will provide language that clarifies that an actor may perform the functions associated with multiple roles. At a role-based level we will consider edits that will clarify the relationship between the roles for the functions within EMVCo scope Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 7; 4.2 4.2 directory- service bullet ge The framework correctly identifies that registered Intent could allow a directory service to validate prior consumer authorisation, potentially avoiding consumer action during 3DS. This is the single most consequential pathway for autonomous mode transactions under strong customer authentication regimes, where the consumer is absent by design. It deserves elevation from a parenthetical observation to a chartered workstream. The existing mandate and MIT precedent demonstrates the pattern: consumer authenticates once, subsequent transactions proceed without presence. Agentic delegation introduces open constraints (amount ceilings, payee allowlists) rather than fixed values, raising the question of whether constraint bounds satisfy dynamic linking requirements. The workstream should define the semantics of this authentication evidence: what it attests to (mandate verified, constraints evaluated, agent operating within delegated bounds), how it is structured, and how it is consumed by the issuer for risk decisions. These attestations reflect execution time verification, which naturally complements the issuer's authorisation decision. Charter intent as authentication evidence within EMV 3DS as an explicit workstream, elevating the observation into scoped future work. Include: the relationship to existing mandate and MIT frameworks; whether open mandate constraint bounds can serve as dynamically linked values for authentication purposes; and the semantics of authentication evidence that attests mandate verification and constraint satisfaction at execution time. Scope the workstream to evaluate the pathway without presupposing regulatory, exemption, or liability outcomes. In Progress The Framework recognises that Intent may provide useful input to 3DS authentication and related issuer risk decisions; however, defining the treatment of MIT transactions, dynamic linking, regulatory requirements, or authentication evidence within 3DS is outside the scope of this Technical Framework. This feedback will continue to be evaluated as the Agentic Payments Framework and related EMVCo specifications develop. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 1.5.1 (Table 1.1), 4.3, 6.1, Section 6 Table 1.1; 6.1 first bullet ge The framework correctly defines Intent semantics as mechanism independent, stating that Intent "may be expressed, communicated, or managed using different mechanisms." It then provides Verifiable Intent as a detailed illustrative implementation, which is valuable. However, the framework's only normative reference is the VI specification (v0.1), and the VI section specifies it at implementation depth (credential format, hash constructions, key resolution). This concentration of specificity risks being read in future work as a de facto prerequisite rather than one of several valid approaches. In production deployments today, service managed models (processor issued scoped credentials with server side constraint enforcement, real time lifecycle management, and instant revocation) satisfy the same mechanism-independent semantics through different mechanisms. These models offer complementary strengths to credential chain approaches: credential chains provide portable, independently verifiable consent evidence that does not depend on any single participant's availability; service managed models provide instant revocation, real Reclassify the VI specification reference as informative. Reposition the VI section as an illustrative annex demonstrating one implementation consistent with the framework's semantics. State explicitly that the mechanism-independent semantics define the surface against which any Intent mechanism is assessed, and that service managed and credential chain models are complementary approaches with distinct strengths (revocation and real time enforcement for the former; portable verification and availability independence for the latter). Note that the two can be composed within a single transaction, with each serving the use cases where its properties are strongest. Accept VI will be removed as a normative reference. Section 6 (the VI section) will be preceded with a note advising reviewers that the description of Verifiable Intent (VI) in this section reflects a snapshot of Verifiable Intent v0.1, and is provided to give reviewers sufficient context to understand the problem this framework addresses Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 time constraint enforcement, and authoritative shared state without requiring status check mechanisms that reintroduce the live connections portability was designed to remove. The two models compose naturally rather than competing: one provides execution time enforcement and revocation, the other provides portable consent evidence for dispute resolution and cross participant verification. Treating the mechanism- independent semantics as the conformance surface would preserve mechanism neutrality while allowing future profiles to specify particular approaches for particular use cases. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 5.1, 5.5, 5.8, 5.9, 6.7.6; 2.5 5.8 non- goals; 5.9; 2.5 ("e.g., payment system, card issuer") te The framework correctly warns against fragmented, payment system specific interpretations of Intent semantics. However, it excludes interface standardisation (API schemas, message formats, protocol requirements) alongside enforcement and decisioning, and these are separable concerns. Interface standardisation does not constrain decisioning autonomy. EMV 3-D Secure demonstrates this within EMVCo's own portfolio: messages are fully standardised while ACS decisioning remains entirely issuer autonomous. Without a common interface commitment, each payment system will implement Intent Services with distinct schemas and lifecycle semantics. Processors and merchants will absorb the integration cost per network, and the framework will have standardised the concept while entrenching the operational fragmentation it identifies as undesirable. Separately, the framework gives payment systems and card issuers as the only Intent Service Provider examples, while its definitions place no restriction on who operates this function and diverse participants are contemplated as trust anchors elsewhere. Broadening the examples would reflect that processors, State that a common Intent Service interface specification is intended for future work, following the 3DS pattern of standardised messages with participant autonomous decisioning. Broaden the Intent Service Provider examples to state that any participant meeting future functional requirements, including processors, wallet providers, and agent platforms, may operate an Intent Service. Define shared state semantics: authoritative record designation, update atomicity, reversal handling, and reconciliation expectations when multiple participants evaluate the same stateful constraints. Distinguish stateless constraints (evaluable by any participant with the relevant disclosures at execution time) from cross participant stateful constraints (requiring a shared coordination layer). In Progress These comments will be considered in the continued development of the Framework and future specifications on Agentic Payments. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 wallet providers, and agent platforms perform analogous state management, lifecycle coordination, and retrieval functions in production today. Finally, stateful constraint tracking (cumulative spend, recurrence) may be evaluated both at a shared coordination layer and at execution time by the processing entity. The framework does not address which record is authoritative when these diverge, or how reversals (approved then refunded transactions) reconcile across participants. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 4.1.1, 6.2.4, 4.3.5 4.1.1 ("an exact amount"); 6.2.4 (closed mandate final values) te Immediate mode and closed mandates carry exact final amounts, with fulfilment evaluated for consistency. In production, consented and captured amounts routinely differ for legitimate reasons: tax finalisation after checkout, shipping recalculation, currency conversion, gratuities, partial shipment, and incremental authorisation. Amount range constraints exist only in open mandates. If any deviation from a closed mandate's exact amount constitutes a violation, legitimate transactions will fail verification. The alternative is that implementers inflate mandate amounts to absorb expected drift, which weakens consumer authorisation controls to the point of ineffectiveness. Production agentic checkout systems provision payment authority at cart total plus a bounded margin for exactly these reasons. A generic tolerance would also weaken authorisation; the semantics should be explicit and consumer approved. Additionally, partial capture (delivering less than authorised) is operationally distinct from upward amount adjustment and should not be treated identically. The framework should also state which participant is expected to verify Define consumer approved amount adjustment semantics for closed mandates: an expected amount and a maximum amount; permitted adjustment categories (tax, shipping, currency conversion, gratuity); cumulative capture limits; distinct treatment of partial capture and incremental authorisation; and re-consent thresholds where an adjustment would exceed the approved bounds. State which participant verifies amount consistency given that the binding hash proves same transaction provenance but selective disclosure means no verifier holds both the checkout and payment mandate values. Reject Immediate Mode is intended for scenarios where the Consumer approves a specific payment amount. The framework does not prescribe authorization, capture, gratuity, incremental authorization, settlement, or payment processing rules. Variations between authorized and captured amounts, as well as the mechanisms used to support such scenarios, remain subject to the applicable payment systems, merchant implementations, and regulatory requirements. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 consistency between the authorisation amount and the closed Payment Mandate, given that selective disclosure means no single verifier holds both mandates' full values simultaneously. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 2.6; 3 2.6 specifically; Section 3 visibility bullets te The framework models consumer consent to agent delegation in detail through the Layer 2 ceremony, but does not address merchant consent to agentic interaction. This is a relationship level concern rather than a per transaction one: merchants already have tools to decline individual transactions, but they currently have no standardised way to authorise, scope, or decline agentic traffic from a given agent or agent platform on a standing basis. In production deployments, bilateral merchant consent is enforced before any consumer data collection occurs, not at transaction time. This serves both merchant autonomy (the ability to differentiate agents by capability, reputation, or commercial terms) and consumer protection (screening agentic traffic before personal data enters the flow). Merchant consent is also where the KYA identifiers become actionable: a merchant can only scope consent to an agent that is stably identifiable at the platform level. Without a consent construct, the framework implicitly assumes universal merchant acceptance of all agentic traffic, which does not reflect production practice or merchant expectations. Recognise merchant consent to agentic interaction as a relationship level framework concept, linked to agent identification. State that merchant consent may be expressed through bilateral authorisation, policy declaration via discovery mechanisms, or allowlists, leaving specific mechanisms out of scope. Note that merchant consent is confirmed before consumer data collection, not solely at transaction time. In Progress EMVCo is considering the communication of agent involvement through its KYA work. These capabilities may provide information that enables Merchants to apply their own access policies. Merchant policy itself and the point at which they are applied are out of scope of this specification. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 4.1, 8.1, 8.2 4.1 first paragraph ("in the context of card payments"); 8.1, 8.2 ge The framework scopes itself to card payments while acknowledging that agentic transaction indicators are needed in ISO 20022, ACH, and other environments. Agents acting on consumer instructions do not inherently distinguish between payment rails, and in many markets non-card payment methods represent the majority of consumer transactions. The framework's Layer 3 semantics (mandates, constraints, fulfilment evaluation, lifecycle states) have no inherent card dependency: they describe the relationship between consumer authorisation, bounded delegation, and transaction execution regardless of the underlying payment instrument. Defining these semantics with unnecessary card assumptions would require rework when the framework is extended to other rails, and would structurally exclude the payment methods that dominate consumer payments in major markets outside North America. Layer 1 trust roots may remain credential specific (card based, account based, or otherwise) without requiring the semantic and indicator layers above them to carry the same specificity. Coordination with other messaging standards bodies would Define Layer 3 semantics (mandates, constraints, fulfilment, lifecycle) and indicator semantics without unnecessary card dependencies, so other rails can adopt them directly. Treat coordination with ISO 20022 and other messaging standards bodies as a priority workstream. Indicators should carry at minimum: the agent's role in the transaction (initiated, facilitated, executed), the execution mode (immediate, autonomous), and an optional intent reference. Acknowledge that Layer 1 trust establishment may remain credential type specific while the layers above it are rail neutral. In Progress While other payment methods, beyond card payments. are out of EMVCo’s scope, these comments will be considered in the continued development of the Framework. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 also benefit from rail neutral semantics that can be adopted directly rather than adapted. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 5.4, 6.4.2; Section 6 5.4 lifecycle states; 6.4.2 ("hours to weeks") te Autonomous Layer 2 credentials are described as persisting "hours to weeks" and are portable by design. The framework's representative Intent lifecycle defines REGISTERED, APPROVED, COMPLETED, COMPLETED_WITH_FAILURES, and FAILED states but includes no REVOKED or CANCELLED state. The consumer can "cancel the instruction" at the agent, but nothing propagates cancellation to a credential already issued and potentially in use. A consumer who revokes delegation (agent compromised, changed mind, lost device) has no defined remediation path for a weeks-long credential already held by the agent or presented to participants. Short expiry windows mitigate but do not solve this: a seven day credential with no revocation mechanism leaves a seven day exposure window. Status check mechanisms are one solution, but reintroduce the live connectivity that portability was designed to remove, creating an inherent tension the framework should acknowledge and address explicitly. In production deployments, instant credential revocation and lifecycle state propagation to all consuming participants are first class Add REVOKED and CANCELLED to the Intent lifecycle states. Define propagation expectations: how and when participants learn that a previously valid credential has been withdrawn. Acknowledge the structural tension between portability (offline verification without live connections) and revocability (timely withdrawal requires reachability), and state that implementations must address both. Include revocation as a mandatory consideration for any Intent mechanism assessed against the mechanism-independent semantics. Accept The feedback is accepted and will be incorporated into a future revision of the Framework, including recognition of revocation within the Intent lifecycle. The final language and treatment may be further refined as EMVCo considers the full set of comments received and aligns the lifecycle concepts across the Framework. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 capabilities, demonstrating that the operational requirement is real and solvable. The framework should define revocation and cancellation semantics, including a lifecycle state, propagation expectations, and guidance on the portability and revocability tradeoff. Additionally, consumers need to have a right to revoke delegation under most payments frameworks. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 4.1.2; 5.2, 5.3 4.1.2 final paragraph; 5.2 registratio n categories; 5.3 retrieval te The framework recommends the agent generate a concise natural language "prompt summary" of the consumer's instruction and include it in the Intent, serving as a consumer reminder and validation aid. The utility is real: prompt summaries provide dispute evidence and help the consumer verify what was delegated. However, natural language consumer instructions can contain sensitive personal information (health conditions, legal matters, financial circumstances, location, relationships) that the consumer did not intend to share with payment infrastructure participants. "Book a hotel near the fertility clinic on the 12th" or "find the cheapest lawyer for a bankruptcy filing" are realistic prompt summaries that would flow through Intent Services and be retrievable by multiple participants. The framework should treat the prompt summary as an optional, selectively disclosable claim rather than a default inclusion. It should be excluded from authorisation time messages (where it serves no decisioning purpose), scoped to consumer review and dispute processes (where it provides genuine value), and subject to the same retention and purpose limitations that should govern Make the prompt summary an optional, selectively disclosable claim. Exclude it from authorisation time messages. Scope its disclosure to consumer review and dispute resolution processes. Add operator side data governance expectations: purpose limitation on registered data, role scoped retrieval with access auditability, and retention bounds proportional to the lifecycle of the underlying Intent. In Progress We agree that privacy concerns exist in the creation of natural language prompt summaries and future versions of the framework and future intent services specifications will attempt to address this particular concern. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 27-Aug-2026 of 52 Intent Service operators generally. Separately, Intent Services as described accumulate longitudinal records of consumer delegation activity across merchants and agents. The framework sets minimisation expectations for retrieval but not for the operator itself. Operator side obligations (purpose limitation on registered data, role scoped retrieval with access auditability, and retention bounds) would address the data accumulation risk. Draft Specification & Bulletin Industry Feedback Form EMVCo Use Only Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reje

Shown in part. Read the original for the full text.