Conversational AI für Banken: Was funktioniert und was scheitert

Was Conversational AI im Banking wirklich bedeutet

Zieht man das Marketing ab, ist Conversational AI genau das: Ein Kunde tippt oder sagt, was er möchte, so wie er es einem Bankangestellten sagen würde, und die Software versteht die Absicht und antwortet oder erledigt die Aufgabe. Kein Telefonmenü, kein „Drücken Sie die 2 für Kontostände“.

Das CFPB stellt das als Stufenleiter der Ausgereiftheit dar, und die Stufen sind entscheidend:

• Regelbasierte Chatbots laufen nach "decision tree logic or a database of keywords", weshalb der Nutzer "limited to predefined possible inputs" ist. Man kann sich das wie ein Menü aus Buttons vorstellen. Wer unseren Vergleich von KI-Agent gegen regelbasierten Chatbot gelesen hat, weiß: Das ist die unterste Stufe.
• NLU-Chatbots nutzen Natural Language Understanding, um die Absicht hinter freiem Text zu erkennen, nicht nur Schlüsselwörter. NatWest beschreibt seinen Cora-Assistenten als ein System, das Anfragen "through natural language processing and machine learning" bearbeitet.
• LLM-gestützte Agenten sind die neue oberste Stufe. Das CFPB stellt fest, dass Banken "moving from simple, rule-based chatbots towards more sophisticated technologies such as large language models" sind.

Die Stufe, die LLMs für das Banking sicher macht, ist Retrieval-Augmented Generation, also Grounding: Das Modell antwortet aus der eigenen Wissensdatenbank der Bank statt aus seinen Trainingsgewichten. DBS beschreibt DBS Joy als ein System, das "large language models with the bank's proprietary knowledge base" integriert und dadurch "move beyond pre-programmed static answers to dynamic responses" kann. Wells Fargo geht noch weiter und gestaltet seinen Assistenten so, dass gar keine personenbezogenen Daten das LLM erreichen.

So sieht ein gut gebauter Ablauf aus, und deshalb ist die Konfidenzprüfung in der Mitte nicht verhandelbar:

Das CFPB ist auch unverblümt, was die Grenze angeht: Chatbots "may be useful for resolving basic inquiries, but their effectiveness wanes as problems become more complex". Das ist keine Kritik an der Technik, sondern die Designvorgabe. Die Tools, die Menschen tatsächlich mögen, sind die, die ihre eigenen Grenzen kennen und nach einem Menschen greifen. Unser Leitfaden zu KI im Kundenservice behandelt diese Grenze allgemein; im Banking steigt einfach der Einsatz.

Wo es bereits funktioniert: die Einführungen der Großbanken

Der Beweis steckt nicht in einer Verkaufspräsentation, sondern in den eigenen Zahlen der Banken. Hier sind die Vorzeigeeinführungen, alle aus primären Newsrooms:

Ein paar Dinge fallen sofort auf. Erstens konzentrieren sich die Anwendungsfälle auf Anfragen mit hohem Volumen und geringem Risiko: Erica markiert Kontostandtrends "in the next 7 days", während Eno proaktiv vor "a double charge, an abnormally large tip amount, or potential fraud" warnt und händlerspezifische virtuelle Kartennummern erzeugt. Zweitens behandeln die klugen Einführungen die KI als Eingangstür, nicht als Wand. NatWests Cora+ übergibt mit einer Zusammenfassung, damit "the human agent can quickly understand what support the customer needs".

Drittens ist mehrsprachige Reichweite ein echter Türöffner, keine Fußnote. Mehr als 3 Millionen spanischsprachige Wells-Fargo-Kunden haben Fargo über 160 Millionen Mal genutzt. Das ist genau die Art von Abdeckung, die mit menschlichem Personal brutal teuer und mit einem auf mehrsprachige Historie trainierten Agenten günstig zu erreichen ist.

Die Wirtschaftlichkeit erklärt den Ansturm. Juniper Research prognostizierte, dass Banking-Chatbots bis 2023 weltweit 7,3 Milliarden US-Dollar einsparen würden, gegenüber 209 Millionen US-Dollar im Jahr 2019, was 862 Millionen Arbeitsstunden entspricht, wobei 79 % der Interaktionen über mobile Apps liefen. Das CFPB beziffert den Einzelwert auf 0,70 US-Dollar Einsparung pro Interaktion. Wer diese Zahlen für das eigene Team überprüfen möchte, findet in unserem Artikel zu KI im Vergleich zu menschlichem Kundensupport den entsprechenden Vergleich.

Was Kunden wirklich denken

Das ist der Teil, den Anbieterseiten auslassen. Wer dort liest, wo echte Bankkunden sich äußern, stellt fest: Die Stimme der Frustration ist lauter, schärfer und konkreter als die des Lobes, und es lohnt sich, ihr zuzuhören, denn sie zeigt genau, was zu vermeiden ist.

Die wütendste Beschwerde ist die Schleife, die selbst dann nicht eskaliert, wenn es brennt:

"I've had fraud happening on my card this week and I've never had such an excruciating experience with a bank... I had to threaten to reach out to KiFid [the Dutch financial ombudsman] for them to allow me to speak to a human. Also the AI will occasionally pretend to be a person too. It's all horrible."

Bitterboule80 on r/bunq

Das ist genau die "doom loop", vor der das CFPB gewarnt hat, mitten in einem Betrugsfall. Das nachfolgende Thema ist ebenso konstant: Menschen wollen einen sichtbaren Menschen, und das Vertrauen bricht in dem Moment ein, in dem es nicht mehr einfach ist. Wie es ein Fintech-Betreiber ausdrückte, der seine eigenen Kunden beobachtete:

"i've seen customers be fine with bots for simple stuff but get wary as soon as money or disputes are involved."

thepillowco on r/fintech

Es gibt sogar eine ausgesprochen bankentypische Beschwerde: den Bot als Downgrade einer Funktion, die man vorher schon hatte. Die Tirade eines Bank-of-America-Kunden darüber, zu "ask Erica" gedrängt zu werden, statt einfach die eigenen Kontoauszüge zu filtern, ist eine nützliche Erinnerung daran, dass Conversational AI nicht automatisch ein Upgrade gegenüber einer guten Suchfunktion ist.

Nichts davon heißt „lass es bleiben“. Es heißt, dass Vertrauen der Maßstab ist und dass der Fehlermodus konkret und vermeidbar ist. Die Praktiker, die das bereits umgesetzt haben, sind sich bei der Lösung einig. Aus demselben r/fintech-Thread:

"The key though is avoiding generic bots and keeping it rules-based, built for a specific domain/process/problem (especially in regulated areas like disputes), integrating with back-office data, and making handover to humans seamless."

Das ist das Rezept, in den eigenen Worten eines Kunden. Die Übergabe richtig hinzubekommen, ist das, was Einführungen, die Menschen ertragen, von denen unterscheidet, bei denen sie wutentbrannt aussteigen.

Was automatisiert und was an einen Menschen übergeben werden sollte

Wo verläuft also die Grenze? Nachdem ich viele solcher Einführungen live erlebt habe, ist meine Regel einfach: Automatisiere die Abfrage, eskaliere die Entscheidung. Wenn die Beantwortung der Frage Geld bewegen, ein Produkt verweigern oder ein Rechtsanspruch auslösen könnte, gehört sie einem Menschen. Alles andere ist faires Terrain für den Agenten.

In der linken Spalte stecken das Volumen und die Einsparungen, und genau das ist die Tier-1-Arbeit, die den Tag eines Support-Teams frisst. Sie deckt sich genau mit dem, was ein guter KI-Helpdesk-Agent bereits gut kann: Wiederholendes abwehren, Antworten konsistent halten, alles protokollieren. Die rechte Spalte ist der Bereich, in dem eine falsche Antwort zum regulatorischen Problem wird, weshalb diese Abläufe die Absicht erfassen und dann weiterleiten sollten, niemals raten.

Der Fehler, den ich am häufigsten sehe, ist, dass Teams versuchen, die Grenze zu schnell nach rechts zu verschieben, und den Bot Reklamationen oder Kreditfragen versuchen lassen, weil eine Demo ihn fähig aussehen ließ. So landet man in den oben genannten r/bunq-Threads. Fang eng an, beweise es in der linken Spalte, und erweitere erst, wenn deine Deflection-Rate und die Qualität deiner Eskalation beide standhalten.

Die Compliance-Anforderungen, die das Banking hinzufügt

Das ist es, was Banking von generischem Support unterscheidet. Eine falsche Antwort ist hier nicht bloß ein verärgerter Kunde, sondern eine regulierte Institution, die möglicherweise Bundesgesetze bricht. Das CFPB sagt es unverblümt: Ein "poorly deployed chatbot can lead to customer frustration, reduced trust, and even violations of the law."

Ein Banking-Bot trägt also eine Compliance-Last, die ein generischer Support-Bot nicht hat:

Der Reihe nach:

• Umgang mit personenbezogenen Daten und Kartendaten. Der Gramm-Leach-Bliley Act und die FTC Safeguards Rule verlangen die Verschlüsselung von Kundendaten bei der Übertragung und im Ruhezustand sowie eine 30-tägige Meldepflicht bei Verstößen. Falls der Ablauf Kartennummern berühren kann, verlangt PCI DSS, dass die Kontonummer maskiert und unlesbar gemacht wird. Deshalb ist Schwärzung in Transkripten und Protokollen keine Option, sondern Pflicht.
• Menschliche Überprüfung automatisierter Entscheidungen. Für EU-Kunden gibt Artikel 22 der DSGVO ein Recht darauf, "not to be subject to a decision based solely on automated processing", das rechtliche oder erhebliche Auswirkungen hat, die Ablehnung eines Kredits ist das Lehrbuchbeispiel, sowie ein Recht auf menschliches Eingreifen.
• Die Hochrisikogrenze des EU AI Act. Nach Anhang III wird KI, die "to evaluate the creditworthiness of natural persons or establish their credit score" eingesetzt wird, als Hochrisiko eingestuft, was Pflichten zur menschlichen Aufsicht und zur Protokollierung auslöst. Hier lohnt sich Präzision: Ein Support-Bot, der "wie hoch ist mein Kontostand" beantwortet, ist nicht automatisch Hochrisiko, dieser Auslöser ist der Anwendungsfall der Bonitätsbewertung. Doch sobald ein Ablauf eine Kreditentscheidung beeinflusst, überschreitet er diese Grenze.
• Die Anbieter-Messlatte. Banken, die ein Tool kaufen, erwarten einen SOC-2-Type-II-Bericht, der prüft, ob die Kontrollen tatsächlich über einen Zeitraum funktioniert haben, nicht nur, dass sie auf dem Papier existieren.

Der rote Faden durch all das ist dasselbe Designmuster, das die Kunden regelrecht eingefordert haben: Grounding, Protokollierung und ein Ausstieg zu einem Menschen. Drei getrennte Rechtsrahmen schreiben unabhängig voneinander den Eskalationspfad vor. Wer Tools evaluiert, findet in unserem Hinweis zu KI-Wissensmanagement für Support-Teams mehr dazu, wie diese freigegebene Wissensebene sauber gehalten wird, denn genau dort beginnt die Genauigkeit.

Wie man sie einführt, ohne die Kunden zur Weißglut zu bringen

Kombiniert man die Stimme der Kunden mit der Compliance-Last, wird das Vorgehen klar. So würde ich es der Reihe nach angehen.

Alles verankern, dann vor dem Go-live beweisen. Den Agenten auf das freigegebene Hilfe-Center und die Richtliniendokumente zu beschränken, verhindert, dass er sich eine Antwort ausdenkt, und ist genau die Maßnahme, die das CFPB implizit einfordert, wenn es sagt, generische Bots seien "ill-suited for tasks that require logic, specialized knowledge, or current data". Ich habe erlebt, wie das auf die harte Tour scheiterte: Der Bot eines zahlenden Kunden erfand eine Produktbehauptung und schickte sie an echte Kunden, weil der Abruf leer blieb und das Modell die Lücke mit Trainingsdaten füllte. Die Lösung ist kein schlaueres Modell, sondern den Agenten zuerst gegen Tausende echter vergangener Tickets zu simulieren, damit man sieht, wo er halluziniert hätte, bevor ein Kunde es tut.

Nach Konfidenz absichern und den Menschen sichtbar halten. Lege eine Schwelle fest: Liegt die Konfidenz darunter, entwirft der Agent für einen Menschen oder übergibt, statt live zu antworten. Begrenze wiederholte Versuche, damit nie eine doom loop entsteht. Das in Banking-Bot-Bewertungen am häufigsten genannte Feature ist eine nahtlose Eskalation, und genau die wurde den r/bunq-Kunden verwehrt.

Sensible Daten dort belassen, wo sie hingehören. Beim Onboarding von Finanz- und Gesundheitsteams ist die harte Hürde immer der Umgang mit Daten. Ein Käufer brauchte die Zusicherung, dass Ticketdaten mit Kartennummern und Passwörtern in der eigenen Umgebung bleiben; die Antwort lautet, dass der Agent über Fragetyp und Antwortstil hinweg schlussfolgert, mit individueller Aufbewahrung und Schwärzung personenbezogener Daten, und dass keine Kundendaten zum Trainieren von Modellen verwendet werden. Genau das sind die Fragen, die eine Sicherheitsprüfung jedem Anbieter stellen sollte.

Mit Tier-1 starten, anhand von Belegen erweitern. Der realistische Umfang, den Praktiker immer wieder betonen, ist Tier-1-Deflection: Lass den Agenten die Fragen zu "wie hoch sind die Gebühren" und "wie hebe ich Geld ab" übernehmen, die Support-Zeit fressen, und leite komplizierte Fälle an einen Menschen weiter. Erweitere erst, wenn deine Erstlösungsquote hält. Wer ein Team dafür aufbaut, findet in unserem Skalierungsleitfaden für Startups einen nützlichen Begleiter.

eesel für Banking- und Fintech-Support testen

Wenn du eine Bank, ein Kreditgeber oder ein Fintech bist, das das gerade abwägt: eesel ist genau für das oben beschriebene Muster gebaut. Es dockt an den Helpdesk an, den du bereits nutzt, lernt aus deinen vergangenen Tickets und Hilfedokumenten und antwortet nur aus diesem freigegebenen Wissen, sodass es Tier-1-Anfragen ablenkt, ohne vom Skript abzuweichen. Das Wichtigste für ein reguliertes Team: Du kannst den Agenten gegen Tausende deiner echten historischen Tickets simulieren, bevor er auch nur einem einzigen lebenden Kunden antwortet, und dann die Autonomie schrittweise über konfidenzbasiertes Routing und eine saubere Übergabe an Menschen hochfahren.

Es läuft bereits im Bank-Maßstab: Unser Agent bearbeitet für eine Kreditvergleichsplattform mehr als 100.000 deutschsprachige Tickets pro Monat, mit SOC-2-Kontrollen, DSGVO und EU-Datenresidenz sowie Schwärzung personenbezogener Daten auf der Sicherheitsseite. Die Preisgestaltung ist nutzungsbasiert, etwa 0,40 US-Dollar pro gelöstem Ticket, ohne Gebühren pro Sitzplatz, sodass du nicht für eine Plattform zahlst, die du noch testest.

Du kannst eesel kostenlos testen oder eine Demo buchen, wenn du die Compliance- und Simulationseinrichtung erst einmal mit jemandem durchgehen möchtest.