Standardsoftware wie eine Individuallösung nutzen? So lässt sich Banken-Software für Workflows öffnen

Die Digitalisierung legt einen Konflikt offen, der in den meisten IT-Abteilungen schwelt: Eine Software für alle, selbst entwickeln oder auf ein Framework setzen? Gegen Standardsoftware sprechen sich vor allem diejenigen aus, die befürchten, sich dadurch nicht mehr ausreichend vom Wettbewerb absetzen zu können. Wer solche Software anbietet, sollte sie deshalb öffnen, damit sich individuelle Abläufe abbilden lassen. Ein Praxisbeispiel aus der Bankenwelt.

von Thomas Riedel und Mathias Seeliger, PPI

„Banking ohne Unsinn“, verspricht eine bekannte Smartphone-Bank aus Berlin, die in den letzten Jahren rasend schnell neue Kunden gewonnen hat.

Das bedeutet andererseits aber auch, sehr viel von der eingesetzten Software selbst zu entwickeln, damit sich das Angebot auch gefühlt von dem anderer Banken unterscheidet.”

Geldhäuser müssten sich gar in Software-Unternehmen verwandeln, sagen einige. Großbanken wie ING oder Goldman Sachs verstehen sich längst als Tech-Firmen mit Banklizenz.

Alles selbst zu machen, zahlt sich aber nicht immer und überall aus.”

Mehr Macht den Anwendern

In Bereichen, in denen immer dasselbe passiert, lohnt sich selbst entwickelte Software nicht. Das gilt beispielsweise für Buchhaltung und Finanzen und vielfach auch für das Personalwesen. Weil Kunden davon ohnehin kaum etwas merken, wäre eine individuell gefertigte Software zu teuer. Frameworks bieten hier einen vermeintlich sicheren Ausweg, weil sie vorgefertigte Module für wiederkehrende Aufgaben mitbringen und darüber hinaus erlauben, einzelne Dienste passend auszuprägen. Doch das erfordert viele manuelle Handgriffe. Daraus entsteht das Risiko, eine kaum noch release-fähige IT-Lösung aufzubauen, die bei jedem Update des Frameworks neue Probleme schafft.

Ideal wäre deshalb eine Standardsoftware, die Kunden erlaubt, selbst Abläufe festzulegen. Die Idee: eine in die Software integrierte Workflow-Engine (WFE), die sich über eine Skriptsprache steuern lässt (vgl. Abb. 1). Die Skriptsprache unterscheidet zwischen Status und Qualitätsabfragen. Jeder Status gibt vor, was als nächstes passieren soll, und jede Qualitätsabfrage prüft, ob zuvor festgelegte Bedingungen vorliegen oder nicht. Davon hängt ab, ob und wie sich ein einzelner Status ändert. Ist der Workflow vollständig beschrieben, kompiliert die Engine den Code. Innerhalb der Software wiederum erzeugt die Workflow-Engine Aufgaben (Tasks), die anschließend von einer Task-Engine abgearbeitet werden. Über die Skriptsprache formulierte Änderungen lassen sich so ohne Release-Wechsel einspielen.

Intern arbeitet die Software ausschließlich mit Tasks, nach außen öffnet sie sich über die Workflow-Engine und die mitgelieferte Skriptsprache. Ein großer Teil der Software-Entwicklung rückt dadurch aus der Sphäre des Herstellers in die Sphäre desjenigen, der die Software einführt. Das kann entweder direkt durch die eigenen IT- und Fachbereiche geschehen oder durch ein Unternehmen, das sich mit dem jeweiligen Sachverhalt auskennt. Die Technik ist praktisch von der Fachlichkeit getrennt. Am Quellcode selbst brauchen die späteren Anwender, anders als bei vielen Frameworks, deshalb keine Änderungen vorzunehmen. Eine der größten Gefahren, an denen viele solcher Projekte scheitern, ist damit gebannt.

Individualität trotz Uniform

Besonders gut eignet sich diese Architektur für Geschäftsvorfälle, die sich in einzelne Teilaufgaben zerlegen und in einer vom Anwender gewünschten Reihenfolge abarbeiten lassen. In Banken stellt der Zahlungsverkehr einen typischen Anwendungsfall dar. Wenn Geld überwiesen werden soll, müssen die Institute beispielsweise prüfen, ob das Konto des Auftraggebers gedeckt ist und ob die IBAN des Empfängers stimmt. Doch das ist längst nicht alles. Banken müssen auch prüfen, ob ein Verdacht auf Geldwäsche vorliegt – gerade bei Zahlungen ins Ausland – und ob der Empfänger auf einer Embargo- oder Sanktionsliste steht. Obwohl die Aufgaben sich von Bank zu Bank kaum unterscheiden, sind die Reihenfolge, die Bedingungen und die verwendeten Schnittstellen zu anderen IT-Systemen dennoch sehr verschieden.

Das folgende Listing zeigt, wie sich die von PPI entwickelte Software für Zahlungsverkehr bei einer eingehenden Zahlung verhalten soll, wenn es um eventuell anfallende Gebühren geht.

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
}

Im abgebildeten Fall nimmt das System eine Zahlung von einer anderen Bank an und prüft, ob die Gebühren von der die Zahlung auslösenden Bank getragen werden – im Fachjargon heißt diese Regel OUR-Charges. Wenn das so ist, soll das System kontrollieren, ob zusätzlich zum überwiesenen Betrag diese Gebühren der Überweisung beiliegen. Falls ja, erzeugt das System einen neuen Status, damit der Gebührenbetrag geprüft und einbehalten wird. Falls nein, fragt das System, ob die Gebühren von der Bank, von der die Zahlung kommt, direkt eingezogen werden dürfen. Davon hängt ab, welcher Status erzeugt wird und ob das System sich die Gebühren direkt holt oder ob eine Zahlungsaufforderung erstellt wird. Je nach Mandant lassen sich nahezu beliebige Regeln abbilden.

Autoren Thomas Riedel und Mathias Seeliger, PPI

Thomas Riedel ist seit 2015 leitender Produktmanager bei PPI (Website) und verantwortet Software für die ZV-Kernverarbeitet sowie das Clearing und Settlement. Zuvor hat der Techno-Mathematiker fast 15 Jahre bei einem internationalen Beratungs- und IT-Haus gearbeitet und Produkte für den Zahlungsverkehr entwickelt, zuletzt als Head of Payments.

Mathias Seeliger ist leitender Software-Architekt bei PPI (Website) und verantwortet die Architektur der ZV-Plattform. Der ausgebildete Fachinformatik verfügt über mehr als 15 Jahre Erfahrung in der Entwicklung von Zahlungsverkehrs-Software. Seine Schwerpunkte liegen auf Continuous Delivery, Testing mit Docker und Kubernetes sowie APIs.

Das ist vor allem im Individualzahlungsverkehr wichtig. Große Konzerne suchen sich üblicherweise in jeder Weltregion eine Bank, die sämtliche Zahlungen zentral abwickelt. Dafür machen sie bestimmte Vorgaben, die das Institut darstellen können muss, um den Zuschlag zu erhalten. Folglich muss die betreffende Bank – beziehungsweise die eingesetzte Software – plötzlich aus einem vermeintlichen Standardprodukt wie dem Zahlungsverkehr ein individuelles Angebot schneidern, bei dem viele Details zu beachten sind. Die Konzerne schreiben häufig vor, über welche Banken das Geld zu leiten und zu welchen Tageszeiten zu buchen ist. Anders als etwa die SEPA-Zahlung im Euroraum ist der Auslandszahlungsverkehr kein einfaches Massengeschäft.

Ganz oder gar nicht?

Viele Banken entscheiden sich vor diesem Hintergrund, ob sie Zahlungsverkehr überhaupt als ein strategisches Geschäftsfeld begreifen wollen oder nicht.”

Einige Banken geben das komplexe Geschäft an ein großes Institut ab oder lagern den Zahlungsverkehr gleich ganz aus, weil sie sich so des Problems entledigen, auf einer möglicherweise selbst entwickelten Plattform permanent gesetzlich vorgeschriebene Anpassungen vornehmen zu müssen. Innovation kommt dann zu kurz, was gerade kleineren Instituten zu schaffen macht, wie eine Untersuchung des europäischen Bankenverbands EBA zeigt.

Eine Software, die sich flexibel anpassen lässt und dessen Hersteller den Anwendern trotzdem alle lästigen Aufgaben abnimmt, zahlt sich deshalb besonders aus. Das mag nicht nur für Banken gelten, die Gelder von einem Land ins andere überweisen, sondern auch für andere Branchen, in denen der Gesetzgeber strenge Vorgaben macht, wie Energie, Logistik oder Außenhandel. Unternehmen, die am internationalen Warenverkehr beteiligt sind, müssen etwa über eine Schnittstelle auf Filterlisten des Zolls zugreifen, die über verbotene Güter oder illegitime Absender informieren. Geht dabei etwas schief, riskieren sie ihren Status als „Zuverlässiger Versender“, was erhebliche Nachteile mit sich bringt. Hinzu kommen IT-Systeme, um Preise zu berechnen, eigene schwarze Listen zu führen und interne Compliance-Vorschriften einzuhalten, ähnlich wie bei einer Bank.

Fazit

Immer dann, wenn sich ein Unternehmen in einem bestimmten Geschäftsfeld vom Wettbewerb unterscheiden möchte, fällt der Blick im digitalen Zeitalter nahezu automatisch auf die eingesetzte Software – und darauf, ob sie selbst entwickelt worden ist oder eingekauft. Gekaufte Software steht dabei im Verdacht, die gewünschte Abgrenzung unmöglich zu machen, weil sich die Entwicklung häufig erst dadurch rechnet, dass viele Kunden auf ein- und derselben Plattform möglichst viele gleichartige Geschäftsvorfälle ausführen. Die Fachlichkeit ist also gleichsam mit genormt.

Wem es gelingt, die Fachlichkeit von der Technik zu trennen, löst sich dieses Grundproblem auf. Kunden können sich dann trotz Standardsoftware ausreichend differenzieren und brauchen sich um die technische Weiterentwicklung nicht mehr zu kümmern – die kommt mit dem nächsten Release.”Thomas Riedel und Mathias Seeliger, PPI

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/106406

• teilen 
• teilen 
• teilen 
• teilen 
• teilen 
• RSS-feed 
• E-Mail 
• drucken