Open Banking Vendor Due Diligence: What to Verify Before You Sign

Open banking vendor due diligence is the evidence pass you run after a promising demo and before legal sends the MSA. It turns marketing claims into test results: institution-level coverage on your mandatory bank list, sandbox behaviour on failure paths, written pricing for failed attempts, subprocessors, and exit terms if the vendor merges or deprioritises your corridor. Skipping that pass is how teams discover missing banks, surprise platform fees, or weak webhook SLAs only after go-live. This guide lists what payments, product, and procurement should verify — and how it differs from a formal open banking RFP.

Open banking vendor due diligence: Structured verification that a regulated provider can deliver your pay-by-bank, verification, or recurring flows — including bank coverage, sandbox evidence, commercial terms, security artefacts, and contract exit rights — before you sign or renew.

What is open banking vendor due diligence?

It is pre-contract verification that a provider’s rails match your real customers, volumes, and ops model — not a repeat of their sales deck. You collect written answers, run engineering-led sandbox tests, and score gaps against your mandatory bank list and use cases. Due diligence usually happens on two to four finalists after how to shortlist open banking providers; an RFP may follow or run in parallel depending on group policy.

Due diligence differs from day-to-day open banking merchant onboarding (your KYC with the provider) and from high-level open banking provider comparison frameworks. The output is a signed-off evidence pack procurement can attach to the contract — or a decision to walk away before integration spend.

Why does vendor due diligence matter more in 2026?

Consolidation and scheme launches change vendor risk faster than annual renewals — ownership shifts, roadmap reprioritisation, and new UK commercial VRP rules all land in the same budget cycle.

Three forces buyers should bake into diligence now:

Provider ownership and roadmap

The Mollie–GoCardless combination (completed September 2026) shows how quickly “independent pay-by-bank specialist” status can change. Diligence should capture change-of-control clauses, written integration timelines, and pricing hold language — themes expanded in Mollie GoCardless acquisition: buyer actions, but your diligence pack should still stand alone for any vendor.

UK commercial VRP and UKPI participation

UK account-to-account recurring payments now run under industry scheme governance. The FCA and PSR prioritisation statement on UKPI commercial VRP describes Phase 1/Wave 1 scope and interim commercial arrangements ahead of longer-term legislation. If you need UK recurring collection, ask vendors whether they participate in the UK Payments Initiative scheme (shareholder or participant), which use cases are live in sandbox, and how purchase protection and pricing evolve into Wave 2 — without assuming parity with card chargeback models. Operational prep belongs with UKPI Wave 2 recurring payments; diligence proves the vendor can execute your wave.

Commercial model transparency

UK Finance’s industry proposal for Wave 2 cVRP commercial models makes clear that e-commerce recurring fees, purchase protection, and ad valorem pricing are still being finalised. Diligence should document what you pay today per successful and failed event, not slide-deck “competitive” language. Cross-check fee shapes against open banking pricing models so finance models failed payments and platform minimums explicitly.

What coverage evidence should you require?

Demand institution-level proof on your mandatory bank list — not a country tick-box or “500+ banks” headline.

Require in writing:

• Exportable institution list with PIS and AIS flags separate per bank
• Last-updated date and process when an ASPSP degrades or leaves the network
• Mobile deep-link behaviour for your top five institutions (screenshots or sandbox video)
• Explicit “no” rows for banks you know matter — gaps are acceptable if documented early

Run a coverage workshop with your customer success or fraud team: list the IBAN prefixes and brands you see in production data. Compare to the vendor matrix. A gap on one dominant bank can invalidate an otherwise attractive per-transaction rate.

For multi-corridor products, tie diligence to open banking UK vs EU assumptions — licensing footprint and bank connectivity are not interchangeable across markets.

Which sandbox tests should engineering own?

Engineering should drive the agenda — happy path alone is not diligence. Schedule a session where your engineers trigger failures and measure webhook latency, not a slideware demo.

Minimum acceptance tests:

Test	Pass criteria
Successful pay or verification	Consent → authorisation → webhook → idempotent retry
User cancel / timeout	Clear error code; no duplicate ledger post
Insufficient funds or limit breach	Customer-safe message; finance can reconcile
Expired consent	Re-auth flow documented; ops runbook supplied
Refund or reversal (if in scope)	Matching reference on webhook and statement

Capture timestamps and raw webhook payloads in the evidence pack. If the vendor cannot reproduce your stack (Shopify plugin, custom checkout, batch verification file), note the integration risk before sign-off.

Teams still deciding build depth should align sandbox scope with build vs buy open banking — diligence on a partner is cheaper than discovering orchestration gaps after you committed to in-house routing.

What commercial and legal items prevent surprise cost?

Written pricing for failure modes and minimums — not “contact sales after launch.”

Collect:

• Fee per successful initiation, verification, or data call
• Fees for failed, abandoned, or duplicate attempts if any
• Monthly minimums, platform fees, and implementation charges
• Price change notice period and CPI or indexation clauses
• Data residency and subprocessors (EU-only if required)
• Exit: termination for convenience, data return, transition assistance, and notice if the vendor is acquired

Ask how pricing shifts when you add open banking multiple providers for failover — some contracts penalise dual routing. Legal should flag auto-renewal and exclusive routing language.

Procurement can reuse scoring weights from your RFP, but diligence adds evidence attachments: signed coverage matrix, sandbox log exports, and security report dates under NDA.

What security and operational artefacts belong in the pack?

ISO 27001 or SOC 2 scope must match the service you buy — not a group certificate for an unrelated product line.

Request:

• Latest SOC 2 Type II or ISO 27001 certificate scope statement
• Penetration test summary date (not full report unless policy allows)
• Incident notification SLA and status page history for bank API outages
• Subprocessor list with change notification
• Support tiers and escalation paths for production incidents

Match ops questions to your use case: recurring billing teams need dunning webhook reliability; checkout teams need peak-traffic behaviour. If you rely on UK recurring rails, confirm operational contacts understand UKPI rulebook updates — industry commentary such as Open Banking Expo’s UKPI overview is useful context, but your vendor should cite primary scheme and regulator sources for live commitments.

How do you close diligence and choose a finalist?

Score gaps, do not average vibes. Weight coverage and sandbox results highest; treat marketing narrative as untested until attached as evidence.

Suggested weighting for a two-finalist decision:

1. Mandatory bank coverage — binary pass/fail on your list
2. Sandbox acceptance — engineering sign-off
3. Total cost model — 12-month, incl. failures and mins
4. Ops and incident fit — SLAs, support, reconciliation tooling
5. Strategic risk — ownership, roadmap, exit terms

If two vendors pass technical gates, use the provider-matching form to stress-test fit against your countries, use cases, and volume bands before you lock the MSA — especially when open banking aggregator comparison style evaluations left you with overlapping finalists.

Document residual risks explicitly (“Bank X AIS only until Q2 roadmap”) so leadership accepts trade-offs before launch, not after the first production incident.

Frequently Asked Questions

What is open banking vendor due diligence?

It is structured pre-contract verification that a regulated open banking provider can deliver your payment, verification, or recurring flows. You validate bank coverage on your mandatory list, run sandbox happy and failure tests, collect written commercial terms, review security artefacts, and confirm contract exit and change-of-control rights before signing.

How is due diligence different from an open banking RFP?

An RFP is a formal procurement process with structured questions and scored responses from multiple bidders. Due diligence is the deeper evidence pass on finalists — sandbox logs, coverage exports, security reports, and commercial schedules — often after demos and sometimes in parallel with RFP stages. Smaller teams may run diligence without a full RFP if policy allows.

Who should attend vendor diligence sessions?

Include a payments or billing lead (scope and commercial), a senior engineer (sandbox and webhooks), finance or ops (reconciliation and fee model), and procurement or legal (contract and subprocessors). Security or IT may join for certificate review. Sales should not be the only voice answering technical tests.

What bank coverage proof is enough?

An exportable matrix listing each institution with separate PIS and AIS support flags, last-updated date, and explicit gaps on your mandatory list. Country-level marketing claims are insufficient. Validate mobile bank flows for your top institutions in sandbox or recorded pilot.

Does vendor due diligence change after M&A?

Yes. After acquisitions such as Mollie–GoCardless, re-run diligence on change-of-control clauses, integration timelines, pricing hold periods, and roadmap priority for your corridors. Consolidation can improve multi-rail coverage or increase concentration risk — document which outcome you are accepting.

When should you walk away from a vendor?

Walk away or demote a finalist when mandatory banks are missing without a dated fix, sandbox failure handling fails acceptance tests, security scope does not cover the service, commercial terms hide failed-payment charges, or exit rights are too weak for your concentration policy. Partial gaps can be acceptable if leadership signs residual risk in writing.