KYA Trust Layer — Use Cases

0 · Why this exists

The agentic-commerce stack has settlement. It does not have identity, authorization, a record that accumulates, or credit. Visa and Mastercard ship agent credentials; Stripe and OpenAI ship the Agentic Commerce Protocol and keep the merchant as merchant of record; Google ships AP2 signed mandates and UCP; x402 has cleared ~150–200M payments but only tens of millions of dollars. Meanwhile regulators are writing the rulebook in real time: the IMF has moved the conversation from Know Your Customer to Know Your Agent, China published a KYA self-regulatory convention, PSD3 will formalise delegated payment initiation, and the EU AI Act's high-risk obligations land 2 Dec 2027 (Reg (EU) 2026/1744 pushed Annex III back from Aug 2 2026).

The gap that makes the product. In an agent dispute, a merchant cannot capture three things today: the mandate that authorized the agent, the identity of the agent that ran the transaction, and a tamper-resistant record tying the two together. Nobody holds them. That is the product. (Sources in the footer.)

The uncomfortable truth. Actual agentic transaction volume in 2026 is roughly $7.7B, not trillions. The 2030 forecasts ($144B → $5T) span two orders of magnitude because nobody agrees on the definition. Build the record, not the volume bet — the record is what survives if volume is 2030 and you are not.

1 · What the decision model said

Scored with tev1:4b at /v1/systemone. Payload + raw response saved alongside the workspace for reproducibility.

Which market to lead

A1 KYA trust layer — 99.3%

Ceiling + $1M reach

Tier 1 — 89.5%

Squash risk in 24 months

0.42 — less likely than not

Moat a solo founder can defend

Distribution — 94.6%

Hardest UC to copy

UC-5 RECEIPT — 87.5%

Most revenue in 12 months

UC-1 VERIFY — 86.7%

Read. The receipt (UC-5) is the thing hardest for a platform to copy — because it needs the merchant's own context and creates a durable record that cannot be retrofitted onto someone else's stack. The verification call (UC-1) is what carries revenue. Ship UC-1 and UC-5 together; they are one product.

2 · How these were scored

Weighted, out of 100. Same 5-axis pattern as M10 (SAT Prep Agent) so priorities are comparable across ideas.

30%Regulatory forcingDoes a binding rule — Visa Core Rules §4.1.24, EU AI Act Art 12/14/49, PSD3/PSR — create a mandatory record or check? Binding > proposed > none.

25%Buyer urgencyDoes this block revenue or cause a loss TODAY (2026), not in 2030?

20%Buyer reachabilityIs the buyer named, enumerable and self-serve purchasable, or does it need an enterprise committee?

15%Moat contributionDoes shipping it make the architecture harder to copy? Protocol-level or dataset beats feature.

10%Revenue attachedDoes it carry dollar revenue now, or is it a free distribution hook?

3 · Who buys it

Dana Okonkwo — Head of Risk & Compliance

Mid-market marketplace or PSP, $50M-$500M processed volume

Buys: The receipt. Needs to prove to a card network, a regulator or an auditor that each agent-initiated action was authorized.

Pays from: Compliance budget + fraud-loss budget

Sam Reyes — Payments Operations Lead

Merchant or billing platform receiving agent-initiated orders

Buys: The API. Wants agent traffic to stop false-positiving in the fraud engine and to stop reaching support.

Pays from: Fraud-loss budget + engineering budget

Yuki Tanaka — Platform engineer, agent company

Shipping an AI agent that buys things for users

Buys: The agent-side SDK. Wants one call that makes their agent defensible to every receiving counterparty.

Pays from: Nothing at first — this is the distribution channel, not the revenue

Alex Moreau — End user whose mandate is enforced

Consumer who told their agent 'buy my groceries up to $200 a week'

Buys: Nothing. Beneficiary. Revocation and step-up exist for them.

Pays from: Nothing — reached via P1/P2 or via the agent platform

Lena Fischer — Dispute analyst

Merchant chargeback / fraud-resolution team

Buys: The evidence pack. This is the person who currently has no answer to give the issuer.

Pays from: Dispute budget. Fastest possible ROI per case won or refunded.

4 · Use-case map

Core use cases, scored out of 100 and assigned a build wave. Wave 1 is the first release; the long optional list follows in section 7.

ID	Label	Use case	Primary buyer	Score	Build wave
UC-1	VERIFY	Verify an incoming agent before the action executes	P2 Payments Ops / P1 Risk	88	Wave 1
UC-2	MANDATE	Check the action against the signed user mandate	P1 Risk / P5 Dispute analyst	86	Wave 1
UC-3	REGISTER	Register, attest, scope, expire and revoke agents	P1 Risk / P2 platform engineering	80	Wave 1
UC-4	STEP-UP	Step-up human confirmation above a threshold	P1 Risk / P4 End user	78	Wave 1
UC-5	RECEIPT	Produce the signed evidence pack	P1 Risk / P5 Dispute analyst / auditor / card network	84	Wave 1
UC-6	DISPUTE	Handle the case where the agent bought the wrong thing	P2 Payments Ops / P5 Dispute analyst / P4 End user	75	Wave 2
UC-7	RISK	Score agent traffic without false-positiving on it	P2 Payments Ops	74	Wave 2
UC-8	CHAIN	Handle delegated agent-to-agent chains	P1 Risk / P3 agent platform engineer	70	Wave 2

5 · The architecture this forces (the moat)

Morsy's call: the architecture is the moat. The use cases below are not independent features — they are the read-and-write surfaces of a single layered service. Drawn as five layers:

Why this shape is the moat. Layer 2 and Layer 5 are commodity — every protocol and every rail is somebody else's. The defensible layer is Layer 3, because it is the only place where a merchant-specific decision becomes a portable record. A card network can copy a credential check; it cannot copy four years of decisions about your merchants.

6 · Core use cases

8 core UCs. Each one is a read/write surface on the same core: register → verify → receipt.

UC-1 · VERIFY 88/100

Verify an incoming agent before the action executes

One call before money moves: is this a real agent, acting for a real person, allowed to do this? Return allow or deny plus a signed receipt.

Buyer: P2 Payments Ops / P1 Risk Tier: CORE Monetization: Per-verification usage fee + platform subscription

Trigger → outcome

Trigger: An agent-initiated order, payment or API call lands on the receiving system

Outcome: Allow or deny decision plus signed receipt, before the money moves

Regulatory anchor

Visa Core Rules §4.1.24.3 (18 Apr 2026): the Agentic Payment Provider must obtain Cardholder consent for the Cardholder-defined payment instruction, clearly state its expiration date, obtain Cardholder acknowledgement that the Cardholder is responsible for the provider's actions, and verify the Cardholder's identity per the Visa Intelligent Commerce specification both before storing a credential and before acting on the payment instruction — retaining that information for the duration of the agreement. EU AI Act Art 12 (automatic event logging) + Art 14 (human oversight) — application deferred to 2 Dec 2027 by Regulation (EU) 2026/1744 (Digital Omnibus on AI, 8 Jul 2026), so this is a 2027-2028 deadline, not a 2026 one.

Competitive note

Beltic is closest (agent visibility + policy engine + intent intelligence, incl. MCP servers) but has no published pricing page and no mandate-citation output. Stripe explicitly does NOT verify agents — its agentic dispute and refund flows work 'without changes'.

Systems touched

PSP / merchant API
agent identity source
mandate store
policy engine
receipt log

Integrations this forces

Card-network agent credentials — Visa Trusted Agent Protocol, Mastercard Agent Pay / Agent Connect, Agent Pay for Machines (announced 10 Jun 2026, no availability date)
AP2 signed mandates (Google; donated to FIDO Alliance 28 Apr 2026)
KYA tokens (Skyfire) and Visa Intelligent Commerce purchase-intent mandates
MCP 2026-07-28 authorization: OAuth 2.1, scope challenge, step-up authorization flow
ACP / UCP checkout, x402 and MPP settlement envelopes
Agent registry lookups: ERC-8004, SPIFFE, AAIF projects (agentgateway, Agent Router)

Main flow

Receiving system receives an agent-initiated action and calls verify(agent, principal, mandate, action, amount).

Resolve the agent's identity across whatever credential it presented — card-network token, KYA token, AP2 mandate, MCP OAuth token, x402 key.

Resolve the principal behind the agent and confirm the mandate exists, has not expired, and covers this action type.

Evaluate merchant policy against the action: amount, category, recipient, frequency, time window.

Return allow with the receipt reference, step_up with the escalation channel, or deny with the failing clause — in under 100ms.

Append the decision to the tamper-evident receipt log before the transaction settles.

Acceptance criteria

Decision returned in under 100ms at p95 for a 99.9% availability target
Every response carries a receipt id that resolves to an immutable record within 60 seconds
The failing mandate clause and policy rule are named in every deny and every step-up
A verify call works with no agent-side integration at all (credential-only path) — this is how a first merchant signs up
Never returns 'allow' when the mandate is expired, revoked, or the amount exceeds the mandate cap

Edge cases

Agent presents a valid credential for an unknown agent — deny or step_up, never allow
Mandate exists but the agent instance is not the one the mandate was issued to — deny
Clock skew between issuer and verifier makes a mandate look expired — fail closed, with a reason code
The principal is a business, not a person — same checks, different principal type
Agent-to-agent: the calling agent is itself a delegate — chain the checks, do not collapse them
Merchant policy is empty (first day on the platform) — default to step_up above a threshold, not allow

UC-2 · MANDATE 86/100

Check the action against the signed user mandate

The exact clause of the user's instruction that authorized this purchase — cited, not inferred.

Buyer: P1 Risk / P5 Dispute analyst Tier: CORE Monetization: Included in platform fee; mandate-check volume is the usage meter

Trigger → outcome

Trigger: Verify returns a known agent and the action details still need scope evaluation

Outcome: Allow / deny / step-up, with the mandate clause that decided it

Regulatory anchor

Visa Core Rules §4.1.24.3 requires the expiration date of the Cardholder-defined payment instruction to be clearly stated, §4.1.24.4 requires the provider to use ONLY the Cardholder-defined criteria for purchasing, and §4.1.24.9 requires consent plus acknowledgement for Agentic Repeated Transactions. IMF's note pushes Know Your Customer to Know Your Agent with verifiable identities for financial bots linked to legal entities. China Payment & Clearing Association self-regulatory convention (24 Aug 2026) proposes a Know Your Agent hierarchical management system with full-link identity transmission.

Competitive note

t54 ships 'Authorization & Intent' with an intent-explanation challenge and agent-trace delta. Beltic ships a policy engine but no mandate-citation output. No vendor we verified publicly shows the mandate clause cited in the decision.

Systems touched

mandate store
policy engine
action descriptor
receipt log

Integrations this forces

AP2 mandate schema and constraints (allowed payee, amount ceiling, recurrence, expiration)
apruuv / M8 signed-mandate wallet as an upstream mandate source
Apple and Google wallet consent receipts
MCP OAuth token introspection and scope intersection
Visa Intelligent Commerce purchase-intent mandate (decline thresholds)

Main flow

Parse the incoming action into a comparable descriptor: amount, currency, category, recipient, quantity, time window, recurring vs one-off.

Fetch the governing mandate and its clauses (scope, cap, expiry, allowed recipients, allowed categories).

Match the descriptor against each clause and record which clause governed the outcome.

Where the action is inside scope but unusual — new recipient, price drift, quantity change — escalate rather than allow.

Emit the decision with the governing clause id and a human-readable quote of the instruction.

Acceptance criteria

Every allow/deny names the mandate and the clause id that produced it
Expiry, cap and recipient restrictions are enforced independently — passing one does not bypass the others
Recurring mandates are re-evaluated per transaction, not cached as a blanket allow
A mandate issued by one protocol can be evaluated even if the transaction arrives on another

Edge cases

Two mandates both cover the action — use the most specific, log both
Mandate covers the category but not the amount — step_up, not deny
Mandate is scoped to a subscription and the action is a one-off top-up — clarify
User revoked the mandate but the agent's credential is still live — deny, and trigger revocation of the credential
Mandate text is ambiguous ('stuff for the house') — deny on ambiguity, escalate to the human

UC-3 · REGISTER 80/100

Register, attest, scope, expire and revoke agents

The agent's identity card: who built it, who runs it, what it may touch, and the switch to stop it.

Buyer: P1 Risk / P2 platform engineering Tier: CORE Monetization: Platform fee; registry-as-a-service to networks

Trigger → outcome

Trigger: A new agent vendor or a new agent instance appears in traffic

Outcome: The agent on the allow-list with a scope, an attestation, an expiry and a kill switch

Regulatory anchor

Visa Core Rules §4.1.24.1: an Agentic Payment Enabler must enroll in and comply with the Visa Intelligent Commerce program and register with Visa, contract with each Agentic Payment Provider, and hold the right to immediately terminate a provider for good cause, fraudulent activity, or upon Visa request. MAS Singapore 'Safeguards for Agentic Finance at Runtime' (3 Jul 2026) proposes an Agent Identity step before every action.

Competitive note

t54 ships a live graph of agents, owners and workloads and claims to catch identity rotation and environment shifts across sessions. Skyfire ships KYA identity plus an agent history track record. Beltic gives every agent an identity of its own. This is the most contested of the core set — and the least where we would lead.

Systems touched

agent registry
attestation store
allow/deny list
admin console
webhook fan-out

Integrations this forces

Agent-vendor onboarding: contract + scoped credential exchange
Continuous attestation polling against the agent's declared runtime
MCP server for agent-side self-registration
AAIF agentgateway / Agent Router as registry integration points
ERC-8004 agent registry and SPIFFE identities for federation

Main flow

Agent vendor registers: legal entity, operator, model and toolchain declaration, contact, intended scope.

Platform issues a scoped, revocable credential bound to that registration.

Scope is expressed as resource + action + limits + expiry, matching the merchant's policy vocabulary.

Attestation is re-checked on a schedule and on every material change to the declared runtime.

Kill switch: revoke one agent, one vendor, or all agent traffic, with fan-out to every connected surface.

Acceptance criteria

Revocation propagates to every connected surface within 60 seconds
An unregistered agent never gets a straight-through allow
Scope changes require re-attestation, not just an admin click
The registry answers 'who can touch this resource right now' in one query

Edge cases

Same operator runs many agents — one registration, many scoped instances
Agent rotates its credential mid-session — detect at verify, not at onboarding
Vendor claims a different scope than the agent actually exercises — flag as drift
Merchant wants agent X allowed but not agent X's sub-agent Y — scope must express delegation depth

UC-4 · STEP-UP 78/100

Step-up human confirmation above a threshold

When software is about to do something a human would think twice about, a human says yes — and the yes is recorded.

Buyer: P1 Risk / P4 End user Tier: CORE Monetization: Included; volume driver

Trigger → outcome

Trigger: Action exceeds an amount, hits a new recipient, changes contact details, or the mandate is ambiguous

Outcome: Human confirms in person, or the action is dropped — and the confirmation is recorded

Regulatory anchor

EU AI Act Art 14 requires human oversight mechanisms that allow intervention and interruption for high-risk systems (applies from 2 Dec 2027 for Annex III systems, per Regulation (EU) 2026/1744). Visa Core Rules §4.1.24.6 requires Cardholder consent or acknowledgement for limited cancellation/refund policies, delayed charges, estimated amounts and upsells before the transaction completes. PSD3/PSR will force Strong Customer Authentication for autonomous agents (not yet in the Official Journal as of 23 Oct 2026).

Competitive note

Beltic reports 5% of actions routed to step-up against 86% straight-through — the mechanics are shipped. t54 ships a challenge flow. This is table stakes, not a differentiator; we ship it because the receipt is worthless without it.

Systems touched

step-up orchestrator
push / SMS / voice channel
mandate store
receipt log

Integrations this forces

apruuv / M8 phone approval surface (iOS, push, Face ID)
Bank push and card 3-D Secure step-up
Voice OTP or contact-centre fallback for the no-smartphone case

Main flow

Decision engine classifies the action as requiring human confirmation.

Step-up request is rendered for the principal — what, how much, at whom, and the reason.

Principal confirms or denies on a channel that proves it was the principal.

Confirmation or denial is written to the receipt log with the channel, the proof and the timestamp.

Timeout or no response is a deny, and the timeout is itself recorded.

Acceptance criteria

A step-up without a recorded human decision can never result in an allow
Timeout always denies and always records
The principal can see what is being asked for and on which device
The recorded proof is sufficient to satisfy a dispute, not just an audit

Edge cases

Principal unreachable (travelling, no signal) — deny, or hold under an explicit merchant rule
Principal is a business entity with a 4-eyes policy — require two approvers
Agent asks repeatedly to trigger step-up — rate-limit the agent, not the human
Human approves but the amount changed between render and confirm — re-verify

UC-5 · RECEIPT 84/100

Produce the signed evidence pack

One artifact that answers: who the agent is, who it acts for, what mandate allowed it, what it did — and proves none of it was altered.

Buyer: P1 Risk / P5 Dispute analyst / auditor / card network Tier: CORE Monetization: Included; the artifact is what makes the subscription defensible

Trigger → outcome

Trigger: Dispute, chargeback, regulator examination or internal audit

Outcome: One signed, tamper-evident pack, exportable in the format the counterparty accepts

Regulatory anchor

Visa Core Rules §4.1.24.3: the Agentic Payment Provider must retain the consent and payment-instruction information for the duration of the agreement and provide it to the Cardholder or Issuer upon written request. §4.1.24.8: an order confirmation must remain available to the Cardholder for at least 120 days from the Processing Date. Dispute Condition 10.4 accepts the agent-platform login ID as a CE data element, in clear text and unhashed. EU AI Act Art 12 automatic logging over the system lifetime; deployer retention baseline of at least six months (Art 19 / Art 26(6)). NOTE: Chapter III Sections 1-3 apply from 2 Dec 2027 (Annex III) per Regulation (EU) 2026/1744 — the requirement is live, the deadline is not 2026.

Competitive note

t54 ships 'signed, replayable evidence record' and a tamper-evident compliance audit chain. Beltic ships 'a signed record of who really acted'. So the artifact itself is NOT unique — but no verified vendor shows the export format a merchant's dispute analyst hands to Visa. The export and the cross-vendor federation around it are the open ground.

Systems touched

receipt log
hash chain
evidence pack builder
retention store

Integrations this forces

Object storage with immutability / WORM
E-signature or third-party attestation service
Visa CE 3.0 data elements — including the Agentic Payment Provider login ID in clear text, which Visa's rules explicitly accept for 10.4 disputes
EU AI Act Art 12 event log export, Art 11 technical documentation, Art 49 registration

Main flow

Request an evidence pack for a transaction id, a dispute id or a date range.

Assemble the chain: registration and attestation, credential presented, principal, mandate clauses, policy evaluation, risk score, step-up if any, settlement outcome.

Hash-chain the pack and sign it with a timestamp.

Render in the counterparty's format — Visa CE 3.0 data elements, EU AI Act examiner export, plain-language cardholder summary.

Deliver to the dispute analyst with the one sentence they will have to say to the issuer.

Acceptance criteria

Any single field can be proven unaltered without trusting the platform that produced it
Pack renders in the Visa CE 3.0 element set, including the agent-platform login ID in clear text
Retention honours the longest applicable obligation: Visa's duration-of-agreement rule, 120-day order confirmation, EU AI Act logging baseline
A pack for a transaction with no mandate still renders and states plainly that no mandate existed

Edge cases

Mandate was revoked after the transaction — the pack must show both states
Agent rotated identity mid-flow — the chain shows both agent ids
Two merchants share a principal — packs must not leak each other's data
Examiner wants raw logs, not a summary — export both

UC-6 · DISPUTE 75/100

Handle the case where the agent bought the wrong thing

No human clicked buy. So who disputes, on what evidence, on which rail — and who pays.

Buyer: P2 Payments Ops / P5 Dispute analyst / P4 End user Tier: CORE Monetization: Per-case fee or success fee; also the least bundle-able piece

Trigger → outcome

Trigger: "My agent ordered the wrong thing" — a charge with no human in the loop

Outcome: A dispute that names the machine, attaches the evidence, and resolves on the rail it arrived on

Regulatory anchor

Visa rules keep the merchant as the party that must answer: §5.4.3 requires the Merchant to comply with §4.1.24.6 for Agentic Transactions and states a Merchant must not require a Cardholder to waive the right to dispute an Agentic Transaction with the Issuer. FATF Travel Rule applies to agent-to-agent transfers. ACI Worldwide notes mandate-based authorization is 'currently untested in courts and before regulators'.

Competitive note

Natural states it 'mediates all disputes for you' — but for payments Natural itself processes. Stripe's agentic refunds and disputes reuse the existing flow unchanged. t54 ships evidence + dispute + chargeback. No one has solved the case where the loss lands on a merchant whose acquirer has no agent-dispute rule yet.

Systems touched

dispute workflow
receipt log
rail adapters (card / ACH / stablecoin)
refund engine

Integrations this forces

Visa and Mastercard dispute APIs
ACH and stored-credit rails
Stablecoin rails (x402, MPP) — note x402 v2 has no refund or dispute flow at all
Merchant support tooling and the cardholder-facing order confirmation

Main flow

Chargeback arrives with no human-initiation trail. Classify the agent case.

Map to the existing reason code: 10.4 (agent not authorized / agent compromised), 13.1 (not received), 13.3 (wrong item or not as described).

Pull the evidence pack and check the mandate against the disputed action.

Decide: refund fast, represent with evidence, or escalate to the network.

Log the outcome and feed the pattern back into the agent's risk profile.

Acceptance criteria

Every agent-initiated charge can be identified as agent-initiated without the issuer telling us
A 10.4 representation built from our pack is accepted at least as often as one built from shipping proof
Refund decisions happen inside the issuer's response window, not after it
The dispute outcome updates the agent's risk profile automatically

Edge cases

Agent bought inside a genuine mandate and the user is simply unhappy — no published network rule fits; this is the unresolved case
The merchant never stored the agent's login ID — CE 3.0 data element is missing, dispute is lost
The agent was compromised rather than mis-scoped — liability is unresolved between issuer, acquirer and agent operator
The transaction settled on a stablecoin rail with no dispute path — nothing to appeal to

UC-7 · RISK 74/100

Score agent traffic without false-positiving on it

Ten thousand agents from one datacentre look exactly like fraud. Change the features, not the thresholds.

Buyer: P2 Payments Ops Tier: CORE Monetization: Usage + platform fee

Trigger → outcome

Trigger: Agent traffic hits the merchant's existing fraud engine

Outcome: A risk score that understands agent patterns instead of flagging them

Regulatory anchor

EU AI Act Art 9 (continuous risk management), Art 15 (accuracy, robustness, cybersecurity) apply to high-risk fraud-scoring systems, from 2 Dec 2027 (Annex III, per Regulation (EU) 2026/1744); ACPR in France already inspects AI in banking. Mastercard's Sept 2026 agent-detection probability score is the network's answer to the same problem.

Competitive note

Mastercard ships an AI-initiated transaction probability score for US testing and a shared intelligence layer with Cloudflare. t54 ships a validator-panel risk decision with confidence score. Adyen publishes a knowledge-hub piece on why traditional fraud detection was not built for AI agents. This is a race we enter third.

Systems touched

risk engine
agent traffic features
case queue
decision log

Integrations this forces

PSP fraud APIs (Stripe Radar, Sift, Sardine)
Chargeback and fraud-outcome feedback feeds
Device and IP attestation — the signals that invert when the buyer is software

Main flow

Agent traffic is separated from human traffic before the existing fraud engine scores it.

Replace inverted signals (device, geography, velocity, session) with agent-shaped ones: agent identity, mandate scope, delegation depth, instruction-vs-action delta.

Score with a confidence output, and route only the genuinely ambiguous cases to review.

Record the score and its inputs on the receipt.

Acceptance criteria

Agent traffic false-positive rate falls materially versus the merchant's existing engine
The score is explainable in one line for a dispute analyst
Score inputs are captured on the receipt so the decision can be re-derived later
Human traffic scoring is unchanged — no regression for the 99% of volume that is not agent traffic

Edge cases

A compromised agent produces perfectly normal agent-shaped traffic — the risk must sit elsewhere
Merchant has almost no agent volume — the model is not trainable, use rules only
Two agents share an IP and device fingerprint — fingerprint is meaningless for agents

UC-8 · CHAIN 70/100

Handle delegated agent-to-agent chains

Agent A called agent B. Scope resets at every handoff unless we say otherwise.

Buyer: P1 Risk / P3 agent platform engineer Tier: CORE Monetization: Usage; deepest defensibility in the set

Trigger → outcome

Trigger: Agent A calls agent B to complete the user's task

Outcome: Scope, liability and re-verification are explicit at every handoff, with a cap on total chain spend

Regulatory anchor

MetaComp's StableX KYA framework extends the FATF Travel Rule to agent-to-agent transactions. Visa's definition of an Agentic Transaction requires that it be based on the Cardholder-defined payment instruction, which a delegated chain can obscure. IETF ATXN (Apr 2026) is the emerging transaction-definition protocol for agent-to-agent.

Competitive note

t54 lists A2A and x402 messaging among supported protocols and says each handoff is a delegation event where risk and assumptions reset. Beltic's CEO states the same principle. Nobody publicly ships a total chain-spend cap with per-hop re-verification.

Systems touched

chain graph
scope propagation
receipt log

Integrations this forces

MCP tool-call layer
Agent-to-agent protocols: A2A (AAIF), IETF draft-stone-atxn (ATXN), x402 A2A messaging
Recursive attestation resolution

Main flow

Detect that the calling agent is itself acting under a delegation.

Resolve the chain to its root principal and record every hop.

Intersect scopes at each hop — the effective scope is the narrowest, never the widest.

Enforce a chain-level total spend cap across all hops, not per hop.

Record the lineage in the receipt so a dispute can name every participant.

Acceptance criteria

A chain deeper than the merchant's policy allows is refused before the final action
The chain-level cap cannot be bypassed by splitting spend across hops
Every hop is independently attributable in the receipt
A delegation that cannot be resolved to a principal is denied

Edge cases

A hop uses a protocol we do not parse — the chain is unverifiable, deny or step_up
The chain exceeds a maximum depth — refuse, do not truncate silently
The intermediate agent is operated by a third party — liability splits are visible in the receipt
An intermediate agent caches a credential and replays it — replay detection on every hop

7 · Optional use cases — the long list

58 candidates across 7 groups. Scored on the same rubric; anything scoring under ~55 is a candidate, not a commitment. Several are marked NOT core because a competitor already ships them, because they need a buyer we do not have, or because they belong to apruuv (M8) rather than to this company.

Agent identity & lifecycle

ID	Optional use case	Who wants it	Why it has value	Why it is NOT core	Score
OPT-A1	Agent census — inventory every agent that touches our systems	P1 Risk / platform engineering	Know your exposure: which agents, which vendors, which volumes	No external demand yet; internal tool	48
OPT-A2	Resolve one agent's many identities across protocols	P1 Risk / integrations engineer	KYA token, AP2 mandate, SPIFFE ID, x402 key, ERC-8004 registry entry all point at the same agent	Only pays off at scale; depends on protocol convergence	45
OPT-A3	Bind an agent to a verified principal (person or business)	P1 Risk / KYC team	The anchor that makes every downstream record meaningful	Baselayer already does business identity for 2,300+ FIs — we consume, we do not compete	52
OPT-A4	Agent runtime attestation — prove which model, tools and guardrails are live	P1 Risk / model governance	Distinguishes a sanctioned agent from a jailbroken one	Requires runtime hooks into agent frameworks we do not control	50
OPT-A5	Continuous attestation monitoring and drift detection	P1 Risk	Catches an agent whose scope or behaviour changed after onboarding	Needs deep agent-side instrumentation	47
OPT-A6	Third-party agent vendor due diligence	P1 Risk / procurement	Score the operator of the agent, not just the agent	Slow, research-shaped, hard to sell self-serve	38
OPT-A7	Agent credential issuance, rotation and short-lived tokens	P2 Payments Ops	Credentials that expire, so a leaked key stops mattering	Card networks and PSPs already issue scoped tokens	44
OPT-A8	Emergency kill switch — stop one agent, one vendor, or all agent traffic	P1 Risk / incident response	The reflex you need at 2am when an agent misbehaves	Feature-shaped, but cheap and trust-building	58
OPT-A9	Agent operator reputation score across merchants	P1 Risk	Network effect: the more merchants use it, the better the score	Needs critical mass; a chicken-and-egg problem	42

Mandate & consent

ID	Optional use case	Who wants it	Why it has value	Why it is NOT core	Score
OPT-B1	Mandate issuance — a user grants an agent a scope in one tap	P4 end user via agent app or apruuv	The upstream source of every mandate we later verify	That is apruuv / M8's job. Our job is verifying what it issues	55
OPT-B2	Mandate store with versioning, expiry and revocation	P1 Risk	The system of record we sell on top of	Only valuable once mandates actually exist in the wild	51
OPT-B3	Scope algebra — compose and intersect multiple mandates	P1 Risk	Least privilege across agent, merchant policy and user grant	Engineering-heavy, no buyer asks for it yet	40
OPT-B4	Mandate translation between protocols (AP2 → internal → ACP → MPP)	P2 Payments Ops	Nobody has a mandate format that all five protocols speak	Protocol churn; translation is a maintenance tax	43
OPT-B5	Signed consent via wallet (eIDAS 2.0 / W3C VC)	P1 Risk / legal	Consent that survives a court and a regulator	Enterprise integration burden, slow cycles	41
OPT-B6	Intent vs instruction — separate what the user wanted from what the agent was told	P1 Risk / disputes	The exact contested fact in an agent dispute	Needs agent-side telemetry we do not own	46
OPT-B7	Hard spend caps and category restrictions on the mandate	P2 Payments Ops	'Up to $200 a week at this grocer' enforced at transaction time	Natural feature of UC-2 mandate check	53
OPT-B8	Time-window and expiry enforcement	P1 Risk	A mandate that expires stops being a liability	Part of UC-2	54
OPT-B9	Counterparty allow-list — which merchants this agent may use	P2 Payments Ops	Blocks the compromised-agent case	Part of UC-2	52
OPT-B10	Consent evidence for privacy law (GDPR / CCPA) — was the agent authorised to share data	P1 Risk / DPO	A second, separate record from the payment mandate	Different buyer, different regulation; expands scope	36

Transaction-time decisions

ID	Optional use case	Who wants it	Why it has value	Why it is NOT core	Score
OPT-C1	Pre-action verify call (the API itself)	P2 Payments Ops	One call before money moves	This IS UC-1	88
OPT-C2	Post-action reconcile — match the request to what actually settled	P2 Payments Ops	Closes the gap between intent and settlement	Needs per-rail integrations	60
OPT-C3	Agent-aware fraud features — velocity, geo and device signals that invert for agents	P2 Payments Ops	Stops good agent traffic false-positiving	That is UC-7	74
OPT-C4	Step-up orchestration across channels (push, SMS, voice, 3DS)	P1 Risk	One integration instead of four	That is UC-4	78
OPT-C5	Duplicate and replay detection for retried agent calls	P2 Payments Ops	Agents retry hard; humans do not	Infrastructure, not a use case a buyer buys	49
OPT-C6	Liability routing — decide which party bears the loss before the transaction	P1 Risk / legal	Prevents the 'whose fault' fight from becoming a 9-month dispute	Needs a rulebook we would be inventing	57
OPT-C7	Automated refund and rollback for agent purchases	P2 Payments Ops	Speed of refund is what agent users actually notice	Feature-shaped; refunds are already a merchant process	56
OPT-C8	Merchant policy engine as code	P2 Payments Ops / platform	Policies versioned, testable, diffable	Developer-facing, small buyer	50
OPT-C9	Agent traffic dashboard — what agents are buying, from whom, at what scope	P1 Risk	The operational view that makes the whole thing usable	Bundled with the platform, not sold alone	59
OPT-C10	Cost attribution per agent, per team, per customer	P1 Risk / FinOps	Who pays for the agent's mistakes, and who benefits	Adjacent to the existing agent FinOps category (SpendOS, Tarmac, KazenAI)	45

Evidence, audit, compliance

ID	Optional use case	Who wants it	Why it has value	Why it is NOT core	Score
OPT-D1	Tamper-evident receipt log with hash chain	P1 Risk	Makes the record worth something in court	That is the core of UC-5	84
OPT-D2	Dispute evidence pack export (Visa CE 3.0 data elements, incl. agent-platform login ID in clear text)	P2 Payments Ops	Win or lose a 10.4 dispute on mandate evidence	That is UC-5 plus UC-6	82
OPT-D3	Regulator examination export (EU AI Act Art 12 + Art 49, from 2 Dec 2027)	P1 Risk / compliance	Answer the examiner in hours, not weeks	That is UC-5	83
OPT-D4	Retention policy engine — keep what the law requires, delete what it does not	P1 Risk / DPO	Retention is a legal obligation and a cost line	Table stakes inside the platform	61
OPT-D5	EU AI Act conformity documentation service (Art 11)	P1 Risk / compliance	A required document set the client must produce	Consultancy-shaped, deadline-shaped, Big 4 will sell it too	54
OPT-D6	Risk-management system as a service (Art 9)	P1 Risk	A required continuous process, not a document	Deep consulting engagement; not self-serve	49
OPT-D7	Human-oversight register (Art 14) — every time a human could and did intervene	P1 Risk / compliance	Proves oversight was real, not theoretical	Only meaningful if step-up volume exists	58
OPT-D8	ML-BOM / model provenance attestation for agents	P1 Risk / model governance	Knows whether a sanctioned model ran the action	Hard, and only three platforms can really attest	47
OPT-D9	Chain audit trail — a complete delegated lineage	P1 Risk	Who delegated to whom, with what scope, at each hop	That is UC-8	70
OPT-D10	PSD3 / SCA readiness report for autonomous agents	P1 Risk / bank compliance	Prepares for a rule that is not fully in force yet	Binding date uncertain — Council first-reading position published 21 Oct 2026, not yet in the Official Journal	51
OPT-D11	SOC 2 Type II and ISO 27001 evidence pipeline	P2 Payments Ops / procurement	Table stakes for selling to any mid-market buyer	Certification is a cost, not a use case	60
OPT-D12	Independent attestation of our own receipts (third-party notary service)	P1 Risk / legal	Makes our evidence credible when the counterparty does not trust us	Strong moat idea, but needs a notary partner we do not have yet	62

Agent-side (distribution)

ID	Optional use case	Who wants it	Why it has value	Why it is NOT core	Score
OPT-E1	Free verification SDK for agent builders	P3 agent platform engineer	Makes us the default check inside the agent stack	Free by design — this is the distribution channel, not revenue	79
OPT-E2	MCP server exposing verify() to any agent	P3 agent platform engineer	One install, every agent	Free by design	77
OPT-E3	Agent-side compliance score badge — 'this agent is verified'	P3 agent platform engineer	Distribution plus marketing; drives receiving-side demand	Free by design	66
OPT-E4	Self-service agent onboarding portal	P3 agent platform engineer	Agent registers itself, gets a scoped credential	Free tier of UC-3	63
OPT-E5	Merchant-side agent catalogue — which agents are approved to buy from us	P1 Risk / merchandising	Turns agent traffic into a curated channel	Only works once merchants have traffic to allocate	44

Merchant readiness

ID	Optional use case	Who wants it	Why it has value	Why it is NOT core	Score
OPT-F1	Catalog legibility for agents — structured product data agents can parse	P2 Payments Ops / e-commerce manager	'Most catalogs are invisible to shopping agents'	Feature-shaped, and Shopify ships it free to its own merchants	55
OPT-F2	Machine-readable policy — returns, warranty, restrictions as data	P2 Payments Ops	The agent cannot guess our policy; it must read it	Same bundling risk as F1	52
OPT-F3	Agent-referred traffic attribution and analytics	P2 Payments Ops / growth	Prove agents are a channel, not a threat	Analytics is easy to copy	50
OPT-F4	Agent-specific merchandising — control what agents can see and at what price	P2 Payments Ops / merchandising	New capability with no incumbent	Needs catalog depth we do not have	46
OPT-F5	Agent-checkout endpoint conformance testing	P2 Payments Ops	A test suite that says 'your checkout is agent-ready'	Nice, small, and copyable by a test-suite vendor	43

Later / adjacent

ID	Optional use case	Who wants it	Why it has value	Why it is NOT core	Score
OPT-G1	Credit and underwriting for agent-initiated purchases	P2 Payments Ops / risk	Agents have no credit history; the merchant carries the risk	Regulated, capital-heavy, wrong shape for us now	34
OPT-G2	Agent purchase insurance / indemnity	P1 Risk / treasury	Transfer the residual liability we cannot eliminate	Needs a balance sheet	31
OPT-G3	Dispute arbitration between agent operator and merchant	P1 Risk / legal	The 'who pays' question needs a forum	Two-sided network, very slow to start	37
OPT-G4	Cross-border agent payment compliance (VARA / ADGM / MiCA)	P1 Risk / treasury	Stablecoin agent rails are moving faster than the rulebook	Jurisdiction-by-jurisdiction	35
OPT-G5	AML / sanctions screening of the agent's principal	P1 Risk / financial crime	Complements KYC for software actors	Baselayer's home turf	33
OPT-G6	White-label the verification layer to card networks and PSPs	P1 Risk at a network	Distribution at scale, no sales team needed	Needs protocol-level credibility first — and Mastercard has already picked Skyfire for this	53
OPT-G7	Public agent-verification registry other markets can query	P1 Risk / ecosystem	Network effect and a standard-setting play	Only credible once several vendors adopt it	45

8 · Competitive landscape

Verified against vendor sites on 2026-10-23, not press summaries. This is the uncomfortable part of the document.

Verdict. The category is REAL and CROWDED, and it is bigger than v0.2 of this spec said. Fifteen players now verified, including two the earlier scan missed that matter a lot: Basis Theory ($33M Series B, merchant-side payment vault, and it LEADS the Agentic Commerce Consortium that is writing the standards) and Okta Agent SSO (enterprise identity, GA Aug 2026). We do NOT win on 'verify the agent' — Okta, Palo Alto/CyberArk, Skyfire, Beltic and t54 all ship identity. We win on the merchant-facing evidence artifact, the dispute precedent, cross-vendor federation, and the chain-level cap.

Player	What they actually ship	Claims	Threat to us
t54 Trustline $5M seed, Ripple-backed (Jun 2026)	KYA graph of agents/owners/workloads; Authorization & Intent challenge with intent explanation and agent-trace delta; validator-panel risk decision with confidence score; tamper-evident compliance audit chain; signed replayable evidence record for disputes and chargebacks; A2A / x402 / MCP / AP2 / ACP / Visa TAP / Skyfire KYAPay integration; Agentic Risk Standard underwriting; x402-Secure as a hosted service	20M+ agent transactions analyzed, 41,000+ agents KYA'd, 97.6% approval rate, <5s decision latency	HIGHEST. Covers 5 of our 8 core UCs including the receipt and the dispute module. But positioned at 'institutional finance' — issuers, funds, institutional desks — not the mid-market merchant receiving side.
Beltic $8.8M seed led by Norwest + $1.5M pre-seed (30 Sep 2026)	Agent identity of its own per agent; operator and origin on every request; live traffic on websites, APIs and MCP servers; a signed record of who acted; policy engine with business-specific rules; intent intelligence that reads the intent behind searching/ordering/paying	86% straight-through allow, 5% step-up over 14 days; no public pricing (404 on /pricing)	HIGH. Closest to the receiving-side wedge — but no published pricing, no mandate-citation output, no dispute workflow, no rail adapters.
Ralio £2.1M / $2.5M pre-seed led by SVV, with SeedX, Antler, Plug and Play (2026)	Rail-agnostic safety layer between agents and payment rails — FPS/BACS/SEPA, Visa/Mastercard/Amex, stablecoins, own wallet; per-workflow spend rules; approvals; confidence thresholds; allowlisted recipients; full audit trail tying payment to agent, prompt, policy and outcome; sells both sides (agent SDK and a control dashboard for receiving platforms)	ISO 27001 and SOC 2 in progress	HIGH on the payer side, MODERATE on the receiving side — Ralio sits between the agent and the rail, we sit between the merchant and the decision.
Natural $30M Series A led by Forerunner, 20 Jul 2026 — 193 days after founding	Agent-first payment primitives: FDIC-insured accounts up to $200M, transfers, cards and credit, processing, billing; stable agent identities tied to a verifiable legal identity; full agent observability on every payment; mediates disputes; MCP, CLI, SDK and API	Backed by Forerunner, Mercury, Brex, Y Combinator, Vercel and others	HIGHEST CAPITAL. If it owns the wallet it can own the identity and the dispute. But its centre of gravity is moving money, not proving decisions.
Skyfire $11M seed (Apr 2026, reported)	KYA identity tokens ('kya', 'kya-pay') that disclose only the required fields; KYAPay settlement across cards, ACH, wires and USDC; agent history as a verifiable track record; budgets and per-agent limits; IETF KYAPay profile draft	MASTERCARD NAMED SKYFIRE AS ITS KYA PARTNER in the Agent Pay Trust Framework announcement (30 Sep 2026)	HIGH. Already has the network's endorsement. Also the most protocol-native of the set.
Baselayer / Osiris Ratings $35M Series A led by M13 (4 Oct 2026)	Agentic Identity Suite built on 'Know Your Agent'; cryptographic traceability of agent actions to the deploying platform and the authorising business; MCP server and Agentic Search tool; Counterparty Verification so agents can check who they are buying from	Business identity used by 2,300+ financial institutions including 1 in 5 US banks; 10M+ applications reviewed; $1B+ fraud prevented	MODERATE-HIGH on identity, LOW on the merchant-side receipt and dispute. Deep incumbent relationships we do not have.
Stripe n/a	ACP (with OpenAI), Shared Payment Tokens, Machine Payments / MPP with Tempo, x402 stablecoin support, agentic checkout for sellers, manual capture, refunds and disputes — and explicitly does NOT verify agents: existing refund and dispute flows work without changes	n/a	THE SQUASH RISK. If Stripe decides to verify, it bundles. Our defence is that our record spans merchants and vendors, not just Stripe's rails.
Mastercard + Cloudflare n/a	Agent Pay Trust Framework: identity, intent, controls, execution, intelligence; an AI-initiated-transaction probability score in US testing; a shared intelligence layer for risk signals; privacy-preserving environments with Cloudflare	1 in 10 consumers projected to routinely use agents to purchase by 2030	HIGH and rising. They are building the risk layer we scored UC-7 on.
Visa n/a	Intelligent Commerce: Trusted Agent Protocol with Cloudflare; purchase-intent mandates with decline thresholds; the 18 Apr 2026 rules that define Agentic Payment Providers and require consent, expiry disclosure, identity verification, retention for the agreement's duration, and a 120-day order confirmation	'Hundreds' of agent transactions as of Dec 2025 — no published volume since	HIGH. Visa is writing the rules we must satisfy. We are a compliance supplier to them, which is a real business and a real dependency.
Basis Theory $33M Series B led by Costanoa (14 Oct 2025); ~$50M total; Bessemer, Kindred, Box Group, Offline Ventures	PCI-compliant payment vault that runs independently of any processor; basistheory.ai unified platform for agentic commerce (launched Jun 2025); agents can initiate, approve and manage transactions inside a PCI-compliant environment; LEDS the Agentic Commerce Consortium (20+ companies defining standards for agent-led commerce)	Customers incl. Pinterest, Melio, MoneyGram; PCI Level 1, SOC 2, developer-first API, zero lock-in	HIGH and structural. This is the merchant-side control plane for agentic payments, plus it is running the standards body. If Basis Theory defines the consortium's agent authorization format, we are downstream of it.
Trustap $10M led by Aperture Capital (10 Jun 2026); ~$19.7M total	Trustap Index — makes marketplace and ecommerce listings structured, discoverable and transactable by AI shopping agents; API into existing marketplace transaction infrastructure; full transaction layer from payment processing to dispute resolution; human confirms each transaction before funds release	Cork-based, founded 2017; hundreds of transactions annually across ecommerce, p2p and marketplaces	MODERATE-HIGH. They already own the dispute-resolution piece for marketplaces — which is our UC-6 white space. Their weakness: dispute resolution is on THEIR rails, not across the ecosystem.
Okta Agent SSO / Cross App Access n/a (Okta public)	Agent SSO GA 24 Aug 2026 — registers agents as first-class identities via the open Cross App Access protocol, replacing static API keys with identity-governed short-lived tokens; admins register an agent as a workload principal and connect it to XAA-enabled OIN apps, SAML or OIDC (30 Sep 2026); Cross App Access introduced Jun 2025	Every agent it touches becomes a first-class identity; no re-registration needed when upgrading to Okta for AI Agents	HIGH. This is the enterprise identity incumbent shipping agent identity natively, and it is where agent 'first-class identity' as a phrase is being set. But it is workforce/enterprise IdP — not the merchant-side receipt, and not the agent-vs-principal mandate model.
Palo Alto Networks (CyberArk) $25B acquisition of CyberArk completed 11 Feb 2026	CyberArk machine-identity and privileged-access management folded into the Palo Alto platform; machine identities are the same primitive as agent identities, with secrets management, least privilege and audit already built and sold into every large enterprise	Positioned explicitly to 'secure the AI era'	HIGH. This is the incumbent most able to bundle agent authorization into an existing enterprise contract. It is the reason agent identity alone is not a moat.
ERC-8004 (Trustless Agents) n/a — Ethereum standard; authors incl. Marco De Rossi (MetaMask), Davide Crapis (Ethereum), Jordan Ellis (Google)	Registry and reputation system for agents: discover agents, establish trust through reputation and validation; on-chain identity records for agents	Emerging open standard for agent identity and reputation	LOW direct, HIGH strategic. If agent identity standardises on-chain, our federation layer (OPT-A2) becomes a bridge between a wallet identity and a compliance record — which is more valuable, not less.
Agentic Commerce Consortium n/a — consortium led by Basis Theory, 20+ companies	A standards body defining the standards and infrastructure that let AI agents become trusted buyers, with a white paper for merchants	Explicitly 'giving merchants the ability to opt into agentic commerce in a secure, controlled manner'	HIGH. If the consortium defines the merchant-facing agent authorization format, our receipt schema must interoperate with it — or be replaced by it. Partnership target, not an enemy, but it sets the spec we must live inside.
Nekuda cumulative ~$5M backing	Secure infrastructure for AI-driven purchasing agents; listed among protocols supported by t54 Trustline	UNVERIFIED beyond funding reports and the t54 integration list	LOW-MODERATE. Appears to be a credential/identity layer for purchasing agents — adjacent to UC-1.

White space — what nobody ships today

A merchant-facing evidence artifact with an EXPORT a dispute analyst hands to the issuer — Visa CE 3.0 element set, EU AI Act examiner export, and a plain-language cardholder summary

Why open: t54 and Beltic ship a signed record, but neither publicly shows a counterparty-format export; the Agentic Commerce Consortium is writing standards for the authorization format but not for the dispute-evidence format

Defensibility: STRUCTURAL — the export schema becomes the contract, and it must interoperate with whatever the Consortium defines

A merchant-facing evidence artifact with an EXPORT a dispute analyst hands to the issuer — Visa CE 3.0 element set, EU AI Act examiner export, and a plain-language cardholder summary

Why open: t54 and Beltic both ship a signed record, but neither publicly shows a counterparty-format export or cross-vendor federation

Defensibility: STRUCTURAL — the export schema becomes the contract

Federated identity resolution across KYA token, AP2 mandate, SPIFFE, ERC-8004 and A2A — one agent, many credentials

Why open: Every vendor has one credential model; no one publicly resolves across them

Defensibility: STRUCTURAL — becomes a de-facto standard if we ship it as an open spec

The merchant-side dispute workflow for agent transactions where no network rule yet exists

Why open: No card network has published an agent-specific dispute rule; x402 v2 has no refund or dispute flow at all

Defensibility: STRUCTURAL — owns the precedent, and the precedent is what gets cited

Chain-level total spend cap with per-hop re-verification

Why open: t54 and Beltic both name the delegation-reset problem in marketing; neither publicly ships a chain-level cap

Defensibility: STRUCTURAL

Liability pre-allocation before the transaction, not after the dispute

Why open: t54 does post-hoc underwriting; nobody pre-assigns

Defensibility: WORKFLOW — becomes sticky once contracts reference it

Bundle-able within 24 months

Verify-the-agent as a single API call — Stripe, Visa, Mastercard or CyberArk can ship this inside their existing surface
Agent-aware fraud scoring — Mastercard is already shipping a probability score
Registry and attestation — t54, Skyfire and Baselayer all ship it
Catalog legibility and machine-readable policy — Shopify ships it free to its own merchants
First-class agent identity inside the enterprise IdP — Okta Agent SSO already shipped it (GA 24 Aug 2026)
Machine-identity and least-privilege enforcement — Palo Alto/CyberArk already own the enterprise contract
The consortium's agent-authorization format — Basis Theory is leading that standards body

NOT bundle-able

A cross-vendor evidence record that includes another vendor's agent and another network's mandate
The dispute precedent and the format the counterparty accepts
The chain-level cap across vendors' agents
The compounding dataset of real agent decisions across the ecosystem
Interoperating with a standards body we do not control — the Consortium's format is dictated, not discovered

9 · Risks and the kill criteria

Structural risks

Feature-shaped. CyberArk/Palo Alto, Stripe, Visa, Mastercard and Google can each ship a verification call. If they do, our defensible surface shrinks to the receipt and the dispute layer.
No dispute rule yet. Neither card network has published an agent-specific dispute rule, so the rules the product exists to satisfy are still being written.
Untested in court. ACI Worldwide calls mandate-based authorization "currently untested in courts and before regulators". A receipt is only worth what a court gives it.
Merchant of record stays with the merchant. Under ACP the merchant keeps settlement, refunds, chargebacks and compliance. That is our customer — and our liability.

Kill criteria

30 named accounts approached, 0 paid pilots by day 60 → wrong buyer.
Every buyer demands on-prem or bespoke implementation → wrong price point.
Visa/Mastercard/Stripe ship a free bundled equivalent covering verification → pivot to the dispute and evidence layer where they are weak.
No mandate format stabilises by mid-2027 → the mandate layer cannot be built on sand; pivot to the receipt as the primary product.

9.5 · SOTA scan — last 6 months (Apr–Oct 2026)

Headline. THE CATEGORY NAME IS NOW THE CARD NETWORKS' STANDARD. Visa + Mastercard + Ant International launched a joint 'Know-Your-Agent (KYA) interoperability framework' on 9-10 Sep 2026 (Reuters, Ant press release). Three 2026-ability protocols aligning: Visa Trusted Agent Protocol, Mastercard Verifiable Intent, Ant Agentic Mobile Protocol. This is validation of the problem AND a naming/positioning event: 'KYA' is no longer ours to define.

Date	Development
2026-09-10	Visa + Mastercard + Ant International announce joint KYA interoperability framework Shared principles for agent onboarding/identification across networks; each network keeps its own verification & decisioning. Reuters + Ant PR. McKinsey $3-5T agent-orchestrated consumer commerce by 2030 cited by all three.
2026-08-18	Agentic Payments Alliance (APA) launched by Rain 26 founding orgs incl Visa, Mastercard, Circle, Solana, Avalanche, Fiserv, Fireblocks, Chainalysis, Uniswap Labs. Scope: how AI agents get AUTHORIZED to spend (authorization, identity verification, disputes listed in coverage).
2026-10-01	Mastercard extends Agent Pay with trust & intelligence US-testing probability score: how likely a tx was agent-initiated; trust/intelligence signals for issuers (pattern match, needs-look, proceed-or-check). Identity side via Skyfire (KYA provider), data side with Cloudflare.
2026-10-03	8 live agentic protocols mapped — stacking, not competing MCP (Anthropic), A2A (Google), ACP (OpenAI/Stripe), UCP (Google/Shopify + Amex/MC/Stripe/Visa), AP2 (Google, consumer mandates), TAP (Visa, agent identity), Agent Pay (Mastercard, identity + tx trust), MPP (Stripe/Tempo, machine-to-machine card). No winner; layers stack.
2026-08	AP2 v0.2 security analysis (arXiv 2608.23858) — PEER VALIDATION of our thesis 48 threats, 5 attack families, 8 High-band (AIVSS). Core finding: 'valid mandate signatures alone do not ensure that an agent-mediated transaction reflects the user's intent when its pre-authorization context is manipulated' — prompt injection, tool-result poisoning, A2A message manipulation all unsecured by the signed mandate. That is exactly our UC-2 MANDATE + UC-5 RECEIPT white space, academically confirmed.
2026-10-20	ACAGS (arXiv 2610.27483) — behavior-aware fraud detection for agent payments Agent impersonation, unauthorized payments, compromised agents, delegated-authority misuse; supervised ML + behavioral analytics framework. Validates UC-7 RISK being needed; also confirms it's an academic swarm (feature-shaped).
2026-07-14	x402 Foundation launches under Linux Foundation Coinbase donated protocol; 40 member companies. Real volume is TINY: 75.41M transactions but only $24.24M trailing-30d volume (~$0.32 avg). Same 'lots of tx, cents per tx' picture as our spec.
2026-09-01	t54 ships on AWS Bedrock AgentCore; Skyfire+Forter enrich merchant checkout (Oct 19) t54: 20M+ agentic transactions screened, 41k agents KYA'd via Amazon Bedrock AgentCore. Skyfire+Forter announced checkout-time trust enrichment 19 Oct 2026.
2026-04-27	Solowin/SC Ventures AGENPAY — bank-grade KYA engine NASDAQ AXG + Standard Chartered venture arm incubating AGENPAY: KYA + Bahrain stablecoin license as the rails for AI wallets. Banks are building in-house KYA engines.

Market sizing — updated

McKinsey (cited by Visa/MC/Ant, Sep 2026): $3-5T agent-orchestrated consumer commerce by 2030
Bain (via commercetools, Oct 2026): US agentic commerce $300-500B by 2030, 15-25% of US ecommerce; Gartner: 20% of digital commerce via AI platforms by 2030
IDC (2026 edition): agentic commerce $18.4B in 2025
x402.org live: 75.41M tx / $24.24M volume trailing 30d (~$0.32 avg)

Where we stand per core UC

UC	Standing
UC-1 VERIFY	CROWDED and consolidating — TAP, Agent Pay (+Skyfire), Ant AMP, Solowin AGENPAY all ship identity verification at network/bank layer. Do NOT lead with verify.
UC-2 MANDATE	Semantically validated by arXiv 2608.23858: mandates don't bind pre-auth context. Productable as intent-check on top of AP2/A2A/MCP; AP2 owns authn, nobody owns pre-auth context verification.
UC-5 RECEIPT	Still open. No protocol, network, or Alliance member ships a merchant-facing evidence artifact with counterparty-format export. Strongest remaining white space.
UC-6 DISPUTE	OPEN and unclaimed: APA lists disputes in scope but has published no dispute standard; x402/AP2/A2A have no refund path; Visa CE 3.0 10.4 is the only network precedent. 16-month window before APA or the KYA framework writes over it.
UC-7 RISK	Feature-shaped swarm (ACAGS, Mastercard probability score, t54 risk engine). Bundle-able; do not lead.

Verdict. The market moved toward us in the last 6 months: the problem is now named by card networks themselves (KYA), two consortia exist (APA 26 orgs, x402 Foundation 40 orgs), and academic work (arXiv 2608.23858) proves the mandate gap is real. But the window is closing on the naming event: if we want receipts+disputes in the standards, we must join the Agentic Payments Alliance and/or engage the Visa/MC/Ant KYA framework BEFORE they publish their evidence/dispute formats. Monday action: apply for APA membership / 1-2 warm intros into Visa & Mastercard's agentic payments teams.

10 · Sources

Primary sources first. Anything not directly verifiable is marked UNVERIFIED in the canonical JSON.

Visa Core Rules and Visa Product and Service Rules, 18 April 2026 — §4.1.24 Agentic Platform Requirements (§4.1.24.1–4.1.24.9), §5.4.3 merchant obligations, Dispute Condition 10.4 (CE 3.0) data elements — Primary. Binding network rules effective 18 April 2026. 2026-04-18
Mastercard advances agentic commerce with new trust and intelligence services — Agent Pay Trust Framework — Primary. Agent-detection probability score + shared intelligence layer; Mastercard names Skyfire as its KYA partner. 2026-09-30
t54 Trustline — transaction-level trust, risk, compliance and evidence for the agentic economy — Competitor site. Ships KYA graph, intent challenge, validator-panel risk, tamper-evident audit chain, evidence/dispute/chargeback. 2026 (accessed 2026-10-23)
Beltic — infrastructure for incoming agent traffic — Competitor site. Agent visibility + policy engine + intent intelligence on websites, APIs and MCP servers. No published pricing page (404 on /pricing). 2026 (accessed 2026-10-23)
Regulation (EU) 2026/1744 of 8 July 2026 (Digital Omnibus on AI) — amends 2024/1689 application dates — PRIMARY. Recital (40): high-risk obligations in Chapter III Sections 1-3 deferred to 2 December 2027 for Art 6(2)/Annex III systems and 2 August 2028 for Art 6(1)/Annex I systems, because of delayed standards and national competent authorities. CORRECTS the earlier 'live since 2 Aug 2026' framing. 2026-07-08 (published OJ)
Ralio — the trust layer for agentic business payments — Competitor site. Rail-agnostic guardrails between agents and payment rails; spend limits, allowlists, audit log. ISO 27001 + SOC 2 in progress. 2026 (accessed 2026-10-23)
Natural — agentic payments primitives (wallets, cards, processing, billing) — Competitor site. $30M Series A led by Forerunner, 20 July 2026. Mediates disputes; ties IDs to a verifiable legal identity. 2026 (accessed 2026-10-23)
Skyfire — KYA (Know Your Agent) and KYAPay — Competitor site. KYA identity + KYAPay settlement + agent history. IETF draft for KYAPay profile. 2026 (accessed 2026-10-23)
AP2 — Agent Payments Protocol, Payment Mandate schema and constraints — Primary protocol spec. Mandate constraints incl. allowed payee, amount, recurrence. 2025-09-16 (spec), donated to FIDO Alliance 2026-04-28
Agentic Commerce Protocol (ACP) — open specification, OpenAI + Stripe — Primary protocol spec. Delegated payment spec keeps settlement, refunds, chargebacks and compliance with the merchant and its PSP. 2026 (accessed 2026-10-23)
Model Context Protocol — Authorization (2026-07-28 revision) — Primary spec. OAuth 2.1, scope challenge, step-up authorization flow, Protected Resource Metadata. 2026-07-28
Stripe — Handle orders from agents (agentic commerce for sellers) — Primary vendor doc. Existing refund and dispute flows work without changes for agentic checkouts — Stripe does not verify agents. 2026 (accessed 2026-10-23)
EU AI Act — Article 12 Record-keeping (automatic event logging over system lifetime; ≥6-month deployer retention baseline under Art 19 / Art 26(6)) — PRIMARY. Regulation (EU) 2026/1744 moved Chapter III Sections 1-3 application to 2 Dec 2027 (Art 6(2)/Annex III) and 2 Aug 2028 (Art 6(1)/Annex I). General application date unchanged at 2 Aug 2026. Article 12 text: https://artificialintelligenceact.eu/article/12/ 2024 in force; general application 2026-08-02; Annex III high-risk obligations deferred to 2027-12-02 by Regulation (EU) 2026/1744 (Digital Omnibus on AI, 8 July 2026)
Council of the EU — PSD3/PSR first-reading position, view to adoption — PSD3/PSR NOT yet in the Official Journal as of 2026-10-23. Build to the rule, not to a date. 2026-10-21 (position), published 2026-10-23
Linux Foundation — Agentic AI Foundation (AAIF): MCP, goose, AGENTS.md, A2A, Agent Router, agentgateway — Primary. Neutral home for the agent protocols we would federate. 2025-12-09 (formation)
IETF Internet-Draft — ATXN: Agent-to-Agent Transaction Definition Protocol (draft-stone-atxn-00) — Primary draft. Expires 27 Oct 2026. 2026-04
Machine Payments Protocol (MPP), Stripe + Tempo — sessions primitive for pre-funded spend limits — Primary. First protocol-level acknowledgement that agents need a limit, not just a payment. 2026-03-18 (launch)
Baselayer / Osiris Ratings — Agentic Identity Suite, $35M Series A led by M13 — Business-identity incumbent entering agent identity. 2,300+ FIs, 10M+ applications, $1B+ fraud prevented. 2026-10-04
Chargeback.io — Agentic Payments and Chargebacks: A Merchant Guide — Maps agent disputes onto existing Visa reason codes 10.4 / 13.1 / 13.3. Cites ACI: mandate-based authorization 'currently untested in courts and before regulators'. 2026 (accessed 2026-10-23)
Digital Applied — Agent Checkout Authentication: Who Vouches for the Bot? — Analysis. No card network has published an agent-specific dispute rule. Visa CE 3.0 accepts the agent-platform login ID as a CE data element, in clear text. 2026 (accessed 2026-10-23)
Agent Payments Tracker — protocol-by-protocol status and public volume evidence — x402 ~109.6M transactions / ~$15M adjusted volume (Visa & Artemis analysis), Apr 2026. Visa 'hundreds' of agent transactions as of Dec 2025. 2026 (accessed 2026-10-23)