> ## Documentation Index
> Fetch the complete documentation index at: https://conto.finance/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# How policies are evaluated
> Policy scope, evaluation order, how ALLOW, DENY, and REQUIRE_APPROVAL rules combine, missing fields, payee status, and wallet balance checks.
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](/docs/policies/overview#what-is-a-policy).
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](/docs/policies/advanced#budget-allocations) and
[Limit transaction velocity](/docs/policies/advanced#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](/docs/guides/custody-modes) 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.
| Action | Meaning |
| ------------------ | ---------------------------------------------------------------------------------------------------------- |
| `ALLOW` | The condition describes what is permitted. If the condition does not match, the payment is denied. |
| `DENY` | The condition describes what is blocked. If the condition matches, the payment is denied. |
| `REQUIRE_APPROVAL` | The condition describes what needs review. If it matches and no DENY fires, the payment requires approval. |
`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](/docs/guides/policy-testing).
## Related
Create, assign, and simulate a policy
Every rule type, operator, and value format