Open Banking AIS vs Registry-Based Verification: When Each Wins for B2B Payments

Open banking AIS is the deepest verification method available — when the account holder is in front of you and consents. Registry-based verification is the only method that works when they're not. Most fintech architects framing this as a binary choice end up rebuilding their verification layer twice. The right answer is layered: AIS where you can use it, registry data everywhere else, and one decision tree on top.

Every fintech architect who's built a verification layer eventually runs into the same wall. Open banking AIS gives you bank-grade data with sub-second confidence — but only for users who'll authenticate against their own bank. Registry-based verification covers everyone else — every supplier, every third-party counterparty, every entity you can't ask to log in — but operates at the entity layer, not the account layer. Picking one of them means accepting a known coverage gap. Picking both means building the routing logic that decides which one to call when.

This article is for the architect making that decision. It explains what open banking AIS actually does, where its operational ceiling sits, where registry-based verification fills the gap, and how to design a verification layer that uses both. The framing throughout is technical: schema, latency, consent semantics, fallback chains, audit trails — not marketing claims. Both methods have real, defensible use cases. Neither is the universal answer that some vendor marketing implies.

One thesis runs through the entire piece. AIS and registry verification are not competing technologies — they're complementary layers solving different parts of the same KYB problem. The teams that get verification right architect for both from day one. The teams that don't end up retrofitting the layer they skipped the day they need to verify a counterparty who can't (or won't) authenticate.

What open banking AIS actually does — the technical reality

Account Information Service (AIS) is one of two regulated third-party services defined under PSD2 in the EU and equivalent frameworks elsewhere (Open Banking UK, CFPB Section 1033 in the US, Australia's CDR, Brazil's Open Finance). An AIS provider — called an AISP — is licensed to query a customer's bank account directly with the customer's authenticated consent, returning read-only data: balance, transaction history, registered account holder name, account identifiers, and account metadata.

The technical mechanics matter for any architect designing around AIS:

• OAuth-based authorisation. The customer authenticates against their bank, grants scoped consent to the AISP, and the bank returns a time-bound, revocable access token. No credentials are shared with the AISP; the bank holds them. This is the security model that makes AIS regulator-defensible.
• Strong Customer Authentication (SCA). Multi-factor authentication is required at the bank for the initial consent grant. Under the PSD2 RTS amendment (effective 2023), AISPs gained more flexibility around re-authentication intervals — the default 90-day Strong Customer Authentication renewal can now extend to 180 days for AIS access in supported markets. This matters: shorter renewal cycles meant constant friction for users, breaking the "set and forget" model that B2B use cases need.
• Licensed and registered providers only. AISPs must be authorised by the relevant national regulator (FCA in the UK, BaFin in Germany, etc.). Most platforms don't get their own AISP licence — they use a partner like Plaid, Tink, Yapily, or TrueLayer, which holds the licence and provides the API.
• Bank-side API standardisation varies. The PSD2 RTS sets minimum technical standards, but individual bank implementations diverge in practice. Tink, Plaid, and similar aggregators exist partly to absorb this fragmentation — they normalise the variance behind a single API.
• Data scope is limited to AIS-specific endpoints. Identity (name on account), account metadata (IBAN/sort code, currency, balance), and transaction history. That's it. No company registry data, no beneficial ownership, no corporate group structure.

The argument for AIS-based verification is its data quality. When the customer authenticates against their bank, the data returned is bank-source-of-truth. The name on the account is what the bank holds. The IBAN is what the bank registered. There's no fuzzy matching, no probabilistic confidence score — the bank either confirms or it doesn't.

What registry-based verification actually does

Registry-based verification queries official government business registries — Companies House in the UK, INPI in France, the Federal Register of Companies in Germany, MCA21 in India, Receita Federal in Brazil, the SEC and state Secretary of State filings in the US — to confirm an entity's legal status, registration details, directors, beneficial ownership, and corporate structure. Most modern KYB platforms aggregate access to 100–200+ registries behind a single API, normalising the schema variation across jurisdictions.

The data registry-based verification returns is structurally different from what AIS returns:

• Entity-level identity: legal company name, registration number, registered address, incorporation date, current status (active/dissolved/inactive), and tax identifiers (VAT, EIN, CNPJ, RFC, USCC depending on country).
• Directors and officers: name, date of birth, appointment date, current status, registered address. Typically updated by the registry as the company files changes.
• Shareholders and beneficial owners: for jurisdictions where this is mandatorily disclosed. Coverage varies — UK Companies House has Persons with Significant Control (PSC) data; EU Member States have UBO registers under AMLD6; the US has very limited public BO data after FinCEN's March 2025 interim rule. (See UBO verification in 2026 for the full regulatory picture.)
• Corporate group structure: parent companies, subsidiaries, ultimate parent entities, ownership trees. This is the data that catches shell-company fraud where the account name matches but the entity sits behind layers of holding companies.
• Historical filings: financial statements where filed, registry change history, director appointment and resignation records.

The argument for registry verification is its coverage. Registries exist in 200+ countries. Most B2B verification workflows need to verify suppliers in markets where AIS doesn't exist (Latin America, Asia outside of regulated open banking markets, Africa, parts of the Middle East) or where the counterparty cannot authenticate (your supplier, your supplier's vendor, your platform's seller — anyone not in a direct authenticated relationship with you).

The argument against registry verification is depth at the account layer. Registries can tell you an entity exists, who owns it, who runs it, and what state it's in. They cannot tell you which specific bank account belongs to that entity, or confirm that account is active. For full verification, the registry layer needs a bank-account-verification layer paired with it — either AIS (when the counterparty can authenticate) or non-AIS methods like VoP, CoP, ACH validation, NPCI, or penny drop (when they can't).

The technical comparison: AIS vs registry

The architectural decision comes down to six properties. Lining them up:

The most important distinction isn't on the row labelled "data source" or "coverage" — it's the consent row. AIS requires the counterparty's authenticated consent. Registry verification doesn't. Every other operational consequence flows from that one constraint.

When open banking AIS wins

AIS is the right verification method in five distinct architectural scenarios. The pattern: the user being verified is the same person interacting with your product.

1. Consumer lending and account-aggregation apps

Klarna, Monzo, Wise, Revolut, and similar consumer-facing fintechs use AIS for KYC + income verification on their own customers. The customer is signing up for the product; asking them to authenticate against their bank is part of the natural onboarding flow. The data returned (account name, balance, transaction history) is exactly what's needed for credit decisioning or account aggregation. Registry data would add nothing here — the customer is an individual, not a legal entity.

2. Account funding and instant transfers

SaaS subscription billing, neobank funding, brokerage account funding, payroll deposits to gig workers — any flow where a user is funding their account from their own bank account. AIS confirms the source-of-funds account is real, active, and owned by the user. Some platforms layer AIS over ACH or SEPA to reduce return rates (NSF, account-closed, name-mismatch returns).

3. B2B onboarding where the company representative IS the account holder

Smaller business banking, sole proprietorships, and partnerships where the director or owner is also the operating-account holder. The company representative authenticates against their business banking app; AIS confirms the company bank account belongs to a verified business. Pairing this with a registry check (does the entity exist? is the authenticating person a director?) creates a complete verification stack at onboarding.

4. Real-time creditworthiness assessment

Embedded finance flows — BNPL, working-capital lending to small businesses, dynamic credit limit adjustment — where you need current cash-flow data not historical financials. AIS reveals 12+ months of transactions, payment patterns, and balance volatility. Registry data is too stale to substitute here; financial filings might be 18 months old. AIS gives you yesterday's deposit.

5. PSD3 readiness (forward-looking)

The proposed PSD3 + PSR1 package, working its way through EU legislative processes, expands the AIS scope and introduces stricter standards for bank-side API quality. For fintechs that already have AIS infrastructure, PSD3 will lower friction further; for fintechs that haven't built around AIS yet, it raises the cost of waiting. Greenfield architectures launching now should be designed with AIS as a first-class layer, not retrofitted later.

When registry-based verification wins

Registry verification is the right method in scenarios where the counterparty isn't authenticating against your product — which describes most B2B verification cases.

1. Supplier and vendor verification (the dominant B2B case)

Your AP team is onboarding a new supplier in Germany. The supplier won't log into their bank account every time you want to verify them — and even if they would once, they certainly won't every 90 days. The verification has to happen about the supplier, not with the supplier. Registry verification queries Companies House (UK), Bundesanzeiger (Germany), INPI (France), SEC + state filings (US), MCA21 (India), and so on — confirming the supplier exists, is in good standing, and matches the registration details they supplied. Pair this with a bank-account check (VoP if EU, CoP if UK, ACH validation if US, NPCI if India, penny drop where rails allow) and the workflow is complete without involving the supplier at all.

2. Marketplace seller onboarding at scale

High-volume marketplaces — Shopify, Amazon Business, Alibaba, eBay — onboard thousands of sellers. Requiring each to authenticate via AIS would crater the conversion funnel; sellers want to start listing, not authenticate against banks. Registry verification at signup, paired with simpler bank-account verification (the platform sends a payout, the seller confirms receipt) hits the right balance of friction and verification depth. See KYB verification for marketplaces for the full workflow.

3. Cross-border B2B where AIS doesn't reach

Latin America (Brazil partially excepted via Open Finance), most of Asia outside regulated open banking markets, Africa, Middle East. Your supplier in Mexico, Vietnam, or Nigeria isn't using an AIS-licensed app to authenticate. Registry verification works because the registries exist (SAT in Mexico, MPI in Vietnam, CAC in Nigeria) and your provider can query them via aggregator APIs. See cross-border verification for the country-by-country picture.

4. Continuous monitoring between payments

Ownership changes happen — acquisitions, restructurings, new shareholders, director resignations, company dissolutions — between the initial verification and the next payment. AIS doesn't watch for these (it's a point-in-time bank-account check; it doesn't surface that the company was acquired by a different entity). Registry data is queryable continuously; modern platforms push webhook alerts when registry data changes. This is what mature compliance programs run as an always-on layer beneath their onboarding-time verifications.

5. Beneficial ownership and corporate group depth

AIS returns the name on the bank account. It doesn't tell you that the company holding that account is owned through three layers of holding companies, two of which are in offshore jurisdictions. For shell-company fraud detection, sanctioned-UBO screening, AMLR-compliant beneficial ownership verification — registry data is the only source. AIS is silent on this layer.

The architecture: how to combine them in production

The verification layer that holds up in production routes between AIS and registry-based verification based on three runtime decisions: who's being verified, can they authenticate, and what depth do you need.

The routing logic

Most verification platforms that ship at scale implement something like this pseudocode at the entry point:

The unified response schema

The architectural shift that matters most: your downstream systems shouldn't have to know which method ran underneath. Whether the verification call went to AIS, registry, both, or a fallback method, the response should normalise into one schema with consistent field names and status codes. Architects who skip this step end up with verification logic scattered across application code — different branches for AIS responses, different branches for registry responses, different branches for hybrid flows. It becomes unmaintainable.

The minimum normalised response shape for B2B verification:

• entity — name, registration_number, status, jurisdiction, source (registry vs AIS), confidence_score
• bank_account — iban_or_local_identifier, name_match (match/close_match/no_match), source (rail used), verified_at
• beneficial_owners — array of UBOs with status flag (verified/partial/unknown), source (registry name)
• verification_result — overall pass/review/fail with reason codes
• audit_trail — methods used, timestamps, source-attribution for every data point

An architect designing this layer can pick any underlying provider for any individual capability — AISP partner, registry aggregator, bank-rail-specific verifier — and as long as the responses normalise into this shape, the rest of the system stays stable. This is what unified-API verification platforms like MonitorPay are designed to deliver: one schema covering every method, so your AP system, fraud platform, or onboarding workflow has one decision tree, not seven.

Fallback chains and graceful degradation

Production verification layers fail in predictable ways: bank API outages, AIS consent expiry, registry rate limiting, regional bank-rail incidents. The architecture needs a fallback chain that degrades gracefully:

• Primary method fails → log the specific failure code, attempt secondary method, flag the audit trail with both attempts
• Both methods fail → return a "review required" status with manual escalation path, never auto-approve
• One method succeeds, the other times out → return partial verification with explicit gap flagged

This is more boring than it sounds, but it's where verification systems actually break in production. The wins go to the architecture that handles failure deterministically, not the one with the cleanest happy path.

What this looks like in practice — a scenario

An anonymised scenario, composite from real B2B verification flows, that shows how the dual-layer architecture handles a typical verification request.

The setup. A French fintech offering B2B payment services is onboarding a new corporate client — "Acme GmbH," a German manufacturer planning to use the fintech's platform to pay suppliers across Europe. The onboarding requires verifying Acme itself (entity-level), confirming the bank account they've supplied for funding (account-level), and identifying beneficial owners for AMLR compliance (UBO-level). Acme's CFO is the contact person, but won't be doing the verification flow personally — that's handled by the fintech's compliance team.

Step 1 — Routing decision. The verification request hits the fintech's routing layer. Question 1: natural person? No, Acme is a legal entity. Question 2: will the counterparty authenticate? No, the CFO isn't running the verification flow. The routing layer skips the AIS-primary path entirely and routes to the registry + bank-rail combination.

Step 2 — Registry call. The registry aggregator queries the German Handelsregister via the platform's API. Response in under 800ms: Acme GmbH exists, registered 2014, status active, registered in Frankfurt am Main, VAT ID confirmed, two directors listed. UBO data: 25% threshold met by a single natural person (the founder), no offshore structures, no sanctions hits. The entity-level verification passes.

Step 3 — Bank-rail call. The supplied IBAN is German. The routing layer dispatches to the EU VoP rail (operational since October 2025). Response: Match. The account holder name registered at the receiving bank exactly matches Acme GmbH's legal name. Bank-account verification passes.

Step 4 — Unified response. The verification layer normalises both responses into one schema. Entity verified (source: Handelsregister). Bank account verified (source: VoP). Beneficial owners identified (source: Handelsregister, UBO register). Overall result: verified. Total elapsed time: 1.2 seconds. Audit trail logs both method calls with timestamps and source attribution.

Step 5 — Continuous monitoring registered. The fintech's compliance policy classifies Acme as a high-value relationship. The verification layer subscribes to webhook alerts on both the Handelsregister entry (for registry changes — director appointments, registration status updates, dissolution) and the bank account (for status changes). The compliance team will be notified within hours if anything material changes between payments.

The architectural point. AIS was never invoked in this flow — and shouldn't have been. The counterparty's CFO had no reason to authenticate against their corporate bank. Registry verification handled the entity question; VoP handled the account question; the unified response gave the fintech's onboarding flow one decision tree to evaluate. If the fintech had architected around AIS as the primary method, this onboarding would have stalled at step 1 — and Acme would likely have churned out of the funnel before completing it.

Common anti-patterns to avoid

Three architectural mistakes that show up repeatedly in fintech verification layers.

1. Treating AIS as a B2B vendor verification method

The most common architectural mistake. AIS requires the account holder's authenticated consent. A vendor or supplier won't authenticate against their own bank every time you onboard them or process a bank-detail change. Teams that try to make AIS the primary B2B verification method discover this when their supplier acquisition stalls: vendors view the consent flow as friction, slow it down by weeks, and often drop out entirely. The fix is structural — use AIS where the user IS your customer, use registry + bank-level verification where the user is a counterparty.

2. Treating registry verification as a substitute for AIS

The opposite mistake. A consumer-fintech architect skips AIS because "we already have registry data through our KYB partner." Registry data confirms the entity exists; it doesn't tell you that the specific bank account belongs to the entity. For account-funding flows, embedded lending, and any case where you need real-time financial data on your own customer, registry is too shallow. Use AIS for the account-layer depth, registry for the entity-layer context.

3. Skipping the response normalisation layer

Architectures that wire AIS responses directly into business logic in one code path and registry responses into business logic in another path become unmaintainable within 12-18 months. The team can't add a new verification method without rewriting the downstream consumers. The team can't swap an AISP partner without re-testing every downstream flow. Normalise responses at the verification-layer boundary — what enters business logic should be method-agnostic.

4. Treating consent expiry as a UX problem instead of an architecture problem

The PSD2 RTS amendment extending re-authentication to 180 days helped, but consent still expires. Architectures that handle this client-side ("we'll prompt the user to re-authenticate") create UX cliffs every six months for products with long-running data dependencies (account aggregation, embedded credit). The fix: design for stale-data tolerance at the data model level. Know which verifications were AIS-sourced vs registry-sourced, and have a routing rule for when AIS data ages out (typically: fall back to less-deep registry data + re-prompt only when the user is naturally in the product).

5. Building AIS first, then realising you need registry

A predictable evolution we see: consumer fintech ships with AIS-first architecture, hits product-market fit, starts adding B2B use cases or expanding into markets without AIS coverage, and discovers their verification layer can't handle non-authenticating counterparties. The retrofit costs more than the original build — because business logic has been written assuming AIS-shaped responses. The lesson for greenfield architectures: design the verification layer for both methods from the start, even if you're only using one initially.

The implementation checklist — what to build, in order

The architecture this article describes can be built incrementally. For a greenfield verification layer, the order below minimises rework. For a retrofit, treat it as a gap analysis — find the steps your current architecture skips.

1. Define the unified response schema first. Before integrating any provider, write the schema your downstream systems will consume. entity, bank_account, beneficial_owners, verification_result, audit_trail. Treat this as your verification-layer contract; everything else conforms to it. Skipping this step is the #1 cause of unmaintainable verification code.
2. Integrate the registry aggregator. This is the universal backstop layer — needed regardless of which other methods you choose. Pick one with broad country coverage (200+ jurisdictions) and a normalised API. This becomes your default verification path for any non-AIS-authenticating counterparty.
3. Add the bank-rail verification layer. VoP for EU SEPA, CoP for UK Faster Payments, ACH validation for US, NPCI for India, and equivalent rail-appropriate methods for other markets. Most platforms surface these as separate endpoints or as part of a verification provider's broader API.
4. Integrate the AIS partner — if your product needs it. If you have consumer flows where the user IS the account holder (account funding, BNPL, embedded credit), integrate an AISP partner (Plaid, Tink, Yapily, TrueLayer). If your product is purely B2B counterparty verification, this step is optional.
5. Build the routing logic. The decision tree from Figure 2 lives here. Implement it as a pure function — given verification context (counterparty type, market, use case), return the ordered list of methods to call. Test the routing in isolation before wiring it to providers.
6. Wire up the fallback chains. Primary method fails → log specific failure → attempt secondary method → return partial verification if both fail with explicit gap flagged. Production verification systems break here in unexpected ways; budget time for failure-mode testing.
7. Subscribe to webhook alerts for continuous monitoring. Registry changes, bank account status updates, sanctions list updates. For high-value relationships, this is the layer that catches what point-in-time verification misses. See why one-time verification fails.
8. Standardise the audit trail. Every verification call must produce a structured log with method used, source attribution, timestamp, and outcome. Auditors, regulators, and your own compliance team will thank you. Under EU AMLR (applicable from July 2027) this is no longer optional.

The pattern that emerges: build the registry layer first, then layer everything else on top. Registry verification is the universal backstop; everything else is jurisdiction-specific or use-case-specific enhancement. Teams that build AIS-first regret it within 18 months when their B2B expansion stalls. Teams that build registry-first can add AIS, bank rails, and continuous monitoring incrementally without retrofitting business logic.

What PSD3 changes for the verification architecture

PSD3 — the proposed successor to PSD2 — is the regulatory question fintech CTOs are actually asking in 2026. The EU Commission published the PSD3 proposal in June 2023 alongside a new Payment Services Regulation (PSR1); both are still working through legislative processes. Application is expected from late 2026 onwards for member-state transposition, with PSR1 directly applicable across the EU.

Three changes matter most for verification architecture:

1. Stronger bank-side API obligations

PSD2's original technical standards (RTS) gave banks significant latitude in how they implemented AIS access. The result was fragmentation — different bank APIs returned data in different formats, with different reliability characteristics, requiring aggregators like Plaid, Tink, and Yapily to absorb the variation. PSD3 + PSR1 tightens this. Banks face stricter performance, availability, and data-quality requirements. For AIS-based verification, this lowers operational friction: more banks, more reliable connections, more consistent data. For architects designing now, it's a tailwind on the AIS layer.

2. Expanded AIS use cases (including some B2B scenarios)

PSD3 explicitly acknowledges that AIS is being used beyond the original consumer-fintech use cases — including for risk-scoring, credit-decisioning, and increasingly for B2B verification flows. The framework expands the regulated scope to formalise these uses. This doesn't change the underlying consent model — AIS still requires the account holder's authenticated permission — but it does mean B2B platforms can use AIS for richer use cases without ambiguity about regulatory status.

3. Tighter fraud-prevention obligations on PSPs

PSR1 introduces stronger fraud-prevention obligations across all regulated payment service providers, with verification-layer implications. The new regime expands liability for PSPs in fraud cases where insufficient verification was performed — effectively raising the cost of running thin verification layers. Combined with the EU Instant Payments Regulation's VoP requirements (already in force since October 2025) and AMLR's UBO verification obligations (applicable from July 2027), the regulatory direction is consistent: verification is moving from "good practice" to "documented compliance obligation" across the board.

The architectural takeaway for greenfield builds in 2026: design the verification layer for both AIS and registry data from day one. PSD3 doesn't change which method wins for which use case, but it raises the cost of having only one. Architectures that treat AIS and registry as complementary will absorb PSD3 changes with config updates. Architectures that hard-code around one method will need structural rebuilds.

Frequently Asked Questions