When DORA Doesn’t Apply: The NIS2 Article 21(2)(d) Gap Covering Your Visa Network and PSD2 API Providers

Every bank, payment institution, and investment firm subject to DORA has by now implemented a Register of Information listing its ICT third-party contracts. SWIFT connectivity—listed. Core banking SaaS provider—listed. Cloud infrastructure—listed. Most compliance officers assume that completes the third-party risk picture.

It does not.

NIS2 Article 21(2)(d) imposes a parallel supply chain security obligation that DORA’s Register of Information was never designed to satisfy—and it still applies to DORA-regulated financial entities for a specific, consistently overlooked category of supplier relationships. The Mastercard Clearing Management System. PSD2 third-party providers accessing your open banking APIs. Integration consultants who ran your ISO 20022 CBPR+ migration and may retain data-mapping access. None of these sit cleanly inside DORA’s ICT third-party framework. All of them require Article 21(2)(d) treatment under NIS2.

This article maps the exact boundary: which supplier relationships fall under DORA Chapter V, which fall under NIS2 Article 21(2)(d), and why three common financial supply chain relationships consistently land on the NIS2 side.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Does This Apply to Your Organisation? DORA Scope and the NIS2 Residual Obligation

DORA (Regulation EU 2022/2554) has applied to 21 categories of EU financial entities since 17 January 2025: credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central counterparties, central securities depositories, trade repositories, insurance and reinsurance undertakings, management companies, data reporting service providers, and several others. If your organisation falls within that list and operates in the EU, DORA’s ICT risk management framework governs your technology supplier relationships.

The widespread assumption in financial sector compliance programs is that DORA replaces NIS2 entirely. It does not.

NIS2 Article 4(1) establishes the displacement condition precisely: sector-specific EU legal acts displace NIS2 only where they require entities to adopt cybersecurity risk-management measures “at least equivalent in effect” to NIS2’s obligations. DORA achieves that equivalence for ICT risk management and incident reporting. Those NIS2 provisions are lawfully displaced for DORA-regulated entities under Article 4(1).

NIS2 Article 21(2)(d)—the supply chain security obligation—is a different case. DORA Chapter V provides an equivalent framework for ICT third-party risk management. It does not provide equivalent coverage for supplier relationships that fall outside its ICT service definition. Where equivalence is absent, NIS2 still applies.

For most banks, this means two parallel frameworks operate simultaneously: DORA Chapter V for ICT vendors, NIS2 Article 21(2)(d) for the supply chain outside DORA’s ICT scope. Both carry independent enforcement exposure. Under NIS2, essential entity penalties reach up to €10 million or 2% of global annual turnover—compounding any DORA enforcement action for ICT failures.

For a complete picture of NIS2 obligations applicable to the banking and financial market infrastructure sector, including entity classification and supervisory contact points, see the NIS2 banking and finance sector guide.

The Lex Specialis Line: Where DORA Chapter V Formally Ends

DORA Article 28 requires financial entities to manage ICT third-party risk “as an integral component of ICT risk within their ICT risk management framework.” The operative scope is ICT. DORA’s Chapter V applies to “ICT third-party service providers”—entities delivering “digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis.”

That definition is intentionally wide. Cloud infrastructure, software-as-a-service platforms, data analytics providers, API-embedded services, and payment-processing technology platforms all sit within DORA’s ICT scope. The EU Commission and EIOPA have confirmed, in EIOPA Q&A 2999, that payment-processing activities and payment infrastructures are included as ICT services where they are provided by non-regulated technology vendors.

But two carve-outs significantly limit that scope.

Carve-out 1: Regulated financial services provided between financial entities. The Commission and EIOPA (Q&A 2999, as reported by Freshfields) have clarified that where a providing entity is regulated under EU, member-state, or equivalent third-country financial law—and the service it provides constitutes a regulated financial service or an ancillary service integral to a regulated financial service—that relationship is treated as a financial service arrangement, not as ICT outsourcing. Both conditions must apply simultaneously. Where they do, the relationship exits DORA’s Chapter V entirely. The Luxembourg financial regulator (CSSF) has issued guidance consistent with this interpretation.

It is worth noting that the Q&A 2999 framework leaves some borderline cases genuinely ambiguous—particularly services with mixed regulatory triggers. Legal review is essential before classifying a specific relationship.

Carve-out 2: Non-technical services. Services without a digital or data component are excluded from the DORA ICT service definition. Non-technical services—cleaning, catering, delivery and courier services, traditional analogue telephone lines—do not qualify as ICT services under DORA Article 3(21). Physical service providers to financial entities fall entirely outside Chapter V.

Both carve-out categories retain a supply chain security obligation under NIS2. Article 21(2)(d) requires “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” The text covers all direct supplier and service-provider relationships, not only ICT ones. For everything DORA doesn’t reach, Article 21(2)(d) applies.

The NIS2 supply chain security guide covers the full Article 21(2)(d) framework across all sectors—a useful baseline before reading the financial-sector-specific analysis below.

Three Financial Supply Chain Relationships That Require NIS2 Article 21(2)(d) Treatment

The DORA–NIS2 boundary creates three specific supply chain categories where financial entities consistently need NIS2 Article 21(2)(d) controls despite operating an otherwise complete DORA program. Each arises from the same structural cause: a supplier relationship that does not qualify as ICT outsourcing under DORA’s definitions, but unquestionably creates supply chain risk that Article 21(2)(d) was written to address.

1. Payment Card Scheme Operators (Mastercard Clearing Management System, Visa)

Banks’ relationships with card network operators present the clearest practical example of the regulated-financial-services carve-out.

The Mastercard Clearing Management System is designated by the European Central Bank as a systemically important payment system (SIPS) under Regulation (EU) 2025/1355. It is overseen jointly by the ECB and the Nationale Bank van België/Banque Nationale de Belgique. As a regulated payment system infrastructure governed by EU financial law, the clearing and settlement services Mastercard provides to acquiring and issuing banks constitute regulated financial services—not ICT services within DORA’s Article 3(21) definition. The EIOPA Q&A 2999 framework applies: Mastercard operates as a regulated entity providing regulated payment settlement services, so the bank–Mastercard relationship is outside DORA Chapter V’s scope.

The position of Visa is similar in principle. Visa’s European payment system is monitored by the ECB under its payment systems oversight framework, and its card clearing and authorisation routing services to banks are regulated financial services. While Visa does not currently hold formal ECB SIPS designation, the same analytical framework—regulated entity, regulated financial service, both conditions met—indicates the bank–Visa relationship is outside DORA’s ICT scope. Legal review of the specific contractual characterisation is advisable.

The compliance consequence is direct: neither card scheme relationship appears in your DORA Register of Information. Both require NIS2 Article 21(2)(d) treatment as critical supply chain dependencies. This is not a cosmetic distinction. If card network clearing infrastructure were compromised at the settlement layer, transactions across every connected bank would be affected simultaneously. Treating that dependency as a financial service arrangement rather than an ICT vendor contract is legally defensible under DORA—but it creates an Article 21(2)(d) audit exposure if the bank has no documented criticality classification, no contractual security clauses in its scheme participation agreement, and no incident notification chain ensuring a scheme-level disruption triggers an internal NIS2 Article 23 early warning assessment.

Minimum NIS2 Article 21(2)(d) controls for card scheme relationships: documented criticality classification; security requirements in the scheme participation agreement or a separate security addendum where the scheme permits; and a clear mapping between a scheme-level incident and your own NIS2 Article 23 early warning obligation.

2. PSD2 Third-Party Providers Accessing Open Banking APIs

PSD2 (Directive 2015/2366) mandates that banks provide licensed Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs) with access to customer account data and payment initiation capability via dedicated API interfaces. Banks cannot refuse access to a nationally authorised TPP. The relationship is regulatory compulsion, not a procurement decision.

That mandate does not eliminate the NIS2 supply chain security obligation.

PSD2 TPPs obtain authenticated, persistent access to customer financial data at scale. A single aggregation platform operating as an AISP may connect to dozens of banks and hold refresh tokens for hundreds of thousands of end-users. If that TPP is compromised, its legitimate OAuth credentials become the attack vector—with no outward sign of intrusion visible to the bank, because the TPP’s traffic pattern looks authorised at the API layer. The bank receives no fraud signal; it receives normal API calls from a legitimate token holder whose back-end has been hijacked.

There is a strong case that PSD2 TPPs fall within the scope of NIS2 Article 21(2)(d)’s reference to “direct suppliers or service providers.” The TPP provides account information or payment initiation services to end-customers via the bank’s infrastructure; the bidirectional nature of that relationship—bank provides API access, TPP provides services through it—creates a security dependency that Article 21(2)(d) was designed to address. Whether regulators will interpret that relationship as a “service provider” relationship for Article 21(2)(d) purposes is not yet settled; legal advice is recommended.

Regardless of how that classification question is ultimately resolved, the practical security controls are the same. API activity monitoring with anomaly detection thresholds per TPP credential; contractual requirements in TPP onboarding agreements covering mandatory notification of TPP-side security incidents, token revocation procedures, and periodic confirmation of NCA authorisation status; and an incident response playbook that covers the “legitimate credentials, compromised TPP” scenario. These controls are not PSD2 SCA obligations—they are supply chain security controls applied to a mandated-but-risky access relationship.

PSD2 is under revision through PSD3 and the Payment Services Regulation (PSR). The incoming framework is expected to introduce stronger authentication and TPP liability provisions, but it does not eliminate the NIS2 Article 21(2)(d) obligation to manage the cybersecurity dimensions of TPP relationships.

3. ISO 20022 Migration Partners as a Supply Chain Transition Event

SWIFT’s global cutover to ISO 20022 CBPR+ messaging completed on 22 November 2025. Banks that had not migrated by that date began incurring penalty fees from January 2026 for continued use of SWIFT’s in-flow translation service. As of mid-2026, residual migration debt is still being resolved across the industry—approximately 33% of SWIFT members had adopted the new standard by early 2025, and the cutover created a concentrated final-quarter migration push with significant third-party vendor involvement.

The migration itself was a supply chain event of the first order.

Banks engaged message transformation middleware vendors, integration consultants, testing and validation platforms, and data-mapping specialists. Many of these vendors received access to live or production-equivalent payment flows for end-to-end testing, reconciliation, and format validation. ISO 20022’s richer data fields—Legal Entity Identifier (LEI), structured address blocks, extended remittance information, purpose codes—mean that vendors with data access during migration handled significantly higher-value financial data than MT message equivalents allowed. A compromised data-mapping consultant with production payment file access is a more serious exposure than the same compromise in a legacy MT environment.

The DORA classification of these vendors is not straightforward. Short-engagement migration consultants and testing platforms brought in under professional services agreements predating DORA’s January 2025 application date were frequently not registered in the ICT Register of Information. Whether they qualify as “ICT third-party service providers” under DORA Article 28 depends on the specific service characterisation; many professional services and consulting engagements fall outside DORA’s ICT service definition.

SWIFT itself, as a Belgian cooperative society owned by its member institutions rather than a commercial ICT vendor, also occupies a complex regulatory position. Banks should confirm with legal counsel whether their SWIFT connectivity relationship falls under DORA Chapter V or requires parallel NIS2 Article 21(2)(d) documentation. The answer has material consequences for which register the relationship appears in and which authority supervises compliance.

NIS2 Article 21(2)(d) obligations for migration events follow a clear logic: as new vendor relationships are established during technology transitions, classify each under the correct framework immediately; include incident notification requirements and access-scope limitations in the engagement contract; and implement a formal access-revocation process at project completion. Migration-related supplier relationships that were opened temporarily should not persist as unclosed access paths after the project ends. Competent authorities reviewing supply chain security compliance under Article 21(2)(d) will scrutinise exactly that gap.

Practical Compliance: Running a DORA Register and NIS2 Article 21(2)(d) Supplier List in Parallel

The most efficient approach for financial entities is a unified supplier repository with two classification layers: one for DORA ICT vendors (Chapter V treatment, Register of Information, critical/important function designation under Article 28), and a separate register for NIS2 Article 21(2)(d) suppliers (criticality assessed, security clauses applied, incident notification required, but not captured in the DORA Register).

The classification decision for each supplier centres on one question: does this entity provide ICT services as defined under DORA Article 3(21), or does it provide regulated financial services or non-technical services that fall outside that definition? If ICT—DORA Chapter V governs the relationship. If regulated financial services or non-technical services—NIS2 Article 21(2)(d) applies. For borderline cases, the EIOPA Q&A 2999 two-condition test (regulated entity AND regulated financial service) is the current primary guidance, and legal review is essential.

The contractual treatment differs materially between the two regimes. DORA ICT vendor contracts must include the key provisions mandated by DORA Article 29: clear service descriptions, audit rights, performance monitoring, RTO/RPO, subcontracting disclosure, exit strategy, and incident notification obligations. NIS2 Article 21(2)(d) supplier contracts require security clauses covering vulnerability disclosure, incident notification chains sufficient to support your own Article 23 timeline, access controls, and periodic security assessment—but are not required to replicate the full DORA Article 29 structure. A proportionate, risk-based approach calibrated to the criticality classification of each supplier is what competent authorities expect to see.

Supervisory jurisdiction over the two registers differs as well. DORA financial entity supervision runs through EBA, EIOPA, and ESMA at EU level, plus national financial regulators (the NCA under DORA is typically the prudential supervisor). NIS2 Article 21(2)(d) compliance is supervised by the national NIS2 competent authority—which for banking may be a different body, often the national cybersecurity authority or a sector-specific NCA designated under the member state’s NIS2 transposition legislation. A dual-register approach makes it straightforward to produce supply chain documentation for either supervisory body on request, without re-processing the entire supplier portfolio.

For a complete checklist of NIS2 obligations applicable to financial market entities—including supply chain, incident reporting, and governance requirements—see the NIS2 banking and finance compliance checklist.

Frequently Asked Questions

Does DORA completely replace NIS2 for banks?

No. DORA displaces NIS2 for ICT risk management and incident reporting, where DORA’s requirements are at least equivalent to NIS2’s obligations (per NIS2 Article 4(1)). NIS2 continues to apply for supply chain security obligations that fall outside DORA’s ICT scope—specifically, for non-ICT suppliers and for regulated financial service providers whose relationships are excluded from the DORA ICT service definition under the EIOPA Q&A 2999 two-condition test.

Are payment card schemes like Visa and Mastercard covered by DORA Chapter V?

The clearing and settlement services provided by card scheme operators to banks are regulated financial services, not ICT services under DORA Article 3(21), based on the EIOPA Q&A 2999 framework. The Mastercard Clearing Management System is additionally designated as a systemically important payment system (SIPS) under ECB oversight, further reinforcing its characterisation as a regulated financial service provider rather than an ICT vendor. Banks should therefore manage their card scheme relationships under NIS2 Article 21(2)(d). Legal counsel should be consulted on the specific contractual characterisation for your institution.

What minimum documentation does NIS2 Article 21(2)(d) require for non-ICT suppliers?

NIS2 Article 21(2)(d) requires financial entities to address “security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” In practice, competent authorities expect: a supplier criticality classification (distinguishing critical from non-critical suppliers); a supplier security policy governing baseline requirements; contractual security clauses or addenda for critical suppliers; a supplier security assessment record; and an incident notification chain ensuring a supplier-side incident triggers your own Article 23 early warning assessment. This documentation exists alongside—not inside—the DORA Register of Information.

When did the ISO 20022 SWIFT cutover happen, and why does it matter for NIS2 compliance now?

SWIFT’s MT-to-ISO 20022 CBPR+ cutover was completed on 22 November 2025. Banks that ran migration engagements with external consultants and middleware vendors in 2024–2025 may have open access paths, undocumented vendor relationships, or expired contracts that were never formally closed. NIS2 Article 21(2)(d) obligations apply at the point the supplier relationship is established—not only at go-live. A post-migration supply chain audit that reviews which migration vendors still retain system access or data-handling permissions is a straightforward Article 21(2)(d) compliance step that most banks have not yet formalised.

Sources

[1] NIS2 Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures

[2] NIS2 Directive (EU) 2022/2555, Article 4 — Sector-specific Union legal acts

[3] Regulation (EU) 2022/2554 (DORA), Article 28 — General principles for ICT third-party risk management

[4] Freshfields, ICT services amongst financial entities — EU Commission clarifies scope of DORA’s ICT third-party risk management obligations

[5] CSSF (Luxembourg), Definition of ICT services under DORA — New forms for ICT-third party arrangements

[6] Simpliant, Who is considered an ICT third-party service provider under DORA?

[7] European Central Bank, Payment systems oversight — Systemically Important Payment Systems (SIPS)

[8] SecurityToday.de (March 2026), DORA and NIS2 Simultaneously: How Financial Service Providers Manage the Compliance Double Pressure

[9] A-Team Insight, November 2025 Deadline for ISO 20022: Are We Ready?

[10] activeMind.legal, NIS2 vs DORA: Differences and Common Misconceptions