{ "file_id": "14_vertical_agentic_payments_and_stablecoins", "version": "2026.07.01", "schema_version": "2.3", "status": "Production Authority", "last_authoritative_sync": "2026-07-01", "description": "Comprehensive enumeration library for the Agentic Payments & Stablecoins vertical. Covers every subdomain where agentic AI is actively deployed in payment workflows as of July 2026: AP2 mandate chain governance (Google Agent Payments Protocol v0.2), x402 HTTP-native stablecoin payments (Coinbase), stablecoin asset and issuer compliance (GENIUS Act, EU MiCA), agentic commerce provider classification, fiat instant rail governance (FedNow, RTP, SEPA Instant), and payment regulatory regime tagging. Designed for use as OTel span attributes in an agentic AI SDK and as policy vocabulary in an OPA Rego GRC portal. The AP2 mandate chain (OpenPaymentMandate → PaymentMandate → PaymentReceipt) is the primary governance model; browser-commerce agents and stablecoin treasury transfers are the highest-risk modalities requiring the most rigorous evidence capture.", "vertical_metadata": { "vertical_key": "agentic_payments", "industry": "Agentic Payments & Stablecoins", "primary_standards": [ "Google AP2 v0.2, Agent Payments Protocol (mandate chain SD-JWT wire format, W3C VC issuance)", "Coinbase x402, HTTP-native stablecoin micropayment protocol (PAYMENT-REQUIRED / PAYMENT-SIGNATURE / PAYMENT-RESPONSE headers)", "GENIUS Act (Pub. L. 119-27, signed July 18, 2025), First US federal payment stablecoin framework; §4 reserve requirements and licensing thresholds", "EU MiCA (Regulation 2023/1114), Markets in Crypto-Assets Regulation; ART/EMT token classification; CASP authorization; full enforcement 2026", "ISO 20022, Universal financial industry message scheme (pacs, pain, camt families for FedNow/RTP/SEPA Instant)", "FedNow, Federal Reserve real-time payment service ISO 20022 profile; launched July 2023", "W3C Verifiable Credentials Data Model 2.0, AP2 mandates as SD-JWT verifiable credentials; Veriproof issues Payment Mandate VDC", "IETF SD-JWT (draft-ietf-oauth-selective-disclosure-jwt), Selective disclosure JWT wire format for AP2 mandate chain", "PCI DSS v4.0, Payment Card Industry Data Security Standard; Requirement 10 (audit logging), Requirement 6.3 (approved software)", "FATF Recommendations (updated 2023), AML/CFT; Recommendation 15 (new technologies / virtual assets); applies globally", "EU AI Act (Regulation 2024/1689), Transparency and high-risk classification for AI payment systems", "EU DORA (Regulation 2022/2554), Digital Operational Resilience Act; applies to PSPs and CASPs operating in the EU", "BSA / FinCEN, Bank Secrecy Act SAR and transaction monitoring obligations for AI-initiated stablecoin payments" ], "primary_source_urls": [ "https://goo.gle/ap2", "https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works", "https://en.wikipedia.org/wiki/GENIUS_Act", "https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica", "https://www.iso20022.org/iso-20022-message-definitions", "https://explore.fednow.org/resources/readiness-guide-iso-20022.pdf", "https://www.w3.org/TR/vc-data-model-2.0/", "https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/", "https://www.pcisecuritystandards.org/document_library/" ], "otel_namespace": "agentic_payments", "opa_namespace": "data.agentic_payments", "agentic_ai_deployment_context": "As of July 2026, agentic AI is deployed across all major payment rails as an initiator, delegator, and governance certifier of transactions. Google AP2 (Agent Payments Protocol v0.2) provides a structured mandate chain (OpenPaymentMandate → PaymentMandate → PaymentReceipt) encoded as SD-JWT verifiable credentials, enabling AI agents to make payments within clearly defined constraints with full auditability. Mastercard has integrated AP2 across its $9T+ annual network volume to support agentic commerce. Coinbase x402 enables HTTP-native micropayments with 75M+ monthly transactions across Base, Polygon, Arbitrum, World Chain, Solana, and Ethereum, allowing AI agents to pay for API access and digital services in a single HTTP round-trip. Browser-commerce agents (OpenAI ChatGPT agent mode, Anthropic computer-use) bypass structured payment APIs and execute checkout flows autonomously, a governance gap that Veriproof fills with session-wrapping and mandate verification. The GENIUS Act (Pub. L. 119-27, signed July 18, 2025) established the first US federal framework for payment stablecoins, requiring 1:1 reserves in cash and T-bills and federal licensing for issuers above $10B AUM. EU MiCA (Regulation 2023/1114, full enforcement 2026) requires CASPs and stablecoin issuers to hold national competent authority authorization and appear in the ESMA Interim Register. FedNow and RTP carry ISO 20022 pacs.008 instruction reference requirements for all AI-initiated real-time payments. Veriproof captures evidence at each mandate step, validates constraints via OPA policy, anchors to Solana, and issues W3C VC Payment Mandate certificates, providing the governance certification layer that AP2 merchants, acquirers, and regulators require." }, "subdomains": [ { "subdomain": "AP2 Mandate Chain", "description": "Covers the Google Agent Payments Protocol v0.2 mandate chain lifecycle. AP2 mandates are SD-JWT verifiable credentials transmitted as a tilde-delimited (~~) chain. The chain flows: OpenPaymentMandate (or OpenCheckoutMandate) → PaymentMandate (or CheckoutMandate) → PaymentReceipt (or CheckoutReceipt). Veriproof acts as the governance certification layer: accepting open mandates, validating constraints via OPA policy, anchoring closed mandates to Solana, and issuing W3C VC Payment Mandate certificates. Constraint violations (amount outside range, payee not in allowlist) emit a SessionDirective(Block) and return 422 without anchoring.", "relevant_standards": [ "Google AP2 v0.2, OpenPaymentMandate, PaymentMandate, OpenCheckoutMandate, CheckoutMandate, PaymentReceipt, CheckoutReceipt VCT types", "IETF SD-JWT (draft-ietf-oauth-selective-disclosure-jwt), Tilde-delimited wire format", "W3C Verifiable Credentials Data Model 2.0, AP2 mandates as SD-JWT VCs; Veriproof issues Payment Mandate VDC", "EU AI Act Article 50, AI transparency in financial transactions" ], "categories": [ { "enum_name": "AP2MandateType", "label": "AP2 Mandate Type", "otel_attribute": "agentic_payments.mandate.type", "opa_policy_path": "data.agentic_payments.mandate.type", "rego_input_key": "agentic_payments_mandate_type", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "AP2MandateType" }, "stability": "experimental", "description": "Classification of the AP2 mandate type in the payment chain. Maps to VCT (VC Type) claim values in the AP2 SD-JWT wire format. Open mandates define spending constraints for subsequent transactions; closed mandates record a specific committed transaction; receipts confirm settlement by the payee or merchant.", "permitted_values": [ "open_payment", "open_checkout", "payment", "checkout", "payment_receipt", "checkout_receipt" ], "value_labels": { "open_payment": "Open Payment Mandate", "open_checkout": "Open Checkout Mandate", "payment": "Payment Mandate (closed)", "checkout": "Checkout Mandate (closed)", "payment_receipt": "Payment Receipt", "checkout_receipt": "Checkout Receipt" }, "code_definitions": { "open_payment": "OpenPaymentMandate, An open-ended authorization granting an agent permission to make payments within defined constraints (amount range, allowed payees, payment instruments). Establishes the governance context for subsequent PaymentMandates. VCT: mandate.payment.open", "open_checkout": "OpenCheckoutMandate, An open-ended authorization for checkout workflows; allows the agent to add items to a cart and proceed to checkout within defined spending limits and merchant constraints. VCT: mandate.checkout.open", "payment": "PaymentMandate, A closed mandate recording a specific committed payment transaction. Must include payment_amount, payee, and payment_instrument. Validated against a prior OpenPaymentMandate by Veriproof OPA policy. VCT: mandate.payment", "checkout": "CheckoutMandate, A closed checkout mandate recording a specific cart checkout. Must include line_items, merchant, and total_amount. Validated against a prior OpenCheckoutMandate. VCT: mandate.checkout", "payment_receipt": "PaymentReceipt, Issued by the payee after settlement confirmation. Includes transaction reference and settlement timestamp. sha256(closed_leaf_jwt) becomes the Veriproof receipt_reference stored in session.otel_attributes for Solana anchoring.", "checkout_receipt": "CheckoutReceipt, Issued by the merchant after order fulfillment confirmation. Includes order reference and item confirmation. sha256(closed_leaf_jwt) is the receipt_reference for the checkout chain." }, "regulatory_mappings": { "ap2_v02": "AP2 v0.2, VCT values: mandate.payment.open, mandate.payment, mandate.checkout.open, mandate.checkout in the AP2 SD-JWT wire format", "w3c_vc_2_0": "W3C Verifiable Credentials Data Model 2.0, AP2 mandates are SD-JWT verifiable credentials; Veriproof issues Payment Mandate VDC on attest-and-close", "sd_jwt_ietf": "IETF SD-JWT, Wire format is tilde-delimited SD-JWT chain; mandate type recorded in VCT claim of each SD-JWT disclosure" }, "source": "Google AP2 SDK v0.2, mandate type VCT definitions; AP2 README scenario paths", "source_url": "https://goo.gle/ap2" }, { "enum_name": "AP2MandateStatus", "label": "AP2 Mandate Status", "otel_attribute": "agentic_payments.mandate.status", "opa_policy_path": "data.agentic_payments.mandate.status", "rego_input_key": "agentic_payments_mandate_status", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "AP2MandateStatus" }, "stability": "experimental", "description": "Lifecycle status of an AP2 mandate as tracked by Veriproof. constraint_violated is set by the OPA policy evaluation engine when the PaymentMandate violates the OpenPaymentMandate constraints (amount range or allowed payees). Once constraint_violated is set, a SessionDirective(Block) is emitted and anchoring is suppressed.", "permitted_values": [ "pending", "active", "completed", "constraint_violated", "disputed", "expired" ], "value_labels": { "pending": "Pending", "active": "Active", "completed": "Completed", "constraint_violated": "Constraint Violated", "disputed": "Disputed", "expired": "Expired" }, "code_definitions": { "pending": "OpenPaymentMandate received and stored in session.governance_contract; awaiting the first PaymentMandate step within the mandate chain.", "active": "Mandate chain is in progress; the open mandate has been validated and subsequent payment steps are being accepted. Chain depth ≥ 1.", "completed": "Mandate chain closed and certified; a closed PaymentMandate or CheckoutMandate has been received, validated, anchored to Solana, and a receipt_reference computed. session.decision contains the closed mandate JSON.", "constraint_violated": "PaymentMandate.payment_amount is outside OpenPaymentMandate.constraints[AmountRange].max, or payee.id is not in AllowedPayees, or payment_instrument is not in AllowedPaymentInstruments. OPA policy ap2_payment_amount_must_be_within_open_mandate_range fires; SessionDirective(Block) emitted; anchoring suppressed; HTTP 422 returned.", "disputed": "Payment or checkout has been disputed by the buyer or their agent after initial completion. Veriproof session frozen pending resolution evidence.", "expired": "OpenPaymentMandate validity period has elapsed without a matching closed PaymentMandate being received within the mandate's temporal constraints." }, "regulatory_mappings": { "ap2_v02": "AP2 v0.2 constraint validation, OpenPaymentMandate.constraints defines AmountRange, AllowedPayees, AllowedPaymentInstruments; Veriproof enforces via OPA policy ap2_payment_amount_must_be_within_open_mandate_range", "pci_dss_v4": "PCI DSS v4.0 Requirement 10.2, Transaction anomalies including constraint violations must be logged as security events with audit-ready evidence" }, "source": "AP2 SDK v0.2 OpenPaymentMandate / PaymentMandate constraint model; Veriproof SessionDirective mechanism", "source_url": "https://goo.gle/ap2" }, { "enum_name": "AP2TransactionModality", "label": "AP2 Transaction Modality", "otel_attribute": "agentic_payments.mandate.modality", "opa_policy_path": "data.agentic_payments.mandate.modality", "rego_input_key": "agentic_payments_mandate_modality", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "AP2TransactionModality" }, "stability": "experimental", "description": "Classification of the agent-payment scenario modality. Maps to AP2 scenario paths. Critical for OPA policy routing: human_not_present and delegated_task require a prior open mandate in the session chain (policy ap2_intent_mandate_required_before_agentic_purchase); browser_agent_checkout requires an explicit intent mandate or human confirmation event (policy browser_agent_checkout_requires_intent_mandate_or_explicit_confirmation); treasury_transfer requires KYC/KYB evidence (policy stablecoin_payout_recipient_must_pass_kyc_kyb).", "permitted_values": [ "human_present", "human_not_present", "delegated_task", "subscription", "browser_agent_checkout", "treasury_transfer" ], "value_labels": { "human_present": "Human Present", "human_not_present": "Human Not Present", "delegated_task": "Delegated Task", "subscription": "Subscription", "browser_agent_checkout": "Browser-Agent Checkout", "treasury_transfer": "Treasury Transfer" }, "code_definitions": { "human_present": "Human is actively engaged in the checkout or payment flow; the agent is assisting but the human retains final approval authority. Lowest governance risk. AP2 scenario path: scenarios/a2a/human-present/", "human_not_present": "Agent executes payment autonomously without real-time human review; highest governance risk for consumer-facing flows; requires prior OpenPaymentMandate in the session chain. AP2 scenario path: scenarios/a2a/human-not-present/", "delegated_task": "Agent acting on delegation from another agent in a multi-agent pipeline; mandate chain must trace back to a human-authorized OpenPaymentMandate; AP2ChainDepth ≥ 2.", "subscription": "Recurring authorized payment (e.g. SaaS subscription, utility, media); governed by a standing OpenPaymentMandate with temporal constraints; agent executes on schedule without per-transaction human approval.", "browser_agent_checkout": "Browser automation agent (e.g. ChatGPT agent mode, Anthropic computer-use, browser-use framework) completing a checkout flow without a structured AP2 mandate API integration. Requires session-declared intent mandate or explicit human_initiated confirmation event before Veriproof certifies. Highest governance risk for enterprise deployments.", "treasury_transfer": "AI-initiated outbound stablecoin or wire transfer from a corporate treasury account; highest value per transaction; requires KYC/KYB evidence for the recipient, GENIUS Act reserve and licensing compliance evidence, and MiCA compliance check if involving EU-domiciled counterparties." }, "regulatory_mappings": { "ap2_v02": "AP2 scenario matrix, human_present / human_not_present determine which AP2 payment scenario path governs the mandate chain structure", "eu_ai_act_2024_1689": "EU AI Act Annex III, autonomous financial decisions with significant impact on persons may qualify as high-risk AI; modality is a primary risk classification input for AI Act compliance assessment", "genius_act": "GENIUS Act §4, stablecoin payments in human_not_present or treasury_transfer modalities are highest priority for reserve composition and licensing compliance checks" }, "source": "AP2 SDK v0.2 scenario path taxonomy; EU AI Act Annex III; GENIUS Act §4", "source_url": "https://goo.gle/ap2" }, { "enum_name": "AP2ChainDepth", "label": "AP2 Chain Depth", "attribute_type": "integer", "otel_attribute": "agentic_payments.mandate.chain_depth", "opa_policy_path": "data.agentic_payments.mandate.chain_depth", "rego_input_key": "agentic_payments_mandate_chain_depth", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "AP2ChainDepth" }, "stability": "experimental", "description": "Number of tilde-delimited (~~) SD-JWT disclosure sets in the AP2 wire format mandate chain, representing the count of delegation hops from the originating OpenPaymentMandate to the current step. Depth 1 = OpenPaymentMandate only. Depth 2 = Intent + PaymentMandate or CheckoutMandate (standard two-party flow). Depth 3+ = multi-agent delegation with intermediary agents. Chain depth ≥ 6 should trigger heightened governance review.", "permitted_values": [ "1", "2", "3", "4", "5", "6+" ], "value_labels": { "1": "Depth 1, Intent mandate only", "2": "Depth 2, Intent + Payment/Checkout (standard)", "3": "Depth 3, One delegation hop", "4": "Depth 4, Two delegation hops", "5": "Depth 5, Three delegation hops", "6+": "Depth 6+, Heightened governance review required" }, "notes": "AP2ChainDepth is an integer OTel span attribute. The permitted_values list represents categorized monitoring thresholds; actual span values are unbounded positive integers. Record the raw integer in the OTel span; use the categorical buckets for OPA policy threshold evaluation.", "regulatory_mappings": { "ap2_v02": "AP2 wire format, SD-JWT chain is tilde-delimited; chain depth is the count of tilde-separated disclosure sets in the wire format string", "eu_ai_act_2024_1689": "EU AI Act Article 9, multi-agent delegation chains with depth > 5 may require documented accountability chain review as part of the risk management system for high-risk AI systems" }, "source": "AP2 SDK v0.2 SdJwtMandate.wire_format specification; IETF SD-JWT draft tilde-delimiter format", "source_url": "https://goo.gle/ap2" }, { "enum_name": "AP2ReceiptReferencePresent", "label": "AP2 Receipt Reference Present", "attribute_type": "boolean", "otel_attribute": "agentic_payments.mandate.receipt_reference_present", "opa_policy_path": "data.agentic_payments.mandate.receipt_reference_present", "rego_input_key": "agentic_payments_mandate_receipt_reference_present", "stability": "experimental", "description": "Boolean flag indicating whether the sha256(closed_leaf_jwt) receipt reference has been computed, stored in session.otel_attributes, and submitted to Solana for anchoring. Set to true by the Veriproof AP2 adapter after successful attest-and-close. When false on a completed mandate session, indicates an incomplete anchoring pipeline requiring investigation.", "permitted_values": [ "true", "false" ], "value_labels": { "true": "Receipt reference computed and anchor submitted", "false": "Receipt reference not yet computed" }, "regulatory_mappings": { "ap2_v02": "AP2 receipt_reference = sha256(closed_leaf_jwt) base64url-encoded; stored in session.otel_attributes['agentic_payments.mandate.receipt_reference']; serves as the non-repudiable mandate chain anchor", "pci_dss_v4": "PCI DSS v4.0 Requirement 10.2, payment audit events must include a non-repudiable transaction reference; receipt_reference_present = false on a completed session is a compliance gap" }, "source": "AP2 SDK v0.2 compute_sha256_b64url utility; Veriproof session.otel_attributes receipt_reference pattern", "source_url": "https://goo.gle/ap2" } ] }, { "subdomain": "x402 HTTP Payment Events", "description": "Covers Coinbase x402 HTTP-native stablecoin payment protocol events. x402 adds payment capability to any HTTP resource using three headers: PAYMENT-REQUIRED (server announces payment terms), PAYMENT-SIGNATURE (client submits EIP-712 signed authorization), and PAYMENT-RESPONSE (server confirms settlement). Veriproof observes the x402 flow as a non-invasive side-effect observer, no changes to the payment flow are required. Each x402 event triggers evidence capture and OPA policy evaluation. As of May 2026, x402 processes 75M+ transactions per month across Base, Polygon, Arbitrum, World Chain, Solana, and Ethereum.", "relevant_standards": [ "Coinbase x402 Protocol, PAYMENT-REQUIRED / PAYMENT-SIGNATURE / PAYMENT-RESPONSE header specification", "EIP-712, Ethereum typed structured data signing standard (used for PAYMENT-SIGNATURE)", "PCI DSS v4.0 Requirement 10, Payment event audit logging", "FATF Recommendation 15, Virtual asset service provider KYC obligations" ], "categories": [ { "enum_name": "X402PaymentEventType", "label": "x402 Payment Event Type", "otel_attribute": "agentic_payments.x402.payment_event_type", "opa_policy_path": "data.agentic_payments.x402.payment_event_type", "rego_input_key": "agentic_payments_x402_payment_event_type", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "X402PaymentEventType" }, "stability": "experimental", "description": "The x402 HTTP protocol payment event type captured by Veriproof at each step of the 11-step x402 payment flow. Veriproof observes x402 headers as a side-effect observer without modifying the payment flow; each event type triggers evidence capture in the active session and OPA policy evaluation. Events map directly to the x402 HTTP header interactions.", "permitted_values": [ "payment_required", "payment_signature_submitted", "facilitator_verified", "settlement_initiated", "settlement_confirmed", "payment_failed", "payment_rejected_402" ], "value_labels": { "payment_required": "402 Payment Required", "payment_signature_submitted": "Payment Signature Submitted", "facilitator_verified": "Facilitator Verified", "settlement_initiated": "Settlement Initiated", "settlement_confirmed": "Settlement Confirmed", "payment_failed": "Payment Failed", "payment_rejected_402": "Payment Rejected (402)" }, "code_definitions": { "payment_required": "Server returned HTTP 402 with PAYMENT-REQUIRED header containing paymentRequirements (scheme, network, maxAmountRequired, asset, extra). Evidence captured from the PAYMENT-REQUIRED response header. Corresponds to x402 flow step 2.", "payment_signature_submitted": "Client resubmitted the request with a PAYMENT-SIGNATURE header containing the EIP-712 signed payment authorization. Evidence captured from the PAYMENT-SIGNATURE request header. Corresponds to x402 flow step 4.", "facilitator_verified": "Coinbase CDP facilitator (or custom facilitator) has verified the client's payment authorization signature. Intermediate state in the settlement flow before on-chain transaction submission. Corresponds to x402 flow step 6.", "settlement_initiated": "Facilitator has submitted the on-chain settlement transaction. Transaction hash is available but the block has not yet been confirmed. Corresponds to x402 flow step 8.", "settlement_confirmed": "On-chain settlement confirmed; facilitator returns HTTP 200 with PAYMENT-RESPONSE header containing transaction hash, block number, and network identifier. Evidence captured from the PAYMENT-RESPONSE response header. Corresponds to x402 flow step 10.", "payment_failed": "The payment authorization signature was invalid or the client's funds were insufficient; the facilitator did not submit a settlement transaction. Corresponds to x402 flow step 11 (failure path).", "payment_rejected_402": "The server returned HTTP 402 after the client's payment attempt; the facilitator confirmed the payment was not accepted. Distinct from payment_failed: this indicates server-side rejection after a payment was submitted." }, "regulatory_mappings": { "x402_coinbase": "Coinbase x402 11-step HTTP payment flow, steps 2 (402 response), 4 (PAYMENT-SIGNATURE resubmission), 6 (facilitator verification), 8 (settlement initiated), 10 (200 with PAYMENT-RESPONSE)", "pci_dss_v4": "PCI DSS v4.0 Requirement 10.2, all payment authorization and settlement events must be logged with non-repudiable evidence including event type, timestamp, and transaction reference" }, "source": "Coinbase x402 Protocol documentation, How It Works; x402 header specification; CDP Facilitator API", "source_url": "https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works" }, { "enum_name": "X402Network", "label": "x402 Settlement Network", "otel_attribute": "agentic_payments.x402.network", "opa_policy_path": "data.agentic_payments.x402.network", "rego_input_key": "agentic_payments_x402_network", "stability": "experimental", "description": "The blockchain network used for x402 on-chain stablecoin settlement. Coinbase CDP Facilitator supports Base, Polygon, Arbitrum, World Chain, Solana, and Ethereum as of May 2026. Different networks carry different transaction finality characteristics, gas cost models, and regulatory jurisdictions. Network selection is specified in the PAYMENT-REQUIRED header's paymentRequirements.network field.", "permitted_values": [ "base", "polygon", "arbitrum", "world_chain", "solana", "ethereum" ], "value_labels": { "base": "Base (Coinbase L2)", "polygon": "Polygon PoS", "arbitrum": "Arbitrum One", "world_chain": "World Chain", "solana": "Solana", "ethereum": "Ethereum Mainnet" }, "code_definitions": { "base": "Base, Coinbase's Ethereum L2 network; primary x402 network with highest CDP Facilitator optimization; sub-second finality for USDC settlements; lowest gas cost among EVM networks.", "polygon": "Polygon PoS, Ethereum sidechain; x402 supported with USDC; ~2 second finality; widely adopted for payments and gaming.", "arbitrum": "Arbitrum One, Ethereum L2 optimistic rollup; x402 supported; ~1 second finality for USDC settlements; strong DeFi ecosystem.", "world_chain": "World Chain, World Foundation's identity-verified blockchain; x402 supported; all transactions require World ID biometric verification; highest KYC assurance of supported networks.", "solana": "Solana, High-throughput L1 blockchain; x402 supported with native USDC via Circle; ~400ms finality; lowest cost per transaction.", "ethereum": "Ethereum Mainnet, Base L1; higher gas cost; use for high-value x402 settlements where L1 finality security is required." }, "regulatory_mappings": { "genius_act": "GENIUS Act, payment stablecoin settlement on any network must trace to a licensed issuer; network selection does not affect the issuer licensing obligation; USDC is Circle-issued on all x402 networks", "eu_mica": "EU MiCA Article 68, on-chain settlement of EMT/ART tokens must comply with MiCA record-keeping requirements regardless of the settlement network; distributed ledger reference must be captured" }, "source": "Coinbase CDP Facilitator supported networks documentation; x402 network configuration specification", "source_url": "https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works" }, { "enum_name": "X402FacilitatorId", "label": "x402 Facilitator ID", "attribute_type": "string", "otel_attribute": "agentic_payments.x402.facilitator_id", "opa_policy_path": "data.agentic_payments.x402.facilitator_id", "rego_input_key": "agentic_payments_x402_facilitator_id", "stability": "experimental", "description": "The x402 facilitator identifier extracted from the payment scheme in the PAYMENT-REQUIRED header. Typically the Coinbase CDP Facilitator URL (cdp.coinbase.com) or a custom facilitator URL registered by the tenant. OPA policy x402_facilitator_must_be_in_tenant_allowlist validates this value against the tenant's approved facilitator list before certifying any x402 payment session.", "permitted_values": [ "cdp.coinbase.com" ], "value_labels": { "cdp.coinbase.com": "Coinbase CDP Facilitator (official)" }, "notes": "X402FacilitatorId is a free-form string OTel span attribute. The permitted_values list shows the canonical Coinbase facilitator identifier; tenants may configure additional approved facilitator hostnames in their Veriproof x402_facilitator_allowlist tenant setting.", "regulatory_mappings": { "x402_coinbase": "x402 protocol, facilitator is identified in the paymentRequirements.scheme field of the PAYMENT-REQUIRED header; format is 'x402///'", "pci_dss_v4": "PCI DSS v4.0 Requirement 6.3, all payment processing components including facilitators must appear on the organization's approved software and vendor inventory" }, "source": "Coinbase x402 PAYMENT-REQUIRED header specification; facilitator URL format in paymentRequirements.scheme", "source_url": "https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works" }, { "enum_name": "X402AttestationType", "label": "x402 Attestation Type", "otel_attribute": "agentic_payments.x402.attestation_type", "opa_policy_path": "data.agentic_payments.x402.attestation_type", "rego_input_key": "agentic_payments_x402_attestation_type", "stability": "experimental", "description": "Optional governance attestation requirements specified by the seller in the x402 PAYMENT-REQUIRED header's extra field. Sellers may require buyers to present evidence of KYC identity verification, geographic authorization, or age verification as a condition of payment acceptance. Veriproof captures the attestation type to enforce OPA governance policies and verify the buyer's session contains the required evidence.", "permitted_values": [ "none", "kyc_verified", "geographic_restriction", "age_verified" ], "value_labels": { "none": "No attestation required", "kyc_verified": "KYC identity verified", "geographic_restriction": "Geographic restriction applied", "age_verified": "Age verified" }, "code_definitions": { "none": "Seller does not require any buyer attestation; payment can be completed with on-chain funds and valid EIP-712 signature alone.", "kyc_verified": "Seller requires proof that the buyer has completed KYC identity verification with a recognized provider; Veriproof checks the session for a valid KYC evidence record before certifying.", "geographic_restriction": "Seller restricts access by geographic jurisdiction (e.g. OFAC sanctioned countries, MiCA EU residency requirements, US state money transmission restrictions); Veriproof evaluates tenant geo-policy and session origin data.", "age_verified": "Seller requires proof that the buyer meets the minimum age requirement (e.g. age-restricted digital content, tobacco, alcohol); buyer must present a valid age attestation credential in the session." }, "regulatory_mappings": { "x402_coinbase": "Coinbase x402 governance extension points, attestation requirements are optional extension fields in the PAYMENT-REQUIRED paymentRequirements.extra object", "eu_mica": "EU MiCA Article 84, CASPs operating in the EU must implement geographic restrictions for non-EU jurisdictions; geographic_restriction attestation type supports this MiCA compliance obligation", "fatf_recommendations": "FATF Recommendation 15, Virtual asset service providers must perform customer due diligence (CDD) equivalent to KYC; kyc_verified attestation type maps to the VASP CDD obligation for transactions above FATF threshold values" }, "source": "Coinbase x402 PAYMENT-REQUIRED specification; x402 optional governance extension points documentation", "source_url": "https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works" } ] }, { "subdomain": "Stablecoin Asset & Issuer", "description": "Covers the stablecoin assets, settlement networks, issuer compliance status, and reserve composition relevant to agentic payment governance. GENIUS Act (Pub. L. 119-27) and EU MiCA (Regulation 2023/1114) impose distinct licensing and reserve requirements on stablecoin issuers. Veriproof evaluates issuer compliance status and reserve composition at session creation to ensure OPA policies genius_act_stablecoin_issuer_must_be_licensed_or_registered and genius_act_reserve_composition_must_be_compliant can fire before any stablecoin transaction is certified.", "relevant_standards": [ "GENIUS Act (Pub. L. 119-27, signed July 18, 2025), §4 reserve requirements and federal/state licensing thresholds", "EU MiCA (Regulation 2023/1114), ART/EMT classification; ESMA Interim Register; volume caps on non-EU stablecoins", "FATF Recommendation 15, AML/CFT for virtual asset service providers", "PCI DSS v4.0, Cardholder data protection obligations where stablecoin-backed cards are used" ], "categories": [ { "enum_name": "StablecoinAsset", "label": "Stablecoin Asset", "otel_attribute": "agentic_payments.stablecoin.asset", "opa_policy_path": "data.agentic_payments.stablecoin.asset", "rego_input_key": "agentic_payments_stablecoin_asset", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "StablecoinAsset" }, "stability": "stable", "description": "The stablecoin asset used in an agentic payment transaction. Issuers and regulatory compliance status differ significantly across assets; governance policies are applied per-asset. GENIUS Act and MiCA compliance obligations depend on the issuer, the asset type, and the regulatory regime tags applied to the session.", "permitted_values": [ "usdc", "usdb", "usdp", "usdg", "eurc", "pyusd", "usdt" ], "value_labels": { "usdc": "USDC (Circle)", "usdb": "USDB (Bridge / Stripe)", "usdp": "USDP (Paxos)", "usdg": "USDG (Gemini)", "eurc": "EURC (Circle)", "pyusd": "PYUSD (PayPal)", "usdt": "USDT (Tether)" }, "code_definitions": { "usdc": "USD Coin, issued by Circle; GENIUS Act federal license eligible; MiCA EMT registration eligible (EURC variant for EU); primary x402 and AP2 settlement asset; 75M+ monthly x402 transactions on Base.", "usdb": "USDB, issued by Bridge (Stripe subsidiary); GENIUS Act state license eligible; supported on Base and Ethereum; primary stablecoin for Stripe stablecoin checkout flows.", "usdp": "Pax Dollar, issued by Paxos; GENIUS Act state license eligible; NYDFS-regulated trust company; DFS-supervised reserve management.", "usdg": "Gemini Dollar, issued by Gemini Trust Company; NYDFS-regulated; GENIUS Act state license eligible; strong institutional custody backing.", "eurc": "Euro Coin, EUR-denominated stablecoin issued by Circle; MiCA EMT registration eligible; primary EU-native agentic payment stablecoin for SEPA Instant and MiCA-compliant flows.", "pyusd": "PayPal USD, issued by Paxos on behalf of PayPal; major consumer payment channel; GENIUS Act eligible; integrated with PayPal agent commerce platform.", "usdt": "Tether USD, largest stablecoin by market capitalisation; Tether does not hold a GENIUS Act license or MiCA registration as of July 2026; EU MiCA Article 75 volume caps apply to USDT transactions in the EU; use requires heightened compliance evidence and explicit regulatory regime tagging." }, "regulatory_mappings": { "genius_act": "GENIUS Act §4 (Pub. L. 119-27), payment stablecoins must be issued by a federally or state-licensed institution; USDC, USDB, USDP, USDG, PYUSD are eligible for GENIUS Act licensing; USDT is not currently GENIUS Act-licensed", "eu_mica": "EU MiCA Article 3 (Regulation 2023/1114), EMT classification applies to USD/EUR-pegged stablecoins; MiCA Article 75 volume caps apply to non-EU EMTs (USDC, USDB, USDT) for EU-domiciled transactions; EURC is MiCA-native" }, "source": "Circle, Bridge (Stripe), Paxos, Gemini, PayPal, Tether issuer documentation; GENIUS Act §4 license registry; ESMA MiCA Interim Register (last updated May 4, 2026)", "source_url": "https://en.wikipedia.org/wiki/GENIUS_Act" }, { "enum_name": "StablecoinNetwork", "label": "Stablecoin Settlement Network", "otel_attribute": "agentic_payments.stablecoin.network", "opa_policy_path": "data.agentic_payments.stablecoin.network", "rego_input_key": "agentic_payments_stablecoin_network", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "StablecoinNetwork" }, "stability": "stable", "description": "The blockchain network on which the stablecoin payment is settled. Network determines transaction finality time, gas cost, and the applicable regulatory jurisdiction for on-chain record-keeping. Veriproof captures the network to ensure evidence packs correctly reference the on-chain transaction location and allow regulators to independently verify settlement.", "permitted_values": [ "ethereum", "base", "solana", "polygon", "arbitrum", "optimism", "avalanche_c_chain", "stellar", "tempo", "world_chain", "tron" ], "value_labels": { "ethereum": "Ethereum Mainnet", "base": "Base (Coinbase L2)", "solana": "Solana", "polygon": "Polygon PoS", "arbitrum": "Arbitrum One", "optimism": "Optimism (OP Mainnet)", "avalanche_c_chain": "Avalanche C-Chain", "stellar": "Stellar", "tempo": "Tempo (Ripple CBDC / fiat rail)", "world_chain": "World Chain", "tron": "Tron" }, "regulatory_mappings": { "genius_act": "GENIUS Act, stablecoin settlement network is not a compliance differentiator; issuer licensing status governs regardless of which network the transaction settles on", "eu_mica": "EU MiCA Article 68, transaction records for EMT/ART on-chain settlements must include the distributed ledger reference; network identification required for ESMA record-keeping and supervisory reporting compliance" }, "source": "Circle USDC multi-chain network support documentation; Coinbase CDP supported networks; Solana Foundation documentation", "source_url": "https://www.circle.com/multi-chain-usdc" }, { "enum_name": "StablecoinIssuerComplianceStatus", "label": "Stablecoin Issuer Compliance Status", "otel_attribute": "agentic_payments.stablecoin.issuer_compliance_status", "opa_policy_path": "data.agentic_payments.stablecoin.issuer_compliance_status", "rego_input_key": "agentic_payments_stablecoin_issuer_compliance_status", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "StablecoinIssuerComplianceStatus" }, "stability": "stable", "description": "The regulatory licensing and registration status of the stablecoin issuer at the time the payment session is created. Veriproof evaluates this status against the applicable payment regulatory regime tags (genius_act, eu_mica) to enforce OPA compliance policies. genius_act_stablecoin_issuer_must_be_licensed_or_registered fires when the regime includes genius_act and the status is not genius_act_federally_licensed or genius_act_state_licensed. mica_casp_must_have_eu_authorization fires when the regime includes eu_mica and the status is not mica_art_registered or mica_emt_registered.", "permitted_values": [ "genius_act_federally_licensed", "genius_act_state_licensed", "mica_art_registered", "mica_emt_registered", "pending_registration", "unregulated" ], "value_labels": { "genius_act_federally_licensed": "GENIUS Act, Federally Licensed (> $10B AUM)", "genius_act_state_licensed": "GENIUS Act, State Licensed (≤ $10B AUM)", "mica_art_registered": "MiCA ART Registered (Asset-Referenced Token)", "mica_emt_registered": "MiCA EMT Registered (E-Money Token)", "pending_registration": "Registration Pending", "unregulated": "Unregulated" }, "code_definitions": { "genius_act_federally_licensed": "Issuer has obtained a federal payment stablecoin license under GENIUS Act §4; applies to issuers with more than $10 billion in outstanding payment stablecoins; subject to OCC, Federal Reserve, and FDIC oversight.", "genius_act_state_licensed": "Issuer operates under a state payment stablecoin license under GENIUS Act §4; applies to issuers with $10 billion or less in outstanding stablecoins; subject to state financial regulator oversight with federal minimum standards as the floor.", "mica_art_registered": "Token is classified as an Asset-Referenced Token (ART) under EU MiCA Article 3; issuer is registered with the national competent authority and listed in the ESMA Interim Register; subject to MiCA Title III obligations.", "mica_emt_registered": "Token is classified as an E-Money Token (EMT) under EU MiCA Article 3; issuer is a licensed e-money institution registered with the national competent authority and listed in the ESMA Interim Register; subject to MiCA Title IV obligations.", "pending_registration": "Issuer has applied for GENIUS Act federal or state license, or MiCA ART/EMT registration, but approval has not yet been granted. Heightened governance review applies to all sessions using this issuer's stablecoin.", "unregulated": "Issuer does not hold a GENIUS Act license or MiCA registration. OPA policy genius_act_stablecoin_issuer_must_be_licensed_or_registered fires when regime includes genius_act. mica_casp_must_have_eu_authorization fires when regime includes eu_mica. Use requires explicit risk acceptance." }, "regulatory_mappings": { "genius_act_s4": "GENIUS Act §4 (Pub. L. 119-27, signed July 18, 2025), federal license threshold: issuers of more than $10 billion in outstanding payment stablecoins must obtain a federal license; state license available for smaller issuers", "eu_mica": "EU MiCA Regulation 2023/1114 Article 3, ART = Asset-Referenced Token (Article 3(1)(6)); EMT = E-Money Token (Article 3(1)(7)); both require national competent authority authorization and ESMA Interim Register listing", "esma_interim_register": "ESMA Interim Register for crypto-asset service providers and stablecoin issuers, last updated May 4, 2026; Veriproof checks issuer registration status at session creation time" }, "source": "GENIUS Act §4 (Pub. L. 119-27); EU MiCA Regulation 2023/1114 Articles 3, 16, 48; ESMA Interim Register", "source_url": "https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica" }, { "enum_name": "StablecoinReserveComposition", "label": "Stablecoin Reserve Composition", "stable_sdk_metadata": { "description": "Reserve asset classes reported for a stablecoin.", "code_definitions": { "cash_demand_deposits": "Cash and demand deposits reported as stablecoin reserve assets.", "short_term_us_tbills": "Short-term U.S. Treasury bills reported as stablecoin reserve assets.", "central_bank_reserve_balances": "Central bank balances reported as stablecoin reserve assets.", "repo_secured_by_tbills": "Repurchase agreements secured by U.S. Treasury bills reported as stablecoin reserve assets.", "money_market_funds": "Money market fund holdings reported as stablecoin reserve assets.", "non_compliant_assets": "Assets reported outside the listed reserve classes." } }, "otel_attribute": "agentic_payments.stablecoin.reserve_composition", "opa_policy_path": "data.agentic_payments.stablecoin.reserve_composition", "rego_input_key": "agentic_payments_stablecoin_reserve_composition", "stability": "stable", "description": "The composition class of the reserve assets backing the stablecoin, as attested in the issuer's most recent reserve report or regulatory disclosure. GENIUS Act §4 mandates 1:1 reserves in specific permitted asset classes only. Veriproof records the reserve composition at session creation to enable evidence-based regulatory compliance attestation. The OPA policy genius_act_reserve_composition_must_be_compliant fires when non_compliant_assets is recorded.", "permitted_values": [ "cash_demand_deposits", "short_term_us_tbills", "central_bank_reserve_balances", "repo_secured_by_tbills", "money_market_funds", "non_compliant_assets" ], "value_labels": { "cash_demand_deposits": "Cash & Demand Deposits", "short_term_us_tbills": "Short-Term U.S. Treasury Bills", "central_bank_reserve_balances": "Central Bank Reserve Balances", "repo_secured_by_tbills": "Repurchase Agreements (T-bill secured)", "money_market_funds": "Money Market Funds", "non_compliant_assets": "Non-Compliant Reserve Assets" }, "code_definitions": { "cash_demand_deposits": "Cash and demand deposits held at FDIC-insured depository institutions or Federal Home Loan Banks; fully GENIUS Act §4-compliant reserve asset class.", "short_term_us_tbills": "U.S. Treasury bills with a remaining maturity of 93 days or less; fully GENIUS Act §4-compliant reserve asset class.", "central_bank_reserve_balances": "Balances held directly at Federal Reserve Banks or other central banks; fully GENIUS Act §4-compliant reserve asset class; highest-quality government-backed reserve.", "repo_secured_by_tbills": "Repurchase agreements (repos) where the underlying collateral is U.S. Treasury bills; fully GENIUS Act §4-compliant reserve asset class.", "money_market_funds": "Government money market funds that invest exclusively in GENIUS Act §4-permitted assets; conditionally permitted under GENIUS Act §4 implementing regulations pending final rulemaking.", "non_compliant_assets": "Any reserve composition element that does not satisfy GENIUS Act §4 requirements; triggers OPA policy genius_act_reserve_composition_must_be_compliant. Examples: commercial paper, corporate bonds, crypto assets, mortgage-backed securities, any non-government security with maturity exceeding 93 days." }, "regulatory_mappings": { "genius_act_s4": "GENIUS Act §4 (Pub. L. 119-27), Permitted Reserve Assets: (1) cash and demand deposits at insured institutions, (2) short-term U.S. Treasury bills (≤93 days maturity), (3) central bank reserve balances, (4) repos secured by T-bills. All other assets constitute non_compliant_assets.", "genius_act_s6": "GENIUS Act §6, Annual third-party reserve audit requirement; reserve composition must be publicly disclosed and independently audited each year; Veriproof evidence packs support audit evidence compilation" }, "source": "GENIUS Act §4 Permitted Reserve Asset definitions (Pub. L. 119-27, signed July 18, 2025); GENIUS Act §6 annual audit requirements", "source_url": "https://en.wikipedia.org/wiki/GENIUS_Act" } ] }, { "subdomain": "Agentic Commerce Providers", "description": "Covers the agentic commerce provider ecosystem and agent presence signal classification. Different providers carry materially different governance requirements: structured AP2 mandate-chain providers (Google, Mastercard) provide full auditability; browser-automation agents (ChatGPT agent mode, Anthropic computer-use) bypass payment APIs and require stricter mandate verification; stablecoin infrastructure providers (Coinbase, Bridge) require GENIUS Act and MiCA compliance evidence. The AgentPresenceSignal enum is required by AP2 PaymentMandate agentPresence claim and is enforced by the OPA policy ap2_payment_mandate_must_include_agent_presence_signal.", "relevant_standards": [ "Google AP2 v0.2, agentPresence claim in PaymentMandate", "EU AI Act Article 50, AI transparency disclosure obligation for systems interacting with natural persons", "GENIUS Act §4, stablecoin issuer obligations for each provider" ], "categories": [ { "enum_name": "AgenticCommerceProvider", "label": "Agentic Commerce Provider", "otel_attribute": "agentic_payments.provider.id", "opa_policy_path": "data.agentic_payments.provider.id", "rego_input_key": "agentic_payments_provider_id", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "AgenticCommerceProvider" }, "stability": "experimental", "description": "The agentic commerce provider or payment protocol through which the AI-initiated transaction is being processed. Different providers require different governance controls: structured protocol providers support AP2 mandate validation; browser-automation providers require session-declared intent mandate or explicit human confirmation before Veriproof certifies. This enum enables provider-specific OPA policy routing.", "permitted_values": [ "google_ap2", "mastercard_agent_pay", "paypal_agent", "stripe", "bridge", "visa_vtap", "coinbase_x402", "openai_chatgpt_agent", "anthropic_claude_agent", "google_adk", "microsoft_copilot_agent", "amazon_alexa_shopping", "solana_pay_sh" ], "value_labels": { "google_ap2": "Google AP2 (Agent Payments Protocol v0.2)", "mastercard_agent_pay": "Mastercard Agent Pay", "paypal_agent": "PayPal Agent Commerce", "stripe": "Stripe", "bridge": "Bridge (Stripe subsidiary)", "visa_vtap": "Visa VTAP (Tokenized Asset Platform)", "coinbase_x402": "Coinbase x402", "openai_chatgpt_agent": "OpenAI ChatGPT Agent Mode", "anthropic_claude_agent": "Anthropic Claude Computer Use / Agent", "google_adk": "Google Agent Development Kit (ADK)", "microsoft_copilot_agent": "Microsoft Copilot Agent", "amazon_alexa_shopping": "Amazon Alexa Shopping", "solana_pay_sh": "Solana pay.sh" }, "code_definitions": { "google_ap2": "Google Agent Payments Protocol v0.2, structured mandate chain with SD-JWT wire format; full Veriproof AP2 adapter support; OpenPaymentMandate → PaymentMandate → PaymentReceipt lifecycle.", "mastercard_agent_pay": "Mastercard Agent Pay, Mastercard's agentic commerce framework; integrates with AP2 mandate chain across the $9T+ annual Mastercard network volume; structured governance model.", "paypal_agent": "PayPal Agent Commerce, PayPal's native agent payment service including PYUSD stablecoin integration; PayPal buyer protection APIs provide additional dispute resolution evidence.", "stripe": "Stripe, payment processing platform; stablecoin checkout via Stripe Stablecoin APIs (USDC, USDB); Stripe Treasury for outbound corporate payments.", "bridge": "Bridge (Stripe subsidiary), stablecoin issuance (USDB) and orchestration; card issuing and outbound treasury transfers; Visa-powered virtual card issuance.", "visa_vtap": "Visa VTAP (Visa Tokenized Asset Platform), tokenized card issuing for AI agents; stablecoin-backed virtual cards with PCI DSS tokenization compliance.", "coinbase_x402": "Coinbase x402, HTTP-native stablecoin micropayment protocol; 75M+ monthly transactions across Base, Polygon, Arbitrum, World Chain, Solana, Ethereum; CDP Facilitator.", "openai_chatgpt_agent": "OpenAI ChatGPT Agent Mode, browser automation agent executing checkout flows without structured payment API integration; requires session-declared intent mandate or explicit human_initiated confirmation for Veriproof certification. Highest governance risk for enterprise deployments.", "anthropic_claude_agent": "Anthropic Claude Computer Use / Agent, computer-use automation completing purchase flows via screen interaction; same governance requirements as openai_chatgpt_agent; both require supplemental governance controls.", "google_adk": "Google Agent Development Kit, ADK-based agents may use the AP2 mandate chain (structured) or direct payment APIs (unstructured); governance level depends on integration choice.", "microsoft_copilot_agent": "Microsoft Copilot Agent, Copilot Studio agents with payment capabilities via Power Platform connectors; governance depends on the payment method integration.", "amazon_alexa_shopping": "Amazon Alexa Shopping, voice-initiated purchases through Alexa Skills; structured intent signal from Alexa Skills platform; lower governance risk than browser automation.", "solana_pay_sh": "Solana pay.sh, Solana Foundation + Google Cloud agent-paid API marketplace, launched 2026-05-05. Agents discover providers via pay skills search or /.well-known/agent-skills/index.json, obtain gateway URLs via get_skill_endpoints, and call APIs through pay curl or Pay MCP tools. Supports both x402 (body-level JSON) and MPP (WWW-Authenticate) challenge protocols. Registry-sourced gateway URLs are verified against a sha content hash before the first paid call. VeriProof is discoverable as a pay.sh provider via its /.well-known/agent-skills/index.json endpoint." }, "regulatory_mappings": { "eu_ai_act_2024_1689": "EU AI Act Annex III, AI systems used in commercial transactions may be high-risk if they significantly affect access to goods, services, or benefits; provider classification is a primary input for EU AI Act risk categorization", "ap2_v02": "AP2 mandate chain providers (google_ap2, mastercard_agent_pay) follow the structured AP2 governance model with full mandate chain auditability; browser-agent providers require supplemental Veriproof session-wrapping governance controls" }, "source": "Google AP2 SDK v0.2; Mastercard Agent Pay product announcement; Coinbase x402 documentation; OpenAI operator documentation; Anthropic computer-use documentation", "source_url": "https://goo.gle/ap2" }, { "enum_name": "AgentPresenceSignal", "label": "Agent Presence Signal", "otel_attribute": "agentic_payments.provider.agent_presence_signal", "opa_policy_path": "data.agentic_payments.provider.agent_presence_signal", "rego_input_key": "agentic_payments_provider_agent_presence_signal", "stability": "experimental", "description": "The signal used to declare or detect AI agent presence in a payment transaction. Required by the AP2 PaymentMandate agentPresence claim. Veriproof OPA policy ap2_payment_mandate_must_include_agent_presence_signal requires this value to be explicitly declared (not not_declared) for all closed Payment Mandates. This enum supports EU AI Act Article 50 AI transparency disclosure obligations in payment contexts.", "permitted_values": [ "explicit_mandate_chain", "session_declared_intent", "browser_automation_detected", "human_initiated", "not_declared" ], "value_labels": { "explicit_mandate_chain": "Explicit AP2 mandate chain (SD-JWT)", "session_declared_intent": "Session-declared intent mandate", "browser_automation_detected": "Browser automation detected (inferred)", "human_initiated": "Human-initiated", "not_declared": "Not declared" }, "code_definitions": { "explicit_mandate_chain": "Agent presence is declared via a structured AP2 SD-JWT mandate chain; the OpenPaymentMandate contains explicit agentId and mandate scope claims; highest governance assurance level; supports full AP2 auditability.", "session_declared_intent": "The buyer's agent has declared an intent mandate in the Veriproof session before the payment step was taken; provides mandate context and intent evidence without full AP2 wire format; second-highest assurance level.", "browser_automation_detected": "Agent presence has been inferred from browser automation signals (headless browser fingerprint, CDP protocol markers, anomalous input event timing, viewport size) rather than explicitly declared; not explicitly declared; requires additional governance controls and human review where feasible.", "human_initiated": "The payment was directly initiated by a human using a standard UI interaction; the agent is acting as an assistant only with no autonomous payment execution capability; lowest governance risk.", "not_declared": "Agent presence is neither declared nor detected. OPA policy ap2_payment_mandate_must_include_agent_presence_signal fires for closed Payment Mandates with this signal value. Use of not_declared in production agentic payment sessions is a compliance gap." }, "regulatory_mappings": { "ap2_v02": "AP2 v0.2 PaymentMandate agentPresence claim, must be explicitly declared for all non-human-present payment scenarios; Veriproof maps AP2 agentPresence values to this enum", "eu_ai_act_2024_1689": "EU AI Act Article 50, AI systems interacting with natural persons must disclose their AI nature; agent_presence_signal supports payment-context AI disclosure compliance and Article 50 audit evidence" }, "source": "AP2 SDK v0.2 PaymentMandate agentPresence claim specification; EU AI Act Article 50 transparency obligations", "source_url": "https://goo.gle/ap2" } ] }, { "subdomain": "Fiat Instant Rail", "description": "Covers fiat currency instant payment rails used for AI-initiated transactions and the ISO 20022 message families that govern them. FedNow and RTP require ISO 20022 pacs.008 InstrId for all AI-initiated real-time payments (Veriproof OPA policy fednow_ai_payment_requires_iso20022_instruction_reference). The Iso20022MessageFamily enum intentionally shares coverage with 01_vertical_banking_financial_services.json; the banking vertical's PaymentStatusISO20022 and PaymentMessageType enums remain authoritative for status codes and message type identifiers. This subdomain records message family context at the session level for agentic payment governance purposes.", "relevant_standards": [ "ISO 20022, pacs, pain, camt message families for instant payment rails", "FedNow ISO 20022 Readiness Guide, pacs.008 InstrId requirement for AI-initiated payments", "NACHA Operating Rules, ACH Same-Day", "EPC SEPA Instant Credit Transfer Scheme Rulebook", "Banco Central do Brasil PIX framework" ], "categories": [ { "enum_name": "FiatInstantRail", "label": "Fiat Instant Payment Rail", "otel_attribute": "agentic_payments.rail.type", "opa_policy_path": "data.agentic_payments.rail.type", "rego_input_key": "agentic_payments_rail_type", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "FiatInstantRail" }, "stability": "stable", "description": "The fiat currency instant payment rail used for an AI-initiated transaction. Different rails carry different ISO 20022 message family requirements and compliance obligations. FedNow and RTP require ISO 20022 instruction reference for AI-initiated payments; SEPA Instant requires compliance with EPC SCT Inst rulebook; PIX requires Banco Central do Brasil endpoint integration. Rail type determines which OPA policy set applies at evaluation time.", "permitted_values": [ "fednow", "rtp", "sepa_instant", "pix_brazil", "uk_fps", "swift_gpi", "achats_instantanes_fr", "ach_same_day" ], "value_labels": { "fednow": "FedNow (Federal Reserve, US)", "rtp": "RTP (The Clearing House, US)", "sepa_instant": "SEPA Instant Credit Transfer (EU)", "pix_brazil": "PIX (Banco Central do Brasil)", "uk_fps": "UK Faster Payments Service", "swift_gpi": "SWIFT GPI", "achats_instantanes_fr": "Virement Instantané (France)", "ach_same_day": "ACH Same-Day (NACHA)" }, "code_definitions": { "fednow": "Federal Reserve FedNow Service, US ISO 20022 instant credit transfer network; launched July 2023; pacs.008 for credit transfers, pacs.002 for status reports; AI-initiated payments must include pacs.008 InstrId for audit traceability (Veriproof OPA policy fednow_ai_payment_requires_iso20022_instruction_reference).", "rtp": "The Clearing House RTP Network, first US real-time payment network; ISO 20022 native; similar compliance requirements to FedNow for AI-initiated transactions.", "sepa_instant": "SEPA Instant Credit Transfer, EU 24/7 instant euro transfer scheme; pacs.008.001.08 message; 10-second settlement maximum; governed by EPC SCT Inst rulebook; AI payment automation growing rapidly in the EU.", "pix_brazil": "PIX, Brazilian instant payment system operated by Banco Central do Brasil; launched November 2020; largest real-time payment volume in the Americas by transaction count.", "uk_fps": "UK Faster Payments Service, operated by Pay.UK; near-ISO 20022 message format; AI-initiated payments require FCA payment service provider authorization under PSR 2017.", "swift_gpi": "SWIFT Global Payments Innovation, enhanced cross-border payment tracking service; AI-initiated SWIFT GPI payments require CBPR+ ISO 20022 MX format (coexistence period ended November 22, 2025).", "achats_instantanes_fr": "Virement Instantané, French instant payment scheme; SEPA Instant Credit Transfer-compliant; operated by STET interbank processor.", "ach_same_day": "ACH Same-Day, NACHA same-day ACH file-based payment; not strictly instant (sub-24h settlement); governed by NACHA Operating Rules; lower compliance overhead than instant rail equivalents." }, "regulatory_mappings": { "iso20022": "ISO 20022, FedNow, RTP, SEPA Instant, SWIFT GPI all use ISO 20022 pacs/pain/camt message families; iso20022_message_family attribute captures the message context at session level", "fednow_readiness_guide": "FedNow ISO 20022 Readiness Guide, InstrId (pacs.008 Instruction Identification) must be present for all AI-initiated FedNow payments for end-to-end audit traceability and OPA policy compliance" }, "source": "Federal Reserve FedNow Service documentation; The Clearing House RTP documentation; EPC SEPA Instant Credit Transfer Scheme Rulebook v1.2", "source_url": "https://explore.fednow.org/resources/readiness-guide-iso-20022.pdf" }, { "enum_name": "Iso20022MessageFamily", "label": "ISO 20022 Message Family", "otel_attribute": "agentic_payments.rail.iso20022_message_family", "opa_policy_path": "data.agentic_payments.rail.iso20022_message_family", "rego_input_key": "agentic_payments_rail_iso20022_message_family", "stability": "stable", "description": "The ISO 20022 message family used for the fiat payment rail message in an agentic payment session. This enum intentionally overlaps with the Payments subdomain of 01_vertical_banking_financial_services.json; the banking vertical's PaymentStatusISO20022 (ISO 20022 status codes) and PaymentMessageType (specific message type identifiers) remain authoritative for their respective values. This category records message family context at the session level for agentic payment governance tagging and policy routing.", "permitted_values": [ "pacs", "pain", "camt", "acmt", "reda" ], "value_labels": { "pacs": "pacs, Payments Clearing and Settlement", "pain": "pain, Payments Initiation", "camt": "camt, Cash Management", "acmt": "acmt, Account Management", "reda": "reda, Reference Data" }, "code_definitions": { "pacs": "pacs, Payments Clearing and Settlement messages; pacs.008 (FI to FI Customer Credit Transfer) and pacs.002 (Payment Status Report) are the primary FedNow and RTP messages for AI-initiated instant payments.", "pain": "pain, Payments Initiation messages; pain.001 (Customer Credit Transfer Initiation) is used for bank-to-payment-network submission originating from an AI agent.", "camt": "camt, Cash Management messages; camt.054 (Debit/Credit Notification), camt.052 (Intraday Account Report), camt.053 (End-of-Day Account Statement) are used for AI treasury monitoring.", "acmt": "acmt, Account Management messages; used for account setup, maintenance, and verification in AI-driven treasury and onboarding workflows.", "reda": "reda, Reference Data messages; used for standing order and payment standing data management in AI-automated recurring payment workflows." }, "notes": "Intentional overlap with 01_vertical_banking_financial_services.json PaymentStatusISO20022 and PaymentMessageType enums. The banking vertical is the authoritative source for ISO 20022 status code values and specific message type identifiers. This enum tags the message family at the agentic payment session level for governance policy routing.", "regulatory_mappings": { "iso20022": "ISO 20022 Message Catalogue, all fiat instant rail messages in this vertical use ISO 20022 format; family prefix determines applicable compliance policies", "fednow_readiness_guide": "FedNow ISO 20022 Readiness Guide, pacs and camt families are the primary message families for FedNow AI payment operations" }, "source": "ISO 20022 Message Catalogue; FedNow ISO 20022 Readiness Guide; SWIFT CBPR+ guidelines", "source_url": "https://www.iso20022.org/iso-20022-message-definitions" } ] }, { "subdomain": "Payment Regulatory Regime", "description": "Covers the regulatory regime classification for agentic payment sessions. PaymentRegulatoryRegime is a multi-value attribute, a single payment session may be simultaneously governed by multiple regimes. For example, a US-based CASP using EU-registered EMT tokens on FedNow to transfer to a UK counterparty may be simultaneously governed by genius_act, eu_mica, eu_dora, bsa_fincen, and uk_fca_ps_reg. Veriproof evaluates all applicable regimes and determines the full set of OPA policies that must pass before the session can be certified.", "relevant_standards": [ "GENIUS Act (Pub. L. 119-27, signed July 18, 2025)", "EU MiCA (Regulation 2023/1114)", "EU AI Act (Regulation 2024/1689)", "EU DORA (Regulation 2022/2554)", "PCI DSS v4.0", "FATF Recommendations (updated 2023)", "BSA / FinCEN", "UK FCA Payment Services Regulations 2017 (PSR 2017, SI 2017/752)", "NYC Local Law 144" ], "categories": [ { "enum_name": "PaymentRegulatoryRegime", "label": "Payment Regulatory Regime", "otel_attribute": "agentic_payments.regulatory.regime", "opa_policy_path": "data.agentic_payments.regulatory.regime", "rego_input_key": "agentic_payments_regulatory_regime", "alias_of": { "file": "00_core_sdk_and_governance.json", "enum_name": "PaymentRegulatoryRegime" }, "stability": "stable", "description": "The regulatory regime or regimes applicable to an agentic payment session. This is a multi-value attribute, a single session may be tagged with multiple regime values. Veriproof evaluates all tagged regimes to determine the full set of applicable OPA policies before certifying the session. Tag conservatively: include any regime that may plausibly apply based on the stablecoin asset, issuer domicile, buyer/seller jurisdictions, and payment rail used.", "permitted_values": [ "genius_act", "eu_mica", "eu_ai_act", "eu_dora", "pci_dss_v4", "fatf_recommendations", "nyc_ll144", "bsa_fincen", "uk_fca_ps_reg" ], "value_labels": { "genius_act": "GENIUS Act (Pub. L. 119-27)", "eu_mica": "EU MiCA (Regulation 2023/1114)", "eu_ai_act": "EU AI Act (Regulation 2024/1689)", "eu_dora": "EU DORA (Regulation 2022/2554)", "pci_dss_v4": "PCI DSS v4.0", "fatf_recommendations": "FATF Recommendations (2023)", "nyc_ll144": "NYC Local Law 144", "bsa_fincen": "BSA / FinCEN", "uk_fca_ps_reg": "UK FCA Payment Services Regulations 2017" }, "code_definitions": { "genius_act": "Guiding and Establishing National Innovation for U.S. Stablecoins Act (Pub. L. 119-27, signed July 18, 2025), First US federal payment stablecoin regulatory framework; §4 reserve requirements (1:1 in cash/T-bills); federal licensing for issuers >$10B AUM; §6 annual reserve audit; §12 AML/BSA obligations for licensed stablecoin issuers.", "eu_mica": "EU Markets in Crypto-Assets Regulation (Regulation 2023/1114), Full enforcement active 2026; applies to CASPs, ART issuers, and EMT issuers operating in or directed at EU residents; ESMA Interim Register registration required; MiCA Article 75 volume caps apply to non-EU stablecoins (USDC, USDB, USDT) when used within the EU.", "eu_ai_act": "EU Artificial Intelligence Act (Regulation 2024/1689), High-risk AI classification for financial decision-making systems with significant impact on natural persons; Article 50 transparency obligations for AI systems interacting with humans; Annex III high-risk use case screening for AI payment authorization systems.", "eu_dora": "EU Digital Operational Resilience Act (Regulation 2022/2554, effective January 2025), ICT risk management, incident reporting, and operational resilience requirements; applies to financial entities and their critical ICT service providers including payment service providers and CASPs operating in the EU.", "pci_dss_v4": "Payment Card Industry Data Security Standard v4.0 (effective March 31, 2024; v3.2.1 retired), cardholder data protection; Requirement 10 (audit log review); Requirement 6.3 (approved software inventory); applies to any AI-initiated payment involving card data, card-on-file, or card tokenization.", "fatf_recommendations": "Financial Action Task Force Recommendations (updated 2023), Global AML/CFT standards; Recommendation 15 (new technologies / virtual assets) requires VASPs to apply risk-based CDD; applies to all agentic payment stablecoin transactions across all jurisdictions.", "nyc_ll144": "New York City Local Law 144 (2021), Bias audit requirements for automated employment decision tools; may apply to AI systems making credit access, payment approval, or benefits-related decisions for NYC employees or residents; evidence of bias audit required.", "bsa_fincen": "Bank Secrecy Act / Financial Crimes Enforcement Network regulations, US AML/CTF obligations; Suspicious Activity Report (SAR) filing requirements; transaction monitoring programs; applies to financial institutions and money services businesses handling AI-initiated stablecoin or fiat payments in the US.", "uk_fca_ps_reg": "UK Financial Conduct Authority Payment Services Regulations 2017 (SI 2017/752, implementing EU PSD2), applies to payment service providers operating in the United Kingdom; AI-initiated payments require FCA authorization or an applicable exemption; strong customer authentication (SCA) requirements apply." }, "notes": "PaymentRegulatoryRegime is multi-value, record all applicable regimes as separate evidence attributes in the session OTel attributes. OPA policies evaluate the complete regime list to determine which compliance checks must pass. Default to tagging conservatively: include any regime that plausibly applies rather than excluding regimes speculatively.", "regulatory_mappings": { "genius_act": "Pub. L. 119-27, signed July 18, 2025; first federal US stablecoin legislation; effective upon enactment", "eu_mica": "Regulation (EU) 2023/1114, full enforcement active 2026; ESMA Interim Register last updated May 4, 2026", "eu_ai_act": "Regulation (EU) 2024/1689, high-risk AI systems in financial services listed in Annex III", "pci_dss_v4": "PCI DSS v4.0, effective March 31, 2024; v3.2.1 retired March 31, 2024" }, "source": "GENIUS Act (Pub. L. 119-27); EU MiCA Regulation 2023/1114; EU AI Act Regulation 2024/1689; EU DORA Regulation 2022/2554; PCI DSS v4.0; FATF Recommendations 2023; NYC Local Law 144; BSA 31 U.S.C. §5311; PSR 2017 SI 2017/752", "source_url": "https://en.wikipedia.org/wiki/GENIUS_Act" } ] }, { "subdomain": "HTTP 402 Protocol & MPP", "description": "Covers the generic HTTP 402 payment lifecycle and the Machine Payments Protocol (MPP), the Solana-native challenge protocol used by pay.sh alongside x402. Unlike x402 (which uses body-level JSON payment requirements), MPP challenges are expressed via WWW-Authenticate and retried with a Solana-signed authorization credential. This subdomain provides the evidence attributes to govern both protocols from the moment a 402 challenge is received through to the final paid response, including wallet approval, receipt header capture, and session-cap lifecycle state.", "relevant_standards": [ "pay.sh protocol, Solana Foundation + Google Cloud agent-paid API marketplace (launched 2026-05-05); MPP single-charge and MPP-session challenge protocols", "Machine Payments Protocol (MPP), WWW-Authenticate challenge-response flow; Solana-signed authorization credential; single-charge (mpp) and capped-session (mpp-session) variants", "Coinbase x402, HTTP-native stablecoin micropayment protocol (covered separately in x402 subdomain)", "EU AI Act Article 50, AI transparency disclosure for autonomous payment steps", "FATF Recommendation 15, virtual asset service provider CDD for AI-initiated stablecoin payments" ], "categories": [ { "enum_name": "AgentPaymentProtocol", "label": "Agent Payment Protocol", "otel_attribute": "agentic_payments.http402.protocol", "opa_policy_path": "data.agentic_payments.http402.protocol", "rego_input_key": "agentic_payments_http402_protocol", "stability": "experimental", "description": "The HTTP 402 challenge protocol active for a given payment step. This is the cross-protocol discriminator that allows governance queries to span both x402 and MPP sessions without conflating their evidence namespaces. Set on every session step that involves a 402 payment event.", "permitted_values": [ "x402", "mpp", "mpp_session", "unknown" ], "value_labels": { "x402": "Coinbase x402 (body-level PAYMENT-REQUIRED JSON)", "mpp": "MPP single-charge (WWW-Authenticate → Solana-signed proof → one paid retry)", "mpp_session": "MPP session payments (capped repeated-call authorization)", "unknown": "Protocol not identified before challenge phase" }, "code_definitions": { "x402": "Coinbase x402, body-level PAYMENT-REQUIRED JSON challenge; existing x402 observers apply for payment-event-type attributes; use observeX402PaymentRequired, observeX402PaymentSignatureSubmitted, observeX402SettlementConfirmed.", "mpp": "Machine Payments Protocol single-charge, agent receives WWW-Authenticate mpp challenge, requests wallet authorization, attaches Solana-signed proof to one retry. Use observeMppCharge to capture this step.", "mpp_session": "MPP session payments, mpp-session challenge authorizes a capped series of repeated calls; cap amount declared at session open; re-authorization required when cap exhausted. Use observeMppSession to capture the session-open authorization step.", "unknown": "Protocol was not identified before the challenge phase; captured for governance review. May indicate a non-standard gateway or missing SDK instrumentation." }, "regulatory_mappings": { "eu_ai_act_2024_1689": "EU AI Act Article 50, AI transparency obligation for autonomous AI-initiated payment steps", "pci_dss_v4": "PCI DSS v4.0 Requirement 10.2, audit log completeness for all payment protocol events" }, "source": "pay.sh protocol documentation", "source_url": "https://pay.sh/docs/protocol" }, { "enum_name": "Http402ChallengePhase", "label": "HTTP 402 Challenge Phase", "otel_attribute": "agentic_payments.http402.challenge_phase", "opa_policy_path": "data.agentic_payments.http402.challenge_phase", "rego_input_key": "agentic_payments_http402_challenge_phase", "stability": "experimental", "description": "The phase of the HTTP 402 lifecycle captured by the current session step. Maps to the 6-step pay.sh lifecycle: client request → API challenge → wallet authorization → proof attachment → paid retry → final response. wallet_authorization_requested is the human-in-the-loop gate for mainnet payments.", "permitted_values": [ "initial_request", "challenge_received", "wallet_authorization_requested", "proof_attached", "paid_retry_sent", "response_received" ], "value_labels": { "initial_request": "Initial request (unauthenticated first call sent)", "challenge_received": "Challenge received (402 Payment Required; WWW-Authenticate or x402 body parsed)", "wallet_authorization_requested": "Wallet authorization requested (local wallet asked to approve payment proof)", "proof_attached": "Proof attached (signed payment proof attached to retry request)", "paid_retry_sent": "Paid retry sent (retry with proof submitted to gateway)", "response_received": "Response received (200 OK or terminal status; payment-receipt header captured)" }, "code_definitions": { "initial_request": "Unauthenticated first call sent to the pay.sh gateway or x402-enabled API; challenge not yet received. Marks the start of the 402 payment lifecycle.", "challenge_received": "402 Payment Required response received; WWW-Authenticate header (MPP) or x402 body (PAYMENT-REQUIRED JSON) parsed. Set AgentPaymentProtocol here to discriminate x402 vs MPP.", "wallet_authorization_requested": "Local wallet (pay CLI, MCP wallet tool) asked to authorize the payment proof. Human-in-the-loop gate for mainnet payments; mpp_mainnet_wallet_requires_explicit_user_approval OPA policy fires if a mainnet wallet proof is attached without this phase.", "proof_attached": "Signed payment proof attached to the retry HTTP request. For MPP: Solana-signed authorization credential. For x402: PAYMENT-SIGNATURE header.", "paid_retry_sent": "Retry request with proof submitted to the gateway. Gateway validates proof and proxies to upstream API or returns demo response depending on routing type.", "response_received": "Final 200 OK (or terminal status) received. payment-receipt response header captured here via observePaymentReceiptHeader." }, "source": "pay.sh protocol documentation, 6-step payment lifecycle", "source_url": "https://pay.sh/docs/protocol" }, { "enum_name": "MppSessionAuthorizationMode", "label": "MPP Session Authorization Mode", "otel_attribute": "agentic_payments.mpp.session_authorization_mode", "opa_policy_path": "data.agentic_payments.mpp.session_authorization_mode", "rego_input_key": "agentic_payments_mpp_session_authorization_mode", "stability": "experimental", "description": "The capped-session authorization lifecycle state for MPP session payments. Distinct from WalletApprovalMode, this records whether the session cap is still active, exhausted, or configured for auto-pay. The mpp_session_cap_required_for_capped_auto_pay and mpp_session_exhausted_requires_reauthorization OPA policies evaluate this attribute.", "permitted_values": [ "single_charge", "capped_session_active", "capped_session_exhausted", "capped_session_auto_pay" ], "value_labels": { "single_charge": "Single charge (mpp one-shot; no session cap applies)", "capped_session_active": "Capped session active (mpp-session cap not yet reached; repeated calls authorized)", "capped_session_exhausted": "Capped session exhausted (cap reached; re-authorization required before next call)", "capped_session_auto_pay": "Capped session auto-pay (user pre-authorized auto-pay within declared cap; elevated risk)" }, "code_definitions": { "single_charge": "mpp protocol single-charge: one paid call authorized per wallet approval. No session cap applies. Use observeMppCharge.", "capped_session_active": "mpp-session protocol: cap amount not yet reached; repeated calls authorized within the declared cap. Use observeMppSession at session open.", "capped_session_exhausted": "mpp-session cap reached; no further calls authorized. Re-authorization via local_user_approval required before the next call. OPA policy mpp_session_exhausted_requires_reauthorization denies calls without explicit re-auth.", "capped_session_auto_pay": "User pre-authorized auto-pay within the declared cap amount. Elevated risk. OPA policy mpp_session_cap_required_for_capped_auto_pay requires cap amount > 0 for this mode." }, "source": "pay.sh MPP protocol", "source_url": "https://pay.sh/docs/protocol/mpp" }, { "enum_name": "WalletApprovalMode", "label": "Wallet Approval Mode", "otel_attribute": "agentic_payments.http402.wallet_approval_mode", "opa_policy_path": "data.agentic_payments.http402.wallet_approval_mode", "rego_input_key": "agentic_payments_http402_wallet_approval_mode", "stability": "experimental", "description": "How local wallet authorization was obtained for the payment proof. This is the human-in-the-loop evidence attribute. OPA policy mpp_mainnet_wallet_requires_explicit_user_approval requires local_user_approval before any mainnet_wallet proof can be attached. mainnet_wallet without a preceding wallet_authorization_requested phase is a governance violation.", "permitted_values": [ "local_user_approval", "capped_auto_pay", "sandbox_wallet", "mainnet_wallet" ], "value_labels": { "local_user_approval": "Local user approval (explicit approval in pay CLI or MCP client)", "capped_auto_pay": "Capped auto-pay (pre-authorized within configured cap; MPP session only)", "sandbox_wallet": "Sandbox wallet (ephemeral; no real funds; test or staging only)", "mainnet_wallet": "Mainnet wallet (real funds; highest governance scrutiny tier)" }, "code_definitions": { "local_user_approval": "User explicitly approved the payment in the local pay CLI or MCP client wallet tool. Required for all mainnet payments. wallet_authorization_requested challenge phase must precede proof_attached when this mode is active.", "capped_auto_pay": "Auto-pay was pre-authorized within a configured cap amount; no per-call user approval. MPP session only. Cap amount must be > 0 (OPA policy mpp_session_cap_required_for_capped_auto_pay).", "sandbox_wallet": "Ephemeral sandbox wallet with no real funds. Use in test and staging environments only. sandbox_wallet in a production session_environment is a governance boundary violation.", "mainnet_wallet": "Real mainnet wallet with real funds. Highest governance scrutiny tier. mainnet_wallet without local_user_approval when the session cap is exhausted triggers OPA policy mpp_session_exhausted_requires_reauthorization." }, "source": "pay.sh pay CLI and Pay MCP wallet tool authorization flow", "source_url": "https://pay.sh/docs/protocol" }, { "enum_name": "PaymentReceiptHeaderPresent", "label": "Payment Receipt Header Present", "otel_attribute": "agentic_payments.http402.payment_receipt_present", "opa_policy_path": "data.agentic_payments.http402.payment_receipt_present", "rego_input_key": "agentic_payments_http402_payment_receipt_present", "stability": "experimental", "attribute_type": "boolean", "description": "Whether the pay.sh gateway returned a payment-receipt response header on the successful paid response. The raw header value (Solana transaction signature or gateway receipt ID) is stored in session_step.metadata[\"http402.payment_receipt_header\"]. Emitted as true by observePaymentReceiptHeader when the header is present; absence means no receipt was captured on the response_received phase.", "notes": "Boolean attribute. No permitted_values enum struct generated. Raw header value stored separately in session_step.metadata.", "source": "pay.sh gateway protocol, payment-receipt response header", "source_url": "https://pay.sh/docs/protocol" } ] }, { "subdomain": "Pay Skills Registry & Gateway", "description": "Covers the governance evidence surface for agent-facing provider discovery (the pay.sh pay-skills catalog, /.well-known/agent-skills/index.json) and gateway-level controls (provider spec YAML, endpoint allowlisting, routing type). Agents that discover providers via the pay.sh catalog must use the gateway URL returned by the registry, not the upstream API URL directly. VeriProof is itself a discoverable pay.sh provider via its /.well-known/agent-skills/index.json endpoint, advertising only the session ingest path consistent with the observability-lane design boundary.", "relevant_standards": [ "pay.sh pay skills catalog, provider discovery via pay skills search / get_skill_endpoints / /.well-known/agent-skills/index.json", "pay.sh gateway spec YAML, endpoints[] allowlist, routing.type (proxy vs respond_demo), credential injection, session.enabled for MPP capped auth", "AP2 v0.2 /.well-known/agent.json, AP2 agent card discovery (covered in AP2 Mandate Chain subdomain)", "PCI DSS v4.0 Requirement 6.3, approved software and component inventory; provider SHA verification supports this obligation" ], "categories": [ { "enum_name": "AgentApiDiscoverySource", "label": "Agent API Discovery Source", "otel_attribute": "agentic_payments.registry.discovery_source", "opa_policy_path": "data.agentic_payments.registry.discovery_source", "rego_input_key": "agentic_payments_registry_discovery_source", "stability": "experimental", "description": "How the agent obtained the gateway URL for a paid API call. The primary governance gate is whether the URL came from a verified registry (auditable) or was specified directly (higher risk). direct_gateway_url bypasses SHA verification. Use observeRegistryLookup before any paid call to establish registry provenance.", "permitted_values": [ "pay_skills_registry", "agent_skills_index", "well_known_agent_json", "direct_gateway_url", "custom_registry" ], "value_labels": { "pay_skills_registry": "pay.sh catalog (pay skills search / get_skill_endpoints)", "agent_skills_index": "/.well-known/agent-skills/index.json on provider host", "well_known_agent_json": "/.well-known/agent.json AP2 agent card", "direct_gateway_url": "Direct gateway URL (not registry-sourced; warn: bypasses catalog SHA verification)", "custom_registry": "Tenant-configured alternative registry (requires tenant allowlist policy)" }, "code_definitions": { "pay_skills_registry": "URL returned by pay skills search or get_skill_endpoints Pay MCP tool from the pay.sh catalog. Provider FQN and SHA available; use observeRegistryLookup with verificationStatus registry_sha_verified before proceeding.", "agent_skills_index": "URL resolved from /.well-known/agent-skills/index.json on the provider host. Enables discovery without the central pay.sh catalog.", "well_known_agent_json": "URL resolved from /.well-known/agent.json AP2 agent card. AP2 provider discovery path. Covered by existing AP2 subdomain; recorded here for cross-protocol provenance evidence.", "direct_gateway_url": "Gateway URL manually specified; not registry-sourced. SHA verification not available. Warn: catalog enrollment and SHA verification should be completed before production use.", "custom_registry": "URL sourced from a tenant-configured alternative registry. Requires explicit tenant allowlist policy." }, "source": "pay.sh pay skills catalog and Pay MCP tool documentation", "source_url": "https://pay.sh/api/catalog" }, { "enum_name": "PaySkillsProviderVerificationStatus", "label": "Pay Skills Provider Verification Status", "otel_attribute": "agentic_payments.registry.provider_status", "opa_policy_path": "data.agentic_payments.registry.provider_status", "rego_input_key": "agentic_payments_registry_provider_status", "stability": "experimental", "description": "Whether the provider's catalog entry was cryptographically verified at lookup time. The pay.sh catalog exposes a sha field (content hash of the provider spec YAML). A mismatch means the spec was modified after catalog indexing. OPA policy pay_skills_provider_sha_mismatch_must_not_proceed fires for registry_sha_mismatch.", "permitted_values": [ "registry_listed", "registry_sha_verified", "registry_sha_mismatch", "not_listed" ], "value_labels": { "registry_listed": "Registry listed (provider found in catalog; SHA not yet verified)", "registry_sha_verified": "Registry SHA verified (catalog SHA matches locally computed SHA at call time)", "registry_sha_mismatch": "Registry SHA mismatch (provider spec may have been tampered; deny, see OPA policy)", "not_listed": "Not listed (provider FQN not found in registry at lookup time)" }, "code_definitions": { "registry_listed": "Provider FQN found in the pay.sh catalog. SHA from catalog entry captured in registry.provider_sha attribute but not yet compared against the locally computed hash.", "registry_sha_verified": "Provider SHA in catalog matches the locally computed SHA of the provider spec at call time. Highest trust level for registry-sourced URLs.", "registry_sha_mismatch": "SHA mismatch detected: catalog SHA does not match the locally computed hash of the provider spec. Provider spec may have been tampered since indexing. OPA policy pay_skills_provider_sha_mismatch_must_not_proceed denies all payment calls with this status.", "not_listed": "Provider FQN was not found in the pay.sh registry at lookup time. May indicate a newly enrolled provider, a private provider, or an unregistered URL." }, "source": "pay.sh pay skills catalog SHA verification", "source_url": "https://pay.sh/api/catalog" }, { "enum_name": "GatewayRoutingType", "label": "Gateway Routing Type", "otel_attribute": "agentic_payments.gateway.routing_type", "opa_policy_path": "data.agentic_payments.gateway.routing_type", "rego_input_key": "agentic_payments_gateway_routing_type", "stability": "experimental", "description": "How the pay.sh gateway routes verified requests. respond_demo is a governance red flag in production contexts, the gateway returns static pre-configured data, not a real upstream response. OPA policy evaluation gateway_respond_demo_routing_denied_outside_sandbox denies respond_demo routing outside sandbox environments.", "permitted_values": [ "proxy", "respond_demo", "unknown" ], "value_labels": { "proxy": "Proxy (gateway proxies verified requests to real upstream API, production mode)", "respond_demo": "Demo response (gateway returns static configured data, demo only; deny outside sandbox)", "unknown": "Unknown (routing type not declared or not yet resolved)" }, "code_definitions": { "proxy": "Gateway proxies verified (paid) requests to the real upstream API. Production-mode routing. payment-receipt header originates from the real upstream call.", "respond_demo": "Gateway returns static pre-configured response data; no real upstream API call is made. For developer demos and testing only. respond_demo in a non-sandbox session_environment is a governance violation.", "unknown": "Routing type was not declared in the provider spec or could not be resolved. Governance warn: audit the provider spec routing.type field." }, "source": "pay.sh gateway provider spec YAML, routing.type field", "source_url": "https://pay.sh/docs/protocol" }, { "enum_name": "GatewayEndpointAllowlisted", "label": "Gateway Endpoint Allowlisted", "otel_attribute": "agentic_payments.gateway.endpoint_allowlisted", "opa_policy_path": "data.agentic_payments.gateway.endpoint_allowlisted", "rego_input_key": "agentic_payments_gateway_endpoint_allowlisted", "stability": "experimental", "attribute_type": "boolean", "description": "Whether the called endpoint path appears in the provider spec's endpoints[] allowlist. Endpoints outside the allowlist return 404 from the gateway. This boolean attribute records the pre-call governance check outcome, captured before the call is dispatched.", "notes": "Boolean attribute. No permitted_values enum struct generated. Captured before the paid HTTP call is dispatched.", "source": "pay.sh gateway provider spec YAML, endpoints[] allowlist", "source_url": "https://pay.sh/docs/protocol" }, { "enum_name": "RegistryProviderFqn", "label": "Registry Provider FQN", "otel_attribute": "agentic_payments.registry.provider_fqn", "opa_policy_path": "data.agentic_payments.registry.provider_fqn", "rego_input_key": "agentic_payments_registry_provider_fqn", "stability": "experimental", "attribute_type": "free_form_string", "description": "The fully-qualified provider name from the pay.sh catalog (for example: openai/dall-e, veriproof/governance). Captured verbatim from the catalog response at lookup time. No permitted_values list.", "notes": "Free-form string attribute. No enum struct generated. Captured verbatim from pay.sh catalog response.", "source": "pay.sh pay skills catalog, provider FQN field", "source_url": "https://pay.sh/api/catalog" }, { "enum_name": "RegistryProviderSha", "label": "Registry Provider SHA", "otel_attribute": "agentic_payments.registry.provider_sha", "opa_policy_path": "data.agentic_payments.registry.provider_sha", "rego_input_key": "agentic_payments_registry_provider_sha", "stability": "experimental", "attribute_type": "free_form_string", "description": "The content SHA from the pay.sh catalog's provider spec entry, captured at lookup time. Compared against the locally computed hash to produce PaySkillsProviderVerificationStatus. No permitted_values list.", "notes": "Free-form string attribute. No enum struct generated. Compared against locally computed SHA to derive PaySkillsProviderVerificationStatus.", "source": "pay.sh pay skills catalog, provider spec SHA field", "source_url": "https://pay.sh/api/catalog" } ] } ], "opa_rego_policy_patterns": { "description": "Agentic Payments & Stablecoins OPA Rego policy patterns. These reference enum values from this file and from 00_core_sdk_and_governance.json. Patterns enforce AP2 mandate chain governance, GENIUS Act reserve and licensing compliance, EU MiCA CASP authorization, x402 facilitator validation, FedNow ISO 20022 instruction reference requirements, and KYC/KYB obligations for stablecoin treasury transfers.", "patterns": [ { "pattern_id": "agentic_payments.ap2_intent_mandate_required_before_agentic_purchase", "pattern_name": "ap2_intent_mandate_required_before_agentic_purchase", "display_name": "Require a purchase mandate before an agent pays", "enforcement_effect": "deny", "description": "Stop a delegated payment when the session lacks its required prior open mandate record. Keep the mandate reference with the policy decision for review.", "applicable_enums": [ "AP2TransactionModality", "AP2MandateType" ], "regulatory_basis": "Application-defined mandate-record control, informed by AP2's delegated checkout and payment flows." }, { "pattern_id": "agentic_payments.ap2_payment_mandate_must_include_agent_presence_signal", "pattern_name": "ap2_payment_mandate_must_include_agent_presence_signal", "enforcement_effect": "deny", "description": "Require that all closed AP2 Payment Mandates and Checkout Mandates explicitly declare an agent presence signal. not_declared is a compliance gap under AP2 v0.2 (agentPresence claim) and EU AI Act Article 50 AI transparency disclosure obligations. Without an explicit presence signal, the mandate chain cannot be audited or certified.", "applicable_enums": [ "AP2MandateType", "AgentPresenceSignal" ], "regulatory_basis": "Google AP2 v0.2 PaymentMandate agentPresence claim; EU AI Act Article 50 AI transparency disclosure obligation; PCI DSS v4.0 Requirement 10.2 audit trail completeness" }, { "pattern_id": "agentic_payments.ap2_payment_amount_must_be_within_open_mandate_range", "pattern_name": "ap2_payment_amount_must_be_within_open_mandate_range", "enforcement_effect": "deny", "description": "Block mandate sessions where the payment amount or payee has already been flagged as violating the OpenPaymentMandate constraint range by the Veriproof API validation layer. When the API sets agentic_payments_mandate_status to constraint_violated, this policy corroborates the block at the OPA evaluation layer and prevents any further certification steps. A disputed status triggers a warning to preserve the evidence chain.", "applicable_enums": [ "AP2MandateStatus" ], "regulatory_basis": "Google AP2 v0.2 OpenPaymentMandate.constraints validation (AmountRange, AllowedPayees, AllowedPaymentInstruments); PCI DSS v4.0 Requirement 10.2 anomaly logging" }, { "pattern_id": "agentic_payments.genius_act_stablecoin_issuer_must_be_licensed_or_registered", "pattern_name": "genius_act_stablecoin_issuer_must_be_licensed_or_registered", "enforcement_effect": "deny", "description": "Block stablecoin payment sessions governed by the GENIUS Act when the issuer does not hold a federal or state payment stablecoin license. GENIUS Act §4 requires federal licensing for issuers with more than $10B in outstanding stablecoins and state licensing for smaller issuers. Operating with an unregulated or pending-registration issuer under a GENIUS Act regime is a legal compliance violation.", "applicable_enums": [ "StablecoinIssuerComplianceStatus", "PaymentRegulatoryRegime" ], "regulatory_basis": "GENIUS Act §4 (Pub. L. 119-27, signed July 18, 2025), federal and state payment stablecoin license requirements; GENIUS Act §12 AML/BSA obligations for licensed stablecoin issuers" }, { "pattern_id": "agentic_payments.genius_act_reserve_composition_must_be_compliant", "pattern_name": "genius_act_reserve_composition_must_be_compliant", "enforcement_effect": "deny", "description": "Block stablecoin sessions where the reserve composition includes non-permitted assets under GENIUS Act §4. GENIUS Act §4 permits only four reserve asset classes: cash and demand deposits, US Treasury bills with maturity of 93 days or less, central bank reserve balances, and repurchase agreements secured by T-bills. Money market funds are conditionally permitted pending final implementing regulations and generate a warning.", "applicable_enums": [ "StablecoinReserveComposition", "PaymentRegulatoryRegime" ], "regulatory_basis": "GENIUS Act §4 Permitted Reserve Asset definitions (Pub. L. 119-27); GENIUS Act §6 annual reserve audit requirement" }, { "pattern_id": "agentic_payments.mica_casp_must_have_eu_authorization", "pattern_name": "mica_casp_must_have_eu_authorization", "enforcement_effect": "deny", "description": "Block stablecoin payment sessions governed by EU MiCA when the issuer is not registered in the ESMA Interim Register as an ART or EMT issuer. MiCA (Regulation 2023/1114) is in full enforcement as of 2026. Processing transactions using an unregistered or pending-registration stablecoin issuer for EU-resident counterparties is a MiCA compliance violation.", "applicable_enums": [ "StablecoinIssuerComplianceStatus", "PaymentRegulatoryRegime" ], "regulatory_basis": "EU MiCA Regulation 2023/1114 Articles 3, 16, 48, ART/EMT registration requirements; ESMA Interim Register; MiCA Article 68 record-keeping obligations" }, { "pattern_id": "agentic_payments.mica_non_eu_stablecoin_requires_volume_monitoring", "pattern_name": "mica_non_eu_stablecoin_requires_volume_monitoring", "enforcement_effect": "warn", "description": "Warn that non-EU stablecoin volume monitoring is required under MiCA Article 75 when a MiCA-regime session is active. Even for registered issuers, MiCA Article 75 imposes daily transaction volume caps on non-EU stablecoins used within the EU. Issuers in pending_registration status during the MiCA transitional period must track and cap volume below ESMA-specified thresholds.", "applicable_enums": [ "StablecoinIssuerComplianceStatus", "PaymentRegulatoryRegime" ], "regulatory_basis": "EU MiCA Article 75, volume cap obligations for non-EU stablecoins used in the EU; ESMA Interim Register transitional provisions" }, { "pattern_id": "agentic_payments.x402_facilitator_must_be_in_tenant_allowlist", "pattern_name": "x402_facilitator_must_be_in_tenant_allowlist", "enforcement_effect": "deny", "description": "Block x402 stablecoin payment sessions where the facilitator is not the canonical Coinbase CDP Facilitator or an explicitly approved custom facilitator. Non-standard x402 facilitators introduce settlement risk and regulatory uncertainty. PCI DSS v4.0 Requirement 6.3 mandates that all payment processing components appear on the organization's approved software and vendor inventory. Tenants may disable or expand this rule via the Veriproof rule management portal.", "applicable_enums": [ "X402PaymentEventType", "X402FacilitatorId" ], "regulatory_basis": "PCI DSS v4.0 Requirement 6.3, approved payment component inventory; Coinbase x402 facilitator specification; FATF Recommendation 15, VASP due diligence" }, { "pattern_id": "agentic_payments.browser_agent_checkout_requires_intent_mandate_or_explicit_confirmation", "pattern_name": "browser_agent_checkout_requires_intent_mandate_or_explicit_confirmation", "enforcement_effect": "deny", "description": "Block browser-automation agent checkout sessions that lack an explicit AP2 mandate chain, session-declared intent mandate, or confirmed human-initiated event. Browser-agent checkout (ChatGPT agent mode, Anthropic computer-use, browser-use framework) bypasses structured payment APIs and represents the highest governance risk in enterprise deployments. Veriproof requires an explicit governance signal before certifying browser-agent checkout sessions.", "applicable_enums": [ "AP2TransactionModality", "AgentPresenceSignal" ], "regulatory_basis": "Google AP2 v0.2 browser-agent scenario governance requirements; EU AI Act Article 50 AI transparency disclosure; GENIUS Act §4 oversight for AI-initiated stablecoin payments" }, { "pattern_id": "agentic_payments.fednow_ai_payment_requires_iso20022_instruction_reference", "pattern_name": "fednow_ai_payment_requires_iso20022_instruction_reference", "enforcement_effect": "deny", "description": "Block AI-initiated FedNow and RTP instant payment sessions that have not produced a receipt reference equivalent to the ISO 20022 pacs.008 InstrId (Instruction Identification). The FedNow ISO 20022 Readiness Guide requires all AI-initiated FedNow payments to include a traceable instruction reference for end-to-end audit traceability. Veriproof maps the mandate receipt_reference to this requirement.", "applicable_enums": [ "FiatInstantRail", "Iso20022MessageFamily", "AP2ReceiptReferencePresent" ], "regulatory_basis": "FedNow ISO 20022 Readiness Guide, pacs.008 InstrId requirement for AI-initiated payments; ISO 20022 pacs message family; The Clearing House RTP ISO 20022 compliance requirements" }, { "pattern_id": "agentic_payments.stablecoin_payout_recipient_must_pass_kyc_kyb", "pattern_name": "stablecoin_payout_recipient_must_pass_kyc_kyb", "enforcement_effect": "deny", "description": "Block AI-initiated stablecoin treasury transfers when the payment session does not include KYC/KYB attestation for the recipient. Treasury transfers are the highest-value stablecoin transactions initiated by agentic AI and require recipient due diligence evidence under FATF Recommendation 15 (virtual asset service provider CDD) and GENIUS Act §12 (AML/BSA obligations for licensed stablecoin issuers). Veriproof requires agentic_payments_x402_attestation_type to be kyc_verified before certifying treasury transfer sessions.", "applicable_enums": [ "AP2TransactionModality", "X402AttestationType" ], "regulatory_basis": "FATF Recommendation 15, VASP customer due diligence (CDD) for virtual asset transactions; GENIUS Act §12 AML/BSA obligations; BSA 31 U.S.C. §5318(h), AML program requirements" }, { "pattern_id": "agentic_payments.mpp_mainnet_wallet_requires_explicit_user_approval", "pattern_name": "mpp_mainnet_wallet_requires_explicit_user_approval", "enforcement_effect": "deny", "description": "Block MPP payment sessions where a mainnet wallet proof was attached without a preceding explicit user approval event. mainnet_wallet without the wallet_authorization_requested challenge phase means the agent spent real funds without human confirmation, violating EU AI Act Article 9 risk management requirements and FATF Recommendation 15 human oversight obligations.", "applicable_enums": [ "WalletApprovalMode", "Http402ChallengePhase" ], "regulatory_basis": "EU AI Act Article 9, risk management system; EU AI Act Article 50, AI transparency for autonomous financial transactions; FATF Recommendation 15, human oversight for AI-initiated payments" }, { "pattern_id": "agentic_payments.mpp_session_cap_required_for_capped_auto_pay", "pattern_name": "mpp_session_cap_required_for_capped_auto_pay", "enforcement_effect": "deny", "description": "Block MPP session-payment sessions where capped auto-pay is active but no positive cap amount is declared. Unbounded auto-pay sessions allow the agent to make unlimited payments without any per-call user approval. EU AI Act Article 9 risk management requires proportionate controls for autonomous financial transactions.", "applicable_enums": [ "MppSessionAuthorizationMode" ], "regulatory_basis": "EU AI Act Article 9, risk management system requiring proportionate controls for autonomous financial transactions; GENIUS Act §4, oversight obligations for AI-initiated stablecoin payments" }, { "pattern_id": "agentic_payments.mpp_session_exhausted_requires_reauthorization", "pattern_name": "mpp_session_exhausted_requires_reauthorization", "enforcement_effect": "deny", "description": "Block MPP payment steps that attempt to proceed after the session cap is exhausted without explicit human re-authorization. capped_session_exhausted with any wallet_approval_mode other than local_user_approval means the agent is attempting to extend a depleted session without user consent.", "applicable_enums": [ "MppSessionAuthorizationMode", "WalletApprovalMode" ], "regulatory_basis": "EU AI Act Article 9, risk management for autonomous AI financial decisions; FATF Recommendation 15, customer due diligence re-verification for high-value recurring payment sessions" } ] } }