Finovate2015-fancy

Brauchen wir „Kernvertriebsbanksysteme“?

Man kann die Veränderungen im Banking fundamental in zwei Gruppen einteilen:

  • Disruption der Produktionsbank: Ersatz der branchenspezifischen Systeme und Protokolle durch offene, internet-basierte Ansätze. Beispiele sind Bitcoin (internetfähiges Geld), Ripple (internetbasierter Zahlungsverkehr in Echtzeit) und P2P-Kredite (Plattform statt Bank als Risikotransformierer).
  • Disruption/Evolution der Vertriebsbank: Weiterentwicklung der digitalen Kundenschnittstelle. Die reine Verbesserung ist zunächst einmal evolutionär, sie kann aber eine Qualität erreichen, durch die sie klassische Vertriebsstrategien in Frage stellt. Dann sind auch diese zunächst vergleichsweise harmlos aussehenden Apps und Websites disruptiv. In dem Sinne, dass sie bestehende Vorteile der Banken zunichte machen. In diesem Fall sind es eben die Vertriebsprozesse, die disrupted werden.

Die Einteilung leuchtet unmittelbar ein, scheint fast trivial. Trotzdem habe ich sie bei meinen Recherchen so nicht finden können – für sachdienliche Hinweise, ob schon mal jemand diesen Blickwinkel auf Next Generation Finance publiziert hat, bin ich dankbar.

Was folgt nun daraus? Die Banken müssen ihre IT in die Lage versetzen, die Veränderungen mit zu gehen, ohne bestehende Investitionen vorschnell zu entwerten. Auf der Finovate gab es mehrere Anbieter, die neue, zentrale Middleware-Plattformen als Lösungsansatz propagiert haben. Die Einsatzzwecke waren unterschiedlich:

  • Omnichannel: Middleware als zentrale „Kanalbündelung“ zur übergreifenden Speicherung von Interaktionen, insbesondere Anträgen.
  • Bank als Plattform: Auch wenn man die Bank öffnet für externe Innovationen, kann eine Middleware Sinn machen, die eine konsolidierte Schnittstelle („API“) zur Verfügung stellt. (Fidor macht das aktuell mit den „Pirates of Banking“, )
  • Neue Protokolle wie Ripple: Würde man radikal andere Zahlungsverkehrsverfahren in die bestehenden Systeme aufnehmen wollen? Wohl er nicht. Die „Altlasten“ befruchten das Neue nicht, behindern es aber. Dann lieber an einer neuen Middleware andocken.

Zu Ende gedacht, entsteht bei mir das Bild eines „Kernvertriebsbanksystems“. Klassische Kernbanksysteme bündeln klassische Bankfunktionen und stellen gerade durch ihre hohe Kohärenz die Konsistenz der Buchungen sicher. Denkt man über Omnichannel, APIs etc. nach, merkt man schnell: genau diese Zusammenführung von Daten in einen einheitlichen Stand, eine einheitliche Sicht, benötigt man hier auch.

Nur sind es eben andere Daten: Alle Zwischenstände ausgefüllter Kontoeröffnungen etwa. Also all die Daten, die aus Sicht der Produktionsbank viel zu vorläufig sind, als dass sie ins Kernbanksystem kämen. Die aber für einen modernen digitalen Vertriebsansatz gültige „Vertriebsbank-Daten“ sind und auch mit entsprechendem Gewicht behandelt gehören.

Bitte nicht falsch verstehen: Sie sollen jetzt keinen neuen Großrechner aufstellen für das Kernvertriebsbanksystem. Natürlich wird man heute keine derartigen Monolithen mehr bauen. Softwaretechnisch wird es sich eher um eine Reihe einzelner Services handeln, die über Standardschnittstellen miteinander und mit ihren Clients kommunizieren. Aber vom Produktmanagement her, von der Konzeption der Datenbestände her muss es als ein Ganzes gedacht sein. Dessen Kernfunktion in der Integration liegt.

Deshalb stehe ich den Produkten, die auf der Finovate gezeigt wurden, dann letztlich doch wieder kritisch gegenüber. Denn natürlich haben Banken heute bereits Datenmodelle, mit denen ihre bestehenden Systeme arbeiten. Bei den einen stehen da die Sparten im Vordergrund, Konten, Depots, Kreditkarten – alles stark getrennt, damit man es im Bedarfsfall einzeln auslagern kann. Macht Sinn. Andere haben eine Objektmodellierung, in der Kunden, Adressen, Verträge zentrale Objekte sind, die spartenübergreifend einheitlich genutzt werden. Macht mindestens genau so viel Sinn. Und jetzt kommt ein fertiges Middlewareprodukt dazu. Das alles einfacher machen soll, indem es einen „Integrationspunkt“ bildet. Und das bringt nun wieder sein eigenes vorgefertigtes Datenmodell mit. Dieses Datenmodell liegt garantiert leicht schief zu jedem vorhandenen Datenmodell. Und daraus können sich ganz fiese Probleme ergeben, die man erst spät in der Implementierung erkennt.

Nein, wenn es einfacher werden soll, muss das Kernvertriebsbanksystem exakt zum Kernbanksystem passen und es in die neue Gestalt transformieren, die digitaler Vertrieb heute braucht. Dann aber scheint es mir eine sehr sinnvolle Komponente der Bank-IT-Landschaft zu sein.

 

Elmar Borgmeier

Gestaltet Online Finance seit 1997. Glaubt an die Symbiose von Finance und IT. Ist Mitgründer und Chief Innovation Officer der syngenio AG. Moderator des JAX Finance Day. Berater für Next Generation Finance. Philosophiert gern über IT und realisiert noch lieber konkrete Lösungen.

Kommentare (2) Schreibe einen Kommentar

  1. Guten Tag,
    Ich habe Rahmen eines Projekts, bei dem ich im vergangenen Jahr maßgeblich mitwirken dürfte, das Core Banking System der Schweizer Firma Avaloq Ecolution AG kennengelernt. Es bildet bereits heute viele der Aspekte ab, die von Ihnen beschrieben wurden. Es war verbunden mit der ABK-Software der Firma EFiS AG, die die technische Anbindung an SWIFT herstellte, für Zahlungsverkehr und Wertpapiernachrichten. Ein sehr effektives System, dass nach Abschluss der so genannten „Germanisierung“ der Software alle Bankbereiche abdecken wird. Diese mit einem wirkungsvollen Vertriebs-Frontend zu verbinden , sehe ich als eine große Chance für kleine und mittelständische Banken, ihre Belange auf eine flexible, schnell und einfach anpassbare Basis zu stellen.
    In dieser Eichtung verläuft für mich die Zukunft der Banken-IT.
    Viele Grüße an Manfred Höfler
    Jochen Schneider
    Schneider EDV-Beratung

    Antworten

  2. Ich bin sehr dafür, ein Kernbankvertriebssystem zu haben. Wie sieht das aus? Es befähigt Kunden, Ihre Finanzen Bank-(Produzenten-)übergreifend und selbständig zu managen.
    Wenn der Kunde einen Berater braucht, kann er sich an jeder Stelle in den Prozess auf Wunsch des Kunden einschalten. Was braucht es dafür? Einen einheitlichen Standard?

    Nein, es benötigt einen einheitlichen Prozess: 1. Zielsetzung (Soll) 2. Ist 3. Abgleich zwischen Soll und Ist. 4. Vorschlag zur Verbesserung 5. Controlling.

    Zu 2. Über Onlinebankingschnittstellen können wir heute schon (zumindest in D) alle Bestands- und Bewegungsdaten in einem einheitlichen System abbilden. Gleichzeitig stehen neben diesen Daten systematisierte Daten zu Wertpapieren in unendlicher Fülle verfügbar und können einfach zugeführt werden. Was (noch) fehlt sind einheitliche Standards für Versicherungen. Hier arbeiten wir mit Dokumentenmanagementsysten und semantischer Suche noch auf einem erst einmal nicht vorhandenen digitalen Niveau.

    Vor der aggregierten Produktdarstellung sind Ziele (1) zu definieren (einfachere Übung) und im Schritt 3 Ziele und Produkte abzugleichen. Hier ist der Standard der Algorithmus und die Finanzmathematik.

    Die Lösung für Differenzen zwischen Ziel und Ist können Robo-Advisers, Asset-Manager oder crowdgesourcte Strategien sein – oder der Berater kommt in Spezialfragen in’s Spiel.

    Das Controlling (5) hat nur zwei Fragen zu beantworten: 1. Ist das Ziel on track? 2. Ist der Weg zur Zielerreichung noch optimal.

    Fertig :)
    Fazit: Das Problem sind Banken, die andere Produzenten negieren. Das entspricht aber nicht der Kundenrealität. Ein Hausbank- und Hausversicherungsprinzip gibt es eben nicht. Umso wichtiger ist die Aggregation (2)
    Wir bei moneymeets arbeiten daran – an der Digitalisierung des Beratungsprozesses. Wenn das geschafft ist, ist die Bank Produzent. Also Banken, arbeitet daran, dass es anders wird!

    Antworten

Schreib einen Kommentar

Pflichtfelder sind mit * markiert.


Top