How an AI Agent Executes a Compliant Payment in Under 200 Milliseconds

When an agent calls oris_pay, four systems activate in sequence. The entire pipeline finishes in under 200 milliseconds. Every stage produces a structured audit record. If any stage fails, the payment stops and the agent receives a detailed rejection reason. This article walks through each stage with exact timing data.

The Pipeline

Stage 1: KYA Verification (~5ms)

The pipeline begins with identity. The agent sends a payment request signed with HMAC-SHA256, including its agent ID, API key, a Unix timestamp, and a unique nonce. The KYA module performs three checks in parallel.

First, it verifies that the agent profile exists and holds an active status. Suspended or revoked agents receive an immediate rejection. Second, it confirms that the agent's trust level meets the minimum threshold for the requested transaction type. An L0 (Registered) agent cannot execute a $5,000 transfer that requires L2 (Trusted) status. Third, it validates the authorization chain, confirming that the operator has granted this specific agent permission to initiate payments.

All three checks read from Redis-cached data. The agent profile, trust level, and authorization records are cached with a 60-second TTL and refreshed on every state transition. This design keeps KYA verification under 5 milliseconds for 99th percentile requests.

Stage 2: Policy Evaluation (<10ms)

The Policy Engine evaluates every spending rule attached to the agent. Operators define these rules through the Oris dashboard or API. Each rule specifies a condition and a consequence.

The engine evaluates all applicable policies in a single pass. If any policy rejects the transaction, the entire payment fails. The engine records every evaluation result (including passes) to the oris_policy_evaluations hypertable. This record provides a complete audit trail showing which rules were checked, which passed, and which (if any) blocked the payment.

Policy data lives in Redis with a configurable TTL. The engine reads policies from cache on every request and falls back to TimescaleDB on cache miss. This architecture keeps evaluation latency under 10 milliseconds at the 95th percentile.

Stage 3: Compliance Screening (<100ms)

The Compliance Bridge performs two categories of checks. Pre-screening validates the transaction against sanctions lists and risk databases before any funds move. Post-screening records the transaction for ongoing monitoring and regulatory reporting.

Pre-screening maps the agent's wallet address to an entity profile through the Veris Entity API. Veris maintains a comprehensive entity database with risk scores, jurisdiction mappings, and sanctions list matches. The Compliance Bridge sends the destination wallet address, the transaction amount, and the agent's entity ID to Veris. Veris returns a risk assessment within 80 milliseconds for 95th percentile requests.

If the destination wallet maps to a sanctioned entity, the transaction blocks immediately. If the risk score exceeds the operator's configured threshold, the transaction enters a review queue. The agent receives a structured rejection with a specific reason code that allows automated retry logic or escalation.

The bridge maintains a circuit breaker pattern for Veris API connectivity. If Veris becomes unavailable (5 consecutive failures), the circuit opens and all payments enter a quarantine state. Quarantined payments do not execute. The system fails closed. Once Veris recovers, a dead letter queue processes quarantined transactions with exponential backoff.

Stage 4: On-chain Execution (~50ms)

After compliance clears, the Wallet Manager executes the payment. It first creates an optimistic balance reservation, deducting the amount from the agent's available balance in Redis. This prevents double-spending if multiple payment requests arrive simultaneously. The manager then submits the stablecoin transfer on-chain and waits for confirmation.

Upon confirmation, the system writes the final transaction record to the oris_agent_transactions hypertable with all metadata: agent ID, operator ID, amount, destination, compliance result, policy evaluation IDs, and on-chain transaction hash. If execution fails, the balance reservation rolls back atomically.

The SDK Call

From the developer's perspective, the entire four-stage pipeline reduces to three lines of code.

from oris import OrisClient

client = OrisClient(api_key="oris_sk_live_...")
receipt = client.pay(agent_id="agent-47b", to="0x1a2b...f9e0", amount=25.00, currency="USDC")

The pay method handles HMAC signing, nonce generation, timestamp injection, and retry logic internally. The returned receipt object contains the transaction hash, the compliance screening result, the policy evaluation summary, and the total pipeline latency in milliseconds.

Every payment produces an immutable audit record. The record links the agent identity, the policy evaluation, the compliance screening result, and the on-chain confirmation into a single verifiable chain. Regulators, auditors, and operators can reconstruct the complete decision path for any transaction at any time.

Explore the full API reference and SDK documentation at docs.useoris.xyz