An open banking request for proposal (RFP) can look thorough and still produce a weak decision. One provider reports bank coverage by brand, another by legal entity and another by whichever journeys passed a test during the previous quarter. Availability may refer to bank interfaces, the provider platform or a customer-facing service. Implementation estimates may exclude certification, finance integration and operational readiness.
The procurement team then receives polished documents that answer different questions. A feature matrix creates an appearance of comparability, while the largest delivery risks remain outside the score.
A stronger Open Banking provider RFP begins with the operating outcome. It defines evidence before responses arrive, weights the risks that affect customers and carries supplier commitments into proof of concept, implementation, service review and exit.
Start with the service your teams need to operate
Open Banking Limited's supplier-management guidance separates procurement into strategy, tender or pre-contract work, contract negotiation and in-life management.¹ The same service objective should remain visible through all four stages.
Write the RFP around a specific customer and operating journey. A Pay by Bank checkout has different dependencies from an account-information feed used for affordability, and a commercial variable recurring payment service creates different consent, exception and reconciliation work from a one-off payment.
The opening section should define:
- the customer journey and the business action it supports;
- the countries, banks, account types and channels in scope;
- expected volumes, peaks and growth assumptions;
- the evidence that permits fulfilment, ledger posting or customer confirmation;
- the maximum acceptable disruption and recovery expectation;
- the teams that will integrate, operate, reconcile and support the service; and
- the regulatory permissions and responsibilities that need live verification.
These details give every supplier the same operating problem. They also help the buying team distinguish a capability that exists somewhere in a provider's estate from a capability available for the required bank, account type and customer journey.
Our enterprise checklist for open banking integration provides the broad qualities to examine. The RFP should convert each relevant quality into a dated claim, an acceptable form of evidence and a pass threshold.
Specify evidence before suppliers respond
An answer such as "supported", "resilient" or "enterprise ready" cannot be scored consistently. Define the artefact or demonstration that will support each response.
A practical evidence scale can use four grades:
- Verified in the buyer's test: the buying team reproduced the result with its own journey, bank set and acceptance data;
- Current operational evidence: the provider supplied dated production measures, incident history, control evidence or a live demonstration with a clear scope;
- Documented capability: current public or controlled documentation describes the behaviour, owner, limits and version;
- Roadmap commitment: the capability has an owner and target date, while production evidence remains unavailable.
The scorecard should reward the first two grades for critical requirements. A roadmap item can still inform the decision, although it should receive a lower score and an explicit delivery dependency. A response with no named artefact remains unverified.
Request evidence at the level needed for the decision. Security reports can remain under a non-disclosure agreement. Customer-confidential records should stay outside the RFP. The evaluation record can state what was reviewed, the date, scope, result and reviewer without copying protected material into a shared pack.
Weight the scorecard around customer and operating risk
Equal weighting encourages suppliers to accumulate easy feature points while a critical weakness disappears into the total. Set weights before opening responses and identify requirements that create an automatic fail.
An enterprise payment procurement might begin with this allocation:
- use-case and bank coverage, 20%;
- reliability, performance and operational control, 20%;
- integration, API lifecycle and developer delivery, 15%;
- security, data and regulatory evidence, 15%;
- onboarding, support and implementation capacity, 10%;
- commercial model and total operating cost, 10%; and
- governance, contract flexibility and exit readiness, 10%.
This is an editorial recommendation, so the buyer should change the weights for its service. A regulated account-information product may place greater weight on consent, data handling and audit evidence. A high-volume checkout may place greater weight on bank-level completion, latency, status quality and reconciliation. A platform entering several markets may need geography and local regulatory delivery to carry more of the score.
Keep the scoring rubric beside the requirement. Define what earns zero, half and full marks. Require evaluators to record evidence and reasoning, then moderate differences before the commercial negotiation changes the ranking.
Measure coverage against the actual customer mix
A coverage percentage needs a denominator and a date. Ask providers to supply a matrix for every priority bank, legal entity, brand, account type and journey.
For payment initiation, the matrix can record web and mobile authentication, business and personal accounts, payment types, callback behaviour, refunds, status retrieval and known restrictions. For account information, it can record the available resources, transaction history, refresh behaviour, consent handling and account-specific limitations.
Use the buyer's customer or transaction distribution to weight the result. A provider covering many low-volume institutions may still leave a large share of customers with an incomplete journey. The RFP should also state how newly supported banks, outages and capability changes enter the provider's directory, API and client communications.
Ask for the observation date and source behind every coverage response. During proof of concept, test the priority journeys with representative accounts. Retain the result as the baseline for implementation acceptance.
Test performance beyond one availability figure
Open Banking Limited reported July 2026 average API availability of 99.77%, average response time of 330 milliseconds, 99.54% successful API calls and 0.46% failed API calls.² These figures show a mature service operating at substantial volume. They also demonstrate the need to define each measure carefully.
The published data is based on account servicing payment service provider submissions. It describes bank-interface performance under the published methodology. A provider RFP needs additional evidence for the provider layer and the buyer's complete customer journey.
Request measures for:
- journey completion by bank, account type, channel and product;
- latency at each provider and bank-dependent stage;
- technical and business failures with stable reason categories;
- callback delay, duplication, replay and delivery exhaustion;
- payments or consents held in transitional states beyond an agreed window;
- reconciliation breaks and time to resolution;
- incident frequency, customer impact and recovery time; and
- measurement coverage, exclusions and retention periods.
Ask for percentiles and distributions where averages could hide poor tail performance. Define the service-level indicator, observation point, calculation, exclusion policy and reporting frequency. The contractual service level can then refer to the same measure used during evaluation.
The RFP should make bank dependency visible. Provider performance should be segmented so the buyer can see whether a problem sits within the provider platform, a bank interface, the customer's return journey or a downstream system. Ownership can vary, while the customer outcome still needs one operational response.
Examine payment states, callbacks and reconciliation
The current Open Banking API Specifications are version 4.0.1 and cover the interfaces behind information sharing, payment initiation, security and reporting.³ A compliant interface alone does not define the buyer's complete operating model.
Ask each provider to demonstrate the evidence behind labels such as authorised, submitted, processing, complete and settled. Require the raw status, reason, timestamp and source behind every normalised state. The buyer's fulfilment and ledger rules should use the evidence appropriate to its service.
Our guide to an open banking payment state machine explains how transport, consent, payment and business states can remain separate. Use that model to write RFP test cases for uncertain outcomes.
The provider response should cover idempotency, callback signing, retry and replay, status retrieval, duplicate suppression, out-of-order events, reconciliation jobs and manual resolution. It should also identify which records finance, support, risk and engineering can retrieve without opening a provider ticket.
Ask for exportable evidence. A dashboard helps during an incident, while durable event data, identifiers and reason codes support ledger repair, audit and migration.
Keep regulatory responsibility with the right owner
The FCA expects firms using outsourced and other third-party providers to understand their dependencies and manage associated operational risk throughout the arrangement's lifecycle. The firm remains responsible for the obligations that apply to it.⁴
That principle should shape the RFP. Ask the provider to identify its legal entity, regulatory status, permissions, subcontractors, hosting locations, data flows and operational responsibilities. Verify regulatory records independently at the relevant decision point.
The buyer should map which people, processes, technology, facilities and information support the service. The provider can supply evidence for its controls and dependencies. The buyer still needs to assess how the arrangement affects its own important services, customer outcomes and recovery plans. Our article on critical third parties and Open Banking sets out this continuing responsibility.
PS26/2 is a final policy statement, with new operational incident reporting rules applying to payment service providers from 18 March 2027. Its material-third-party reporting requirements apply to the firm categories listed by the FCA, including authorised payment institutions and authorised electronic money institutions.⁵ Buyers should confirm their own scope and use the preparation period to establish the data they will need from provider records.
The RFP can request a current subprocessor inventory, incident taxonomy, notification fields, service mapping, recovery objectives, audit rights and change-notification process. These artefacts help regulated buyers operate their controls and can improve governance for firms outside the specific reporting scope.
Price implementation and in-life operations
Transaction fees form one part of the cost. Build a scenario model covering implementation, certification, minimum commitments, platform fees, bank or geography additions, premium support, data retention, reporting, refunds, reconciliation, change requests and exit assistance.
Ask suppliers to price the same volume bands and growth cases. State which measure triggers a fee, such as an API call, connected account, attempted payment or successful payment. Record tax, currency, indexation, overage treatment and any third-party component separately.
Implementation effort also needs a common scope. Require a delivery plan with buyer and provider responsibilities, environments, test data, security review, bank testing, acceptance evidence, operational handover and support readiness. A short integration estimate has limited value if finance reconciliation, customer support and incident response remain outside it.
Version support belongs in the commercial model. Ask for notice periods, overlapping support, migration assistance and the consequences of a bank-specific change. The Open Banking API version migration runbook provides test and cutover questions that can become RFP requirements.
Run a proof of concept that creates failure
A successful payment confirms one path through one set of conditions. Production readiness depends on behaviour when evidence is delayed, duplicated, conflicting or unavailable.
Give shortlisted providers the same test pack. Include customer abandonment, bank rejection, a timeout after submission, a duplicate request, repeated and out-of-order callbacks, an unmapped status, a delayed payment, a temporary callback outage, a bank-specific capability gap and a reconciliation mismatch.
For each case, score the customer message, API response, raw evidence, normalised state, retry guidance, operational alert, support visibility and recovery path. Measure the time and manual effort needed to reach a safe result.
Use realistic data volumes and the buyer's priority banks. Record provider help required to complete the test, since that effort indicates the likely operating dependency after launch. A provider may meet the technical requirement while creating substantial manual work for finance or support, and the scorecard should make that cost visible.
The proof of concept should end with an acceptance report. Carry failed tests and roadmap dependencies into the implementation plan with owners, dates and contractual consequences.
Carry the evidence into the contract and exit plan
The winning response should become part of the operating agreement. Translate critical claims into schedules for supported journeys, service levels, incident communication, security obligations, audit evidence, reporting, change control, data return and deletion, transition assistance and termination.
Define remedies that support the service outcome. A service credit may address part of a commercial failure, while a repeated bank-level performance issue may also require remediation, enhanced reporting, customer communication or an exit right.
Plan exit before signature. Ask how consents, configuration, payment records, event histories, reconciliation evidence and reporting data can be exported. Define formats, timing, retained identifiers, secure deletion and transition support. Test at least one representative export during due diligence when portability is critical.
The contract should preserve access to evidence after an incident and during termination. A buyer needs enough history to resolve open payments, support customers and meet applicable record-keeping duties after the provider relationship changes.
Make the decision reproducible
The final selection record should identify the criteria, weights, evidence grades, test results, commercial scenarios, exceptions, conflicts and approval owners. Keep supplier claims dated. Record every assumption that depends on a roadmap item, contract negotiation or buyer-side control.
Moderate the scores across product, engineering, payments operations, finance, security, risk, legal and procurement. Each team sees a different part of the service. A common evidence model turns those perspectives into one decision.
After signature, reuse the scorecard for implementation acceptance and periodic service review. Update the evidence when bank coverage, API versions, subcontractors, prices or regulatory requirements change. The procurement then becomes the first version of a living operating record.
An effective Open Banking provider RFP gives the buying team a precise answer to four questions: what the service must achieve, which evidence proves the supplier can deliver it, how performance will be governed and how the enterprise can change course safely.
Footnotes
- Open Banking Limited, operational guidance for supplier strategy, tendering, contracts and in-life management. Contract and Supplier Management
- Open Banking Limited, July 2026 availability, response-time, successful-call and failure data, including methodology notes. API performance stats
- Open Banking Limited, current technical specification index, version 4.0.1, published 18 March 2026. API Specifications
- Financial Conduct Authority, third-party dependency, lifecycle risk-management and continuing accountability guidance. Outsourcing and operational resilience
- Financial Conduct Authority, final rules, scope and commencement date for operational incident and material-third-party reporting. PS26/2: Operational incident and third party reporting