Building an Intent Registry for AI-Driven Payments

An AI agent with a valid payment credential can complete a transaction. Whether it should complete that transaction is a different question entirely. EMVCo released a draft framework on Sept. 1, 2026, proposing Intent Services as a shared layer for managing consumer authorization in agentic commerce. The public comment period runs through Sept. 30. For your compliance team, this isn't just a technical specification, it's a signal that your authorization logic, dispute workflows, and fraud detection systems will need a new data layer.

The Problem: Authorization Without Boundaries

Your current payment stack can authenticate a cardholder, tokenize a credential, and authorize a single transaction. It can't determine if a recurring AI-driven purchase fits within a $300 monthly grocery budget or if the fourth transaction this week exceeds the consumer's standing instruction.

This gap creates three immediate risks:

Dispute exposure. A consumer disputes a $95 charge because their agent was authorized to spend "around $50" on household supplies. Your transaction logs show a valid credential and successful 3-D Secure authentication, but you have no record of the spending limit.

Fraud detection blind spots. Your transaction monitoring flags unusual spending patterns, but you can't distinguish between an agent operating within broad authority and one exceeding its mandate. Both look like legitimate credential use.

Regulatory uncertainty. When a regulator asks how you verify that an AI agent acted within consumer authorization, your current answer is "we verified the payment credential." That won't satisfy questions about consumer consent and transaction appropriateness.

What You Need Before Starting

Before implementing an intent layer, ensure you have:

• Transaction logging infrastructure that can capture and store additional authorization metadata beyond standard ISO 8583 fields.
• API gateway capability to call external services during authorization flows without adding unacceptable latency.
• Dispute management system that can ingest and display structured intent data alongside transaction records.
• Access to the EMVCo draft specification (available during the public comment period through Sept. 30) to understand the proposed data model.
• Legal review capacity to assess how intent records affect your existing cardholder agreements and dispute resolution procedures.

You don't need to wait for finalized specifications to start planning. The core concept, maintaining a reference to consumer authorization parameters that persist across multiple transactions, can be prototyped now.

Step-by-Step Implementation

Phase 1: Extend Your Authorization Data Model

Start by adding intent reference fields to your authorization request structure. You're not yet calling an external Intent Service; you're preparing your systems to handle intent identifiers when they become available.

Add these fields to your authorization request object:

• intent_reference_id: Unique identifier for the consumer's standing authorization.
• intent_status: Active, suspended, expired, or revoked.
• intent_scope: Transaction type, merchant category, spending limit, or time window.
• cumulative_spend: Running total against any spending cap in the intent.

Store these fields alongside your existing transaction data. Modify your authorization decision logic to check intent status before approving. If intent_status is anything other than "active," decline the transaction even if the credential authenticates successfully.

Phase 2: Build Intent Validation Logic

Create a validation function that runs before your standard fraud checks. This function should:

1. Retrieve the intent record using the intent_reference_id.
2. Check whether the current transaction fits within the intent scope (merchant category, transaction amount, cumulative spending).
3. Verify the intent hasn't expired based on its defined time window.
4. Update cumulative spend if the intent includes a spending cap.
5. Return a pass/fail decision with a reason code.

Implement this as a separate service, not embedded in your authorization flow. You'll need to call external Intent Services eventually; designing this as a discrete API call now makes that transition simpler.

Phase 3: Integrate With Dispute Workflows

Modify your chargeback response process to include intent data. When you receive a dispute, your response package should contain:

• The original intent record showing what the consumer authorized.
• Transaction-by-transaction evidence showing each purchase remained within scope.
• Timestamps proving the intent was active when the transaction occurred.
• Any modifications to the intent that happened before the disputed transaction.

This requires updating your dispute management system's data schema and your representment document templates. The intent record becomes your primary defense in "unauthorized transaction" disputes involving AI agents.

Phase 4: Prepare for External Intent Services

When EMVCo finalizes the Intent Services specification, you'll need to replace your internal intent validation with calls to a shared registry. Prepare for this by:

• Designing your validation service with a pluggable backend (internal registry now, external service later).
• Documenting the data mappings between your current intent fields and the draft EMVCo data model.
• Testing authorization latency impact by simulating external service calls with artificial delays.
• Establishing fallback logic for when the Intent Service is unavailable (do you approve, decline, or route to manual review?).

Validation: How to Verify It Works

Test your implementation with these scenarios:

Spending cap enforcement. Create an intent with a $300 monthly grocery limit. Submit five $70 transactions. The first four should approve; the fifth should decline with an "intent limit exceeded" reason code.

Expired intent handling. Create an intent with a 30-day duration. Submit a transaction on day 31. It should decline even if the credential is valid.

Intent revocation. Approve a transaction, then revoke the intent. A second transaction should decline immediately.

Dispute response completeness. Generate a chargeback for a transaction covered by an intent. Verify your response includes the intent record, scope definition, and compliance evidence.

Run these tests in your staging environment before the EMVCo specification is finalized. You're validating your data model and workflow logic, not conformance to a standard that doesn't exist yet.

Maintenance and Ongoing Tasks

Monitor intent lifecycle events. Track how often intents are created, modified, revoked, and expire. Unusual patterns (mass revocations, very short-duration intents) may indicate consumer confusion or agent misbehavior.

Review decline reason distribution. If "intent limit exceeded" becomes a top decline reason, consumers may be setting unrealistic caps or agents may be poorly optimized.

Update dispute strategy. As you accumulate dispute outcomes involving intent records, document which evidence formats work best with card networks. Intent data is new; your representment approach will need refinement.

Participate in specification updates. The Sept. 30 comment deadline is your opportunity to influence the final standard. If your implementation testing reveals data model gaps or workflow problems, submit feedback.

The intent layer won't be optional for long. Issuers who build this capability early will have cleaner dispute outcomes, better fraud detection, and a head start when the standard becomes mandatory.