A signed decision record for every agent action, before it reaches your payment system.
R3 evaluates proposed agent actions against configured policy, blocks or escalates violations, and writes a tamper-evident record. For compliance teams: an answer for every audit question. For engineering teams: a forcing function that cannot be bypassed through a timeout or error.An audit-ready record for every action your agents take.
When an auditor asks, you pull the signed record.
Every agent action that passes through R3 produces a decision record containing the policy inputs, the outcome, the evaluation timestamp, and a cryptographic hash of the previous record in the chain.
When examiners ask about your governance of agentic AI decisions, you produce the evidence chain, not an anecdote about how the system was designed to work.
Policy failures block. Timeouts block. Nothing silently approves.
The gate is fail-closed. A policy error or timeout contributes a block to the aggregate decision. Your agents cannot accidentally receive a silent approval because a policy service was slow or unreachable.
The downstream payment executor must independently verify the scoped authorization token before executing. R3 creates a hard enforcement boundary, not a soft advisory.
Evaluate, decide, record. In that order, every time.
The gate aggregates policy outcomes: any block overrides all, any escalate overrides allow. The evidence record is written before any authorization token is issued. If the evidence write fails, the request fails.
Submits a proposed action envelope: amount, accounts, payee, timing, and agent identity.
Your agent does not change. It calls R3 before it calls the payment system.
Four policies run concurrently: amount limit, FDCPA timing window, new payee threshold, velocity limit. Any block wins. Any escalate triggers human review.
The gate overrides agent-claimed values. New-payee status, velocity counts, and borrower-local time come from R3's own data, not the agent.
Returns allow, escalate, or block. Writes a signed, hash-linked record to the evidence chain. On allow, issues a scoped authorization token with a 60-second expiry.
The record is written before the token is issued. No record, no token. The chain cannot be altered after the fact.
Must verify the token's cryptographic signature, binding (agent, amount, accounts), expiry, and single-use nonce before executing.
The executor enforces independently. R3 does not have access to payment execution systems.
What a design partner evaluation looks like.
We are in conversation with compliance teams at fintech lenders and regional banks building payment, collections, and treasury workflows. A design partner evaluation has three steps.
A 30-minute call
We learn about your workflow, the agent you are deploying, and what your compliance team needs the evidence record to demonstrate. No demo at this stage. We want to understand whether R3 fits your specific scenario before we ask for your time on a test.
A controlled test scenario
We configure R3 against one real workflow from your environment and run a sample of proposed agent actions through the gate. You see the decision logic, the evidence output, and the full audit trail. We document what the gate blocked, escalated, and allowed, and why.
A written evaluation report
You receive documentation of what R3 evaluated, what the gate found, what the evidence record looks like for your scenario, and how it maps to your governance requirements. This is the document you bring to a compliance or legal review.
What crosses the boundary and what does not.
What R3 receives from the agent
Agent ID and type, action type, amount_cents, currency, source and destination account references (opaque identifiers, max 64 characters), payee name, borrower timezone, and a capped metadata field (128 keys, 8 KiB). No bank credentials, no routing numbers, no customer PII.
What R3 computes independently
Evaluation timestamp (gate receipt time, never agent-supplied). Borrower-local hour (computed from timezone, overrides agent claim). Velocity count (from gate's own database, not agent metadata). New-payee status (from gate's own payee registry, not an agent flag).
What R3 never receives
Account balances, bank routing numbers, SWIFT codes, customer PII (SSN, date of birth, address), transaction history beyond the gate's own counters, bank credentials, or customer profile data. R3 evaluates action envelopes, not account records.
Decision evidence is encrypted at rest in production using industry-standard encryption. Plaintext evidence storage is rejected by the production configuration validator.
Can you trust R3 with real money?
If R3 goes down, nothing executes without a token
When R3 is unreachable, an agent receives no authorization token. Execution depends on the downstream executor enforcing the token requirement. That dependency is by design: the gate is in the critical path, not an advisory overlay. Policy errors and timeouts contribute a block to the aggregate outcome. The gate does not fail open.
No one can alter a decision record after it is written
Each record is cryptographically signed with a scoped key and hash-linked to the previous record. Production uses hardware-backed key management. The canonical record format is versioned; changing it requires a version bump and invalidates historical records against the new format.
Minimal footprint, minimal privilege
The production container runs as a non-root, least-privilege user with a read-only root filesystem. All OS capabilities are dropped; the container follows default system call restrictions. Database credentials, signing keys, and API keys are injected at runtime from secrets management. None are stored in the container image.
Governance evidence ready when examiners ask
R3 provides evidence indexes mapped to FFIEC operational risk categories and consumer protection obligations. It is not a compliance certification, a supervisory determination, or a substitute for an institution's own governance program.
These are current implementation controls, not independently audited certifications. We are seeking design partners. No customer endorsements or production SLAs are represented on this site.
Designed so that failure is never a silent approval.
Every design decision in R3 starts from one principle: an uncertain outcome is a blocked outcome. The enforcement guarantees are structural, not procedural.
Errors and timeouts become blocks
The gate aggregates policy outcomes fail-closed. A policy that errors or times out contributes a block to the aggregate decision. No policy, no approval. There is no code path that defaults to allow on uncertainty.
Evidence is written before the token is issued
If the evidence write fails, the request fails. No record, no authorization token. The two are atomic by design. An agent can never receive an allow response without a corresponding tamper-evident record in the chain.
Authorization tokens are single-use and transaction-scoped
Each token is bound to the exact agent, source account, destination account, and amount. A 60-second expiry and a single-use nonce prevent replay and scope escalation. The payment executor independently verifies every field before proceeding.
Records cannot be altered after they are written
Each record is cryptographically signed and hash-linked to the previous record. The record format is versioned. Altering a record breaks the chain signature. There is no update or delete path in the evidence store.
What evaluation teams ask about R3.
Policy errors and timeouts contribute a block to the aggregate decision. The gate does not fail open. If R3 itself is unreachable, the agent receives no authorization token. Whether a payment proceeds then depends on the downstream executor enforcing the token requirement.
No. The payment executor must independently verify the scoped authorization token, checking signature, binding (agent, amount, accounts), expiry, and single-use nonce before executing. R3 does not have access to payment execution systems. It evaluates proposed actions and produces evidence records.
The default policy set is: amount limit, FDCPA time window, new payee threshold, and velocity limit. Additional policies such as sanctions screening are available when enabled in tenant configuration. Tenants can configure per-tenant thresholds for each policy, with the platform enforcing a floor.
No. R3 provides runtime policy enforcement and decision evidence. It does not certify compliance, provide legal advice, or replace an institution's governance program. It is evidence infrastructure for demonstrating governance of agentic AI decisions in examination contexts, covering FFIEC operational risk categories and consumer protection obligations (FDCPA, UDAP, BSA/AML).
R3 exposes an HTTP API at /v1/evaluate for submitting action envelopes. On allow, the agent receives a scoped cryptographic authorization token (60-second expiry) to present to the payment executor. SDKs are available for Python and TypeScript. Contact the design-partner team to discuss integration and deployment requirements for your environment.
Each record is cryptographically signed and hash-linked to the previous record in the chain. Altering any record breaks the chain signature and renders verification impossible. There is no update or delete path in the evidence store. The record format is versioned; changing the format requires a version bump that explicitly invalidates the hash chain for older records. Production uses hardware-backed key management for signing operations.
Yes. Each tenant can configure custom thresholds for the core policies (amount limits, velocity windows, new payee criteria) and define custom agent types with specific permission sets. Threshold overrides are injected at evaluation time, so the platform enforces your institution's specific limits rather than platform defaults. Policy configuration is part of the design partner onboarding.
The action envelope contains policy inputs: account references (opaque identifiers, max 64 characters), amount, action type, payee name, timing, and agent identity. R3 derives velocity counts, new-payee status, and borrower-local time from its own data sources, not from agent-supplied values.
R3 never receives account balances, bank routing numbers, SWIFT codes, customer PII (SSN, date of birth, address), transaction history beyond its own velocity counters, bank credentials, or customer profile data.
Start a design partner evaluation.
Tell us the workflow you are building, the agent you are deploying, and what your compliance team needs the evidence record to demonstrate. We confirm whether R3 fits your scenario before we ask for more of your time.
Usage-based pricing for production. Design partner terms negotiated individually.