code402.dev / for payment platforms

Validate bank details before you send money

If your platform moves money for other people, a mistyped or impossible bank detail is not a cosmetic bug — it is a failed payout, a reversal, a support ticket, or a fraud loss. The checks below are deterministic: the same input always produces the same verdict, and every response explains why. No model, no guessing, no scraping.

What we check

CheckMethodCatches
IBANISO 13616 + ISO 7064 MOD-97-10transposed or mistyped digits, impossible country/length combinations
SWIFT/BICISO 9362 structuremalformed bank, country or branch codes
ABA routingFedwire/ACH (3,7,1) mod-10 checksumrouting numbers that cannot be valid
LEIISO 17442 + MOD-97-10 check digitsbad entity identifiers on counterparty records
VATMOD-97 familymalformed tax identifiers on invoices
Sanctions (address/jurisdiction)OFAC SDN digital-currency address list + sanctioned jurisdictionsknown-listed payout addresses and restricted jurisdictions
What this is not. These are structural checks. They do not prove an account exists, is open, or belongs to the name on the invoice. We do not do name-based or fuzzy sanctions screening, and our sanctions screen is address- and jurisdiction-level only — a no-match result is not a sanctions clearance. Every response states its own scope and whether the check was checksum-verifiable or format-only. Treat this as one cheap gate before your own controls, never as a replacement for them.

Why a per-call check rather than a platform contract

Integrate in an afternoon

REST, MCP, or the SDKs. The first calls each day are free, so you can run this against your worst historical samples before committing to anything.

curl -X POST https://hcrb.in/v1/tools/iban-check/call \
  -H 'content-type: application/json' \
  -d '{"input":{"iban":"GB29NWBK60161331926819"}}'
Try a free callPay per call in USDC