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. The SDK policy response lists each policy’s scope and whether it reaches the payment through the organization, agent, wallet, or card. Daily, weekly, and monthly limits at organization or agent scope use the agent’s combined wallet and live-card spend. See how spend limits count for concurrent reservations, wallet-only and card-only limits, and test cards.

​
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 AND logic. Each active policy that applies is evaluated once, and every rule in it 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 a field a rule checks, the payment is denied, whatever the rule’s action. The reason names the missing field.
  • Exceptions: a DENY or REQUIRE_APPROVAL rule on context.recipientCountry, on the Fairscale score, or on targetContractAddress does not apply when the field is missing. Plain transfers never carry a contract, and address sanctions screening still runs on every payment. ALLOW versions of these rules still deny.
  • A card payment is checked only against rules that apply to cards. A rule written for wallet, x402, or MPP payments, such as a trust rule or an x402 price ceiling, is skipped on a card payment whatever its action.
  • On wallet, x402, and MPP payments, a DENY or REQUIRE_APPROVAL rule written for another payment type is skipped, and an ALLOW rule still denies them. For example, an ALLOW card store rule denies the agent’s wallet payments, because they carry no store domain. To limit one payment type without blocking the others, use NOT_IN_LIST with DENY.
Send every field your rules read. To make a country or contract list hold when the agent leaves the field out, write it as an ALLOW list.

​
Checkout purchases

A checkout checkpoint is evaluated against the agent’s policies at begin and again at confirm. It needs no linked wallet.
  • The merchant is the checkout domain. Counterparty rules see the registrable domain of the checkout URL as the recipient. Case and a leading www. do not matter, so https://WWW.Example.com/cart is the merchant example.com.
  • Counterparty lists use that domain. Allow and block lists, payee status, and relationship controls match the checkout host and each parent domain up to the registrable domain. An entry for example.com covers shop.example.com. Write entries as domains.
  • Velocity rules count checkout purchases. VELOCITY_LIMIT counts a purchase with the agent’s other payments while its spend is held and after it is paid. Cancelled, rejected, expired, and not-paid purchases stop counting. With RECIPIENT scope, the rule counts purchases at the same merchant.
  • Period limits include checkout spend. Daily, weekly, and monthly limits at organization or agent scope count checkout spend together with wallet and card spend.
  • Budgets and relationship limits count checkout purchases. BUDGET_CAP rules and relationship daily and monthly limits count a purchase while its spend is held and after it is paid, as velocity rules do. A relationship with example.com also counts purchases on shop.example.com.
Connected-card store rules also apply to checkouts. They match the host of the checkout URL, so an entry for example.com covers a checkout at shop.example.com.

​
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.