Home/Offers/Banking, Payments & Credit/Bank Account Verification API

Banking, Payments & Credit

Bank Account Verification API

Every payout you make to an unverified account is a bet that somebody typed sixteen digits correctly and honestly. Most of the time they did.

Payment service providers
Lenders
Payroll platforms
Marketplaces
Insurers

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

The failure modes split cleanly in two. There are mistakes — a transposed digit, a closed account, a sort code that belongs to a branch that merged three years ago — which cost you a failed payment, a support ticket and a reconciliation entry. And there is fraud, where the account is real and open and simply does not belong to the person on the invoice.

Mandate and payout fraud works precisely because account number validation does not check ownership. A modulus check tells you the digits are structurally plausible. It tells you nothing about whose name is on the account, which is the only fact that matters when someone emails your accounts payable team a new set of bank details.

The verification methods that do establish ownership are available in most developed markets, but they are fragmented and inconsistent. Open banking account information gives you the strongest evidence where the account holder will authenticate. Confirmation-of-payee style name checks exist in some schemes and not others. Micro-deposit verification works almost everywhere and takes two days. Building one API over all of them, with a clear statement of which evidence was obtained, is the useful piece of work.

Who buys this

Payment service providers, Lenders, Payroll platforms, Marketplaces, Insurers

Category: Banking, Payments & Credit

What the API returns

What comes back

Account existence and open/closed status where the scheme supports the check
Account holder name match result, with a similarity grade rather than a bare yes or no
Bank, branch and scheme routing details resolved from the account identifier
Supported payment schemes and currencies for that account
Verification method actually used, and the strength of evidence it provides
Structural validation including modulus, IBAN checksum and country-specific format rules
Reusable verification token so a verified account need not be re-verified on every payout
Audit record of what was checked, against which source, and when

Endpoints

Method	Path	Returns
POST	/v1/accounts/validate	Structural and routing validation without contacting the bank
POST	/v1/accounts/verify	Full verification including ownership evidence where available
POST	/v1/accounts/name-check	Name match against the account holder of record
POST	/v1/accounts/microdeposit	Initiate and later confirm a micro-deposit verification
GET	/v1/verifications/{id}	Retrieve a stored verification result and its evidence
GET	/v1/coverage	Which verification methods are available per country and scheme

Request and response

illustrative

Request

{
  "account": {
    "country": "GB",
    "sort_code": "20-45-77",
    "account_number": "41029834"
  },
  "claimed_holder": { "type": "business", "name": "Northgate Logistics Ltd" },
  "methods": ["name_check", "open_banking"],
  "reference": "payout_setup_55120"
}

Response

{
  "verification_id": "vrf_2026102109482210",
  "status": "verified",
  "method_used": "scheme_name_check",
  "evidence_strength": "strong",
  "account": {
    "exists": true,
    "status": "open",
    "bank_name": "Example Bank plc",
    "branch_city": "Manchester",
    "schemes": ["faster_payments", "bacs", "chaps"],
    "currency": "GBP",
    "accepts_credits": true
  },
  "name_match": {
    "result": "close_match",
    "grade": 0.91,
    "matched_against": "NORTHGATE LOGISTICS LTD",
    "note": "Legal suffix abbreviated; no other difference detected"
  },
  "structural": { "modulus_check": "pass", "format": "valid" },
  "reusable_token": "acct_tok_9f41c7",
  "token_expires_at": "2027-04-21T09:48:22Z",
  "checked_at": "2026-10-21T09:48:22Z"
}

Where the data comes from

Open banking account information APIs	The strongest ownership evidence available, because the account holder authenticates directly with their bank — but it requires their consent and a regulated permission to access
Scheme name-verification services	Confirmation-of-payee style checks where the national scheme operates one; coverage varies considerably by country
Bank and branch reference data	Sort code, routing number, BIC and IBAN directories, which resolve an identifier to an institution and its supported schemes
Modulus and checksum rule sets	Published national validation rules; cheap, instant and they catch most typing errors before any network call
Your own payment outcome history	Failed and returned payments with their reason codes, which is the best available signal on which accounts are quietly stale
Micro-deposit settlement confirmations	Your own banking rails, used as the fallback method where no ownership check exists in that market

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

A method-selection layer that picks the strongest available verification per country and account type, rather than forcing one method everywhere
Name matching built for institutional naming rather than generic string similarity: legal suffix handling, transliteration, initials, trading-name variants and known bank truncation behaviour
Graded match output with a configurable acceptance threshold, because a close match on a business name is a policy decision and not a technical one
Structural validation run first and locally, so obvious typing errors never consume a paid or rate-limited network check
Verification token issuance with an expiry policy you set, so repeat payouts to a known account skip re-verification without the result going stale indefinitely
Negative-outcome learning from your returned-payment reason codes, which surfaces accounts that validate cleanly but are no longer usable
Per-scheme latency and availability monitoring, since these dependencies fail independently and your flow needs to degrade predictably
Full evidence retention per verification, versioned, so a disputed payout can be reconstructed exactly as it was approved

What it changes for the business

Fewer failed payouts

Structural and status checks catch the transposed digits and closed accounts before the payment file is submitted.

Mandate fraud resistance

A name check at the point of adding or changing bank details is the single most effective control against invoice redirection.

Lower support load

Failed payments generate disproportionate support contact, and most of those failures are preventable at setup.

Evidence for disputes

A retained verification record with the method and evidence strength is what a chargeback or liability argument actually turns on.

How it fits into your product

How it embeds

Called at the point a customer or supplier adds or edits bank details, which is where the fraud control belongs
Reusable tokens so your payout service checks a token rather than re-verifying an account on every run
Graceful degradation: when a scheme check is unavailable the response says so and names the weaker method used instead
Webhooks for asynchronous methods such as micro-deposits, which complete over one to three business days
Coverage endpoint your product can query to decide whether to show a verification step for a given country at all
Deployment inside your infrastructure where account identifiers must not leave your environment

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 12 weeks

Discovery and data review

Weeks 1–2

We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.

Architecture and prototype

Weeks 3–4

You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.

Production build

Weeks 5–10

Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.

Integration and handover

Weeks 11–12

We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Can you verify ownership in every country?

No. Strong ownership verification depends on either an open banking regime the account holder will authenticate through, or a national name-check scheme. Plenty of markets have neither. There the honest answer is structural validation plus micro-deposits, which takes days and proves control rather than legal ownership. The coverage endpoint tells you which markets fall into which bucket before you design your flow.

Does a close name match mean we should pay?

That is your policy decision and we would not bury it in a model. The API returns a graded match with the specific difference it found — abbreviated suffix, missing middle name, trading name versus registered name. You set the acceptance threshold and the review path, and both are configurable per market and per payout value.

Does open banking access require a licence?

Yes, in every regime we would build against. Either you hold the regulated permission yourself or the integration runs through a licensed provider. That is a procurement and legal question we flag in discovery, because it affects architecture and timeline more than anything technical.

How long should a verification stay valid?

Accounts close, businesses change banks and mandates get redirected, so an indefinite token is a liability. We would normally recommend six to twelve months for low-value recurring payouts and re-verification on any change of details or any unusual payout value. The expiry policy is yours to set; we just will not default it to never.

What does this cost per check?

It varies by method and that is the main reason method selection matters. Structural validation is effectively free. Scheme name checks and open banking calls carry per-call costs set by the provider or scheme, not by us. The design deliberately spends the cheap checks first so the paid ones are only used where they change the answer.

All Banking, Payments & Credit offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers