DORA Compliance for Fintech: KYC Vendor Checklist 2026

Disclosure: PrimeBiometry does not provide legal advice. This checklist reflects editorial analysis of public DORA requirements. Consult qualified legal counsel for your jurisdiction.

As of January 17, 2025, the Digital Operational Resilience Act is fully in force across all 27 EU member states: and 2026 is when national competent authorities are actually enforcing it. According to KPMG’s 2024 DORA Readiness Survey, only about 33% of major European financial institutions were confident they could meet all requirements by the deadline. The gap isn’t just in internal IT frameworks. It’s in the vendor stack.

Here’s the part most compliance teams missed: every SaaS tool in their KYC and AML stack is an ICT third-party service provider under DORA Articles 28-44. Not “might be.” Is. Identity verification, AML screening, biometric liveness, case management: all of it. That classification carries mandatory due diligence, specific contractual clauses, and ongoing oversight obligations that your vendors have to actively support.

Seven things to verify before your next supervisory review: and an independent look at how Veriff, Sumsub, iDenfy, and ComplyCube each hold up against the requirements.

TL;DR

• DORA Articles 28-44 classify KYC and AML SaaS as ICT third-party service providers. Documented risk assessment, mandatory contractual clauses, ongoing monitoring: all required, no SaaS exemption.
• Only ~33% of EU financial institutions were confident they’d meet all DORA requirements by the January 2025 deadline (KPMG, 2024).
• Senior management faces personal fines up to €1M. Institutional exposure: up to 2% of global turnover or €10M per violation type.
• This checklist covers the minimum your vendor must satisfy. The vendor comparison below shows who’s already there.

---

What DORA means for your KYC and AML vendor stack

Under DORA Articles 28-44, every technology vendor supporting your regulated operations is an ICT third-party service provider. That includes identity verification platforms, AML screening tools, biometric authentication services, and KYC case management systems. There’s no SaaS exemption: the regulation classifies vendors by function, not delivery model. A cloud-hosted API gets the same treatment as an on-premise installation.

DORA Art. 2 covers 21 types of financial entities: credit institutions, payment institutions, investment firms, crypto-asset service providers (CASPs), insurance companies, e-money institutions, and more. If your fintech holds any of these licenses, your ICT vendor stack is in scope. The DORA ICT third-party risk requirements run through the full supply chain: your KYC vendor, their sub-processors, and any infrastructure providers they use for critical functions.

Why did so many compliance teams miss this? Most focused on cloud infrastructure and payment processors first. KYC and AML SaaS tools process more regulated data than many internal systems: document images, biometric scans, PEP screening hits: but got categorized as “software subscriptions” rather than critical ICT dependencies. That categorization doesn’t survive a DORA audit. Regulators didn’t notice it was missing until they started actually checking.

DORA entered into force on January 16, 2023 and became fully applicable January 17, 2025. In 2026, national competent authorities are cross-checking Register of Information submissions and: per the EBA’s published roadmap: issuing the first threat-led penetration testing (TLPT) notifications to critical ICT TPPs.

If your KYC vendor contracts were signed before January 2025 and nobody updated them for DORA Art. 30 provisions, you have a gap regulators can find in a standard audit. That’s what the checklist below is designed to fix.

---

The 7-point DORA vendor checklist for KYC tools

Run through each point before signing a new contract or renewing an existing one. After reviewing items 1-2, you can jump to the vendor comparison table to see which platforms already have those certifications in place.

1. Get the vendor’s SOC 2 Type II report before you sign anything. DORA Art. 28(4) requires a pre-contractual risk assessment with a documented risk rating for each ICT TPP. SOC 2 Type I only verifies design at a point in time: it doesn’t cover operating effectiveness over 6-12 months, which is what DORA actually expects to see. Ask: “Can you provide your SOC 2 Type II report and completed security questionnaire responses?” Write down your risk conclusion before contract execution, not after.

2. Confirm the vendor’s standard MSA includes DORA Art. 30 provisions. Ask: “Can you provide a redline showing where each Art. 30 required clause appears in your contract?” If they haven’t prepared a DORA addendum yet, negotiate one before signing. The full clause list is in the Art. 30 section below.

3. Get a specific incident notification SLA in writing. Your DORA obligation is to notify your national competent authority within 4 hours of classifying a major incident. Your vendor must notify you fast enough to make that window: which means their contractual SLA needs to be under 2 hours for Severity 1 events. Ask: “What is your contractual notification SLA for Severity 1 ICT incidents?” If they don’t have one, you’re absorbing their response time risk.

4. Confirm audit rights are written into the contract, not just promised. DORA requires you to retain inspection rights over ICT TPPs: and those rights must extend to your national competent authority, not just your internal team. Ask: “Does the contract include explicit audit rights covering both our team and our competent authority?” Some vendors bury this in the DPA rather than the main agreement. Either location is fine, but it has to be in writing.

5. Ask for the exit strategy documentation. Art. 28(8) requires documented exit plans. Ask: “What does data export and off-boarding look like? What’s the timeline, and what formats do you support?” A vendor that can’t answer this creates both a DORA exposure and a concentration risk that supervisors will flag.

6. Assess concentration risk. DORA requires you to evaluate whether your ICT TPPs are substitutable. Ask: “What percentage of EU-regulated financial institutions depend on your platform for critical onboarding functions? What’s your uptime SLA and geographic redundancy?” Supervisory reviews are starting to flag vendors with high market share specifically.

7. Verify this vendor appears in your Register of Information with all required fields. Every ICT TPP contract must appear there: LEI number, DORA service category, criticality classification, contract dates, data categories processed, and geographic locations. See the RoI section below for what to collect from each vendor.

---

Which KYC vendors meet DORA ICT requirements

We assessed four commonly used identity verification and KYC platforms against primary DORA ICT security indicators. This reflects publicly available trust center documentation and vendor-provided attestations, verified as of July 2026.

Methodology note: We verify DORA readiness against public trust center documentation and vendor-provided attestations. This is an editorial assessment: not a legal opinion. Verify directly with your vendor before procurement.

Vendor	SOC 2 Type II	ISO 27001	DORA Readiness Statement	Audit Rights	Incident SLA	Starting Price
iDenfy	✓	✓	On request	Yes (DPA)	Negotiate in contract	€1.25/check
Veriff	✓	✓	Published (Trust Center)	Yes (MSA)	Enterprise contract	$0.80/check
Sumsub	SOC 2 only	✓	Trust Center	Yes (MSA)	Enterprise contract	$1.35/check
ComplyCube	SOC 2 only	✓	On request	Yes (DPA)	Status page + contract	from $99/mo

Veriff and iDenfy are the only two in this group holding SOC 2 Type II: the audit variant that covers operating effectiveness over time, not just design at a point in time. For your pre-contractual DORA risk assessment, that distinction matters. Sumsub and ComplyCube hold SOC 2 Type I, which covers design but doesn’t satisfy the ongoing evidence standard DORA expects documented.

All four carry ISO 27001 certification. None currently holds eIDAS 2.0 accreditation: that’s not a DORA requirement, but it’s relevant if you’re also tracking EU digital identity wallet obligations separately.

The “DORA Readiness Statement” column affects your procurement timeline. Veriff publishes its readiness documentation publicly, which speeds up your vendor qualification. Sumsub maintains a trust center that covers the relevant attestations. iDenfy and ComplyCube require you to request documentation through their enterprise sales process: factor that into your timeline.

For institution-type specific guidance, credit institutions and banks can compare platforms in our KYC software for banks review, which cross-references DORA ICT obligations against EBA credit institution supervisory priorities. Starting-price data from the table above is expanded with volume tiers and hidden-cost analysis in the KYC vendor pricing guide 2026.

→ Run this calculation for your volume: KYC Cost Calculator →

Compare all KYC and identity verification vendors on PrimeBiometry

---

DORA contractual clauses your KYC vendor contract must include

DORA Art. 30 lists what must be in your ICT TPP contracts. Here’s what that means in practice for a KYC vendor negotiation.

1. SLAs need a number, not a feeling. Uptime commitments must be a specific percentage (99.9%), not “reasonable efforts” or “best endeavors.” If the current contract uses soft language, request a service schedule with hard SLAs per component: API availability, document processing latency, AML screening response time.

2. Processing locations must be listed by geography. For EU-regulated fintechs subject to GDPR, this means confirming no data leaves the EU without an adequate transfer mechanism. Ask for a complete list of processing and sub-processing locations, including where AI model training occurs.

3. Audit rights need to cover both you and your competent authority explicitly. Generic “customer audit rights” clauses often don’t include the competent authority right that DORA Art. 30 specifically requires. Check the DPA addendum if it’s not in the main agreement.

4. Incident notification must have a defined timeframe. “Promptly” and “without undue delay” don’t satisfy DORA. Negotiate a specific SLA: we recommend 1-2 hours for Severity 1: that lets you meet your 4-hour reporting window. This is the most commonly absent clause in standard MSAs.

5. Data portability and deletion terms need specifics. Timelines for export, supported formats, deletion confirmation, and what happens to data held by sub-processors after termination. Vague “we’ll handle it” language fails Art. 28(8).

6. Sub-outsourcing arrangements must be disclosed and notified. Your KYC vendor probably uses sub-processors for liveness detection, document scanning AI, or AML database access. You need to know about these, and you need contractual notification when they change.

7. Business continuity needs specific RTO and RPO values for the identity verification API specifically. A generic “we have a DR plan” clause isn’t sufficient. Get the numbers.

If your vendor refuses any of these provisions, that’s a regulatory exposure you’re absorbing: not a negotiating position you can walk away from. The practical path is a DORA addendum to the existing MSA. Most enterprise KYC vendors have one prepared. If they don’t, that tells you something about where they are in their own readiness process.

For the broader compliance framework, see our KYC/AML compliance checklist for fintech.

---

Building your Register of Information for KYC vendors

According to the EBA’s 2024 DORA implementation progress survey, between 60% and 70% of EU financial institutions had a “work in progress” Register of Information at the January 2025 deadline. Only about 30% had a complete register. The RoI is the first document supervisors request in any DORA-related examination.

For each KYC and AML vendor, DORA Art. 28(3) and the EBA’s RTS on Register of Information require these fields:

Field	What to collect	Where to find it
LEI number	20-character legal entity identifier	Ask the vendor; Veriff and Sumsub publish it in their DPA
Service category	DORA taxonomy label	”Identity proofing and authentication” for KYC; “risk monitoring and compliance” for AML screening
Criticality	critical / important / non-critical	Your risk assessment: if it’s required for customer onboarding, “important” is the realistic minimum
Contract dates	Start date, end date, notice period	Your signed contract
Data categories	PII, biometrics, financial data	Your DPA; note that biometric data is GDPR Art. 9 special category, which also triggers a separate DPIA
Processing locations	All data center geographies	Vendor DPA or security addendum: must match what’s in your contract

The biometric data classification is the most common gap we see in practice. Teams list the KYC vendor in their register correctly but categorize document scans and facial biometrics as “standard personal data” rather than special category. That affects both the GDPR DPIA requirement and how the vendor gets classified for DORA criticality: and it’s the first thing a thorough supervisory review picks up.

In 2024, the EBA’s DORA implementation progress survey found that roughly 60-70% of EU financial institutions had a “work in progress” Register of Information at the January 2025 application date (EBA, 2024). Only about 30% had a complete register. The EBA has since made clear that the RoI is the first document supervisors will request in any DORA-related examination. If your register doesn’t include your KYC and AML vendors with correct DORA taxonomy entries, that’s the first gap they’ll find.

---

DORA incident reporting: what to require from your KYC vendor

Your DORA obligation is to notify your national competent authority within 4 hours of classifying an ICT incident as major. That clock starts when you classify it: not when the incident is resolved. And you can’t classify what your vendor hasn’t told you about yet.

That upstream SLA is more critical than most fintech compliance teams realize, and it’s also the most commonly absent clause in standard MSAs. Across the KYC vendor space, the most common incident language is “notification without undue delay”: which could mean hours or days, and doesn’t support your 4-hour reporting window.

What counts as a major incident under DORA? The EBA’s RTS on major incident classification sets indicative thresholds: service unavailability affecting more than 10% of your clients, financial impact exceeding approximately €5M, or any significant data breach. For a KYC platform, realistic triggers include: identity verification API outage during a high-volume onboarding period, AML screening downtime during transaction monitoring windows, or a security incident touching document images or biometric data.

What to negotiate into the contract: a maximum 1-2 hour notification SLA for Severity 1 incidents, routed through a dedicated security contact rather than a general support ticket queue. A public status page is useful supplementary information, but it can’t substitute for a contractual SLA you can enforce. For post-incident documentation: DORA Art. 19 requires an intermediate report within 72 hours and a final report within one month: your vendor needs to actively support that cycle, not just fix the outage.

Ask: “What is your contractual notification SLA for Severity 1 incidents, and can it be under 2 hours for enterprise customers?”

Under DORA Art. 19, major ICT incidents require initial notification to the national competent authority within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month (DORA Regulation 2022/2554, Art. 19). For a KYC vendor handling biometric data and document scans, a major incident triggers both DORA reporting and a GDPR personal data breach notification: two parallel regulatory clocks, different competent authorities, different timelines.

---

DORA fines and what active enforcement means in 2026

The grace period is over. National competent authorities across the EU are actively cross-checking Register of Information submissions, reviewing ICT vendor contracts for Art. 30 compliance, and issuing the first formal enforcement communications.

Institutional exposure runs up to 2% of global annual turnover or €10M, whichever is higher (DORA Art. 64). That’s not a total cap: it applies per violation type. Gaps in your Register, your vendor contracts, and your incident reporting each carry separate exposure.

Personal liability is the detail that changed the compliance conversation. Senior managers face individual fines up to €1M for failures attributable to them specifically. That’s a different category of risk than institutional fines, and it’s driving board-level attention in ways that earlier DORA implementation phases didn’t.

Vendors the supervisory authority designates as critical ICT TPPs face up to €5M per violation plus 1% of global daily turnover for up to 6 months of ongoing non-compliance (DORA Art. 35). None of the four KYC vendors in this review have been designated critical yet: but designation decisions can change as supervisors build out their vendor oversight frameworks.

The enforcement dynamic shifted between 2025 and 2026. Last year, examiners checked whether DORA frameworks existed. Now they’re asking for documentation: show the Register of Information, show the KYC vendor contracts with Art. 30 provisions, show the incident notification records. Verbal assurances and “in progress” answers are no longer accepted. First formal enforcement actions for reporting failures are expected in H2 2026.

---

Frequently Asked Questions

Does DORA apply to non-EU KYC vendors serving EU fintechs?

Yes. DORA applies based on the location of the regulated financial entity, not the vendor. If you’re an EU-regulated fintech using a US-based KYC vendor, that vendor is an ICT TPP under DORA. Your Art. 30 contractual obligations apply regardless of where the vendor is incorporated or headquartered.

Is my KYC SaaS vendor automatically an ICT third-party service provider under DORA?

Yes, if they provide ICT services supporting your regulated business functions. Identity verification, AML screening, KYC case management, and biometric authentication all qualify. DORA doesn’t carve out SaaS tools: classification is based on function, not delivery model.

What’s the minimum DORA due diligence before signing with a new KYC vendor?

DORA Art. 28(4) requires a pre-contractual risk assessment covering: the vendor’s information security posture (SOC 2 Type II / ISO 27001), data processing locations, subcontracting arrangements, financial stability, and business continuity capability. Document the assessment and your risk conclusion before contract execution.

Can I rely on my KYC vendor’s ISO 27001 certificate to satisfy DORA requirements?

ISO 27001 satisfies part of the security posture assessment but isn’t sufficient alone. DORA additionally requires specific contractual clauses (Art. 30), audit rights, incident notification obligations, exit strategy documentation, and Register of Information entries. It’s a baseline input to your risk assessment, not a DORA substitute.

How often must I review my KYC vendor’s DORA compliance?

DORA requires ongoing monitoring, not just pre-contractual review. Annual risk reviews are the minimum expectation. Event-triggered reviews are required on: material changes to the vendor’s services, significant incidents, ownership changes, or the vendor being designated critical by a supervisory authority.

---

Three things to do this week:

• Pull your KYC vendor MSA and search for “incident notification”: if there’s no specific timeframe, that’s a DORA gap.
• Ask your vendor for their LEI number and SOC 2 Type II report (not just Type I).
• Check your Register of Information: does this vendor appear with a criticality classification and biometric data flagged as special category?

Bottom line

Every KYC and AML SaaS tool in your compliance stack is an ICT third-party service provider under DORA. There are no exemptions for SaaS delivery, US incorporation, or small vendor size. If it processes data supporting your regulated functions, it’s in scope.

Key takeaways:

• All 7 checklist items require documented evidence: verbal assurances and “in progress” answers don’t satisfy DORA’s audit trail requirements.
• SOC 2 Type II is the baseline, not Type I. Among the four vendors assessed, iDenfy and Veriff hold Type II; Sumsub and ComplyCube hold Type I only.
• Register of Information is the first supervisory checkpoint: and 60-70% of EU institutions missed the January 2025 deadline with a complete register.
• Incident SLA gaps are the most common contractual failure: “without undue delay” doesn’t support your 4-hour reporting chain.

When narrowing the vendor shortlist, the Veriff vs Jumio comparison benchmarks both platforms on contract transparency, audit documentation, and AML bundling. The KYC/AML software architecture guide covers how to structure a full compliant stack across identity, AML, and fraud layers.

Compare KYC vendors with verified compliance documentation

---

James Whitfield is a Senior Security Analyst at PrimeBiometry, covering regulatory compliance, identity verification, and ICT risk management for financial services. He evaluates KYC and AML vendors against EU and US compliance frameworks. Questions or corrections: contact us.