Skip to main content
Every active organization baseline, every policy of the agent’s team, and 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 that applies automatically to every agent in the organization.
  • Team: applies to every agent in one team (teamId). An agent belongs to at most one team.
  • 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 team scope for rules a department sets for its own agents. Use assigned scope for rules that vary by agent, wallet, or card. Organization and team policies cannot be bypassed by removing an assignment, and a team policy can only add limits on top of the organization’s. GET /api/sdk/policies returns each policy’s scope and appliesVia, which lists organization, team, agent, or wallet. Daily, weekly, and monthly limits at organization, team, 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.
    • A wallet pays only an address on its own network. Conto uses a linked wallet on the recipient’s network and denies the payment when there is none. An EVM address sent without its 0x prefix is denied.
  2. Geographic and sanctions: sanctions screening of the recipient wallet address, 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
    • A network-wide block holds the payment for approval. It denies only after Conto has reviewed and confirmed the block.
  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, approved but unconfirmed, or waiting for reconciliation. Missing history denies the payment. See Period caps and Limit transaction velocity. Conto checks the full policy set again right before a managed payment executes and before it approves an external-wallet payment, whether approve or request approved it. A new denial at that point stops the payment. An external-wallet approval counts toward spend limits, approved 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

Every rule in every applicable active policy is checked. What a match does depends on the action: A rule whose value the engine cannot read denies the payment, whatever its action, so a stored rule in the wrong shape never stops matching without notice. The policy endpoints refuse such a value when it is saved.
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, 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.
  • Exception: a country DENY or REQUIRE_APPROVAL rule does not apply on a card payment or checkout when Conto has no country for it. On a wallet payment with no context.recipientCountry, a country DENY or REQUIRE_APPROVAL rule holds the payment for approval. ALLOW versions of these rules still deny.
  • Contract rules on a wallet payment check the address the payment is sent to, so they never lack a contract there. See contract allowlist.
  • 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.
A BUDGET_CAP scoped to a department, project, or category counts a payment that leaves the label out, so leaving it out never takes a payment outside the budget. A payment that names a different label is outside the budget, and a DENY or REQUIRE_APPROVAL budget does not act on it. See budget caps. Send every field your rules read. To make a country list hold on card payments and checkouts with no known country, write it as an ALLOW list.

x402 and MPP payees

The agent sends both the service URL and the address to pay, so a service rule alone does not prove the address belongs to the service. For a PROD agent, Conto records the payee before evaluation, the same as wallet payments, and holds the first payment to a new address for review. After an organization’s first approved payment to a service, that address is bound to that service. A different address for the service, or a bound address sent under another service’s URL, is held for review until someone approves the payee in Counterparties.

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. At organization or agent scope, a budget without a category counts it together with wallet and live-card spend. 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.