How Does DORA Article 30 Apply When You Buy a Deepfake Detection or Identity API?

What does DORA Article 30 require in an ICT vendor contract?

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, was published on 27 December 2022 and has applied since 17 January 2025 to banks, payment and e-money institutions, investment firms, insurers, crypto-asset service providers and other EU financial entities. Chapter V governs ICT third-party risk. Article 28 sets the principles, Article 29 covers concentration risk and Article 30 lists the key contractual provisions.

Article 30(1) requires the rights and obligations of both parties to be clearly allocated in writing, in one document that includes the service level agreements. Article 30(2) then sets the minimum content for any contract for ICT services, whatever the function. The table summarises those nine elements and what they mean for a media authenticity or identity API.

Does a deepfake detection API support a critical or important function under DORA?

Often yes, but it is the financial entity's assessment to make. Article 28(4)(a) requires the entity to assess, before contracting, whether the arrangement covers ICT services supporting a critical or important function. A detection check that sits inline in account opening, video KYC, account recovery or high-value payment approval can stop those processes when it fails, and a silent degradation can let fraud through. Those are strong reasons to classify it as supporting a critical or important function. An offline research tool used occasionally by an investigations team is less likely to qualify.

Classification changes the contract. Article 30(3) adds six elements for critical or important functions: full service level descriptions with precise quantitative and qualitative performance targets; notice and reporting duties for developments that could affect service; requirements for the provider to implement and test business contingency plans and maintain appropriate ICT security; participation and full cooperation in the entity's threat-led penetration testing under Articles 26 and 27; unrestricted rights of access, inspection and audit for the entity, an appointed third party and the competent authority; and exit strategies with a mandatory adequate transition period. The entity must also inform its competent authority in a timely manner about planned arrangements for critical or important functions, and record every ICT arrangement in its register of information under Article 28(3).

What due diligence should come before signing a detection vendor?

Article 28(4) lists five pre-contract steps, and Article 28(5) adds that entities may only contract with ICT providers that comply with appropriate information security standards. For a deepfake detection or identity vendor, due diligence should cover both the security of the service and the evidence behind its accuracy claims, because a detector that quietly misses new attack types is an operational resilience problem as much as a fraud one.

• Classify the function the service supports and record the reasoning, including what happens to onboarding or payments if the API is slow, down or wrong.
• Check information security certifications and the scope they cover, and request the latest independent audit reports.
• Map data flows: what media leaves your environment, where it is processed, how long it is kept, and which sub-processors touch it.
• Test accuracy yourself on representative data and attack types, and ask how the vendor's published benchmark results were produced.
• Assess concentration risk under Article 29, such as several critical services on one cloud provider, and whether on-premises or private-cloud deployment reduces it.
• Agree an exit plan: data return, a transition period and a fallback control if the service ends.

How does DORA connect to deepfake fraud risk more broadly?

DORA is about operational resilience, not fraud law, but the two meet in identity controls. A bank that depends on liveness and face matching from one vendor has a single point of failure if attackers find a face-swap or injection technique that defeats it. DORA's insistence on testing, monitoring performance against quantitative targets and keeping exit options gives procurement teams a reason to ask for measurable detection performance and to plan for layered controls, rather than accepting a vendor's assurance that its model handles deepfakes.

It also shapes evidence. Article 30(3)(e) audit rights and the general record-keeping in Chapter V mean the entity should be able to show supervisors how each detection decision was reached: the signals returned, the model version and the policy applied. Vendors that return signal-level evidence make that easier than those that return a single opaque yes or no.

How does NeuroVerify support a DORA-aligned procurement?

NeuroVerify is Neural Defend's deepfake and manipulation check for faces in onboarding, recovery and payment flows. One API call analyses a face image, video or audio and returns one unified risk score with signal-level evidence from six signals: Visual Safety Screening, Live Presence Verification, Face Manipulation Detection, AI Generative Model Analysis, AI Pixel-Level Manipulation and AI Content Compliance. Eligible image requests return in under 200 ms at p95 under defined test conditions, with methodology available on request, which gives a concrete figure to write into Article 30(3)(a) service levels after you confirm it on your own traffic.

For data location and concentration risk under Articles 29 and 30(2)(b), Neural Defend deploys as a managed cloud API, in a private cloud or VPC, as a secure container, on-premises or air-gapped, scoped during evaluation. On-premises and air-gapped options keep biometric media inside your environment and reduce dependence on a shared cloud. Neural Defend holds ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 42001 and SOC 2 Type II certifications, relevant to the Article 28(5) information security test and to GDPR processor due diligence.

For accuracy evidence, the public VendorBench-100 benchmark tested 36 systems on 100 adversarial still images; Neural Defend ranked first with an MCC of 0.876 against 0.646 for the next vendor. One VendorBench author also co-authored Neural Defend's ARCAS 1B paper, and the corpus and results are public so your team can rerun them. The benchmark does not measure video, audio, injection attacks or latency, so include those in your own testing.