Fehler in der Schnittstelle
Schnittstellen sind „in“. Wer neben regulatorischen Themen noch Luft hat, arbeitet jetzt an Schnittstellen – denn die sind Basis einer jeden Digitalisierungsstrategie, und wer keine Digitalisierungsstratgie hat, ist sowieso out. Mit dem richtigen Blickwinkel wird ohnehin alles irgendwie zur Schnittstelle: Das neue online-Banking? Eigentlich nur eine Web-Schnittstelle zum Zahlungssystem. Der Robo-Advisor? Eine Schnittstelle vom Online-Portfolio-System zur Wertpapierabwicklung. Bitcoin? Eine dezentrale Blockchain-Datenbank, die durch Schnittstellen zusammengehalten wird.
In einem aktuellen Projekt teste ich gerade Schnittstellen. Ein neu programmiertes System zur Vermögensverwaltung liest Daten aus etwa einem Dutzend verschiedener Schnittstellen, die von Depotbanken gestellt werden. Ein erster Test besteht in einem Vergleich der Depot- und Kontoauszüge der jeweiligen Bank mit dem, was im neu programmierten Zielsystem ankommt. Wenn die Zahlen abweichen, muss auf dem Transportweg von der Bank über Schnittstelle und Konvertierung ins Zielsystem etwas schief gelaufen sein. In einer neuen Software darf man Fehler erwarten, und tatsächlich kam es bisher bei jeder Bank zu Abweichungen. Bemerkenswert ist jedoch, dass nur etwa die Hälfte der bisher gefundenen Fehler an dem neuen System lag. Die andere Hälfte waren Differenzen zwischen den Berichten und den gelieferten Daten, also Differenzen in der Bank!
Die Recherchen konnten belegen, dass Daten aus Bankschnittstellen nicht übereinstimmen mit den Daten auf den Kundenberichten. Wie kann das sein? Durch Vorschriften der Aufsicht zum Risikomanagement (MaRisk) und die „Bankaufsichtlichen Anforderungen an die IT“ (BAIT) sind Regeln vorgegeben, die auch die Banken zu Tests verpflichten. Aber wie heisst es so schön: Tests belegen nicht die Abwesenheit von Fehlern, sondern die Anwesenheit. Und natürlich liegt der Teufel im Detail. Einige Differenzen fallen in die Kategorie „das muss man nur richtig interpretieren“. Dazu gehört als Klassiker die Abgrenzung nach Handel- oder Valutadatum. Aber auch Bewertungsfragen (Depotauszug zeigt Xetra-Schlusskurs, Schnittstelle nutzt andere Kursquelle) oder der Umgang mit nachträglichen Korrekturen (im Bericht drin, in Schnittstelle nicht). Andere Differenzen fallen in den „menschlichen“ Bereich: Gebühren manuell mit falschem Buchungsschlüssel gebucht (erscheint im Bericht als Auszahlung, in Schnittstelle als Fremdgebühr), oder auch ein alter Bekannter: Ein Wertpapier in Pfund angelegt (GBP), obwohl der Kurs in Pence (GBX) geführt wird. Der Kunde freut sich über den um Faktor 100 erhöhten Wert seiner Position.
Schlimmer sind die echten Fehler. Unglaublich aber wahr: In einem Kontoauszug der Bank ergab Anfangssaldo plus der aufgeführten Kontobewegungen nicht den Endsaldo. Ursache (aber keine Entschuldigung) war ein Storno, das in der Summe berücksichtigt war, in den Kontobewegungen aber nicht. Einer meiner Lieblingsfehler ist der mit dem Semikolon. Da viele Schnittstellen die Werte in einer Datei durch Semikolon voneinander trennen (Erika;Mustermann;Miete für Mai;800.00;EUR;) kann ein Semikolon im Buchungstext Böses anrichten. Die korrekte Handhabung muss sauber programmiert werden (z.B. das Feld in Anführungszeichen setzen), was aber gelegentlich unterbleibt oder falsch umgesetzt wird. Schreibt Frau Mustermann auf ihren Überweisungsauftrag so etwas wie „Miete für Mai; 1998“, werden im schlimmsten Fall 1998,- EUR überwiesen. Je nachdem, welche Felder danach stehen, kann auch z.B. die Kontonummer ins Betragsfeld rutschen. Das erinnert an die Berichte über die ungewollten Überweisung von 28 Milliarden bei der Deutschen Bank: Vielleicht ist nur die elfstellige Kontonummer mit „28“ am Anfang ins Betragsfeld gerutscht?
Da hätten wir also ein Rezept, um schnell reich zu werden: Geben Sie bei ihrer Bank ein paar Überweisungsträger mit kreativ gesetzten Semikolons im Buchungstext ab. Wenn sie es schaffen, ihre eigene Kontonummer in das Feld für das Zielkonto zu „schieben“, geht die nächste Milliardenüberweisung an Sie.