Advanced Policies

Agent identity enforcement

Agent identity policies can constrain payment authorization by environment, risk tier, owner role, required identity tag, and attestation mode. Missing identity context fails closed for allow rules. DEV and STAGING agents also cannot select mainnet or unclassified wallets, even when one was accidentally assigned. Supported rule types are AGENT_ENVIRONMENT, AGENT_RISK_TIER, AGENT_OWNER_ROLE, AGENT_TAG, and ATTESTATION_LEVEL. Use advanced rules when simple spend limits, time windows, and counterparty controls are not enough. Most teams should start with Policy Overview, then add only the controls their agent actually needs.

Effective policy stack

Conto evaluates the complete policy stack for each payment: every active organization policy plus every active assigned policy linked to the payment’s agent and wallet or card. Organization policies are mandatory baselines and cannot be attached to individual resources. Assigned policies do nothing until they are linked to an agent, wallet, or card. All applicable policies are composed once before their rules are evaluated. A direct assignment cannot replace or weaken an organization baseline, and a denial from any applicable rule wins. The SDK policy response identifies each policy’s scope and whether it applies through the organization, agent, wallet, or card.

Rule shape

{
  "ruleType": "MAX_AMOUNT",
  "operator": "LTE",
  "value": "500",
  "action": "ALLOW"
}

Field	Purpose
`ruleType`	What the rule evaluates
`operator`	How the request value is compared
`value`	String value, or JSON encoded object/array
`action`	`ALLOW`, `DENY`, or `REQUIRE_APPROVAL`

Operators

Operator	Meaning
`EQUALS`, `NOT_EQUALS`	Exact match or mismatch
`GREATER_THAN`, `GTE`, `LESS_THAN`, `LTE`	Numeric comparison
`IN`, `IN_LIST`, `NOT_IN`, `NOT_IN_LIST`	List membership
`BETWEEN`, `NOT_BETWEEN`	Range comparison

Supported Rule Types

Category	Rule types
Amount limits	`MAX_AMOUNT`, `DAILY_LIMIT`, `WEEKLY_LIMIT`, `MONTHLY_LIMIT`, `BUDGET_CAP`
Approval	`REQUIRE_APPROVAL_ABOVE`
Time	`TIME_WINDOW`, `DAY_OF_WEEK`, `DATE_RANGE`, `BLACKOUT_PERIOD`
Category	`ALLOWED_CATEGORIES`, `BLOCKED_CATEGORIES`
Counterparty	`ALLOWED_COUNTERPARTIES`, `BLOCKED_COUNTERPARTIES`, `TRUST_SCORE`, `COUNTERPARTY_STATUS`
Contract controls	`CONTRACT_ALLOWLIST`
Velocity	`VELOCITY_LIMIT`
Geographic	`GEOGRAPHIC_RESTRICTION`
x402	`X402_MAX_PER_REQUEST`, `X402_PRICE_CEILING`, `X402_ALLOWED_SERVICES`, `X402_BLOCKED_SERVICES`, `X402_ALLOWED_FACILITATORS`, `X402_MAX_PER_SERVICE`, `X402_MAX_PER_ENDPOINT`, `X402_VELOCITY_PER_ENDPOINT`, `X402_SESSION_BUDGET`
MPP	`MPP_MAX_PER_REQUEST`, `MPP_MAX_SESSION_DEPOSIT`, `MPP_SESSION_BUDGET`, `MPP_MAX_CONCURRENT_SESSIONS`, `MPP_MAX_SESSION_DURATION`, `MPP_BLOCK_SESSION_INTENT`, `MPP_ALLOWED_SERVICES`, `MPP_BLOCKED_SERVICES`, `MPP_MAX_PER_SERVICE`, `MPP_MAX_PER_ENDPOINT`, `MPP_VELOCITY_PER_ENDPOINT`
Commerce facts	`COMMERCE_EXTENSION_FACT`

Rule Patterns

Registered Commerce Fact Rules

COMMERCE_EXTENSION_FACT evaluates a scalar property from a schema-validated commerce proposal extension. The rule value is JSON encoded and contains the exact schema binding plus the expected value:

{
  "ruleType": "COMMERCE_EXTENSION_FACT",
  "operator": "EQUALS",
  "value": "{\"namespace\":\"acme.procurement.v1\",\"path\":[\"costCenter\"],\"schemaRevision\":1,\"schemaFingerprint\":\"<64-character-sha256>\",\"expected\":\"OPS\"}",
  "action": "ALLOW"
}

Supported operators are EQUALS, NOT_EQUALS, IN, NOT_IN, IN_LIST, NOT_IN_LIST, and the numeric operators GREATER_THAN, LESS_THAN, GTE, and LTE. Paths contain one to five property segments and must resolve to a scalar in the registered schema. Policy writes reject disabled, stale, or mismatched schema bindings. Evaluation also fails closed if the proposal omits the fact or carries a different revision or fingerprint.

Require review above a threshold

{
  "name": "Approval Over 500",
  "policyType": "APPROVAL_THRESHOLD",
  "rules": [
    {
      "ruleType": "REQUIRE_APPROVAL_ABOVE",
      "operator": "GREATER_THAN",
      "value": "500",
      "action": "REQUIRE_APPROVAL"
    }
  ]
}

A policy decision that requires approval always creates a request in Alerts & Approvals. If no custom workflow matches, one review from an organization Owner, Admin, or Manager is required, and the initiator cannot approve their own held payment. A final approval automatically submits the payment for Conto-managed wallets and links the chain receipt from the approval review. External and smart-contract wallets retain their manual execution requirements. A final decision emits an approval.approved or approval.denied webhook to your organization webhook for your own audit trail (see Webhooks).

Request a scoped policy change

An agent with an admin SDK key can request a specific policy change without editing the policy directly. Use POST /api/sdk/policies/exceptions with the policies:exceptions scope, then use GET /api/sdk/policies/exceptions to track it.

curl -X POST https://conto.finance/api/sdk/policies/exceptions \
  -H "Authorization: Bearer $CONTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "spend_limit",
    "reason": "The annual vendor renewal is due this week.",
    "priority": "high",
    "details": {
      "policyId": "policy_123",
      "requestedLimit": 750,
      "amount": 600
    }
  }'

The response preserves the original exceptionId, uppercase type, and uppercase status fields for existing integrations. It also includes id, normalizedType, normalizedStatus, and statusLabel for applications that want stable customer-facing values:

{
  "id": "exception_123",
  "exceptionId": "exception_123",
  "type": "INCREASE_SPEND_LIMIT",
  "normalizedType": "spend_limit",
  "title": "Spending limit request",
  "reason": "The annual vendor renewal is due this week.",
  "priority": "high",
  "severity": "HIGH",
  "status": "PENDING",
  "normalizedStatus": "pending",
  "statusLabel": "Pending review",
  "reviewUrl": "/alerts"
}

normalizedStatus is one of pending, in_review, resolved, or dismissed. List responses include the same items under both exceptions and the additive requests alias. Customer-supplied reason, priority, and validated details are returned. title and severity are stable values derived from the request type and priority; operational alert copy and metadata are not part of this API. Creating a request does not change a policy by itself; review it in Alerts & Approvals.

Limit transaction velocity

Set exactly one of maxCount or maxAmount. Supported periods are HOUR, DAY, WEEK, and MONTH. HOUR and DAY use rolling one-hour and 24-hour history. Weekly and monthly counts use UTC calendar periods; weekly and monthly amount limits use the matching cumulative spend counters.

{
  "name": "Hourly Velocity Limit",
  "policyType": "VELOCITY",
  "rules": [
    {
      "ruleType": "VELOCITY_LIMIT",
      "operator": "LTE",
      "value": "{\"maxCount\": 10, \"period\": \"HOUR\"}",
      "action": "ALLOW"
    }
  ]
}

For an amount-based rate limit, use the same rule with maxAmount:

{
  "ruleType": "VELOCITY_LIMIT",
  "operator": "LTE",
  "value": "{\"maxAmount\": 300, \"period\": \"HOUR\"}",
  "action": "ALLOW"
}

Count-based velocity accepts an optional scope. The default WALLET counts all of the wallet’s transactions in the window. RECIPIENT counts only transactions to the current recipient address, which limits rapid repeated payments to one counterparty without counting unrelated activity:

{
  "ruleType": "VELOCITY_LIMIT",
  "operator": "LESS_THAN",
  "value": "{\"maxCount\": 5, \"period\": \"HOUR\", \"scope\": \"RECIPIENT\"}",
  "action": "ALLOW"
}

Wallet velocity includes pending, confirming, and confirmed transactions plus other executing payment reservations that have not produced a transaction record yet. Card velocity includes recorded card transactions plus approved, executing, and confirming reservations. A policy linked to a card uses card-wide history, while an agent-linked card policy uses that agent’s history on the card assignment. Missing history, unsupported periods, and malformed velocity configuration deny the payment rather than defaulting the prior count or spend to zero.

Restrict by category

{
  "name": "Approved Categories",
  "policyType": "CATEGORY",
  "rules": [
    {
      "ruleType": "ALLOWED_CATEGORIES",
      "operator": "IN_LIST",
      "value": "[\"infrastructure\", \"ai_services\", \"marketing\"]",
      "action": "ALLOW"
    }
  ]
}

Relationship-scoped payee controls

Use relationship controls when two agents need different authority for the same counterparty. From the counterparty detail page, configure:

Control	Behavior
Per-payment limit	Denies a payment above the relationship limit
Daily/monthly limits	Denies aggregate spend above the configured period limit
Require approval	Routes every matching payment to review
Allowed categories	Denies missing or non-allowed payment categories
Expiry	Returns the relationship to review after the configured timestamp

These controls are additive to global counterparty lifecycle gating, organization baselines, and assigned wallet or agent policies. Moving a counterparty to APPROVED or TRUSTED does not weaken a relationship-level approval requirement. For production agents, the first payment attempt to an unknown address creates a DISCOVERED counterparty and relationship before evaluation. The payment is routed to review until an operator advances the counterparty lifecycle. If Conto cannot persist that review record, the request fails closed with COUNTERPARTY_REVIEW_UNAVAILABLE. Review routing never overrides a hard denial. Spend limits, allowlists, sanctions rules, and other deny controls must leave an eligible wallet before counterparty or relationship approval can apply.

Geographic Restrictions OFAC

Use GEOGRAPHIC_RESTRICTION with ISO country codes when a policy needs explicit country gates. Sanctions screening can still block high-risk recipients even when no geographic rule is attached.

{
  "ruleType": "GEOGRAPHIC_RESTRICTION",
  "operator": "IN_LIST",
  "value": "[\"CU\", \"IR\", \"KP\", \"SY\", \"RU\"]",
  "action": "DENY"
}

Contract Allowlist

{
  "name": "Approved Protocols",
  "policyType": "CONTRACT_ALLOWLIST",
  "rules": [
    {
      "ruleType": "CONTRACT_ALLOWLIST",
      "operator": "IN_LIST",
      "value": "{\"protocols\": [\"uniswap\", \"aave\"], \"categories\": [\"DEX\", \"LENDING\"]}",
      "action": "ALLOW"
    }
  ]
}

For contract controls, include targetContractAddress in the payment request so Conto can evaluate the rule against the intended contract interaction. If a rule uses protocol names or categories, register the organization’s known contract classifications through the authenticated contract registry:

GET /api/contract-registry lists entries and supports category, limit, and offset
POST /api/contract-registry saves an address with optional chainId, label, protocolName, and protocolCategory
GET, PATCH, or DELETE /api/contract-registry/{address} reads, updates, or removes one entry

The address is the stable entry identifier. Registry responses return the customer-managed classification fields for that address. Registry changes require policy write permission and are recorded in the organization’s audit history.

x402 Protocol Rules

The dashboard exposes guided X402_SPEND_LIMIT, X402_SERVICE_CONTROL, and X402_ENDPOINT_CONTROL policy types. The API also accepts those policy types directly; use COMPOSITE only when one policy deliberately mixes categories.

{
  "name": "x402 API Guardrails",
  "policyType": "COMPOSITE",
  "rules": [
    {
      "ruleType": "X402_MAX_PER_REQUEST",
      "operator": "LTE",
      "value": "0.10",
      "action": "ALLOW"
    },
    {
      "ruleType": "X402_ALLOWED_SERVICES",
      "operator": "IN_LIST",
      "value": "[\"api.example.com\", \"data.provider.io\"]",
      "action": "ALLOW"
    }
  ]
}

MPP Protocol Rules

The dashboard exposes guided MPP_SPEND_LIMIT, MPP_SERVICE_CONTROL, MPP_ENDPOINT_CONTROL, and MPP_SESSION_LIFECYCLE policy types. Session-lifecycle rules are evaluated only for session intent, and expired sessions do not count toward concurrency.

{
  "name": "MPP Session Guardrails",
  "policyType": "COMPOSITE",
  "rules": [
    {
      "ruleType": "MPP_MAX_SESSION_DEPOSIT",
      "operator": "LTE",
      "value": "25",
      "action": "ALLOW"
    },
    {
      "ruleType": "MPP_MAX_CONCURRENT_SESSIONS",
      "operator": "LTE",
      "value": "3",
      "action": "ALLOW"
    }
  ]
}

Budget Allocations

Use BUDGET_CAP when a wallet or agent needs a bounded allowance for a period, project, or category. Supported periods are DAILY, WEEKLY, MONTHLY, QUARTERLY, and YEARLY. Period boundaries are calculated in UTC.

{
  "ruleType": "BUDGET_CAP",
  "operator": "LTE",
  "value": "{\"amount\": 2500, \"period\": \"MONTHLY\", \"category\": \"infrastructure\"}",
  "action": "ALLOW"
}

Add department, project, or category to the rule value to scope the cap. Conto compares only transactions recorded with the same dimensions and includes pending, confirming, and confirmed spend. The request must pass the matching scope through context.department and context.project; category uses the payment category.

Expiration Policies

Use DATE_RANGE for temporary permissions and BLACKOUT_PERIOD for known no-spend windows.

{
  "ruleType": "DATE_RANGE",
  "operator": "BETWEEN",
  "value": "{\"start\": \"2026-07-01\", \"end\": \"2026-07-31\"}",
  "action": "ALLOW"
}

Time Rules and Timezones

Set an IANA timezone in policy-rule values when a schedule represents local operating hours. TIME_WINDOW and recurring BLACKOUT_PERIOD values accept timezone alongside their existing fields. DAY_OF_WEEK accepts an object containing days and timezone. When timezone is omitted, these policy rules retain the legacy server-local behavior. Supplied values must be valid IANA identifiers; invalid values are rejected on write, and invalid legacy values fail closed during evaluation rather than falling back to server-local time.

[
  {
    "ruleType": "TIME_WINDOW",
    "operator": "BETWEEN",
    "value": {
      "start": "09:00",
      "end": "18:00",
      "timezone": "America/Los_Angeles"
    },
    "action": "ALLOW"
  },
  {
    "ruleType": "DAY_OF_WEEK",
    "operator": "IN_LIST",
    "value": {
      "days": ["Mon", "Tue", "Wed", "Thu", "Fri"],
      "timezone": "America/Los_Angeles"
    },
    "action": "ALLOW"
  }
]

Built-in screening

Conto can combine configurable policies with sanctions and trust checks. Use Trust Scoring for counterparty-aware controls and Trust & Risk Providers for provider setup.

Spend limits

Common amount and budget controls

Time windows

Business hours and blackout windows

Counterparties

Recipient allowlists, blocklists, and trust rules

Recipes

Copy-paste policy setup snippets

Start

Products

Build

Guides

Reference

Changelog

Advanced Policies

Advanced Policies

Agent identity enforcement

Effective policy stack

Rule shape

Operators

Supported Rule Types

Rule Patterns

Registered Commerce Fact Rules

Require review above a threshold

Request a scoped policy change

Limit transaction velocity

Restrict by category

Relationship-scoped payee controls

Geographic Restrictions OFAC

Contract Allowlist

x402 Protocol Rules

MPP Protocol Rules

Budget Allocations

Expiration Policies

Time Rules and Timezones

Built-in screening

Spend limits

Time windows

Counterparties

Recipes

​Advanced Policies

​Agent identity enforcement

​Effective policy stack

​Rule shape

​Operators

​Supported Rule Types

​Rule Patterns

​Registered Commerce Fact Rules

​Require review above a threshold

​Request a scoped policy change

​Limit transaction velocity

​Restrict by category

​Relationship-scoped payee controls

​Geographic Restrictions OFAC

​Contract Allowlist

​x402 Protocol Rules

​MPP Protocol Rules

​Budget Allocations

​Expiration Policies

​Time Rules and Timezones

​Built-in screening

​Related

Spend limits

Time windows

Counterparties

Recipes

Advanced Policies

Agent identity enforcement

Effective policy stack

Rule shape

Operators

Supported Rule Types

Rule Patterns

Registered Commerce Fact Rules

Require review above a threshold

Request a scoped policy change

Limit transaction velocity

Restrict by category

Relationship-scoped payee controls

Geographic Restrictions OFAC

Contract Allowlist

x402 Protocol Rules

MPP Protocol Rules

Budget Allocations

Expiration Policies

Time Rules and Timezones

Built-in screening

Related