Dynamische Banking-Engagement-Plattformen: Die fehlende Schicht zwischen Core und Kundendialog

Eine Bank kann ihren Core modernisieren, ein neues Frontend einführen und dennoch an einem praktischen Problem scheitern: Ein relevantes Kundenereignis wird erkannt, aber nicht verlässlich in eine passende, zulässige und nachvollziehbare Interaktion überführt. Zwischen Buchungssystemen und Kundendialog fehlt dann eine verbindende Schicht.

Forrester fasst diese Schicht unter dem Begriff Digital Banking Engagement Platform (DBEP). In der Auswertung für das zweite Quartal 2026 beschreibt Forrester DBEPs als weiterhin entscheidend für Banken. Ihre Rolle verschiebt sich jedoch: Weg von einer vorgefertigten Sammlung digitaler Angebote, hin zu einer Plattform, auf der Banken und Partner Ideen erkunden und neue Funktionen zügig entwickeln können. Forresters Einordnung zur DBEP-Welle 2026 ist damit kein Aufruf, den Core zu ersetzen. Sie lenkt den Blick auf die Fähigkeit, Daten, Entscheidungen und Interaktionen über bestehende Systeme hinweg zu verbinden.

Autor: acceleraid Redaktion
Datum: 13. August 2026

Die fehlende Schicht ist ein Ausführungsproblem

Der Core ist das System of Record: Er führt Konten, Salden, Buchungen und Produktverträge. Er muss stabil, korrekt und kontrolliert arbeiten. Ein Kundendialog verlangt etwas anderes. Er braucht Kontext, Regeln für Kontaktfrequenz und Einwilligung, eine Entscheidung über den nächsten sinnvollen Schritt sowie eine Ausspielung im passenden Kanal oder an den passenden Mitarbeitenden.

Eine DBEP kann diese Aufgaben zusammenführen, ohne den Core mit jeder neuen Journey zu belasten. Die Trennung ist wichtig: Ein digitales Engagement-System verarbeitet nicht anstelle des Cores die fachliche Wahrheit über eine Buchung. Es nutzt vereinbarte Schnittstellen, um einen Kontext für Interaktion und Arbeit zu bilden. Ein Plattformanbieter beschreibt diese Ebene entsprechend als Software zwischen Core Banking und den täglichen Kundeninteraktionen, die Daten, Workflows und Interaktionen über Mobile, Web, Filiale und Betrieb hinweg koordiniert. Diese Architekturdefinition von Backbase ist eine nützliche Abgrenzung, keine allgemeine Produktbewertung.

Gerade deshalb ist eine DBEP nicht einfach eine neue Mobile App. Eine App ist ein einzelner Zugangskanal. Sie kann eine Oberfläche verbessern, löst aber nicht automatisch die Frage, wie eine Entscheidung mit Web, Kontaktcenter, Beratungsarbeitsplatz und anderen Kanälen abgestimmt wird. Ebenso wenig schafft sie aus sich heraus eine nachvollziehbare Rückmeldung darüber, was nach einer Interaktion passiert ist.

Forrester beobachtet zudem, dass sich die Zielgruppe der Plattformen erweitert. DBEPs werden zunehmend mit einer größeren Zahl interner und externer Systeme verbunden; gleichzeitig bauen Anbieter Low-Code- und No-Code-Funktionen aus, ohne professionelle Entwicklung in zentralen Bereichen zu ersetzen. Forresters DBEP-Analyse beschreibt damit eine Veränderung der Arbeitsweise, nicht bloß ein neues Bedienkonzept.

Ein Architekturmodell mit fünf verbundenen Ebenen

Für die Auswahl und Einführung hilft ein klares Schichtenmodell. Es ist kein normierter Zielzustand und keine Vorgabe für eine bestimmte Produktsuite. Es macht sichtbar, welche Verantwortung wo liegen sollte.

1. Systems of Record. Core Banking, Zahlungsverkehr, Kredit- und Kartenplattformen sowie weitere führende Systeme bleiben Ursprung der jeweils maßgeblichen Daten und Prozesse. Die Engagement-Schicht darf diesen Systemen nicht stillschweigend neue fachliche Wahrheiten hinzufügen. Sie braucht klare Verträge für Lesezugriffe, Ereignisse, Schreibvorgänge und Fehlerfälle.

2. Governed Data und Decisioning. Diese Ebene verbindet zulässige Kundensignale, Identitäten, Einwilligungen, Produkt- und Kontextdaten. Sie enthält zudem Regeln, Modelle und Entscheidungslogik: etwa Ausschlüsse, Eignungsgrenzen, Prioritäten und den Fall „keine Ansprache“. Entscheidend ist nicht, möglichst viele Daten zusammenzutragen, sondern Herkunft, Aktualität, Zweckbindung und Verantwortliche zu klären.

3. Orchestrierung. Hier wird aus einer Entscheidung ein steuerbarer Ablauf. Die Orchestrierung löst Schritte aus, behandelt Abhängigkeiten, legt Reihenfolgen fest und übergibt Fälle an Menschen, wenn eine automatisierte Bearbeitung nicht ausreicht. Sie sollte auch konkurrierende Anliegen ordnen: Eine Servicekommunikation, eine Warnung und ein Produktangebot dürfen nicht unkoordiniert um denselben Kundenmoment konkurrieren.

4. Kanäle und Mitarbeitenden-Tools. Mobile und Web sind Ausgabepunkte, nicht die Plattform selbst. Hinzu kommen E-Mail, Nachrichten, Kontaktcenter, Filiale und Beratungsarbeitsplätze. Gute Architektur sorgt dafür, dass Mitarbeitende den Kontext, die erlaubte Handlung und den bisherigen Verlauf sehen. Das verhindert, dass ein Kunde eine Interaktion in einem Kanal beginnt und im nächsten alles erneut erklären muss.

5. Feedback. Zustellung, Reaktion, Abbruch, manuelle Übersteuerung und Folgeereignisse müssen wieder zurückfließen. Feedback ist mehr als ein Kampagnenreport. Es ist die Grundlage, um Regeln zu prüfen, Journeys zu verbessern und zu erkennen, ob eine Entscheidung tatsächlich hilfreich war.

Quer durch alle Ebenen verlaufen Sicherheit, Datenschutz, Berechtigungen, Protokollierung und Betriebsüberwachung. Diese Anforderungen sind kein nachträglicher Kontrollring. Sie bestimmen, welche Daten in einer Entscheidung verwendet werden dürfen, wer eine Regel ändern kann und wann ein Mensch eingreifen muss.

Der Rollenwechsel: von fertigen Erlebnissen zu einer Bau- und Betriebsumgebung

Die jüngere DBEP-Diskussion dreht sich nicht darum, ob jede Bank alle Oberflächen selbst entwickeln sollte. Der zentrale Punkt ist die Veränderbarkeit. Forrester beschreibt führende Plattformen als Mittel, mit denen Banken und Drittpartner neue Ideen und Funktionen schnell erproben und aufbauen können. Der Bericht verweist dabei auch auf Werkzeuge zum Testen und Messen neuer Produkte.

Das hat Konsequenzen für das Betriebsmodell. Fachbereiche benötigen eine Möglichkeit, Inhalte, Reihenfolgen und klar begrenzte Journeys zu konfigurieren. Technologie- und Sicherheitsteams müssen die wiederverwendbaren Integrations-, Identitäts- und Kontrollbausteine verantworten. Risiko, Compliance und Datenschutz gehören früh in den Lebenszyklus einer Entscheidung: bei Datennutzung, Regeldefinition, Freigabe und laufender Prüfung. Kein Team kann die gesamte Plattform allein sinnvoll steuern.

Auch „API-first“ ist kein ausreichendes Auswahlkriterium. Forrester weist darauf hin, dass nahezu alle untersuchten Anbieter APIs in den Mittelpunkt ihrer Positionierung stellen, während Banken in der Praxis teils auf nicht funktionierende Schnittstellen oder deutlich schwierigere Integrationen stoßen als erwartet. Diese Warnung von Forrester spricht für Tests an realen Schnittstellen, echten Fehlerbildern und den eigenen Sicherheitsvorgaben statt für eine Entscheidung anhand von Architekturfolien.

Gleiches gilt für KI-Funktionen. Eine Konversationsoberfläche oder ein Generator für Workflows kann nützlich sein, ersetzt aber keine Entscheidungsrechte, Datenkontrollen und Eskalationswege. Der belastbare Test lautet: Kann die Bank erklären, welche Daten und Regeln eine Handlung ausgelöst haben, was der Mitarbeitende ändern darf und wie die Wirkung überprüft wird?

Auswahlfragen, die eine Produktdemo nicht beantwortet

Eine sinnvolle Vorauswahl beginnt nicht mit einer Funktionsliste, sondern mit konkreten Interaktionen. Diese Fragen helfen, die Architektur und das Betriebsmodell zu prüfen:

• Systemgrenzen: Welche Systeme bleiben für welche Daten und Transaktionen führend? Sind Lese-, Schreib- und Ereignisschnittstellen dokumentiert und im eigenen Umfeld testbar?

• Entscheidungsführung: Wie werden Einwilligung, Kontaktregeln, Eignungsanforderungen, Prioritäten und bewusste Nichtansprache gemeinsam durchgesetzt?

• Nachvollziehbarkeit: Lässt sich für eine einzelne Interaktion zeigen, welche Daten, Regeln, Inhalte und Freigaben verwendet wurden?

• Orchestrierung: Wie behandelt die Plattform Fehler, zeitversetzte Prozesse, doppelte Ereignisse und die Übergabe an Mitarbeitende?

• Kanalübergreifende Arbeit: Erhalten Kunden und Mitarbeitende einen konsistenten Verlauf, oder entstehen getrennte Dialoge je Kanal?

• Änderbarkeit mit Kontrolle: Was dürfen Fachanwender konfigurieren, was erfordert Entwicklung, und welche Änderungen brauchen vorab eine Prüfung?

• Feedback und Betrieb: Welche Ereignisse fließen zurück? Wer überwacht Datenqualität, Regelwirkung, Zustellung und Ausnahmen im Tagesgeschäft?

• Portabilität: Wie lassen sich Daten, Inhalte, Regeln und Integrationen dokumentieren und im Fall eines Anbieterwechsels geordnet überführen?

Eine dynamische Banking-Engagement-Plattform ist damit weder ein kosmetischer Frontend-Relaunch noch ein Ersatzprojekt für den Core. Sie ist eine verbindende Betriebs- und Ausführungsschicht. Ihr Wert entsteht, wenn eine Bank Entscheidungen über Systeme und Kanäle hinweg kontrolliert in Dialog und Arbeit überführen kann — und aus dem Ergebnis wieder lernt.

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.