How to issue German IBANs

German IBANs are the simplest of the big-market formats — 22 characters, no national check overlay — but the institutional plumbing behind them runs through the Bundesbank’s Bankleitzahl system. The eight digits in the middle of every DE IBAN are not yours to choose freely: half are set by the Bundesbank, they encode a clearing area and an institution group, and they sit in a quarterly file whose fourteen fields decide whether your BIC, your check-digit method and your IBAN derivation work in German payments at all.

1. The German IBAN format

The German IBAN follows the ISO 13616 pattern DE2!n8!n10!n — 22 characters:

• Positions 1–2: country code, always DE
• Positions 3–4: the two ISO check digits (Modulus 97 under ISO/IEC 7064)
• Positions 5–12: the Bankleitzahl (BLZ) — the eight-digit German sort code identifying the payment service provider
• Positions 13–22: the ten-digit account number, zero-padded on the left where the underlying account number is shorter

Unlike Spain (CCC digits), France (RIB key) or Italy (CIN letter), the German IBAN carries no national check construct — only the ISO Modulus-97 check. German account numbers do embed institution-specific check-digit methods, but those live inside the account number and are validated by the issuer.

One presentation rule is worth passing to marketing and finance: the Bundesbank asks participants in cashless payments to show account details on letterheads and invoices as IBAN, BIC and the name of the payment service provider, and states that the Bankleitzahl is not to be shown separately. Where it does appear alone, the convention is two blocks of three and one of two, as in 390 601 90.

2. Who can be allocated a Bankleitzahl

Eligibility is narrower than “a firm in German payments”. Three categories of payment service provider can receive a BLZ: credit institutions within Article 4(1)(1) of Regulation (EU) No 575/2013 entitled to do business in Germany; payment institutions within § 1(1) no. 1 ZAG holding a permission under § 10 ZAG or § 39 ZAG (the European passport route); and other payment service providers within § 1(1) nos. 2, 4 or 5 ZAG. The Bundesbank notes that “bank” here is not used in the sense of § 39 KWG.

The Bundesbank allocates, amends and deletes sort codes, and the structure of the BLZ, the basis of allocation and the maintenance of the file are set out in an agreement between the German banking industry and the Bundesbank. Applications follow those guidelines — a separate track from the BaFin authorisation, best started as soon as the licence decision is in sight.

3. How the eight digits are built

The BLZ is numeric, eight digits, and not arbitrary. The Bundesbank fixes the first four; the applicant generally sets its own numbering in digits five to eight, in consultation with the Bundesbank.

The clearing areas run 1 for Berlin, Brandenburg and Mecklenburg-Vorpommern; 2 for Bremen, Hamburg, Lower Saxony and Schleswig-Holstein; 3 for the Rhineland; 4 for Westphalia; 5 for Hesse, Rhineland-Palatinate and Saarland; 6 for Baden-Württemberg; 7 for Bavaria; 8 for Saxony, Saxony-Anhalt and Thuringia. In the institution-group digit, 0 is the Bundesbank, 5 the Girozentralen and savings banks, 6 and 9 the cooperative sector, and 4, 7 and 8 are reserved for named large banks — leaving 1 to 3 for payment service providers not captured by another group. That is the range a new payments firm should expect.

Two refinements matter for group structures. A PSP may hold an additional BLZ to settle a high-volume business line’s traffic separately, differing from the main code in digits seven and eight. And moving seat to another clearing area, or changing institution group in a merger or a transfer, does not in principle force a new BLZ — but a PSP leaving an institution group may keep the code only with the consent of the groups involved.

4. The Bankleitzahlendatei and its calendar

The sort-code file is the directory of all valid BLZ, and the Bundesbank is emphatic about its purpose: the data serve only the automated processing of payments. It is not a postal address list and not a directory of every branch — at most one entry per BLZ per PSP per municipality, with exceptions during mergers.

The calendar is the part to diarise. The file is produced four times a year and takes effect on the Monday following the first Saturday of March, June, September and December. It is made available on the Bundesbank’s website, non-bindingly, by the twentieth calendar day of February, May, August and November — roughly a fortnight of lead time in which a routing table has to be rebuilt and tested. Two versions are published: both carry fields 1 to 13, and the extended file adds field 14, the applicable IBAN rule. The record is fixed-width ASCII, 168 characters standard and 174 extended, empty fields blank-filled.

5. The fields that decide whether payments reach you

Four fields carry the operational weight.

Field 2 — sort-code-holding or not. Exactly one record per reported BLZ carries the flag “1”, and those are the records used in payments. Where the same BLZ is used at other locations for further branches, those records carry “2” and exist only to support location-based lookup. Building routing from the wrong flag is a silent error.

Field 8 — the BIC. A PSP holds in principle one BIC per BLZ, and is obliged to record against every “1”-flagged BLZ a BIC under which it is reachable in all the SEPA schemes it has joined — SCT, SCT Inst, SDD Core and SDD B2B — plus paperless cheque collection, the German ATM system and SCC-format submission in electronic cash. Different BICs for different SEPA schemes cannot be reported; the same BIC may sit against several BLZ; only a “1”-flagged record’s BIC matters for payments. Because the file and the BIC directory update on different rhythms, a new BIC can be reported only once it is in the BIC directory at that file’s validity date, and may be replaced only by another SEPA-reachable one.

Field 9 — the check-digit calculation method. PSPs must use in payments only account numbers secured by the method recorded against them. The Bundesbank assigns new method codes centrally; codes may combine letters and digits except the letter “O”, and method “09” — no check-digit calculation — is permitted. “2”-flagged records inherit the code of the “1”-flagged record for the same BLZ.

Field 14 — the IBAN rule. IBAN rules are the PSP’s own instructions for deriving an IBAN from account number and BLZ. Each gets a four-digit code plus a two-digit version, starting at “00” and incrementing on change. The standard rule is “000000”; “000100”, no IBAN derivation, is permitted where the BLZ is not used in payments. The code appears only in the extended file, and a BIC held inside an IBAN rule is not the one to use for SEPA payments — that is field 8.

6. Deletion, succession, and the substitution trap

Field 11 marks each record: “A” added since the last close, “M” modified, “U” unchanged, “D” deleted. Deleted records appear one last time as a notice and must not be used in payments from that file’s validity date. Field 12 lets a PSP announce an intended deletion once it has told customers about the changed details — but the announcement is information only: the BLZ stays in use until actually deleted. Field 13 carries either “00000000” or the successor BLZ.

Here is the trap. Users may not substitute the successor sort code for the one inside an IBAN — with one exception: where field 14 shows the standard rule “000000”, the BLZ inside the IBAN may be replaced and the IBAN check digits must then be recalculated. Where a successor is published, users may adopt it in payment files by permanently replacing the old BLZ in account master data while keeping the account number. And a rule that cuts the other way: payment service providers are not entitled to replace sort codes with successor codes in payment files.

7. SEPA adherence and the German direct-debit reality

Scheme adherence sits alongside the BLZ work, and field 8 makes it concrete: the BIC you record has to be reachable in every scheme you have joined. SCT is the baseline; SCT Inst is mandatory for euro-area PSPs under the Instant Payments Regulation on its phased deadlines; and SDD Core and B2B are close to non-negotiable in Germany, where recurring household payments run on Lastschrift. A current-account product without direct-debit support is incomplete for this market, and mandate management is a launch feature, not a fast-follow. On settlement, German PSPs reach euro rails through the Eurosystem’s TARGET services, directly where they hold a settlement account or indirectly through a sponsor — the standard route for a new non-bank PSP.

8. What switches on at first IBAN issued

• Prudential and statistical reporting via ExtraNet
• § 43 GwG SAR reporting via goAML Germany
• The § 24c KWG account file where the firm issues accounts in its own name
• CESOP once the 25-payments-per-payee threshold is met on cross-border flows
• AWV external-sector reporting on cross-border positions and flows
• AnaCredit — only where the institution holds in-scope credit exposures; see AnaCredit for payment firms

9. Three worked examples

One: the IBAN that was “helpfully” migrated. Facts: a counterparty’s BLZ appears with field 12 = “1” and a successor in field 13; an operations team rewrites the stored IBANs to the successor code. Rule: substitution inside an IBAN is permitted only where field 14 shows the standard rule “000000”, and even then the ISO check digits must be recalculated; PSPs are in any case not entitled to replace sort codes in payment files. Action: read field 14 first, recalculate the check digits where substitution is allowed, and otherwise update account master data and wait for the customer’s new details. Outcome: no batch of structurally invalid IBANs.

Two: the BIC that was not yet in the directory. Facts: a firm obtains a new BIC in late February and reports it for the file taking effect on the Monday after the first Saturday of March. Rule: a new BIC may be reported only once it is also in the BIC directory at that validity date, and may replace an existing one only if SEPA-reachable. Action: line the two calendars up — BIC registration first, sort-code reporting second — and keep the old reachable BIC until the new one is live in both. Outcome: no interval in which the published BIC is unreachable.

Three: the routing table built on the wrong record. Facts: a validation service ingests the file and keys on the first record per BLZ, which for one institution is a location record. Rule: exactly one record per BLZ carries “1” in field 2, and only those are used in payments. Action: filter on field 2 = “1” at ingestion, and rebuild quarterly from the file effective on the Monday after the first Saturday of March, June, September and December. Outcome: routing keyed on payment-valid records, refreshed inside the two-week publication window.

10. What to do, today

• Start the BLZ application alongside the BaFin file, expect institution-group digit 1 to 3, and design any internal numbering scheme to fit positions five to eight.
• Sequence the BIC before the sort-code report: it must be in the BIC directory at the file’s validity date and SEPA-reachable when it replaces another.
• Ingest the file filtering on field 2 = “1”, and rebuild routing in the two-week window between publication (by the 20th of February, May, August or November) and validity.
• Record your check-digit method (field 9) and IBAN rule (field 14) deliberately — only the extended file carries field 14.
• Write the successor-BLZ rule into data-migration procedures: no substitution inside an IBAN unless the rule is “000000”, and recalculate the check digits when it is.
• Zero-pad account numbers to ten digits consistently — a padding inconsistency creates two “different” IBANs for one account.
• Plan SDD Core with mandate management as a launch feature, and map the post-go-live reporting catalogue before the first IBAN.

Related: AnaCredit phases 1, 2 and 3 · Dutch IBANs · Luxembourg IBANs · Spanish IBANs · EMI licence in Germany · Which BaFin licence you need in Germany · Kontenabrufverfahren — the § 24c KWG account file