# Sanctions-screen a beneficiary IBAN before an agent pays it

> IBAN sanctions screening in one paid call: the issuing bank cleared against the OFAC, EU and UN lists and its jurisdiction rated for risk — plus how to read that verdict without overclaiming.

Published 2026-06-24 · Updated 2026-08-15 · HTML version: https://invoket.com/blog/screen-an-iban-before-an-agent-pays

---

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`](/docs/api/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**:

| `risk`       | What it means for your agent                                     |
|--------------|------------------------------------------------------------------|
| `prohibited` | Sanctioned bank/BIC **or** an embargoed jurisdiction — do not pay |
| `high`       | High-risk jurisdiction (FATF black / EU-AML), bank not sanctioned |
| `elevated`   | Monitored jurisdiction (FATF grey) — apply your own policy        |
| `clear`      | No signal on the covered lists                                   |
| `unknown`    | Valid IBAN, but bank/BIC or country outside coverage — no claim   |

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`](/docs/api/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](/docs/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](https://api.invoket.com/catalog); see the
[endpoint reference](/docs/api/iban-screen) 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`](/docs/api/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 out of scope for this endpoint.
- 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](/docs/api/iban-screen); for how agents
discover and call Invoket endpoints, see [For agents](/docs/for-agents).