Screen a beneficiary IBAN before your agent pays it

If an agent can move money, it can move money to the wrong place. Before an autonomous workflow disburses to an IBAN it was handed — by a user, a vendor feed, an invoice it parsed — it should establish that the issuing bank is not sanctioned and the jurisdiction is not embargoed. That check is a single paid call: GET /iban/screen. This article shows where it belongs in the x402 loop and how to read its verdict honestly.

The problem: a payable IBAN is not a safe IBAN

A structurally valid IBAN passes its mod-97 checksum and nothing more. Validity says the number is well-formed; it says nothing about who sits behind it. An agent that resolves an IBAN to a bank and pays it can still be routing funds to an institution on an OFAC, EU, or UN sanctions list, or into a jurisdiction under an embargo. For any agent acting in a KYB or onboarding context, clearing the beneficiary is not optional — and a human is not in the loop to catch it.

The data needed to make that call — current sanctions registries and jurisdiction risk lists (FATF black/grey, EU-AML, embargoes) — is exactly the kind of bulky, frequently-updated public data an LLM cannot reliably hold in its weights. It is a good fit for a pay-per-call lookup against a fresh snapshot.

The check: one call, one risk band

GET /iban/screen takes an iban and returns a ScreenResult: the resolved bank and BIC, whether that bank/BIC matched a sanctions list, the account country’s jurisdiction level, and an aggregated risk band:

The band is the field your control flow keys on: gate on prohibited, escalate high/elevated to whatever policy or human review you define, and treat unknown as not cleared rather than cleared — the service deliberately refuses to assert clear without data behind it.

Where it sits in the x402 loop

Screening is a gate placed before the disbursement, not a replacement for it. The agent’s loop becomes:

1. Resolve the IBAN if you need bank/BIC details (GET /iban/resolve).
2. Screen it — GET /iban/screen — and read risk.
3. Branch: stop on prohibited, escalate the risky bands, proceed on clear.
4. Pay the actual beneficiary through your own rails.

Each paid call follows the same x402 pattern as every Invoket endpoint: call, receive the 402, sign the chosen rail, replay. The Quickstart walks the whole discover → 402 → pay → replay cycle with runnable snippets. The price and accepted rails are not pinned here — they are served live by the catalog; see the endpoint reference for the current figure.

Per the x402 golden rule, the agent pays for the answer to its question. “This jurisdiction is high-risk” and “this IBAN is invalid” are both successful answers — they return 200. The 4xx range is reserved for requests the service genuinely cannot answer.

Screening a list, not just one IBAN

When the input is a batch — onboarding a vendor file, clearing a payout run — POST /iban/screen/batch screens many IBANs under one x402 settlement instead of one settlement per row, which is the difference between a workable pre-payment gate and a per-item toll.

What this check does not do

Be precise about scope, because compliance language is easy to overclaim:

• It screens the bank/BIC against sanctions lists and the jurisdiction risk — it does not screen the account holder’s name. Sanctions/PEP name matching is Verification of Payee, a separate endpoint (GET /iban/verify-name).
• A clear verdict means no signal was found on the covered lists as of the snapshot date returned in provenance.freshness. It is not a legal compliance opinion and does not discharge your own AML obligations.

Used for what it is — a fast, honest, pre-payment gate on the bank and the jurisdiction — it lets an autonomous agent refuse the payments it should refuse, before the money leaves. For the full field reference and error codes, see the GET /iban/screen documentation; for how agents discover and call Invoket endpoints, see For agents.