Kontenabrufverfahren — the § 24c KWG account file in Germany

Germany does not run a central bank-account register in the way France or Luxembourg do. It runs something stranger and, for a payments firm, more demanding: every institution keeps its own account file, and the supervisor reaches into it directly. The firm is required not to know when that happens. The obligation sits in § 24c of the Kreditwesengesetz, it reaches payment and e-money institutions through a cross-reference most licence projects never open, and since 2020 it has had a virtual-IBAN chapter that changes what a German correspondent will ask you for. This is how the Kontenabrufverfahren actually works, and where firms get it wrong.

1. The Dateisystem, not a register

Under § 24c Abs. 1 KWG, a credit institution must maintain a data file — a Dateisystem — in which it records, without delay, each account, securities deposit and safe-deposit box it keeps. The same duty attaches to the Deutsche Bundesbank in respect of accounts it keeps for third parties. There is no central database into which anyone uploads: the data stays with the institution, in a defined structure, and the supervisor queries it.

That choice explains most of what follows. There is no submission to schedule, no acknowledgement to reconcile and nothing to archive as proof of filing — only an accuracy and availability obligation running continuously, plus a legal requirement that the institution be blind to its own file’s use.

2. The fields, and the two deletion clocks

The record set is identity data, not balances: for each account, deposit or box, the number, the opening and closure dates, the name of the holder and of anyone with a power of disposal — with date of birth for natural persons — and the name and address of any beneficial owner within the meaning of the Geldwäschegesetz.

Retention runs on two separate clocks, and conflating them is the commonest data-lifecycle defect here:

Worked example. A customer changes surname after marriage and moves address in the same month. Facts to rule: two declared attributes changed, so § 24c Abs. 1 requires a new record, and the prior one survives for three years rather than being overwritten. What the engineer does: make the account file append-only with an explicit supersession pointer, and run the three-year purge against the record’s creation timestamp, not the account’s. Outcome: a retrieval landing eighteen months later still resolves the customer’s former name — which is the entire point of holding history. The failure mode is a nightly job that updates in place, deletes on closure, and quietly destroys both clocks at once.

3. Payment and e-money institutions are in scope — through the ZAG

§ 24c KWG addresses credit institutions, which is why payment and e-money institutions read the provision, conclude it is a banking rule and move on. It is not. § 27 Abs. 2 Satz 1 of the Zahlungsdiensteaufsichtsgesetz declares §§ 6a, 24c, 25i, 25m and 60b KWG, together with § 93 Abs. 7 and 8 in conjunction with § 93b of the Abgabenordnung, to apply correspondingly to institutions within the meaning of the ZAG. Satz 2 adapts the retrieval right so that BaFin may pull individual data from the § 24c Abs. 1 file for its supervisory tasks under the ZAG.

So a German-authorised payment or e-money institution owes the same file, on the same terms, as a bank. This is a build, not a policy paragraph: an always-current identity file, queryable by an external party, carrying history.

4. Virtual IBANs: the order that reshaped correspondent relationships

On 8 December 2020 BaFin issued a general order (Allgemeinverfügung) under § 6 Abs. 3 in conjunction with § 24c Abs. 1 KWG, addressed to credit institutions within the meaning of § 1 Abs. 1 KWG that issue German-country-code IBANs to payment service undertakings for onward distribution to those undertakings’ own customers.

The order requires each such virtual IBAN to be recorded in the § 24c file promptly, correctly and completely, with the payment service undertaking as the account holder and the end customer — or the ultimate natural person behind them — as the person with power of disposal or as beneficial owner. It carves out the case where a virtual IBAN goes to a customer that is not a payment service undertaking and serves only to ease that customer’s own bookkeeping.

Two features of the order matter more than its substance. First, institutions that had already issued virtual IBANs were given six months from notification to record them retrospectively — and where that proved impossible to do correctly, completely or in time, the order requires the institution to terminate the accounts through which those virtual IBANs are processed, or otherwise ensure the identifiers can no longer be used. Second, BaFin’s reasoning states expressly that the issuing bank’s own recording duty is unchanged even where the payment service undertaking is itself subject to § 24c Abs. 1 — while allowing the data to be collected through that undertaking.

Worked example. An e-money institution distributes DE virtual IBANs issued by a German correspondent to its own retail customers. Facts to rule: the correspondent is inside the December 2020 order and must hold every end customer in its own file; the e-money institution is separately obliged under § 27 Abs. 2 ZAG. What the compliance officer does: treat the correspondent’s data request as a regulatory requirement with a termination consequence attached rather than a commercial ask, and build one reconciled feed — identifier, holder, end customer, power of disposal, beneficial owner, opening and closure dates — that populates both files. Outcome: the same identity record answers a retrieval from either side. The failure mode is two divergent files, found when a retrieval returns an end customer at one institution and nothing at the other.

5. Two doors, and only one of them tells the customer

Retrievals reach the same file from two statutory routes, and the difference in what the account holder learns is the part customer-facing teams need to understand.

Neither route returns money. A retrieval answers who holds what, where, and since when; anything beyond that needs a separate information request or a court order. The BZSt acts as an intermediary and does not vet the merits of a request — responsibility for the lawfulness of each retrieval rests with the authority that made it.

6. Blindness, and the person who owns the procedure

§ 24c Abs. 1 requires the institution to ensure, by technical and organisational measures, that retrievals do not come to its knowledge. That is an unusual control objective: access logging normally exists to make access visible, and here the goal is the opposite for one class of reader. In practice the retrieval interface must raise no operational alert, appear in no customer-facing case history and feed no relationship-management tooling — and the control has to be evidenced, because an incidentally-visible query is a breach even where nobody acted on it.

Alongside it sits a governance requirement that is easy to let go stale. BaFin’s Rundschreiben 9/2010 (GW) requires participating institutions to staff the defined roles — including a person responsible for the procedure — and to notify BaFin of those role holders and their contact details, reporting changes without delay. BaFin’s Merkblatt of 4 May 2022 collects its notes on the procedure. Neither is technically demanding; both are the kind of standing notification that survives three reorganisations unamended, and both are trivially checkable in an inspection.

7. What AMLD6 changes, and what it does not

Germany’s model is a permitted implementation of the EU requirement, not an outlier — but the requirement is being tightened. Article 16 of Directive (EU) 2024/1640 obliges Member States to maintain centralised automated mechanisms allowing timely identification of persons holding or controlling payment accounts, IBAN-identified bank accounts including virtual IBANs, securities accounts, crypto-asset accounts and safe-deposit boxes. Article 16(3)(d) requires, for a virtual IBAN, both the identifier itself and the unique identifier of the account to which payments addressed to it are redirected — the EU catching up with what BaFin ordered in 2020.

Two dates anchor the plan: transposition by 10 July 2027, and interconnection of the national mechanisms through the bank account registers interconnection system, BARIS, which the Commission is to deliver with Member States by 10 July 2029. Financial intelligence units, and AMLA for joint analyses, are to have immediate and unfiltered access.

One trap is worth naming now. Article 16(8) sets availability at five years after account closure, with an optional further five where a Member State establishes necessity. That is a floor, not a ceiling, and it is shorter than the ten years § 24c already runs. A German firm that reads the Directive and shortens its retention to five years will be non-compliant with the national rule that still binds it.

8. Questions that come up

9. What to do, today

• If you hold a ZAG authorisation, confirm in writing whether § 27 Abs. 2 Satz 1 puts you inside § 24c — and if it does, whether the file exists.
• Separate the two deletion clocks in code: three years from creation of a superseding record, ten years from account closure. An update-in-place job breaks both.
• Map every virtual IBAN you issue or receive to a named end customer and beneficial owner, and agree with the correspondent which side collects what.
• Evidence the blindness control — show that retrievals raise no alert, no case note and no CRM entry.
• Re-confirm the role holders notified to BaFin under Rundschreiben 9/2010 (GW), including contact details, and put the check on an annual cycle.
• Do not shorten retention to the five years in Article 16(8) of Directive (EU) 2024/1640. Ten years still binds in Germany.

Related: Account registers compared across the EU · How to issue German IBANs · Transparenzregister and beneficial owners · § 43 GwG and goAML in Germany