Die Aufsicht fordert beispielsweise einen unterbrechungsfreien Betrieb, sofern eine Bank Instant Payments verarbeiten möchte. Welche Herausforderungen das für die Architektur bedeutet, haben wir beim TRAVIC-Payment Hub am eigenen Leib erfahren. Hinzu kommen die zahlreichen Umsysteme, wie Geldwäsche oder Embargo- und Sanktionslisten, von der Leitwegsteuerung ganz zu schweigen. Alles selbst zu machen, bedeutet allein aus Kostengründen für viele Banken, Zahlungsverkehr dann lieber gar nicht zu machen – also auszulagern oder von einem Zentralinstitut innerhalb eines großen Verbunds erledigen zu lassen. Das aber ist keine Option, sofern sich der Zahlungsverkehr zu einem strategisch wichtigen Geschäftsfeld entwickeln soll.
Jahrmarkt-Karussell für Zahlungen
Wir haben uns deshalb gefragt, was genau die „Special Sauce“ ist, die Banken in ihre ZV-Systeme kippen können müssen, um sich vom Wettbewerb zu unterscheiden und Zahlungsverkehr als eigenes Produkt anbieten zu können. Das ist besonders dann relevant, wenn sich ein Institut darum bewirbt, für Firmenkunden den Zahlungsverkehr in einer bestimmten Weltregion abzuwickeln. Und siehe da: In sich gleichen sich zahlreiche Abläufe von Bank zu Bank, sie unterscheiden sich häufig nur darin, in welcher Reihenfolge sie diese durchführen. Dieser Erkenntnis folgend haben wir das Bild von einer ZV-Plattform entworfen, die wie ein Karussell funktioniert. Jede Spezialfunktion soll, wie Kinder auf dem Rummel, überall zusteigen können (vgl. Abb. 1).
Der TRAVIC-Payment Hub erlaubt einer Bank, jede nur denkbare Konfiguration abzubilden. Das gilt sowohl für die Leitwegsteuerung, für die sich nahezu beliebig komplexe Regelwerke festlegen lassen, wie auch für die anzusteuernden Umsysteme. Woher aber weiß der TRAVIC-Payment Hub, was geschehen soll, wenn etwa vom Compliance-System ein bestimmter Status zurückkommt? Normalerweise müssen sich die Umsysteme doch daran orientieren, was das führende System vorgibt – warum sollte eine Bank, nachdem sie sich möglicherweise in der Kernverarbeitung bereits des Monolithen entledigt hat, sich im Zahlungsverkehr gleich den nächsten hinstellen? Die Antwort liefert eine integrierte Workflow-Engine, die über eine eigene Skriptsprache verfügt, um vergleichsweise simpel – und unabhängig vom Hersteller, also auch von uns – die übrigen Systeme anzubinden.
Das „Hub“ in TRAVIC-Payment Hub ist insofern Produktname und Leistungsversprechen zugleich.
Software-Entwicklung Inside-Out
Technisch krempeln wir das, was sich anderenfalls zu „Legacy“ entwickeln würde, nach außen. Die implementierte Skriptsprache ermöglicht einer Bank, die eigene Fachlichkeit in den TRAVIC-Payment Hub einzufügen, ohne dafür den Quellcode der Software selbst aufmachen zu müssen. Weil Technik und Fachlichkeit voneinander getrennt sind, rückt ein wesentlicher Teil der Software-Entwicklung aus der Sphäre des Herstellers in die Sphäre der Anwender. Dadurch bleibt die ZV-Plattform releasefähig, obwohl der TRAVIC-Payment Hub ein möglicherweise komplexes Netz an Umsystemen steuern muss. Zudem kommen die IT-Abteilungen gar nicht erst in die Versuchung, zu nahe an der ZV-Kernverarbeitung zu entwickeln und damit das Risiko einzugehen, Mikado-Effekte zu erzeugen – an einer Stelle etwas zu verändern und an einer anderen plötzlich ein Problem zu provozieren.
In der Praxis sieht das so aus: Der TRAVIC-Payment Hub nimmt von den angeschlossenen Systemen unterschiedliche Status ein. Über die Skriptsprache legen die eigenen IT-Kollegen oder der Integrationspartner fest, was mit Zahlungen in jedem einzelnen Status geschehen soll. Sobald der Workflow fertig beschrieben ist, kompiliert das System den Code, damit der TRAVIC-Payment Hub arbeiten kann. Das geschieht über von der Workflow-Engine erzeugte Tasks, die eine interne Task-Engine abgearbeitet. Hier ein ganz einfaches Beispiel, wie die von PPI für den TRAVIC-Payment Hub entwickelte Skriptsprache mit OUR-Charges umgeht, also feststellt, ob die fälligen Gebühren einer Zahlungen beiliegen und einbehalten werden dürfen oder eine Zahlungsaufforderung zu erstellen ist.
Status CHECKINBOUNDCHRGS {
if payment is inbound and (payment is ourCharges) then {
if payment is ourChargesReceived then {
just set status VALIDATERECEIVCHGS and leave step
}
if payment is correspondentChargeExpected then {
if payment is debitAuthorized then {
just set status CREATEADVICEOFCHGS and leave step
}
just set status CREATECHARGEREQ and leave step
}
}
just set status DONE and leave step
}
TRAVIC-Payment Hub einführen
PPI bildet mit der TRAVIC-Produktfamilie den gesamten Zahlungsverkehrsprozess einer Bank ab, vom Zahlungseingang über das Interbankengeschäft bis hin zum Clearing. TRAVIC-Payment Hub stellt die Kernverarbeitung für den Zahlungsverkehr dar. Unsere Lösung funktioniert als Kunden- und als Clearingbank – auch im Parallelbetrieb – und kann Instant Payments. Zudem lässt sich die Lösung On-Premises betreiben wie auch als ausgelagerte Hochverfügbarkeitslösung gemeinsam mit unseren Infrastrukturpartnern.
Autor: Thomas Riedel
Mehr Informationen:
- Standardsoftware wie eine Individuallösung nutzen?, Fachbeitrag von Thomas Riedel und Mathias Seeliger, erschienen im IT-Finanzmagazin
- TRAVIC-Payment Hub für Instant Payments
- TRAVIC-Payment Hub für Individualzahlungsverkehr
0 Kommentare:
Kommentar veröffentlichen