Auch wenn die Übergangsfrist zur SEPA-Einführung jetzt noch einmal verlängert werden soll, werden die neuen IBANs das alte Duo „Kto. und BLZ“ bei innerdeutschen Transaktionen ablösen. Die IBAN – das ist die neue und jetzt auch EU-weit einheitliche Kontonummer, die so kompliziert ist, dass man es den Menschen noch nicht einmal zutraut, sie fehlerfrei angeben zu können – und daher eine „zweistellige Prüfziffer“ eingebaut hat.
Richtig gehört, nicht etwa zwei Prüfziffern, sondern eine zweistellige Prüfziffer. Oxymoron detected!? War es nicht so, dass das Wort „Ziffer“ ein (einziges) Zahlzeichen bezeichnet und eine Ziffer daher gar nicht zweistellig sein kann? So wie ein Buchstabe auch selten zweistellig ist? Aber das nur am Rande.
Aus der „Übersicht über die SEPA-Regeln“ der Bundesbank geht hervor, dass eine deutsche IBAN wie folgt aufgebaut sein muss:
- 2 Stellen für das Länderkennzeichen (DE für Deutschland)
- 2 Stellen für die „zweistellige Prüfziffer“
- 8 Stellen für die Bankleitzahl
- 10 Stellen für die Kontonummer
Macht summa summarum 22 Stellen. Kontonummern mit weniger als 10 Stellen werden „linksbündig mit Nullen aufgefüllt“. Eine IBAN könnte also so aussehen: DE32153412760000012015
Wie viele Nullen stehen da? Zugegeben, wenn die IBAN ordentlich in Vierergruppen formatiert angegeben wird, ist es ein bisschen einfacher zu sehen; aber in der Praxis kann man sich eben nicht darauf verlassen, dass sich jeder an die empfohlene Schreibweise hält: DE32 1534 1276 0000 0120 15
Wenn jemand aus dem Ausland nach Deutschland überweist, kommt neben den 22 IBAN-Stellen auch noch die acht- oder elfstellige BIC dazu, die ebenso komplex ist und noch dazu redundante Informationen enthält, da sie den internationalen Ersatz für die Bankleitzahl darstellt.
Es ist offensichtlich, dass bei der Entwicklung der IBAN die einfache Merkbarkeit oder Abtippbarkeit zweitrangig war, stattdessen stand scheinbar die einfache Verarbeitung in Computersystemen im Fokus. Die können fünf Nullen nämlich problemlos von sechs Nullen unterscheiden, der Mensch (bei entsprechend schlechter Darstellung) eben nicht auf den ersten Blick. Außerdem soll die Nummer konstant 22 Stellen haben. Wie, deine alte Kontonummer ist zu kurz? Na, öhm, dann füll die doch linksbündig mit Nullen auf! Dann passt das doch!
Wenn man schon so ein Zahlenmonster haben will, hätte man nicht wenigstens sowas wie DE-Prüfziffer-BLZ-Kontonummer machen können? Also DE-32-15341276-12015? Das wäre dann schon mal etwas besser merkbar und vor allem besser abschreibbar.
Ach ja, richtig, dann könnten IBANs ja unterschiedlich lang sein. Dann müssten die armen Programmierer ja, äh… – Ja, was müssten sie denn? iban.split("-") anwenden? Wo ist das Problem?
Aber die Datenbankler! Die müssten ja, äh… – Genau. Nichts anderes als jetzt auch. Es gäbe zwar keine konstante Länge, aber eine maximale Länge könnte man immer noch festlegen. Da könnten dann alle ihre Datenbankfelder drauf eichen und das Problem ist gelöst.
Aber die Überweisungsträger in den Banken! Die müssten ja, äh… – Richtig. Die würden auf die Maximallänge von meinetwegen 25 Zeichen (22 + 3 Bindestriche) ausgelegt, fertig.
Für die Systeme in anderen EU-Staaten ließe sich sicher eine ähnliche Lösung finden.
Aber entfernen wir uns doch mal von den numerischen Zeichenfolgen. Wie wäre es denn mit einer Kontoadresse gewesen, im Stil von Mailadressen: max.muster@beispielbank-berlin.de. Das ist einfach zu merken, der Domainteil (beispielbank-berlin.de) ersetzt die BLZ (bzw. die BIC und den entsprechenden Teil der IBAN), und der Localpart (max.muster) ersetzt die Kontonummer (bzw. den entsprechenden Teil der IBAN). Und wenn mein Name schon vergeben ist, dann nehme ich halt mein Geburtsdatum, meinen Ort oder den zweiten Vornamen meines Haustiers mit dazu. Das klappt bei Mailadressen doch auch. Konten bekommen einfach Namen statt Nummern.
Was im Internet schon lange funktioniert, hätte man auch gut auf das Bankenwesen übertragen können. Bei der Entwicklung eines Adressierungskonzepts, mit dem Millionen von Menschen umgehen können müssen, die einfache maschinelle Verarbeitung an erste Stelle zu stellen, halte ich für den größten möglichen Denkfehler: der Mensch sollte sich nicht an die Maschine anpassen müssen, sondern die Maschine an den Menschen. Maschinen lassen sich programmieren, und auch wenn der Programmcode dann halt komplexer wird: Who cares? Da müssen die armen Programmierer und Datenbankler dann halt mal durch, dafür werden sie schließlich bezahlt. Und das Argument, dass eine andere Kontobezeichnung ja die Systeme ausbremsen würde weil das ja so schrecklich unperformant wäre, lasse ich im Falle der Banken nicht gelten – die brauchen doch sowieso Stunden und Tage für die Verarbeitung einer einfachen Überweisung, für ein einfaches Rumschubsen einiger Bits von einer Datenbank in die andere, da machen mir die paar Sekunden auch nichts mehr aus.
Auch das Vergangenheitsargument ist aus meiner Sicht ungültig: „Das mit den Zahlen, das hat doch schon immer funktioniert!“ – Ja, hat die Leute aber auch schon immer genervt. Bei der Gelegenheit, wo sich jetzt sowieso alle umstellen müssen, hätte man auch mal etwas weiter denken können. Stattdessen dürfen wir uns mit noch komplexeren Zahlenmonstern herumplagen. Danke, liebe Verantwortliche, dass ihr so engstirnig an die Sache herangegangen seid, mit einem Vereinheitlichungsanspruch, aber nicht mit einem Vereinfachungsanspruch.