Bad payments stop
before they happen.
Counterparty risk, sanctions exposure, behavior baseline, cross-chain context. Every agent payment passes all four in under 100 ms. One fail, the payment never reaches your provider.
Three steps. 100 ms.
Every payment runs the same pipeline. The pipeline finishes before your provider ever sees the request.
01 · Agent calls pay
Your agent issues agent.pay() with the destination, amount, and chain. Oris receives the request and opens an evaluation context bound to the agent's KYA level.
agent.pay( to="0xA1b2...C3d4", amount=25.00, chain="base", )
02 · Safety evaluation
The safety engine resolves four checks in parallel. Each check has a deterministic budget. The slowest path wins; the overall pipeline finishes under one hundred milliseconds.
03 · Pass or block
A clean evaluation forwards the transaction to your provider. A failed evaluation returns a structured error code with the matched indicator, the rule that triggered the block, and the screening trace ID. The provider never sees the request.
Every block explained.
Each block names the indicator, the counterparty, and the rule that fired. Aggregates roll up by hour, day, and policy.
Each blocked transaction records the matched indicator, the rule, the counterparty graph, and the screening trace ID. Operators can replay any block decision from the activity log to confirm the verdict.
Aggregate counts roll up by hour, day, and policy. Pass rate, average latency, and block reason distribution are available through the analytics API and the regulator-portal export.
If in doubt, block.
The engine refuses any payment it cannot clear with certainty. An outage returns a structured error. An outage never turns into a silent payment.
A blocked transaction returns a structured error code that includes the failure mode. Your application can render the reason to the operator, surface it to the agent, or queue the payment for manual review through the operator console.
There is no soft-fail mode. There is no rate-limited fallback that lets a transaction through. The safety pipeline is a strict gate. If the gate cannot produce a verdict, the gate stays closed.
Three risks. Three guards.
Three risk signals feed every payment. One fails, the payment stops.
Counterparty risk
The destination address is checked against the labeled-address graph, sanctions lists, and known illicit-actor clusters. Addresses linked to OFAC SDN, mixers, or sanctioned protocols are blocked before the request leaves Oris.
Transaction patterns
Unusual amounts, frequencies, or destination clusters are scored against the agent's behavioral baseline. A statistically significant deviation produces a drift event that demotes the agent and blocks the in-flight payment.
Cross-chain context
The screening engine joins the agent's activity across all ten supported chains into a single risk view. An address that appears innocuous on Base may be heavily linked to a sanctioned cluster on Ethereum. The cross-chain view sees both.
Veris does the heavy lifting.
Ten chains indexed in real time. Seventy thousand labeled addresses. Fifteen detection models. Every verdict signed and traceable.
The engine inside the engine.
Every safety verdict carries a Veris attestation. The feed version, the model hash, the signature over the verdict, all checkable on chain.
This runs underneath every payment. You do not configure it. You do not pay for it separately. The engine ships with the protocol.
Stop a bad payment before it happens.
Screening ships with every plan. No setup. Every agent payment runs the same pipeline from your very first call.