Twelve questions to ask any fintech infrastructure vendor before signing.

A bank or insurer's procurement / CTO due diligence checklist. Twelve specific questions, what good answers look like, what red flags mean a vendor isn't DORA-ready, AI-Act-ready, or fit for a regulator audit. Written so the buyer can take it directly to vendor RFP cycles.

Why this checklist exists

A bank or insurer evaluating a fintech infrastructure vendor in 2026 has a harder job than the same buyer in 2020. The vendor landscape is more crowded; the regulatory bar (DORA, EU AI Act, AMLA) is higher; the consequences of a bad vendor selection are larger. A wrong choice locks the institution into a 3-5 year integration that becomes painful to unwind.

I have sat on both sides of this table. As a fintech operator hiring vendors for our own stack in 2018-2022, and now as the founder of a vendor that gets evaluated by tier-1 banks and insurers across CEE and Western Europe. The checklist below is what I now wish every buyer was using. Some of it favours Coreal; most of it is vendor-agnostic. All of it filters out the vendors who won't survive the first DORA audit cycle.

Twelve questions. Each one has: the question itself, why it matters, what a good answer sounds like, and the red flag if the vendor can't answer.

You can take this directly to vendor RFP cycles. It generalises beyond Coreal — apply it to any ICT third party supporting a critical-or-important function.

1. DORA Article 28 evidence pack

Question: Show us the evidence pack you hand to a bank for its DORA Article 28 outsourcing register. What's in it?

Why it matters: DORA enforced January 2025. Every bank now needs a documented register entry for every ICT third party. A vendor who can't ship this pack is putting the burden on the bank's compliance team — which means slower onboarding, more friction, and possibly your DORA audit failing.

Good answer: A specific, structured pack with 6-10 named artefacts: ICT third-party identification card, concentration-risk note, sub-provider chain + flow-down clauses, ICT risk-management framework alignment statement, operational continuity & exit plan, incident-reporting hookup, DORA-compliant contractual clauses, audit rights & access to information. Reference: our DORA Art. 28 evidence pack shows the format.

Red flag: "We'll provide the documentation as needed during onboarding" — translation: they don't have it yet. Their first tier-1 bank customer is the one who'll find out.

2. 90-day exit plan

Question: Show us the exit plan from your platform. Specifically: day 0 to day 90 of a termination notice. What happens, who runs it, what we get at the end?

Why it matters: DORA Art. 28(8) requires a documented exit strategy. Most vendors satisfy this by writing "we will assist with data migration" in the contract. That's not an exit plan. A real exit plan is named milestones, a named migration engineer dedicated to your handover, documented data schemas, source-code escrow timing.

Good answer: "On day 0 of notice, we continue at full SLA for the notice period (typically 6-12 months). On day 1-30, named migration engineer assigned; data replication starts; schemas documented. Day 60: bank-side dry-run of fallback. Day 90-270: gradual cut-over. Day final: source code escrow released. Pre-qualified replacement providers attached."

Red flag: Vague "we'll help you migrate" without specifics. The vendor's commercial team doesn't want to think about exit; the regulator wants to see exactly what it looks like.

3. Read-only on book of record

Question: Confirm in writing that your platform will not write to our book of record (core banking system, policy admin system, BSS, etc.) during Wave-1 deployment. Show us the architecture diagram.

Why it matters: The single most important architectural decision for a regulated buyer. A vendor that wants to write to your book of record on day one is a vendor that wants to lock you into their stack. A vendor that subscribes read-only and posts new flows alongside is a vendor whose departure doesn't break your operations. See Adjacent vs replacement: why bank-core projects fail at month 18.

Good answer: Yes, confirmed in writing. Architecture diagram shows the platform subscribing via DBA-approved read-replica or vendor-supported event bus. Write-path is to the platform's own ledger; reconciliation back to your book of record is on a documented cadence (typically T+1 batch).

Red flag: "We integrate deeply with your core for performance reasons." Deep integration means lock-in. Lock-in means painful exit. Painful exit means the vendor can extract premium pricing during contract renewal.

4. Audit rights for our national competent authority

Question: What audit rights does our national competent authority (BaFin, ACPR, ČNB, FCA-equivalent, etc.) have on your platform? Can they conduct on-site audits?

Why it matters: DORA Art. 30(3)(d) requires that the bank's regulator be able to audit the provider. Some vendors push back on this — claiming customer-confidentiality or commercial-secret protection. That position is incompatible with DORA. A vendor who pushes back here will be a problem at the first regulator review.

Good answer: "On-site audit rights granted to your competent authority with reasonable notice (typically 30 days). No fee charged for these audits. We've participated in [N] regulator audits in the last 24 months and the reports are available under NDA."

Red flag: "We have a SOC 2 report; that should suffice." It doesn't. DORA explicitly requires on-site audit capacity, not just third-party assurance reports.

5. Source code escrow

Question: Source code escrow — when do you place code in escrow, where, and under what conditions can we access it?

Why it matters: Source code escrow is the technical guarantee that you can take over operations if the vendor disappears. Without it, you have software you can use but cannot maintain. The trigger conditions and the escrow agent both matter.

Good answer: "Source code in escrow with [named third party — Iron Mountain, Escrow London, NCC Group, etc.] from contract signing. Release triggers: vendor bankruptcy, vendor breach of contract, vendor failure to deliver SLA for [N] consecutive periods. You can verify the escrow contents at any time via the escrow agent."

Red flag: "We can put code in escrow if you require it" — translation: only the deals where it's a deal-breaker get escrow. Not the default. Means it's a contract-negotiation footnote, not an operational reality.

6. Concentration risk note for our outsourcing register

Question: Provide a concentration risk note for our DORA Art. 29 analysis. What share of our function are you handling? What share of your business is our function? What's your sub-provider concentration?

Why it matters: DORA Art. 29 requires the bank to assess concentration risk — the risk that a vendor's failure has disproportionate impact. The bank's compliance team can't do this without inputs from the vendor.

Good answer: Specific numbers: "We handle X% of your KYC volume / payment orchestration / etc. You are Y% of our annual revenue. Our sub-providers (cloud, sanctions screening, etc.) and our share of their volume are documented in attachment B."

Red flag: Refuses to provide concentration information citing commercial confidentiality. The bank legitimately needs these inputs; the vendor's confidentiality argument fails against DORA's explicit requirements.

7. Sub-provider chain + flow-down clauses

Question: Map your sub-provider chain. For each sub-provider, confirm that DORA flow-down clauses (Art. 30(2)(a-i)) propagate.

Why it matters: A vendor that uses sub-providers (AWS for cloud, Refinitiv for sanctions, etc.) without flowing-down DORA's contractual clauses creates a regulatory gap. The bank's risk doesn't disappear when the vendor outsources — it just becomes harder to see.

Good answer: Documented sub-provider map (2-3 layers deep). Each sub-provider has a contractual addendum showing DORA flow-down clauses propagating. Documented review schedule for sub-provider risk (typically annual).

Red flag: "Our sub-providers are commercially confidential and we manage our supply chain ourselves." Translation: they haven't done the work. The bank will inherit the regulatory risk.

8. Decision journal retention

Question: Decision journal — what's your retention policy, what's the schema, and how do we query it for a regulator audit?

Why it matters: DORA Art. 5 and 17 require decision journals on material ICT decisions. BCBS 239 implies them on risk-data changes. AMLA reviews them on AML decisions. EU AI Act Art. 12 mandates them on high-risk AI system invocations. The decision journal is the single artefact that ties all four regimes together. See BCBS 239 + DORA + AMLA: one evidence pack and the dedicated decision journal architecture piece.

Good answer: "7-year retention by default (alignable with your retention policy). Event-sourced schema with documented structure. Replay engine supports time-travel queries. Specific example: you can ask 'what was the decision rationale for customer X's KYC approval on date Y' and get a complete reconstructed trace in 4-8 seconds."

Red flag: "We have audit logs" — translation: they have application logs, not decision journals. Different artefact. Application logs are not regulator-readable; decision journals are.

9. ICT incident webhook to our GRC tool

Question: When a major ICT incident happens on your platform, how does that information reach our GRC tool (ServiceNow, OneTrust, Archer, etc.) within DORA's reporting timelines?

Why it matters: DORA Art. 19 requires the bank to report major ICT incidents to its national competent authority within 1 hour for initial notification, 72 hours for full incident report. The bank cannot meet these timelines if the vendor notifies via email. Hook-up to the bank's GRC tool is required.

Good answer: "Pre-built webhook to [ServiceNow / OneTrust / Archer / custom]. Incident classification taxonomy maps automatically to DORA's. Sample incident records available for review under NDA."

Red flag: "We notify by email within 24 hours" — translation: they will cause you to fail DORA Art. 19 reporting timelines.

10. EU AI Act high-risk classification

Question: Your platform includes AI features. Which of those features are classified as high-risk under EU AI Act Annex III? What conformity assessment have you completed?

Why it matters: EU AI Act high-risk obligations bind August 2026. A vendor whose AI features land on the high-risk side without prepared conformity assessment is a vendor that will be in non-compliance from day one of usage. The bank inherits the operational risk. See EU AI Act for regulated fintech.

Good answer: "Three features classified high-risk: credit scoring (Annex III(5)(b)), biometric behavioural monitoring (Annex III(1)(a)), AML transaction monitoring (treated as functionally high-risk). Conformity assessment completed for all three; CE marking applied; EU database registration submitted. Technical files available for review."

Red flag: "We're still working on AI Act readiness." Translation: they're not ready, and the August 2026 deadline is racing toward both of you.

11. Multi-region resilience and sovereign cloud option

Question: Where does the platform run? What's the multi-region resilience design? Is there a sovereign EU cloud option?

Why it matters: Data residency, sovereign cloud, and multi-region failover are increasingly required by EU regulators. UK FCA, German BaFin and French ACPR have all stated explicit positions on sovereign cloud for systemically important banks. A vendor without a sovereign-cloud option locks the bank into a sub-optimal regulatory posture.

Good answer: "Primary region: Frankfurt. Backup: Dublin. Recovery time objective: 15 minutes. Recovery point objective: 60 seconds. Sovereign EU cloud options available: AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty, Gaia-X-aligned providers. Deployment to your nominated region available."

Red flag: "We run on AWS US-East" — translation: data residency depends on US legal jurisdiction, which is increasingly unacceptable for EU regulated entities.

12. Pricing model and total cost of ownership

Question: Pricing model — is it recurring SaaS, capex, transaction-based, or a hybrid? What's the typical 3-year TCO for an institution of our size?

Why it matters: Vendors who price in confusing ways are vendors who extract value through contract complexity. Clear pricing protects the buyer. Total cost of ownership over 3-5 years often dwarfs the initial contract value; the vendor that's cheapest in year 1 may be most expensive in year 4.

Good answer: "Recurring SaaS, priced per active user / transaction volume / module. 3-year TCO for a bank of your profile: €X-Y million, breaking down as: subscription €A, implementation €B, ongoing operational support €C. Comparable benchmark: vendor [Z] at €X*1.2 for less functionality. Open to discussing alternative structures (capex, hybrid)."

Red flag: "Pricing is bespoke based on your specific situation" — translation: they're trying to maximise the deal size based on what they think you can pay, not what the value is worth.

How to use this list

1. Send the 12 questions to every vendor in your RFP shortlist with a 14-day response window. The quality of the responses tells you which vendors are operationally serious vs commercially performative.

2. Score the answers blind. Have your procurement and compliance teams score independently before comparing notes. Vendors will know how to spin to the buying signal; structured scoring filters this.

3. Verify selectively. Pick 3-4 of the answers and ask for evidence — actual exit plan document, actual decision journal sample, actual sub-provider map. The vendors who can produce these in 48 hours pass; vendors who delay or hedge fail.

4. Don't compromise on questions 1, 3, 10. DORA Art. 28 pack (Q1), read-only on book of record (Q3), and AI Act classification (Q10) are non-negotiable for any tier-1 European regulated entity in 2026. A vendor that doesn't pass these isn't ready for European regulated finance.

What this filter selects for

The vendors that pass this checklist are operationally mature, regulator-aware, and confident in their architecture. They tend to be slightly more expensive than the marketing-strong / operationally-thin alternatives. They tend to be slightly slower in sales cycles because they want to verify your readiness too. They tend to be the ones who survive contact with your first regulator audit.

The vendors that fail are usually fine for a non-regulated proof-of-concept or a research project. They are not fine for production banking, insurance or payment infrastructure where the regulator's stamp matters.

I would rather lose a deal because the buyer asks these questions and we don't measure up than win a deal because the buyer didn't ask. The first kind of loss is information that I should improve. The second kind of win is a lawsuit waiting to happen 18 months in.

If you take one thing from this essay: questions 1, 3, and 10 are the killers in 2026. DORA evidence pack, adjacent architecture, EU AI Act readiness. A vendor that can't answer those three is not a 2026-ready vendor for European regulated finance.

The rest of the questions are useful but recoverable — a vendor that's weak on sub-provider mapping but strong on the killers can be coached. A vendor that's weak on the killers is a fundamental architectural mismatch that no contract structure can fix.

Use the list. Save your DORA audit. Save your procurement cycle. Save your renewal pain in year 3.

Engagement-side disclosure: I am the founder of Coreal, a fintech infrastructure provider you might be evaluating. This checklist favours how we already operate — but the questions are vendor-agnostic. I would happily lose to a competitor that scores better on these 12; I would not happily lose to a competitor that ducked the questions. For our specific answers to the 12, see /security-compliance and /solutions/banks. For a Wave-1 brief, book a working session →.