ZAIT repealed: ICT risk for German payment and e-money institutions under DORA

Germany used to run its own IT rulebook for payment and e-money institutions. It does not any more — and the firms that simply renamed their ZAIT gap analysis “DORA” are the ones failing the first supervisory cycle. BaFin repealed the ZAIT circular with effect from the day before DORA became applicable, and a licensed German Zahlungsinstitut or E-Geld-Institut now sits directly under Regulation (EU) 2022/2554 — with German specifics that survive in the reporting plumbing rather than in the substantive rules. This piece sets out what was repealed and when, what replaced each obligation, how BaFin actually collects the register and the incident reports, and three scenarios where the transition goes wrong.

1. What was repealed, and when

DORA — Regulation (EU) 2022/2554 — has applied directly in Germany since 17 January 2025. To avoid double regulation, BaFin repealed its sector-specific IT circulars for the entities DORA now covers: the Zahlungsdiensteaufsichtliche Anforderungen an die IT (ZAIT) for payment and e-money institutions, together with VAIT for insurers and KAIT for asset managers, with expiry of 16 January 2025 — the day before DORA became applicable, leaving no gap and no overlap.

The banking circular survived longer. BAIT — Bankaufsichtliche Anforderungen an die IT, BaFin Circular 10/2017, in the version of 16 December 2024 — remains in force for KWG-regulated entities that are not caught by DORA’s ICT risk-management provisions, and is set for full repeal on 31 December 2026. Institutions subject to DORA’s ICT risk-management requirements fall outside BAIT’s scope. For a payment or e-money institution this is largely academic: BAIT never applied to you, ZAIT did, and ZAIT is gone.

2. The first thing to get right: Articles 5–15, or Article 16?

DORA is not uniform. Most financial entities apply the full ICT risk-management framework in Articles 5 to 15. A defined, narrow group applies the simplified framework in Article 16 — and the group is defined by exemption status, not by size in the ordinary sense. Article 16 reaches small and non-interconnected investment firms, payment institutions and electronic money institutions that are exempted under the payment-services and e-money directives, certain exempted credit institutions, and small institutions for occupational retirement provision.

The consequence for Germany is blunt. A licensed ZAG institution — a Zahlungsinstitut or E-Geld-Institut holding a BaFin authorisation — applies the full Articles 5 to 15, regardless of headcount or balance sheet. Only registered, exempted firms get the simplified regime. Being a twelve-person licensed EMI does not put you in Article 16; it puts you in Articles 5 to 15 with proportionality applied inside them.

3. Incident reporting: the clocks, and BaFin’s channel

Article 19 requires financial entities to report major ICT-related incidents to the competent authority. The timing is fixed by Commission Delegated Regulation (EU) 2025/301, and it is a three-report sequence rather than a single filing:

Where a deadline falls on a weekend or a bank holiday, the report may be submitted by noon of the next working day. That concession is narrower than it looks: it applies to the submission, not to the classification decision that starts the four-hour clock.

In Germany the report goes through BaFin’s Melde- und Veröffentlichungsplattform (MVP). The reporter must be registered in MVP and separately activated for the “Digital Operational Resilience Act (DORA)” specialist procedure, then submit under Meldung schwerwiegender IKT-bezogener Vorfälle. The primary route is the MVP web form with its three submission stages; a SOAP web service and a JSON file upload are available for firms that want to automate. An Excel template plus e-mail to the IKT-Vorfall@bafin.de mailbox exists only as a fallback for when MVP is unavailable. Voluntary notification of significant cyber threats under Article 19(2) uses a separate form to the same mailbox.

One activation detail derails more onboarding projects than any other: a legal entity identifier is a prerequisite for activation for the DORA procedure. A firm without a current, renewed LEI cannot be activated, and cannot report.

4. The register of information — where the old outsourcing habit fails

Article 28(3) requires every in-scope entity to maintain a register of information on all contractual arrangements for the use of ICT services provided by third-party providers. Commission Implementing Regulation (EU) 2024/2956 sets the templates and the identification rules — Article 3(5) requires each ICT third-party service provider to be identified by an LEI or, where applicable, an EUID.

The scope is materially wider than a classic outsourcing register. A German institution that populated its register from its existing list of notified outsourcings will be short: ICT services that do not amount to a formal outsourcing but still support business functions belong in the register too. Sub-contracting chains supporting critical or important functions have to be visible, not just the direct counterparty.

BaFin collects the register through the same MVP DORA procedure. Firms submit either an xBRL-CSV package built to the European supervisory authorities’ taxonomy or a BaFin-provided Excel template, against a 31 December reference date, in an annual submission window that BaFin publishes in the first quarter — for the 2026 cycle, a window in the second half of March. Confirm the exact dates each year on BaFin’s DORA pages rather than working from last year’s calendar.

5. Testing: everyone tests, few do TLPT

DORA splits resilience testing in two. The general digital operational resilience testing programme applies across in-scope entities and covers vulnerability assessments, scenario-based tests, performance testing and similar exercises on a risk-based cadence. Threat-led penetration testing is different: it applies only to financial entities identified by the competent authority as required to perform it, using the criteria in Article 26. Most German payment and e-money institutions will not be designated; those that are face a specialist exercise with defined tester requirements and authority involvement, on a multi-year cycle.

The failure mode is planning either extreme — assuming TLPT applies and over-buying, or assuming no testing obligation exists because you were not designated. The general testing programme is not optional.

6. Three transition scenarios

Scenario 1 — the licensed EMI that claimed Article 16. A fourteen-person German E-Geld-Institut reads that Article 16 provides a simplified framework for small payment and e-money institutions and scopes its programme accordingly: a short policy, no formal incident-classification procedure, no testing plan. The error is that Article 16 addresses exempted institutions, and this firm holds a full BaFin authorisation. Under supervisory questioning it has to rebuild against Articles 5 to 15 — board-approved framework, ICT asset and dependency mapping, classification criteria, a testing programme and a complete Article 28(3) register — under time pressure rather than on its own schedule.

Scenario 2 — the Saturday-night cloud outage. A payment institution’s card-authorisation service degrades at 02:10 on a Saturday. Duty staff triage it as a performance issue; at 07:40 on Sunday the incident manager applies the classification criteria and concludes it is major. The initial notification is due within four hours of that classification — and in any event within 24 hours of the firm becoming aware at 02:10, which is the binding constraint here. The weekend concession would allow submission by noon on Monday only if the deadline itself fell on the non-working day; it does not rescue a firm that took 30 hours to classify. The intermediate report follows within 72 hours of the initial notification, the final one within a month of the intermediate. Separately, there is no second PSD2 incident report to file: Directive (EU) 2022/2556 removed that duplication for PSPs that are DORA financial entities — though customer-communication duties under the payment-services rules are unaffected.

Scenario 3 — the register that fails in the submission window. A firm builds its Article 28(3) register from its outsourcing inventory: eleven arrangements, all with named providers. Two problems surface in March. First, a monitoring tool, a code repository and an e-mail security service were never treated as outsourcings and so were never inventoried — but they are contractual arrangements for ICT services and belong in the register. Second, three of the eleven providers have no LEI on file, and Implementing Regulation (EU) 2024/2956 requires an LEI or EUID for each. Neither gap can be closed inside a three-week window, because obtaining identifiers depends on the counterparty. The fix is upstream: make identifier capture and ICT-service classification mandatory fields at vendor onboarding, so the register is a query rather than an annual project.

7. FAQ

8. What to do, today

• Confirm in writing whether you apply Articles 5–15 or Article 16 — and base the answer on your authorisation status, not your headcount.
• Check that your LEI is current and that at least two named people are registered in MVP and activated for the DORA procedure, before you need them at 02:00.
• Rehearse the classification decision, not just the submission: the four-hour clock starts when you classify, and the 24-hour clock starts when you become aware.
• Re-derive the register of information from contracts for ICT services rather than from your outsourcing list, and add LEI/EUID capture to vendor onboarding.
• Retire any residual references to ZAIT in your internal policies — an ICT policy that still cites a repealed circular is an easy supervisory finding.

Related: Major ICT incident reporting under PSD2 and DORA · The DORA register of information · EMI licence in Germany (BaFin, ZAG) · German supervisory reporting