How to run fintech provider due diligence and an RFP

Choosing an infrastructure provider is a structured process, not a demo-driven decision. Run it as one: define what your product needs, separate must-haves from nice-to-haves, review each candidate’s regulatory, financial, security and data-protection posture, then score without inventing precision you do not have. A request for information (RFI) and request for proposal (RFP) are the tools that make comparisons fair. This guide walks through the sequence, from requirements to exit, so selection is defensible rather than driven by whoever demos best.

Define product requirements

Start by writing down what your product actually does and needs — capabilities, volumes, markets, integration points and operational expectations. Requirements written after seeing vendor features tend to be shaped by those features. Define them first, independently, so the market is measured against your needs rather than the other way around. This mirrors the product-and-permissions mapping in how to choose an EMI or BaaS provider.

Separate mandatory and optional capabilities

Split requirements into mandatory (a candidate is disqualified without them) and optional (desirable, scored). Without this split, a strong optional feature can mask a missing essential, producing a false comparison. Agree the split internally before issuing the RFP so scoring later cannot be gamed by an impressive but non-essential capability.

Regulatory and legal-entity review

Confirm which legal entity provides each regulated activity, its status and its country of authorisation, verified in the relevant official register rather than a marketing page. Do not accept brand-level claims. Where regulated permissions are involved, the specific entity and scope matter far more than the group name.

Financial and ownership review

Assess the provider’s financial standing and ownership: who owns and controls the company, its financial stability, and any concentration or dependency risks. A provider you will depend on operationally is also a counterparty. Ask for the information you would expect of any critical supplier, and note where it is unavailable.

Security and resilience

Review information security and operational resilience: security certifications and practices, incident history and communication, business continuity and disaster recovery. Ask how the provider detects, responds to and communicates incidents, and how it tests resilience — not just whether it holds a certificate.

DORA relevance

The Digital Operational Resilience Act has applied since 17 January 2025 and covers ICT risk management, incident reporting, resilience testing and ICT third-party risk 1. Distinguish direct exposure (where the entity is itself subject to DORA) from contractual exposure (where DORA-driven requirements flow through to a vendor via contract). Do not assume every unregulated fintech is directly subject to every DORA requirement, and do not assume using a vendor moves resilience responsibility away from the regulated entity — see DORA, fintech vendor risk and outsourcing.

Data protection

Where the provider processes personal data, review the roles (controller/processor), the processing terms, international transfers, and data-minimisation and retention under the General Data Protection Regulation 2. The data-processing terms should be reviewed alongside the commercial contract, not after signing. Confirm what data is processed, why, and how long it is kept.

Subcontractors

Providers rely on their own subcontractors (sub-processors, infrastructure, downstream partners). Ask for the chain: who they depend on, for what, and how changes are notified. A dependency you cannot see is a risk you cannot manage. Notification and approval rights for material subcontractor changes should be in the contract.

Product coverage

Test claimed coverage against your real requirements: markets, currencies, features, edge cases and volumes — not a headline country list. Coverage asserted as a list often hides gaps in the specific corners your product needs. Ask for evidence tied to your use cases.

Integration

Evaluate the developer experience honestly: API completeness, documentation quality, sandbox fidelity, webhooks, idempotency and rate limits. Integration quality determines how much time your team spends fighting the platform after launch, so weight it accordingly.

Operations

Understand day-two operations: reporting, reconciliation, exception handling, and how routine and non-routine events surface to your team. Operational friction is a recurring cost that demos rarely reveal. Ask to see real reports and reconciliation flows.

Support

Clarify support hours, escalation paths, named contacts and incident communication. When something breaks in production, the quality of support matters more than a headline uptime figure. Confirm who you can reach and how fast during a live problem.

Pricing

Compare pricing like-for-like: setup, minimums, per-unit fees, variable charges and anything conditional. Model it at expected and stressed volumes. Ask for a complete price list so hidden or conditional charges do not surface after selection.

Implementation

Understand the implementation path: timelines, responsibilities, milestones, testing and go-live support. Ask what has to be true for a realistic launch date, and who does what. Optimistic timelines that ignore approvals and testing are a common source of slippage.

Exit

Plan the exit before you sign: what data you can export, in what format, over what period, and how you migrate off. Providers rarely volunteer favourable exit terms after go-live. Exit and portability belong in the contract from the start.

Scoring without false precision

Score candidates against your criteria, but do not fabricate precision. A single decimal on an aggregate score implies certainty you do not have from incomplete public information. Use clear bands, record the evidence and reasoning behind each score, and be explicit about unknowns. Do not declare a numerical “winner” based on incomplete data — the score supports a decision, it does not make it.

Proof-of-concept planning

Where the decision is material, run a scoped proof of concept against real (or realistic) scenarios rather than a canned demo. Define success criteria up front, so the POC produces evidence rather than an impression. Keep it time-boxed and focused on the risky assumptions.

Reference checks

Ask for references and, where possible, speak to comparable customers about real experience — integration, operations, support and incidents. Prepare specific questions tied to your requirements. Treat references as evidence to probe, not endorsements to accept at face value.

Contract schedule checklist

• Regulated entity and permissions verified in the official register
• Financial and ownership review completed
• Security, resilience and incident-communication terms reviewed
• DORA direct vs contractual exposure assessed and reflected in the contract
• Data-processing terms, transfers, minimisation and retention reviewed
• Subcontractor chain, notification and approval rights documented
• Product coverage evidenced against real use cases
• Integration validated in a realistic sandbox or POC
• Full pricing modelled at expected and stressed volumes
• Exit, data-portability and migration terms agreed before signing

Sample RFI structure

An RFI gathers structured information before a full RFP:

1. Company, legal entities and regulated status
2. Product and coverage overview
3. Security, resilience and certifications
4. Data-protection and subcontractor summary
5. Integration and support model
6. Indicative pricing model
7. References and comparable deployments

Keep the RFI focused enough that responses are comparable, and clear enough that vendors can answer without a sales call — clear internal and external documentation improves the quality of responses 3.

Sample RFP table

Criterion	Weight (band)	Evidence requested	Mandatory?
Regulated entity and permissions	High	Register entry, scope	Yes
Product coverage for our use cases	High	Evidence vs requirements	Yes
Security and resilience	High	Certs, incident process	Yes
Data protection	High	DPA terms, transfers	Yes
Integration quality	Medium	Docs, sandbox, POC	No
Operations and reconciliation	Medium	Sample reports	No
Support and escalation	Medium	SLA, contacts	No
Pricing	Medium	Full price list	No
Exit and portability	High	Export and migration terms	Yes

Decision log

Keep a decision log recording who decided what, when, on what evidence and why — including options not chosen. A decision log makes the choice auditable, helps onboarding of new team members, and is invaluable if the relationship is later questioned. Record the unknowns and assumptions explicitly.

Questions to ask providers

• Which legal entity provides each service, and where can we verify its status?
• Who owns and controls the company, and how financially stable is it?
• How do you manage security, resilience and incident communication?
• Are you directly subject to DORA, or do DORA-driven requirements flow to you by contract?
• What are the data-processing terms, transfers, minimisation and retention?
• Who are your material subcontractors, and how are changes notified and approved?
• Can you evidence coverage against our specific use cases and volumes?
• What does implementation require, and what is a realistic timeline?
• What are the full costs at expected and stressed volumes?
• What can we export on exit, and how does migration work?

Common failure modes

• Writing requirements after seeing vendor features, so the market shapes the spec.
• Failing to separate mandatory from optional, letting a nice-to-have hide a gap.
• Accepting brand-level regulatory claims instead of verifying the entity.
• Assuming a vendor absorbs DORA or data-protection responsibility.
• Ignoring the subcontractor chain.
• Scoring with false precision and declaring a numerical winner on thin data.
• Leaving exit and portability until after go-live.

What this does not cover

This guide does not evaluate any specific provider, does not rank vendors, and does not determine whether a contract or structure is compliant for your business. It does not recommend a numerical winner from incomplete public data. It complements — but does not replace — legal, regulatory and security advice tailored to your entities and use cases.

FAQ

What is the difference between an RFI and an RFP?

An RFI gathers structured information to shortlist candidates; an RFP asks shortlisted candidates to propose against detailed requirements. The RFI narrows the field; the RFP supports the final decision.

Why separate mandatory and optional capabilities?

So a strong optional feature cannot mask a missing essential. Mandatory items disqualify a candidate if absent; optional items are scored. Without the split, comparisons become misleading.

Does using a vendor transfer our DORA or data-protection responsibility?

No. DORA-driven and data-protection obligations may flow to a vendor by contract, but the regulated entity remains responsible 1. Distinguish direct exposure from contractual exposure rather than assuming responsibility disappears.

How should we score candidates?

Use clear bands rather than false-precision numbers, record the evidence and reasoning for each score, and be explicit about unknowns. The score supports a decision; it does not replace judgement, and you should not declare a numerical winner on incomplete data.

When should we plan the exit?

Before signing. Data export, format, portability and migration terms are far harder to negotiate once you are live and dependent on the provider, so put them in the contract from the start.