Skip to main content

Configuration (API)

Create a complete COUNTERPARTY policy with its rules in one request:

Rule types

ALLOWED_COUNTERPARTIES

Only allow payments to specific wallet addresses (allowlist):
Any recipient not in the list is denied. Address matching is case-insensitive.

BLOCKED_COUNTERPARTIES

Block payments to specific addresses:

TRUST_SCORE

TRUST_SCORE compares the payee’s Conto network trust score, from 0 to 1. An address with no network history scores 0.5, and so does every address when network sharing is off. A threshold above 0.5 therefore denies every first payment to a new payee. This rule allows new payees and denies payees whose network score has dropped below 0.5:
The network score weighs success rate (30%), transaction volume (20%), number of organizations (20%), flags and blocks (20%), and account age (10%). The per-organization score on the counterparty page uses different weights and is not what TRUST_SCORE reads. See Trust Scoring.
Conto looks up both values during evaluation. TRUST_SCORE reads the network score and COUNTERPARTY_STATUS reads your organization’s trust level for the payee. The payment request does not need to include either value.

COUNTERPARTY_STATUS

Require a specific trust level (TRUSTED, VERIFIED, UNKNOWN, SUSPICIOUS, or BLOCKED):
See how trust levels are assigned.

Card payments

A card payment has no wallet address. On a card, an ALLOWED_COUNTERPARTIES or BLOCKED_COUNTERPARTIES entry matches the merchant by the card network’s merchant ID, by the merchant name (case and extra spaces are ignored), or by domain. A domain covers the store’s checkout domain and every subdomain of it, so example.com covers checkout.example.com. Wallet addresses, EINs, DUNS numbers, and LEIs never match a card merchant, so a list of only those does not apply to card payments. TRUST_SCORE, COUNTERPARTY_STATUS, and COUNTERPARTY_APPROVAL_STATUS do not apply to card payments. Your counterparty records also apply to a card purchase when a counterparty’s domain is the store’s checkout domain or a parent of it, or when its name matches the merchant name. A BLOCKED counterparty denies the purchase. A counterparty that is PENDING_REVIEW, MONITORED, or QUARANTINED, or DISCOVERED when the agent is a production agent, sends it to approval, and so does a relationship with the agent that requires approval or has expired. Relationship spend limits do not apply to card payments.

Relationship spend limits

Each agent’s relationship with a counterparty can carry its own limits. Set them on the counterparty detail page: open the Agents tab and click Controls next to the agent. Leave a field empty for no cap. A limit of 0 blocks every payment to that counterparty. These limits are checked after the trust and block checks and before the final approval decision. If a counterparty has a $500/day limit, the evaluator adds up the agent’s confirming and confirmed transactions to that address today, across all of its wallets, payments to it that are executing or approved but unconfirmed, and checkout purchases on its domain or a subdomain while their spend is held or after they are paid. It blocks the payment if the new amount would exceed the limit. POST /api/relationships accepts a signed-in dashboard session, not an API key.

Managing counterparties

Add a counterparty

Block a counterparty

Block a counterparty from its page in the dashboard. The status endpoint accepts a signed-in session, not an API key.

Network intelligence & external providers

Conto’s network intelligence shares risk signals across organizations. Solana wallets with no Conto network history get their Fairscale onchain reputation score. See external enrichment and compliance signals for all available providers.

Best practices

Begin with a small list of trusted vendors:
As you verify new vendors, move them through the lifecycle:
  1. New vendor: DISCOVERED. A production agent’s payments to it wait for review.
  2. After review: APPROVED
  3. After history: TRUSTED