Skip to main content
Every active organization baseline plus every policy assigned to the selected agent, wallet, or card must pass. The first DENY stops evaluation immediately. Counterparty or relationship review is considered only after hard wallet and policy controls pass, so an approval route cannot turn a denied payment into an approvable request. An unset (null) wallet or relationship limit means no cap. A limit of 0 blocks every payment. A positive value is the cap.

​
Policy scope

Every policy has one explicit scope:
  • Organization: a mandatory baseline applied automatically to every payment in the organization.
  • Assigned: applies only through an explicit agent, wallet, or card assignment. An unassigned policy is a draft control and is not enforced.
Use organization scope for universal compliance and safety limits. Use assigned scope for rules that vary by agent, wallet, or card. Organization baselines cannot be bypassed by removing an assignment.

​
Evaluation order

  1. Pre-checks: the agent must be ACTIVE with linked wallets
    • DEV and STAGING agents can use only known testnet wallets. Mainnet and unclassified chains are denied.
  2. Geographic and sanctions: address sanctions screening on every payment, plus an OFAC country check when the request includes context.recipientCountry (no policy needed)
  3. Counterparty trust: pre-fetch trust level and network trust score for use in policy rules
  4. Wallet policies: spend limits, wallet-level time windows (timezone-aware), and other configured policy rules
    • Identity allow rules evaluate environment, risk tier, owner role, tags, and attestation mode. Missing identity context denies the payment.
  5. Counterparty rules: block list, trust requirements, network intelligence
  6. Relationship controls: per-agent payee limits, category allowlists, approval requirements, and temporary access expiry
  7. Final decision: any denial denies. Otherwise a rule or workflow that requires approval holds the payment. Otherwise it is approved. See outcomes.
Protocol-specific budget rules only count transactions recorded through the matching protocol flow, so ordinary wallet transfers do not reduce protocol allowances. Endpoint velocity and service call counts include every item in a recorded batch. Budget caps and velocity rules count recorded transactions plus payments that are executing or approved but unconfirmed. Missing history denies the payment. See Budget allocations and Limit transaction velocity. Conto checks the full policy set again right before a managed payment executes and before it issues an external-wallet approval token. A new denial at that point stops the payment. An external-wallet approval counts toward budgets, velocity, and per-counterparty limits until it is confirmed or expires. See wallet custody for what policy can restrict on each wallet type.
Address sanctions screening is active by default and uses maintained compliance data. A sanctions match can deny a payment even when every configured policy would otherwise allow it.

​
Counterparty lifecycle and agent controls

Counterparty lifecycle state and per-agent relationship controls are evaluated independently:
  • A counterparty can move through DISCOVERED, PENDING_REVIEW, APPROVED, TRUSTED, MONITORED, QUARANTINED, and BLOCKED.
  • PENDING_REVIEW, MONITORED, and QUARANTINED route payments to approval.
  • DISCOVERED routes a production agent’s payments to approval. Development and staging agents, which can only use testnet wallets, are not held for payee discovery.
  • BLOCKED denies the payment.
  • Each agent-to-counterparty relationship can add stricter per-payment, daily, and monthly limits, require approval, restrict categories, or expire at a specific time.
Approving a counterparty globally does not remove a stricter agent-specific approval requirement. An expired relationship returns the payment to review.

​
Evaluation semantics

Policy rules use simple AND logic. Every active organization policy and every active policy assigned to the selected agent, wallet, or card is evaluated once, and every rule inside those policies must pass unless it is a DENY or REQUIRE_APPROVAL trigger that does not match.
priority is sort order, not override precedence. A higher-priority ALLOW cannot override a lower-priority deny or a failed allowlist. Use one wider allowlist rule when you need alternatives, not two competing policies.

​
When the request leaves out a field

Many rules read a field from the payment request, such as category, context.recipientCountry, targetContractAddress, or the x402 or MPP service.
  • If the request does not include the field an ALLOW rule checks, the payment is denied.
  • If the request does not include the field a DENY or REQUIRE_APPROVAL rule checks, that rule does not apply. A BLOCKED_CATEGORIES rule blocks nothing when the agent sends no category.
Send every field your rules read. For example, always send category when you use category rules. When a list must hold even if the agent leaves the field out, write it as an ALLOW list.

​
Wallet balance and custody

Evaluation checks the wallet balance only for wallets Conto custodies. For those, the recorded balance is a ledger Conto maintains as it executes each payment, so a payment that would overdraw the wallet is denied with INSUFFICIENT_BALANCE. External wallets are not checked this way on the external-wallet approval flow (POST /api/sdk/payments/approve). Conto does not hold the keys and never sees the transfers the agent signs, so the balance it records is a point-in-time reading rather than a running total. Enforcing it would block funded wallets while still clearing drained ones. Spend limits, policy rules, counterparty controls, budgets, and approval workflows apply to external wallets exactly as they do to custodied ones, and an underfunded transfer reverts onchain rather than settling. For a hands-on walkthrough, test allow, review, and deny.

Policies

Create, assign, and simulate a policy

Policy rule reference

Every rule type, operator, and value format