Agent Payment Assurance Framework.

Why assurance, why now

The agent-payment protocol stack (FIDO AP2, Mastercard Verifiable Intent / Agent Pay, Visa VIC / Trusted Agent Protocol, OpenAI/Stripe ACP, x402, and peers) converges on one job: proving a payment was authorized. Signed mandates, layered SD-JWT selective disclosures, RFC 9421 HTTP message signatures, checkout hashes, and cnf-bound agent keys answer "is this transaction validly authorized?" — and current drafts answer it well.

They do not answer the question every issuer, sponsor bank, and merchant processor actually asks at settlement time: should this validly-authorized payment occur?

A mandate can be cryptographically perfect and still be:

• issued under a compromised agent key (no revocation path — AP2 #386),
• re-presented after fulfillment (proof of delegation is not proof of non-reuse — AP2 #346),
• mismatched between the approved cart and the payment container (AP2 #211),
• within its constraints but pointed at a sanctioned counterparty or a newly injected beneficiary,
• the fortieth transaction an agent has closed in an hour under an "open" mandate the user signed once and forgot,
• settled with zero evidence trail an auditor or disputing cardholder can independently recompute and verify offline.

This document names the missing layer — payment assurance — and defines the rubric for evaluating anything that claims to provide it. Requirements use RFC 2119 keywords (MUST/SHOULD/MAY).

1. Scope

An assurance layer sits between an agent-payment protocol surface and a settlement rail. It:

• consumes protocol artifacts (mandates, layered SD-JWTs, HTTP signatures, receipts, agent keys, transaction intents) — it does NOT define them;
• emits verdicts (approve / decline / escalate), actuates release controls (holds, releases, RFP accepts/rejects, synchronous auth-loop declines) via the tenant's sponsor bank or processor, and produces signed compliance evidence — it does NOT move money through its own accounts;
• operates pre-settlement — decisions MUST be possible before funds commit.

It MUST NOT: custody funds, act as a payment-rail participant, or store end-customer payment credentials (PANs, CVCs, or signing keys it does not own). Storing tenant-scoped sponsor-bank API credentials in encrypted form to actuate verdicts on the tenant's own bank account is inside the boundary; pooling funds or executing on a shared platform bank account is not. If a product takes custody or participates directly on a rail, evaluate it under MSB/processor diligence instead.

2. The seven domains

APAF-1 · Mandate lifecycle & protocol conformance verification

Beyond signature validity, the layer MUST evaluate:

• Existence & state machine: mandate resolves to a live record and tracks state transitions (active → expired → revoked → superseded → consumed) with atomic spend/count reservation (SELECT … FOR UPDATE or equivalent) so a single-use or capped mandate cannot verify twice under concurrency (AP2 #346).
• Scope & constraint evaluation: amount (including minor-unit ISO-4217 normalization), cumulative budget, recurrence, counterparty/payee, category, currency, and execution window within bounds. Unrecognized or unresolved constraint types MUST fail closed to unverifiable (escalate or decline), never silently drop.
• Cart-to-payment integrity binding: for protocols that separate checkout and payment artifacts (AP2 checkout_hash / transaction_id, Mastercard Verifiable Intent L1→L2→L3 sd_hash chain), the layer MUST recompute the cryptographic binding between the merchant's checkout and the payment mandate rather than trusting caller-supplied fields (AP2 #211).
• Temporal validity: exp set and unexpired — standing/open mandates without exp MUST be treated as an unverifiable risk signal, not silently approved (AP2 #386).
• Provenance: issued by the party that owns the agent relationship and verified against per-tenant counterparty key registries (never pooled across tenants).

APAF-2 · Agent identity & authority

Every transacting agent MUST resolve to a registered identity bound to an accountable human or legal entity (beneficial owner / operator). Registration MUST carry a risk tier that gates transaction limits, rate quotas, and escalation thresholds. Agent status MUST support suspension and revocation with enforcement at decision time — not just at registration.

• Cryptographic key & credential binding: agent keys bound to mandates (cnf) or HTTP message signatures (RFC 9421) MUST resolve to a registered identity or scoped counterparty key registry (ap2_merchant, vi_issuer, vic_tap). Self-declared headers (X-Agent-ID) without cryptographic proof MUST be rejected, and an unknown key is an unknown agent regardless of signature validity.
• Identity-bound throttling: rate limits and quotas SHOULD bind to the authenticated credential and risk tier rather than IP address alone, since autonomous agents share cloud egress IPs or rotate across regions (OWASP API4:2023 / AI Agent Payments Cheat Sheet §6).

APAF-3 · Behavioral risk assessment

Authorization checks are point-in-time; assurance requires pattern-in-time across three horizons (CSA ATSF v1 §4, §7):

1. Per-transaction deviation: score each transaction against the agent's own behavioral baseline — amount distribution (z-score), counterparty novelty, category, time-of-day, and protocol.
2. Session & mandate cumulative drift: detect beneficiary creep (rapid counterparty acquisition velocity — an agent paying many distinct counterparties in a short window, characteristic of indirect prompt injection / OWASP ASI01) and scope inflation (cumulative spend approaching or cycling mandate caps).
3. Fleet & cross-agent correlation: detect Sybil agent rotation (multiple agents under the same owner splitting volume to evade per-agent caps) and mule fan-in (multiple distinct agents converging on one counterparty within a short window).

Scores MUST be explainable: a number without the factor breakdown and retrieved evidence that produced it is a liability, not a control. The layer SHOULD support a shadow / observation mode (mode="shadow") and output drift detection so baselines can be enrolled without live-rail exposure and guarded against gradual baseline poisoning (OWASP ASI06).

Fail-closed is non-negotiable: scoring or baseline infrastructure failure MUST produce decline-or-escalate, never silent approve.

APAF-4 · Counterparty & operator screening

Every transaction MUST be screened synchronously before execution against sanctions and adverse-entity data (OFAC SDN, EU Consolidated, UN Security Council, FATF high-risk) — and the screen MUST traverse relationships, not just string-match names. A merchant whose beneficial owner or parent entity sits on a list is a hit even when the merchant name is clean.

• Full-party coverage: screening MUST cover all parties to the delegation: agent owner/operator (at registration and at transaction time), end user, merchant/counterparty, and where resolvable, the counterparty's controlling entities.
• Evasion resilience: matching MUST normalize Unicode/homoglyphs, corporate suffixes, punctuation, and known aliases, and isolate tenant-specific watchlists from cross-tenant leakage.
• Freshness tracking: the layer MUST track per-source list refresh timestamps and entity counts so every screening verdict can prove which list state backed the check (OWASP AI Agent Payments Cheat Sheet §10).

APAF-5 · Decision provenance & offline-verifiable evidence

Every verdict MUST be recorded as a tamper-evident event in a hash chain the assurance layer cannot silently rewrite. Four properties must be separated — they fail independently (AP2 #290, #338):

• Completeness: no event in a decision boundary was dropped (monotonic sequence + predecessor linkage across transaction, mandate, and governance events).
• Existence-at-time: the record existed when claimed — a chain reconstructed later satisfies every internal integrity rule while being temporally false. Closing this requires anchoring chain-tip digests to a store the operator doesn't control (WORM S3 Object Lock in COMPLIANCE mode, transparency log, or equivalent), on a defined cadence.
• Withholding resistance: an anchored-but-unpresented event verifies individually and silently — completeness and existence-at-time don't see it. The layer MUST commit {head, count} at each boundary close, fixed in the chain at close and discoverable by the relying party, so a presented set must recompute to a digest it cannot take back.
• Witnessed silence: the seal cadence MUST fire on schedule, not on activity — a period with no new events still re-commits the prior head and count. Otherwise an adversary starves the ledger into looking idle, and a missing seal is indistinguishable from a quiet one.

Honest limit: all four are guarantees up to the last external seal — a tail cut inside the current window is undetectable until the next anchor lands, so boundary-close commits shrink the exposure to the transition itself. The complementary failure mode — a producer that never records an action at all — is not addressable at the hash layer; it belongs to the signing-trust / counterparty-observation surface (APAF-1, APAF-2).

For dispute and examiner readiness, exported evidence bundles MUST:

• Recompute live, not replay cache: re-verify protocol authorization against current key registries and re-screen named parties at export time.
• Bind sanctions-list freshness: include the screening timestamp and per-source sanctions list freshness metadata (source list, entity count, last-ingested timestamp) inside the signed bundle digest so an examiner can verify the screen was not run against a stale list (OWASP Cheat Sheet §10).
• Verify offline via canonical digest + JWS: compute a deterministic canonical-JSON SHA-256 digest over all bundle sections and sign it with a platform attestation key (EdDSA / ES256 JWS) verifiable against a published JWKS endpoint supporting key rotation — so an issuer, sponsor bank, or arbitrator can verify authenticity and tamper-evidence offline without calling the vendor.

APAF-6 · Human escalation & dual control

Assurance that can only say yes or no will eventually have to say "wait." The layer MUST define an escalation verdict with a binding hold mechanism on parkable rails — funds frozen at the sponsor bank while review runs — and MUST enforce maker-checker: the party that requested or initiated a decision cannot approve its release.

• Out-of-band & context-isolated review: escalation notifications and approval surfaces MUST operate out-of-band from the agent's runtime and LLM context (so a prompt-injected agent cannot approve or spoof its own escalation — CSA ATSF v1 §2–3; OWASP ASI01) and MUST present structured, normalized transaction facts rather than unverified agent-generated rationales (OWASP Explainability Fabrications).
• Rail-timing honesty: on synchronous authorization-loop rails with hard sub-second/second-class budgets (e.g., card auth loops at ≤1500 ms) that cannot park a transaction for human review, an escalated risk verdict MUST fail closed into an immediate decline (manual_review_required), never a deferred pass.

Escalations on parkable rails MUST resolve to approve (release hold + execute) or reject (release hold + cancel/return) with the full path audited. Timeouts MUST fail closed.

APAF-7 · Rail-agnostic settlement boundary

The verdict path MUST be separable from any single rail or provider. Rails differ (book/ACH/wire/RTP/FedNow, ISO 20022 pacs.008/pain.013/camt.054, card authorization loops, ACP/AP2/VI/TAP checkout flows); assurance semantics don't. The layer MUST normalize provider and protocol events into one verdict model and MUST scope provider credentials per tenant/project so each deploying customer operates under its own sponsor-bank relationship (never a shared platform account).

Honesty requirement: the layer MUST NOT claim rail certification, network participation, or settlement capability it doesn't hold. A verification layer verified through a sponsor bank is a different claim — and a stronger one — than claiming to be the rail.

3. Maturity model

Self-scoring rule: a level is claimed only when every requirement in each of its domains holds. "Mostly L2 with list-match-only screening" is L1.

4. Standards & regulatory alignment cross-walk

To assist bank TPRM teams, compliance officers, and protocol implementers, the table below maps APAF-1..7 to adjacent industry standards and regulatory frameworks:

5. What this framework is not

• Not a protocol. APAF consumes protocol artifacts; it doesn't define wire formats. Protocol gaps belong upstream (FIDO Payments TWG / Agentic Authentication TWG, AP2, Mastercard VI, ACP).
• Not a compliance program. BSA/AML/OFAC obligations stay with the licensed institution. An assurance layer produces enforcement inputs and evidence — the institution owns its program.
• Not certification. Scoring against APAF is self-attestation. Formal assurance (SOC 2, PCI QSA, regulatory exams) applies to deployments, not rubrics.

6. Contribution

This is a living rubric. Corrections, domain proposals, and scoring challenges: contact@paymnts.ai, or the AP2 tracker where they intersect protocol semantics. Cite as:

APAF-1 — Agent Payment Assurance Framework v1.2, Sunhill LLC (paymnts.ai), Oct 2026. CC-BY-4.0.