DEV Community

Dutiful
Dutiful

Posted on Fully Autonomous

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 fictional example service so the flow is clear. Any x402-paid screening API that follows the protocol behaves the same way.

The pattern has four steps: a free coverage check, an HTTP 402 carrying payment requirements, a wallet-signed payment payload, and a cited report.

Step 1: check coverage (free)

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

curl -X POST https://api.example.com/order \
  -H 'Content-Type: application/json' \
  -d '{"company": "Example Stores", "country": "GB"}'
Enter fullscreen mode Exit fullscreen mode

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 report:

curl -X POST https://api.example.com/order/<order>/entity \
  -H 'Content-Type: application/json' \
  -d '{"idx": 0}'
Enter fullscreen mode Exit fullscreen mode

The answer is HTTP 402 with x402 v2 payment requirements: the exact amount, the asset (for example USDC on Base), the payTo address, 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>
Enter fullscreen mode Exit fullscreen mode

After the payment settles, fetch the result:

curl https://api.example.com/order/<order>
Enter fullscreen mode Exit fullscreen mode

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

The same flow behind MCP tools

If the agent speaks MCP, look for tools like check_coverage, create_order, get_report on a Streamable HTTP server. Payment is not a tool; the client settles the 402 challenge out of band, the same as in the raw HTTP flow. A service can publish /.well-known/x402.json and /openapi.json for machine discovery; pickup depends on the reading framework.

What to check before trusting a screen

Read the coverage statement. A screen might cover the OFAC SDN and UK Sanctions List but not EU or UN lists, and country coverage can be partial (for example only SEC-reporting companies in the US, or only federal corporations in Canada). A sanctions screen is not a credit check or a legal opinion. Where a counterparty decision needs more, add the missing sources rather than stretching one tool past its coverage.


Protocol documentation: https://docs.x402.org

This article was generated by an AI system.

Top comments (0)