Audience: CISOs at financial institutions deploying agent-initiated payments, model risk officers (MROs) governed by SR 26-2, fintech architects integrating Visa TAP or Mastercard Agent Pay, payment operations teams evaluating Stripe MPP, CFPB examiners reviewing agent-driven adverse actions, and enterprise procurement leads authorizing autonomous spending.
1. The Evidence Gap
Complementary, not competitive. Payment networks move money and verify identity. SWT3 produces the independent evidence of why the agent acted, which model decided, and whether guardrails were active. The two layers serve different purposes. Neither replaces the other.
Every agentic payment protocol in production today answers one set of questions well and leaves another set entirely unanswered.
| What the Payment Rail Proves | What No Payment Rail Proves |
|---|---|
| The token has $500 of spending authority | Why the agent decided to spend it |
| The agent is registered in an approved directory | Which foundation model version generated the purchase decision |
| The merchant is legitimate | Whether a content safety guardrail was active at checkout |
| The transaction settled successfully | Whether human approval was recorded before execution |
| The credential was scoped to this merchant category | Whether the agent experienced prompt injection during the session |
This is not a criticism of payment infrastructure. Visa, Mastercard, and Stripe built excellent systems for what they were designed to do: identity, authorization, and settlement. The evidence gap exists because compliance questions about AI agent behavior sit above the payment layer. The payment rail confirms the transaction happened. It does not confirm the agent was operating within its governance boundaries when it decided to make the transaction.
SR 26-2 Model Risk Implications: Under SR 26-2 (which superseded SR 11-7), the AI model that evaluates vendors and selects a purchase is itself a model subject to model risk governance. The payment receipt documents that the transaction executed. It does not document the model's version, validation status, or decision provenance. That documentation gap is what independent witnessing fills.
Organizations operating below the regulatory threshold for independent evidence -- consumer agent shopping, low-value automated purchases -- may not need this layer. Enterprise procurement, regulated financial services, high-value autonomous transactions, and any deployment subject to SR 26-2, CFPB adverse action rules, or EU AI Act deployer obligations do.
2. A Scenario: What a Disputed Agent Purchase Looks Like
A procurement agent spends $50,000 on cloud infrastructure. The CFO disputes the purchase. What evidence exists?
| Source | What It Says | What It Cannot Answer |
|---|---|---|
| Stripe | Payment successful, $50,000, Oct 9, 2026, merchant: CloudCorp Inc. | Who authorized this? Why CloudCorp over two cheaper alternatives? |
| Mastercard | Agentic Token valid, within $75K quarterly spend cap, correct merchant category | Was the spending policy active when the agent checked out? Which model decided? |
| Visa TAP | Agent identity verified via Ed25519 signature, directory registration confirmed | Did the agent compare vendors? Was a guardrail active? Was a human in the loop? |
Now the same scenario with an SWT3 witness chain:
| Step | What Happens | Witness Anchor |
|---|---|---|
| 1 | VP of Engineering approves $75K quarterly cloud budget | AI-HITL.2 (human approval recorded with identity and timestamp) |
| 2 | Agent queries 3 cloud vendors via MCP tool calls | AI-TOOL.1 (x3, each vendor query witnessed with scope and duration) |
| 3 | Model evaluates vendor proposals on price, SLA, and compliance posture | AI-MDL.2 (model version recorded), AI-EXPL.1 (evaluation criteria recorded) |
| 4 | Spending policy guardrail confirms $50K is within $75K quarterly cap | AI-GRD.1 (guardrail active, policy evaluated, no violations) |
| 5 | Agent executes payment via Stripe MPP | AI-FIN.1 (authorization type, amount, outcome) |
| 6 | Full decision chain anchored from approval to payment | AI-CHAIN.1 (6 steps linked, 1 model, 0 gaps) |
With this witness chain, the CFO's question is answerable in minutes: the VP approved the budget, the agent evaluated three vendors, the model selected CloudCorp based on documented criteria, the spending guardrail confirmed the amount was within policy, and the full chain is cryptographically verifiable. Without it, the answer lives inside the AI platform's operational logs -- logs controlled by the same entity being questioned.
3. The Payment Protocol Landscape
Five protocols are in production or late-stage deployment for agent-initiated payments. Each is well-engineered for its purpose. The "Gap" column identifies what falls outside each protocol's scope.
| Protocol | Operator | What It Does | Gap |
|---|---|---|---|
| Agent Pay | Mastercard | Agentic Tokens via MDES -- scoped credentials bound to specific agent, merchant category, and dollar cap. First live transaction: Singapore, Mar 4, 2026 (DBS Bank, Hoppa). | Requires "agent attestation" but does not provide it. No model identity, no intent verification. |
| Trusted Agent Protocol (TAP) | Visa + Cloudflare | Ed25519 signatures in HTTP headers (RFC 9421). Agent identity, user consent, and transaction intent signed into request headers. Verified against Visa's Agentic Directory. Open specification on GitHub. | Verifies agent identity, not agent reasoning. No behavioral monitoring post-authorization. No dispute resolution for autonomous transactions. |
| Machine Payments Protocol (MPP) | Stripe + Tempo | HTTP-native billing for AI agents: subscriptions, streaming usage, reconciliation. Link Agent Wallet issues one-time-use cards per task. Shared Payment Tokens prevent credential reuse. | Audit trail is inside Stripe's infrastructure. Metering is operational, not independently verifiable. |
| Agent Payments Protocol (AP2) | Three cryptographically signed mandates as W3C Verifiable Credentials: Intent (user authorization), Cart (agent assembly), Payment (charges). 60+ partners. | Mandate compliance monitoring at scale -- validating thousands of payments against a single Intent Mandate in real time. | |
| x402 | Open protocol | Payment embedded in the HTTP layer. Sub-2-second settlement in USDC on Base. 50+ million transactions in first 9 months. Machine-to-machine micropayments. | Optimized for speed and cost, not compliance evidence. No agent behavior witnessing. |
Ant International, Visa, and Mastercard have agreed on a shared agent identity standard, signaling industry convergence on the identity layer. The evidence layer -- independent proof of agent behavior during the transaction -- remains unaddressed by any payment protocol.
4. The Three-Layer Stack
Visa TAP / Mastercard / Stripe MPP
Identity, tokenization, authorization, settlement. Moves the money.
SWT3 Protocol
Witness anchors, decision provenance, model identity. Proves why the money moved.
Auditors / MROs / Examiners
Verify anchors, reconstruct decision chains, validate compliance. Independent evaluation.
Each layer operates independently. Payments process if the evidence layer is unavailable. Evidence records remain verifiable without the payment rail running. Assessment can occur offline from either layer.
5. Protocol Features Mapped to SWT3
| Protocol Feature | SWT3 Procedure | Why Independent Evidence |
|---|---|---|
| Mastercard Agentic Tokens (scoped credentials bound to agent + merchant + cap) | AI-ID.1, AI-ACC.1 | Mastercard confirms the token is valid. It does not confirm the agent was operating within its governance policy when it used the token. |
| Visa TAP (Ed25519 signed identity in HTTP headers) | AI-ID.1 | TAP verifies agent identity cryptographically. It does not verify the agent's reasoning or model integrity during the transaction. |
| Visa Agentic Directory (verified registry of agents and merchants) | AI-MCP.1 | The directory confirms the agent is registered. A witness anchor proves what the agent was authorized to do at a specific point in time -- registrations can change. |
| Stripe Link Agent Wallet (one-time-use cards, per-task tokens) | AI-FIN.1, AI-TOOL.1 | Link provides a transaction receipt inside Stripe's dashboard. A witness anchor exists outside the payment processor's infrastructure. |
| Stripe MPP (session metering, streaming usage, reconciliation) | AI-AUDIT.1 | MPP metering is operational telemetry that can be rotated or filtered. A witness anchor is an immutable record that the metering existed and was complete. |
| AP2 Intent Mandate (W3C VC of user authorization) | AI-ACC.1, AI-HITL.2 | The mandate records user authorization. A witness anchor independently records that the authorization was verified before the agent acted on it. |
| AP2 Cart Mandate (agent-assembled purchase as W3C VC) | AI-CHAIN.1 | The cart records what the agent assembled. A witness anchor records the full decision chain -- how the agent arrived at that cart. |
| All protocols: model selection | AI-MDL.2 | No payment protocol records which foundation model made the purchase decision. Under SR 26-2, that model is subject to model risk governance. |
| All protocols: guardrail status | AI-GRD.1 | No payment protocol confirms whether a content safety or spending policy guardrail was active during the checkout flow. |
6. Procedure Deep Dives
Agent Transaction Witnessing
Records the authorization basis, value, and outcome of an agent-executed financial transaction. This is the primary evidence anchor for agentic commerce -- it captures not just that a payment occurred, but under what authority and with what result.
| Factor A | authorization_type -- how the agent was authorized (pre-approved, human-authorized, policy-based, budget-limited) |
| Factor B | amount -- transaction value |
| Factor C | outcome -- authorized, denied, or escalated |
| Verdict | PASS when authorization type is documented and outcome is recorded |
For transactions above the organization's delegation threshold, verify that authorization_type is not "pre-approved" without a corresponding AI-HITL.2 anchor establishing the pre-approval. A pattern of high-value transactions with "pre-approved" authorization and no linked human approval is a finding. Also check for "denied" and "escalated" outcomes -- their presence indicates the authorization layer is actively enforcing boundaries, not rubber-stamping.
Agent Identity Witnessing
Records that the agent's identity was verified before the transaction. In the payments context, this witnesses the binding between the agent's operational identity and the payment credential -- whether that credential is a Mastercard Agentic Token, a Visa TAP-signed header, or a Stripe Shared Payment Token.
| Factor A | agent_id -- the agent's unique identifier |
| Factor B | identity_provider -- the system that verified the identity (Visa TAP, Mastercard MDES, internal IdP) |
| Factor C | credential_type -- the payment credential bound to this identity |
| Verdict | PASS when identity is verified and credential binding is confirmed |
Cross-reference the agent_id in the witness anchor with the agent identity in the payment protocol's records. For Mastercard, verify the Agentic Token was issued to this specific agent. For Visa TAP, verify the Ed25519 public key in the Agentic Directory matches. An agent transacting under a different identity than it was witnessed with is a critical finding.
Access Authorization Witnessing
Records that a pre-transaction authorization check occurred before the agent executed the payment. The critical distinction: this witnesses the policy evaluation, not just the payment authorization. A Mastercard token being valid is payment authorization. The spending policy being evaluated and satisfied is governance authorization.
| Factor A | authorization_id -- the policy or spending rule evaluated |
| Factor B | decision -- permit or deny |
| Factor C | resource_scope -- what the authorization covers (merchant category, dollar range, time window) |
| Verdict | PASS when the authorization check completed (regardless of permit/deny) |
Verify the anchor timestamp precedes the payment timestamp. Authorization that occurs after the payment is post-hoc rationalization, not governance. For organizations with tiered spending policies (e.g., under $1K auto-approved, $1K to $10K manager approval, above $10K VP approval), verify the resource_scope matches the tier appropriate for the transaction amount.
Human-in-the-Loop Approval Witnessing
Records that a human reviewed and approved the agent's proposed action before execution. In the payments context, this is the evidence that a person with appropriate authority signed off on the spend -- whether that approval came through Stripe's Link app notification, an internal approval workflow, or a budget mandate.
| Factor A | approver_role -- the role or authority level of the human approver |
| Factor B | approval_scope -- what was approved (specific transaction, budget envelope, category) |
| Factor C | approval_method -- how approval was recorded (app notification, email, workflow system) |
| Verdict | PASS when human approval is recorded with identity, scope, and timestamp |
For high-value transactions, verify the AI-HITL.2 anchor timestamp precedes the AI-FIN.1 anchor timestamp. A gap of more than the organization's defined approval window (e.g., 72 hours) between approval and execution may indicate stale authorization. For budget-envelope approvals ("$75K this quarter"), verify cumulative spend against the envelope by filtering all AI-FIN.1 anchors within the approval period.
Model Card Witnessing
Records which foundation model made the purchase decision. This is the procedure that connects agentic payments to model risk management. Under SR 26-2, the model that evaluates vendors, compares prices, or selects products is subject to model governance -- including validation, performance monitoring, and documentation requirements.
| Factor A | model_id -- the specific model version used for the purchase decision |
| Factor B | provider -- the model provider |
| Factor C | task_type -- the decision task (vendor evaluation, price comparison, inventory selection) |
| Verdict | PASS when model identity is recorded for the decision |
This is the SR 26-2 linchpin. If the organization cannot produce the model version that made a purchase decision, the model risk management framework has a gap. Verify that the model_id corresponds to a model in the organization's approved model inventory. A purchase decision made by an unapproved model version is a model risk finding regardless of whether the transaction itself was financially authorized.
Decision Chain Witnessing
Records the full sequence from user intent to payment execution. In the payments context, this is the evidence that reconstructs the complete decision path: who approved, what was evaluated, which model decided, what guardrails checked, and when the payment executed -- all linked in a single verifiable chain.
| Factor A | chain_id -- unique identifier linking all steps in this transaction |
| Factor B | step_count -- number of steps in the chain |
| Factor C | gap_count -- number of missing steps (0 = complete chain) |
| Verdict | PASS when the chain is complete with no gaps |
A complete decision chain is the single most valuable evidence artifact for dispute resolution. When a transaction is contested, filter the witness ledger by chain_id to reconstruct the full path. Chains with gaps (missing steps between authorization and execution) indicate incomplete witnessing -- the transaction may be legitimate, but the evidence is insufficient to prove it.
Guardrail Attestation
Records that a spending policy, content safety filter, or compliance guardrail was active during the checkout flow. In the payments context, this answers a question no payment receipt can: "Was the organization's AI governance policy being enforced when this agent decided to spend money?"
| Factor A | guardrail_type -- the control category (spending policy, content filter, compliance check) |
| Factor B | policy_active -- whether the guardrail was in effect during the transaction |
| Factor C | evaluation_result -- pass, block, or flag |
| Verdict | PASS when the guardrail was active (regardless of whether it blocked anything) |
A payment processed without a corresponding AI-GRD.1 anchor is a finding. It means no evidence exists that a governance control was active when the agent made the spending decision. The absence of a guardrail anchor is more significant than a guardrail that evaluated and passed -- the first indicates no governance; the second indicates governance that found no issues.
Explainability Witnessing
Records why the agent made this specific purchase decision. Under CFPB Circular 2026-03, organizations must provide specific, accurate reasons when an AI system makes an adverse determination. While the circular targets credit decisions, the same explainability principle applies to any AI-driven financial decision that a consumer or stakeholder might dispute.
| Factor A | decision_type -- the nature of the decision (vendor selection, price acceptance, quantity determination) |
| Factor B | criteria_count -- number of evaluation criteria used |
| Factor C | explainability_method -- how the decision factors were captured |
| Verdict | PASS when decision criteria are documented |
If a consumer or business partner disputes an agent-driven decision ("why did the agent choose Vendor A over Vendor B?"), this anchor provides the starting point for reconstruction. Under CFPB Circular 2026-03, model complexity is explicitly not a defense for failing to explain a decision. Verify that criteria_count is greater than zero and that the criteria are specific enough to satisfy Regulation B requirements for adverse action notices.
7. Regulatory Framework Mapping
The following table shows how the combined payment protocol + SWT3 stack maps to specific regulatory requirements. For deeper coverage of individual frameworks, see the dedicated crosswalk guides for SR 11-7 / SR 26-2, CFPB Circular 2026-03, Treasury FS AI RMF, and EU AI Act.
| Framework | Citation | Requirement | Payment Rail Role | SWT3 Evidence |
|---|---|---|---|---|
| SR 26-2 | Model Governance | All models used in decision-making must be documented in the model inventory with version, validation, and performance records | Not addressed -- payment rails do not track model identity | AI-MDL.2, FIN-MRM.1 |
| CFPB 2026-03 | Adverse Action | Lenders using AI must provide specific, accurate reasons for adverse determinations; model complexity is not a defense | Not addressed -- payment rails record outcomes, not reasoning | AI-EXPL.1, AI-CHAIN.1 |
| EU AI Act | Art. 12 | High-risk AI systems shall allow automatic recording of events (logs) throughout their lifetime | Transaction logs only -- not AI decision events | AI-AUDIT.1 |
| EU AI Act | Art. 26 | Deployers shall keep logs automatically generated by the high-risk AI system, to the extent they are under their control | Payment logs are acquirer/issuer controlled, not deployer controlled | AI-CHAIN.1, AI-FIN.1 |
| PSD2 / PSD3 | SCA | Strong customer authentication for electronic payments; delegated authority must be traceable to the authorizing customer | Authentication handled by payment protocol | AI-HITL.2, AI-ACC.1 |
| FINRA 2026 | Agent Classification | AI agents executing financial transactions must be classified, registered, and subject to supervisory controls | Visa Agentic Directory covers registration | AI-ID.1, AI-GOV.1 |
8. Coverage Matrix
SWT3 witness procedures mapped to payment protocol components. A "Y" indicates the procedure produces independent evidence for that protocol's operations.
| Procedure | Mastercard | Visa TAP | Stripe MPP | AP2 | x402 |
|---|---|---|---|---|---|
| AI-FIN.1 | Y | Y | Y | Y | Y |
| AI-ID.1 | Y | Y | Y | Y | |
| AI-ACC.1 | Y | Y | Y | ||
| AI-HITL.2 | Y | Y | Y | Y | |
| AI-MDL.2 | Y | Y | Y | Y | Y |
| AI-CHAIN.1 | Y | Y | Y | Y | Y |
| AI-GRD.1 | Y | Y | Y | Y | Y |
| AI-EXPL.1 | Y | Y | Y | Y | Y |
| AI-TOOL.1 | Y | Y | Y | ||
| AI-MCP.1 | Y | ||||
| AI-AUDIT.1 | Y | Y |
9. For Auditors, MROs, and CISOs
| Examiner Question | Where to Look |
|---|---|
| "Can you prove human approval preceded this $50K purchase?" | AI-HITL.2 anchor with timestamp before AI-FIN.1 anchor. Filter by chain_id to see both in sequence. |
| "Which model decided to buy from Vendor A instead of Vendor B?" | AI-MDL.2 anchor shows the model version. AI-EXPL.1 anchor shows the evaluation criteria and decision factors. |
| "Was the spending limit enforced at the model level, not just the token level?" | AI-ACC.1 anchor shows the policy evaluation. AI-GRD.1 anchor confirms the guardrail was active. Compare against the Mastercard token cap to verify both layers enforced. |
| "Can you reconstruct the full decision chain for this disputed transaction?" | AI-CHAIN.1 anchor links all steps. Filter the witness ledger by chain_id to see the complete sequence from authorization to payment. |
| "Does this evidence satisfy SR 26-2 model documentation requirements?" | AI-MDL.2 documents the model identity. FIN-MRM.1 documents the model's inventory status and validation. Together they satisfy the model governance documentation requirement. |
| "A consumer disputes an agent-denied purchase. Can you produce the specific adverse action factors?" | AI-EXPL.1 anchor records the decision criteria. AI-CHAIN.1 reconstructs the full reasoning path. Together they satisfy CFPB Circular 2026-03's requirement for specific, accurate reasons. |
| "How do you verify these records weren't altered after the dispute was filed?" | Each SWT3 Witness Anchor contains a SHA-256 fingerprint that any party can independently verify. Paste the anchor at sovereign.tenova.io/verify or use the protocol verifier. |
10. Clearing Levels for Financial Transactions
SWT3 clearing levels classify the sensitivity of witnessed operations. For agentic payment workloads:
| Level | Classification | Transaction Type | Evidence Handling |
|---|---|---|---|
| L0 | Analytics | Aggregate spend reporting, category-level summaries | No transaction-level detail in witness factors |
| L1 | Standard | Routine business purchases, office supplies, SaaS subscriptions | Full factor detail, standard retention |
| L2 | Sensitive | Customer financial data, vendor contract terms, pricing intelligence | Encrypted factors, restricted access, extended retention |
| L3 | Classified | AML/KYC workflows, regulatory reporting, cross-border settlement | Full chain-of-custody, jurisdiction controls, legal hold capable |
Clearing levels are set per witness call. An organization running both routine procurement agents (L1) and AML monitoring agents (L3) applies different evidence handling to each without changing the payment integration.
11. Code Examples
SWT3 integrates with any payment flow using the existing SDK. No additional packages are required -- the same wrap_tool() method that witnesses any function call witnesses a payment call.
Python: Witness a Stripe Payment
from swt3_ai import Witness
import stripe
witness = Witness(
api_url="https://sovereign.tenova.io/api/v1/witness",
api_key="axm_live_...",
agent_id="procurement-bot-09"
)
# Wrap the Stripe payment call -- 1 line of integration
pay = witness.wrap_tool(stripe.PaymentIntent.create, "stripe-payment")
# Every payment is now independently witnessed
result = pay(
amount=50000_00, # $50,000
currency="usd",
payment_method="pm_card_visa",
metadata={"vendor": "CloudCorp", "budget_id": "Q4-2026-CLOUD"}
)
TypeScript: Witness a Stripe Payment
import { Witness } from "@tenova/swt3-ai";
import Stripe from "stripe";
const witness = new Witness({
apiUrl: "https://sovereign.tenova.io/api/v1/witness",
apiKey: "axm_live_...",
agentId: "procurement-bot-09"
});
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const pay = witness.wrapTool(
stripe.paymentIntents.create.bind(stripe.paymentIntents),
"stripe-payment"
);
// Every payment is now independently witnessed
const result = await pay({
amount: 5000000, // $50,000
currency: "usd",
payment_method: "pm_card_visa",
metadata: { vendor: "CloudCorp", budget_id: "Q4-2026-CLOUD" }
});
12. Get Started
pip install swt3-ai
or npm install @tenova/swt3-ai