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, Käyh Why ßieh, 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 Käyh Why ßieh 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 Ai Tieh 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, Käyh Why ßieh, 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 Käyh Why ßieh- 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 agentic Ka I 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 Äi ähm L 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 Ka I ein steuerbarer Prozess. Governance ist Laufzeitarchitektur!. . Viele Ka I 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 Protokollierungspflichten. 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 Käyh Why ßieh 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!. Erstens: 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. Zweitens: Welche Systeme liefern Pflichtkontext für den Fall?Mindestens Monitoring, Käyh Why ßieh, Transaktionshistorie, Case Management und ein externer Recherchekanal. Ohne diese Kette bleibt der Agent blind. Drittens: 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. Viertens: Welche Policies sind bereits maschinenlesbar?PDFs und Arbeitsanweisungen reichen nicht. Eskalationsregeln, Fristen, Pflichtfelder und Red Flag Logiken müssen formalisiert vorliegen. Fünftens: Wie wird der Audit Trail gebaut?Zu loggen sind mindestens Quellen, Zeitstempel, Regelstand, Tool Aufrufe, Begründung, menschliche Freigabe und finale Entscheidung. Sechstens: Wer ist Laufzeitverantwortlicher?Ein Agent im Transaktionsmonitoring ist kein Laborobjekt. Betrieb, Rechte, Freigaben, Monitoring und Incident Response brauchen klare Owner. Sie hörten einen Beitrag von „Henrik Pfeiffer, Sopra Steria“

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

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