Transaktionsmonitoring: Für Agentic‑AI braucht es keinen IT-Neustart

Banken müssen für Agentic AI im Transaktionsmonitoring weder zwingend ihre Kernbankensysteme austauschen noch jahrelange Transformationsprogramme abwarten. Die zentrale Aufgabe ist die Integration von Alerts, Datenquellen, Policies, Investigationslogik und Audit-Trail.

von Henrik Pfeiffer, Sopra Steria

Wer Agentic AI im Transaktionsmonitoring als besseren Chatbot denkt, baut am tatsächlichen Problem vorbei. In Banken wird die Automatisierung von AFC-Prozessen selten von einem fehlenden Operating Model behindert. Sie schlägt oftmals fehl, weil die Systembrüche zwischen Alert, KYC, Transaktionshistorie, externer Recherche und Case-Management nicht überwunden werden. Analysten springen zwischen Anwendungen, kopieren Daten, strukturieren Rohmaterial und dokumentieren Ergebnisse mehrfach.

Im bestehenden Operating Model fließen so oft 70 bis 80 Prozent der Arbeitszeit in Datensammlung, Aufbereitung und Dokumentation, nicht in die eigentliche Risikobewertung.“

Genau dort setzt Agentic AI technisch an. Ein Agent ist in diesem Kontext kein Assistent, der auf Prompts wartet. Er ist Teil einer Event-getriebenen Alert-Pipeline. Ein Orchestrator-Agent übernimmt entweder das Eingangssignal aus dem Monitoring-System und legt einen Fall im Case Management System an oder der Fall ist je nach Systemlandschaft bereits automatisch angelegt und wird von dem Agenten aufgenommen. Die Investigation wird anschließend in Teilaufgaben zerlegt und die Arbeit auf spezialisierte Sub-Agenten verteilt. Diese holen KYC-Daten ein, ziehen Transaktionshistorien, lesen Kontext aus dem CRM-Tool, holen externe Treffer, verdichten Ergebnisse und bauen daraus einen vorstrukturierten Bericht. Der menschliche Analyst prüft nicht mehr Rohdaten, sondern eine vorbereitete Investigation mit nachvollziehbarer Empfehlung.

Legacy ist kein Ausschlusskriterium

Der wichtigste Punkt für Bank-IT lautet deshalb nicht: Welches Modell ist das stärkste? Sondern: Wie bekommt man Agenten in eine bestehende Landschaft, ohne daraus ein mehrjähriges Kernsanierungsprojekt zu machen?
Die nüchterne Antwort ist: über eine zusätzliche Orchestrierungs- und Integrationsschicht. Der Agent muss nicht tief in das Kernbankensystem eingebaut werden. Er kann über APIs auf Monitoring, KYC, CRM und Case-Management zugreifen. Wo Schnittstellen fehlen, lassen sich Übergangslösungen über RPA oder UI-Automation einsetzen.

Das Ziel ist nicht, Fachsysteme zu ersetzen, sondern ihre Nutzung prozessual zu koordinieren.“

Wichtig ist dabei die Reihenfolge. Der sichere Einstieg ist fast immer read-heavy. Der Agent liest, korreliert, bewertet und dokumentiert. Geschrieben wird zunächst nur in einen klar abgegrenzten Fallcontainer oder in das Case-Management-System. Keine verdeckten Rückschreibungen ins Kernsystem, keine autonome Eskalation, keine stillen Änderungen an Stammdaten. Das reduziert das Betriebsrisiko und macht Freigaben durch Architektur, Informationssicherheit und Revision realistisch.

Ohne Datenkontext nur schnelleres Rätselraten

Die technische Hürde liegt meist eine Ebene tiefer. Ein Agent kann nur dann sinnvoll arbeiten, wenn er auf einen konsistenten Datenkontext zugreift. Fünf isolierte Screens sind noch keine Ermittlungslogik. Der Agent braucht ein kanonisches Fallobjekt: Kunde, Gegenpartei, Konten, Risikoklasse, Zeitfenster, Alert-Typ, Transaktionshistorie, offene Tickets aus dem Kundenservice und Treffer in externen Datenbanken, bspw. zu negativer Berichterstattung. Erst dann lassen sich Muster, Abweichungen und Red Flags belastbar priorisieren.

Mit einer strukturierten Datenplattform, auf der relevante Informationen aus verschiedenen Quellen zusammengeführt werden, lässt sich das gut umsetzen.“

Ohne diesen Kontext produziert Agentic AI vor allem eines: schnelleres Rätselraten. Das ist gerade in Banken gefährlich, weil KYC- und CRM-Daten häufig historisch gewachsen, semantisch widersprüchlich oder unvollständig sind. Zwei abweichende Kundenschlüssel, ein altes Adressobjekt und ein Freitext im Ticketsystem reichen, um eine saubere Modellantwort in eine unbrauchbare Investigation zu kippen. Das National Institute of Standards and Technology NIST empfiehlt für generative und agentische KI nicht nur menschliche Kontrolle, sondern ausdrücklich Nachvollziehbarkeit, Dokumentation und laufendes Monitoring der eingesetzten Systeme.

Policies müssen maschinenlesbar werden

Der nächste Engpass ist kein Datenproblem, sondern ein Policy-Problem. In vielen Häusern liegen AML-Regeln in PDFs, Word-Dokumenten oder verstreuten Arbeitsanweisungen. Für Analysten ist das mühsam, für Agenten ist es wirkungslos.

Ein Agent kann nur innerhalb eines klar definierten Entscheidungsraums operieren.“

Dafür müssen Regeln formalisiert vorliegen: Welche Konstellationen sind zwingend zu eskalieren? Welche Quellen sind zulässig? Welche Dokumentation ist pro Alert-Typ Pflicht? Welche Fristen gelten für Triage, Investigation und Verdachtsmeldung?

Technisch heißt das nicht zwingend „Policy Engine“ im großen Stil.“

Aber es heißt mindestens versionierte Regeln, maschinenlesbare Entscheidungslogik, referenzierbare Regelstände und nachvollziehbarer Bezug zwischen Fall, Regel und Empfehlung. Sonst entsteht Text, aber keine kontrollierbare Operation. Es braucht ein dynamisches Rule Book, das historisches Wissen, institutsindividuelle Regeln und Fachwissen verbindet. Genau dort wird aus KI ein steuerbarer Prozess.

Governance ist Laufzeitarchitektur

Viele KI-Projekte behandeln Governance wie einen am Ende stehenden Freigabeprozess. Im Transaktionsmonitoring ist das zu spät. Governance muss Teil der Laufzeitarchitektur sein. Gespeichert werden müssen mindestens Modell- oder Prompt-Version, verwendete Tools, Quellreferenzen, Regelstand, Bearbeitungszeit, menschliche Overrides und finale Entscheidung. Es geht nicht darum, das Innenleben des Modells vollständig zu konservieren.

Es geht darum, einen belastbaren Prüfpfad zu erzeugen.“

Das ist nicht nur Best Practice, sondern regulatorisch naheliegend. Die Rahmenwerke des Digital Operational Resilience Act (DORA) verlangen, dass Sicherheitsrichtlinien für Information and Communication Technology (ICT), Verfahren und Werkzeuge in das ICT-Risikomanagement eingebettet sind. Für Banken bedeutet das: Ein Agent im AFC-Betrieb ist kein Laborobjekt, sondern ein regulierter ICT-Baustein mit klaren Verantwortlichkeiten, Kontrollpunkten und Protokollierungs­pflichten.

Womit Banken beginnen sollten

Der technisch sauberste Start ist kein Großprojekt, sondern ein klar abgegrenzter Pilot. Eine Alert-Familie mit hohem Volumen, vielen Medienbrüchen und standardisierbarer Investigation reicht für den Anfang. Dann wird die Integrationskette gebaut: Event aus dem Monitoring, Zugriff auf KYC und Transaktionshistorie, externer Kontext, Regelprüfung, dokumentierter Vorschlag, menschliche Freigabe. Erst wenn dieser Pfad stabil läuft, werden weitere Datenquellen, komplexere Regeln und zusätzliche Agenten ergänzt.

Die Botschaft ist damit unspektakulär, aber für viele Banken befreiend: Agentic AI im Transaktionsmonitoring setzt kein technisches Großreinemachen voraus.“

Institute können mit ihrer heutigen Landschaft beginnen, solange sie Integration, Datenkontext, Policies und Audit-Trail sauber aufsetzen. Wer parallel modernisieren will, kann das tun. Wer erst modernisieren will, bevor er anfängt, startet womöglich zu spät.

Technische Mindestfragen vor dem ersten Pilot

1. Welches Alert-Szenario ist klein genug für einen sauberen Start?
Nicht das gesamte Monitoring auf einmal. Besser eine klar abgrenzbare Alert-Familie mit hohem Volumen und vielen manuellen Schritten.
2. Welche Systeme liefern Pflichtkontext für den Fall?
Mindestens Monitoring, KYC, Transaktionshistorie, Case-Management und ein externer Recherchekanal. Ohne diese Kette bleibt der Agent blind.
3. Welche Zugriffe sind read-only und wo darf geschrieben werden?
Der sichere Start ist ein Read-heavy-Setup mit Rückschreiben nur in einen definierten Fallcontainer oder ins Case-Management.
4. Welche Policies sind bereits maschinenlesbar?
PDFs und Arbeitsanweisungen reichen nicht. Eskalationsregeln, Fristen, Pflichtfelder und Red-Flag-Logiken müssen formalisiert vorliegen.
5. Wie wird der Audit-Trail gebaut?
Zu loggen sind mindestens Quellen, Zeitstempel, Regelstand, Tool-Aufrufe, Begründung, menschliche Freigabe und finale Entscheidung.
6. Wer ist Laufzeitverantwortlicher?
Ein Agent im Transaktionsmonitoring ist kein Laborobjekt. Betrieb, Rechte, Freigaben, Monitoring und Incident Response brauchen klare Owner. Henrik Pfeiffer, Sopra Steria