Dutiful

All guides

How an agent checks a counterparty against the OFAC SDN list before paying

An agent that transacts with counterparties on its own needs a sanctions check it can call like any other tool: structured input, structured output, sources it can show. This post walks through the general pattern for doing that over the x402 payment protocol, with a live service as the worked example so every step is reproducible.

The pattern has four steps: a free coverage check, an HTTP 402 carrying payment requirements, a wallet-signed payment payload, and a cited report. The worked example is a company-report API that screens against the OFAC SDN and UK Sanctions List plus a news and web scan, with each finding cited. It covers 12 registries (US coverage is SEC-reporting companies; Canada is federal corporations). EU and UN lists are not screened.

Step 1: check coverage (free)

Before paying anything, check that the counterparty is in a covered registry:

curl -X POST https://dutiful.work/api/order \
  -H 'Content-Type: application/json' \
  -d '{"company": "Sainsbury", "country": "GB"}'

The response is JSON candidates with registry identifiers. No match means stop, and nothing was spent.

Step 2: read the payment requirements (402)

Pick a candidate and request the entity report:

curl -X POST https://dutiful.work/api/order/<order>/entity \
  -H 'Content-Type: application/json' \
  -d '{"idx": 0}'

The answer is HTTP 402 with x402 v2 payment requirements: the exact USDC amount, the payTo address on Base, and the deadline. No account and no API key; the payment is one EIP-3009 transfer authorization.

Step 3: sign and submit the payment

This step needs wallet code, not curl. An x402 client library (for example the x402 fetch wrapper) reads the 402 requirements, signs the EIP-3009 authorization with the agent's wallet, and resubmits the request with the payment payload:

PAYMENT-SIGNATURE: <base64-encoded x402 payment payload>

After the payment settles, fetch the result:

curl https://dutiful.work/api/order/<order>

The report carries the registry profile, officers and owners where published, and the sanctions and news screen, every finding with its source, so downstream systems or humans can verify each line instead of trusting a score.

The same flow behind MCP tools

If the agent speaks MCP, coverage check, order creation, and report retrieval are three tools on one Streamable HTTP server: check_coverage, create_order, get_report. Payment is not a tool; the client settles the 402 challenge out of band, the same as in the raw HTTP flow. The server card is at /.well-known/mcp/server-card.json, and machine discovery works through /.well-known/x402.json and /openapi.json.

What the output looks like

Two public sample reports show the exact format an agent receives: J Sainsbury plc and Vodafone. Cited registry facts, officer data, and the sanctions screen result with its sources.

What this does not do

A screen of this kind covers the OFAC SDN and UK Sanctions List plus a news and web scan. It does not screen EU or UN lists, and it is not a credit check or a legal opinion. Where a counterparty decision needs those, add the missing sources rather than stretching one tool past its coverage.

Reference links: developers, x402 protocol docs, sample reports.

Run the free coverage check · See a sample report