Den Schweizer Zahlungsverkehr im Blick

Montag 05.09.2016 Christian Walter
Christian Walter

Christian Walter ist Geschäftsführer und Redaktionsleiter von swiss made software. Bis Ende 2010 arbeitete er als Fachjournalist für das ICT-Magazin Netzwoche, publizierte zuletzt aber auch im Swiss IT Magazin, der Computerworld sowie inside-it.

Die Echtzeitüberwachung grosser Datenmengen wird immer wichtiger. So auch bei Six, wo ein neues Werkzeug die Überwachung von sieben Millionen täglicher Zahlungen in Echtzeit ermöglicht.

Im Blick: 1700 Events pro Sekunde verteilt über hunderte heterogener Systeme. (© Jule_Berlin/Fotolia)

Seit 1987 erfolgt die Abwicklung des gesamten Zahlungsverkehrs zwischen den Schweizer Finanzinstituten mithilfe des Interbank Clearing Systems (SIC). Betreiber ist die SIX Interbank Clearing Group unter Aufsicht der Schweizer Nationalbank. Trotz stetiger Evolution stösst das System seit einer Weile an seine Grenzen und wird zurzeit erneuert. Dies auch, um den geänderten Anforderungen Rechnung zu tragen – so stieg allein das Transaktionsvolumen um ein Vielfaches. Auch relevant ist die aktuelle Erneuerung im Zusammenhang mit der europäischen Harmonisierung des Zahlungsverkehrs im Rahmen von SEPA.

SIC4, so der Name des mehrjährigen Grossprojekts, gliedert sich in verschiedene Komponenten wie Buchung, Übertragung und Überwachung. Letztere wurde durch die Berner Firma mimacom umgesetzt. Ziel war ein System, das sieben Millionen täglicher Zahlungen in Echtzeit überwachen kann. Gleichzeitig wurde eine hohe Benutzerfreundlichkeit angestrebt. In der Vergangenheit wurden auftretende Probleme nicht automatisch angezeigt, sondern mussten entweder durch gezielte manuelle Suche oder aufgrund externer telefonischer Hinweise identifiziert werden. Zudem konnten die Nutzer nur über spezielle Transaktionsanwendungen mit dem System kommunizieren, für welche Expertenkenntnisse nötig waren.

Fast genauso aufwendig wie die Identifikation eines Problems war der Weg zu dessen Lösung, da häufig der Kontext fehlte. Beispielsweise konnte ein identifizierter Zahlungsstau nicht automatisch einer Bank zugeordnet werden, da diese nicht mit Klarnamen gespeichert waren, sondern nummeriert. Die der Kennnummer zugehörigen Details waren zusammen mit den Kontaktdaten in einem anderen System abgelegt. Der Nutzer musste zwischen verschiedenen Systemen hin- und herspringen, um sich ein Gesamtbild der Lage zu machen. «Bei historisch gewachsenen Systemen wird aus Wachstum irgendwann einfach Wucher. Dann wird es Zeit für etwas Neues», so Agim Emruli, mimacom. Zentrale Anforderungen waren also die End-to-end-Abbildung der Prozesse sowie ein medienbruchfreies Arbeiten. Six stellte ausserdem die zentrale Forderung auf, dass jeder Event binnen zweier Sekunden sichtbar sein musste. 

Genau wie bei Netflix

Da SIC4 nicht nur das Monitoring betrifft, sondern die Ablösung des Gesamtsystems, hatte mimacom das Privileg, fast auf der grünen Wiese anfangen zu können. Basis des neuen Systems ist Elasticsearch – ein Open Source Produkt. Die Lösung ist erst seit 2012 kommerziell am Markt, hat aber unter dem Namen Apache Lucene eine lange Vorgeschichte im universitären Umfeld. In den letzten Jahren taucht sie vermehrt an Orten auf, wo grosse Datenmengen in Echtzeit überwacht werden. Ein prominenter Kunde ist Netflix, der über 700 Server für die Echtzeit-Loganalyse parallel im Einsatz hat. «Das System skaliert sehr gut», so Emruli.

Es handelt sich aber um keine Out-of-the-box-Lösung. Vielmehr ist Elasticsearch «nur» der Motor des neuen Vehikels: Um richtig zu laufen sind wie bei einem Wagen weitere Komponenten wie Karosserie, Bremsen und Lenkrad nötig. Neben der eigentlichen Integration in die Umsysteme heisst das vor allem Benutzbarkeit. Vorgabe war nicht nur, die Daten in Echtzeit abgreifen zu können, sondern diese auch ansprechend und klar verständlich zu visualisieren. Dargestellt werden diese auf einem frei konfigurierbaren Dashboard als Ampeln. Die Nutzer legen fest, welche Werte überwacht werden und bei welchen Grenzwerten Alarm geschlagen wird. Dabei kommen weit mehr Variablen ins Spiel als nur die Anzahl Zahlungen.

1700 Events pro Sekunde

Jede Zahlung besteht aus mehreren sogenannten Log-Events deren Summe täglich etwa 50 Millionen beträgt. Diese Log-Events stehen für die einzelnen Schritte im Zahlungsprozess (Meldungseingang, Prüfung, Zahlungsbuchung, Meldungsausgang etc.). Je nachdem, wo das Problem auftritt, kommen unterschiedliche Strategien zur Problemlösung zum Einsatz. Dies, obwohl die unmittelbare Konsequenz sehr ähnlich ist. Probleme im Zahlungsverkehr manifestieren sich häufig in Form von Rückstau, also einer Menge nicht abgeschlossener Zahlungen. Hakt es einmal, kann diese Zahl schnell explodieren. Kein Wunder bei durchschnittlich 1700 Log-Events pro Sekunde. Deshalb ist es wichtig sofort zu sehen, bei welchem Schritt es im Zahlungsverkehr hakt.

Aber selbst die Identifikation des entsprechenden Events ist nur der erste Schritt. Anschliessend kommen zahlreiche weitere Variablen ins Spiel. Kein Wunder, bei sprichwörtlich hunderten involvierter, heterogener Bankensysteme. Liegt es zum Beispiel an der Infrastruktur? Gibt es einen geographisch isolierten Netzwerkausfall, der einen Teil der Systeme geschluckt hat? Liefern die Banken vielleicht falsche Zahlungsdaten? Sind diese komplett falsch oder nur teilweise? Ersteres deutet auf ein misslungenes Update hin, Letzteres macht eine andere Art von Übertragungsproblem wahrscheinlich.

Mithilfe des Dashboards lassen sich diese Werte frei definieren. Der Nutzer kann sich anschliessend durch die Anzeigen klicken und tiefer ins System blicken (Drill-down). Das ist auch ein Schlüsselelement des neuen Systems. Die Überwachung ist nicht statisch. Es gibt nicht nur Zugriff auf die einmal festgelegten KPIs; vielmehr sind diese nur Einstiegspunkte. Das neue System hat also ein exploratives Element, das es so als Standardlösung erst seit wenigen Jahren gibt. «Früher dachten Monitoring-Lösungen in vordefinierten Mustern. Eine rote Ampel signalisierte die Erkennung eines vordefinierten Problems. Dass die Interaktion komplexer Systeme auch nicht vorher erkennbare Probleme produzieren kann, musste man ignorieren. Bei uns kann der Nutzer in unstrukturierten Daten auf Suche gehen», so Emruli.

Agil mit Blick zum Ziel

Das Projekt wurde unter Verwendung agiler Entwicklungsmethoden durchgeführt. «Bei Six wusste man sehr genau, was man wollte. Auf dem Weg zum Ziel hatten wir aber viel Freiheit», so Emruli. «Die zentralen Anforderungen, sprich jedes Event in zwei Sekunden abbilden zu können, war Gegenstand der ersten Sprints. Alle zwei Wochen gab es ein neues Release. Nach sechs Sprints stand das minimum viable product.» Mit dieser Methodik konnte früh erkannt werden, ob die Kernforderung umsetzbar war. Mit jedem weiteren Sprint wurde wieder das Feedback auch von der Business-Seite abgeholt, um zu sehen, ob das Projekt auf dem richtigen Weg war, beziehungsweise wo etwas angepasst werden musste.

So konnte mimacom in zwölf Wochen mit drei Personen ein völlig neues Monitoring-System bauen, das sich nahtlos in ein Grossprojekt einfügt, an dem parallel zu mimacoms Team sieben weitere Teams beteiligt waren. Im April 2015 ging mit den Euro-Zahlungen die erste Komponente des neuen Zahlungssystems live. Frankenzahlungen folgen Anfang 2016. 

mehr davon...

...gibt es im neuen swiss-made-software-Buch "Fintech". Erhältlich als Print und eBook hier.