Sorgt KI wirklich für effizientere Bankprozesse?

. Die Integration künstlicher Intelligenz soll Bankprozesse spürbar effizienter gestalten. Sie verspricht schnelle Antworten, korrekte Ergebnisse und ein ideales Nutzererlebnis. Entsprechend groß ist das Interesse daran, Ka I in bestehende Prozesse zu integrieren. von Ideal Syka, i6eal. Das anschließende Ausbleiben unerwünschter Fehlermeldungen kann dabei schnell als erfolgreiche Integration gewertet werden. Der Statuscode HTTP 200 signalisiert beispielsweise, dass eine Anfrage aus Sicht des Servers erfolgreich bearbeitet wurde. Doch ob man dann tatsächlich den richtigen Betrag, das angeforderte Dokument oder alle erforderlichen Angaben als Rückmeldung vor sich hat, ist damit nicht garantiert.Der Statuscode allein sagt nicht aus, ob das Ergebnis auch fachlich korrekt und vollständig ist.“Dadurch kann es vorkommen, dass interne Dashboards nach einer Ka I Integration keine Hinweise auf akuten Handlungsbedarf geben, obwohl die Ergebnisse fehlerhaft sind. Daher sollten Ka I Antworten in einem Bankprozess erst dann automatisch weiterverarbeitet werden, wenn die dafür vorgesehenen fachlichen Prüfungen bestanden sind. Je nach Vorgang können diese automatisiert erfolgen oder eine zusätzliche menschliche Prüfung erfordern. KI Integration: Vorschläge kritisch hinterfragen!. . Die sorgfältige Bewertung von Vorschlägen sollte ein standardisiertes Vorgehen sein, das auch nach der Integration künstlicher Intelligenz beibehalten wird. Ob es sich um Ka I Antworten oder menschliche Anregungen handelt, sollte am Anspruch auf fachliche Richtigkeit nichts ändern. Über eine API kann ein Programm Daten von einem Server abrufen, an ihn senden oder Änderungen anfordern. Auch wenn eine solche Anfrage technisch erfolgreich durchgelaufen ist, sollte im nächsten Schritt kontrolliert werden, ob das zurückgegebene Ergebnis stimmt. Es kann untersucht werden, ob beispielsweise alle erforderlichen Angaben vorhanden sind und das erwartete Format eingehalten wird. Zudem sollte man sicherstellen, dass die übermittelten Daten auch wirklich zu dem entsprechenden Dokument oder Vorgang gehören.Insbesondere kritische Werte wie Beträge sollten zusätzlich mit dem Original oder einer zweiten verlässlichen Quelle abgeglichen werden, um mögliche Fehler zu erkennen.“Dies sollte unabhängig davon erfolgen, wie fortschrittlich das eingesetzte Ka I Modell ist. Ein aus einem Scan falsch übernommener Betrag kann schließlich das richtige Zahlenformat haben und trotzdem inhaltlich falsch sein. Effektivität kommt vor Effizienz!. . Wenn neben der funktionierenden Übermittlung von Datensätzen auch die Inhalte stimmen und aufeinander aufbauende Schritte zuverlässig ablaufen, ist eine wichtige Voraussetzung für eine gelungene Ka I Integration erfüllt. Nach Peter Drucker bedeutet Effektivität sinngemäß, die richtigen Dinge zu tun und Effizienz, die Dinge richtig zu tun. Auf Bankprozesse übertragen sollte daher zunächst feststehen, ob die Ka I den vorgesehenen fachlichen Zweck erfüllt. Anschließend lässt sich beurteilen, ob dadurch tatsächlich Aufwand eingespart wird. Um die Erfassung von Dokumenten im Bankbetrieb zu prüfen, kann mit Musterdokumenten begonnen werden. Danach sollten Fälle wie unscharfe Scans, fehlende Seiten, unübliche Layouts, doppelt eingereichte Dokumente oder widersprüchliche Angaben in die Tests einbezogen werden.Sobald sich gezeigt hat, wie zuverlässig das System verschiedene Unterlagen erkennt und welche Fälle eine Nachprüfung erfordern, lohnt sich ein genauer Blick auf die weiteren Schritte nach der Dokumenterfassung.“. . Dazu gehört die Frage, ob Dokumente dem richtigen Vorgang zugeordnet und korrekt gespeichert werden. Hierbei sollten auch gezielt Störungen und fehlerhafte Rückmeldungen getestet werden. Beispiele dafür sind ein Verbindungsabbruch mitten im Upload, unerreichbare Dienste oder eine Antwort mit dem Statuscode HTTP 200, in der erforderliche Angaben fehlen. Wenn die Verarbeitung länger dauert, sollte eine feste Wartefrist vorgesehen sein. Sofern der Dienst dies unterstützt, kann währenddessen der Status des laufenden Auftrags abgefragt werden. Dadurch lässt sich vermeiden, dass derselbe Auftrag erneut angelegt wird, obwohl die ursprüngliche Verarbeitung noch läuft.Bei vorübergehenden technischen Fehlern können begrenzte Wiederholungsversuche sinnvoll sein. Dafür sollten eine maximale Anzahl und zunehmende Abstände zwischen den Versuchen festgelegt werden.Besonders sorgfältig sollte der Fall geprüft werden, dass die Verarbeitung bereits erfolgreich war, die Antwort jedoch nicht angekommen ist.“Eine erneute Anfrage mit derselben Auftragskennung darf dann keine doppelte Ausführung verursachen.Voraussetzung dafür ist, dass der Dienst diese Kennung tatsächlich verwendet, um wiederholte Anfragen zu erkennen. Eine Kennung, die lediglich im Fehlerprotokoll gespeichert wird, verhindert keine doppelte Verarbeitung. Zudem muss der Schutz über den vorgesehenen Zeitraum der Wiederholungsversuche bestehen bleiben. Nach Ablauf der Wartefrist sollten keine weiteren automatischen Verarbeitungsversuche gestartet werden. Der Vorgang wird dann zur Klärung weitergeleitet. Dabei ist zu berücksichtigen, dass ein Auftrag beim Dienst weiterhin laufen kann, auch wenn das anfragende System nicht mehr auf die Antwort wartet. Tests nach der Integration in geschlossener Umgebung durchführen!. . Die Testfälle sollten in einer getrennten Umgebung mit eigenen Zugangsdaten und eindeutig gekennzeichneten Testdaten durchgeführt werden. Dabei muss sichergestellt sein, dass keine echten Folgeaktionen ausgelöst werden können. Ein Testdokument darf beispielsweise nicht zu einer tatsächlichen Buchung führen.Auch bei der Auswertung sollten Testfälle und echte Aufträge getrennt betrachtet werden.“Erfolgreiche Tests mit Musterdokumenten liefern wichtige Hinweise auf die Funktionsfähigkeit des Systems. Sie reichen jedoch nicht aus, um die Qualität bei bisher unbekannten Unterlagen zu beurteilen.Dafür sollten ergänzend Stichproben aus dem laufenden Betrieb fachlich geprüft und mit verlässlichen Referenzen abgeglichen werden. Technischen Ablauf und inhaltliche Qualität getrennt bewerten!. . Für die technische Zuverlässigkeit kann ein internes Betriebsziel festgelegt werden, ein sogenanntes Service Level Objective (SLO). Ein mögliches Beispiel wäre, dass mindestens 99,5 Prozent der berücksichtigten Aufträge innerhalb von acht Sekunden ein Prüfergebnis im festgelegten Datenformat zurückliefern. Bei 20.000 Aufträgen in einem Zeitraum von 30 Tagen dürften damit höchstens 100 Aufträge diese Vorgabe verfehlen. Diese zulässige Abweichung wird als Fehlerbudget bezeichnet. Welche Aufträge in die Auswertung einbezogen werden, sollte vorab eindeutig feststehen. Die Zeitmessung würde in diesem Beispiel im anfragenden System mit dem ersten Übermittlungsversuch beginnen. Wartezeiten und Wiederholungsversuche wären darin enthalten. Jeder ursprüngliche Auftrag würde nur einmal gezählt, auch wenn mehrere Versuche notwendig sind. Aufträge, die unter die festgelegten Kriterien fallen, deren technische Annahme aber scheitert, müssten ebenfalls berücksichtigt werden.Ein solches Betriebsziel beschreibt die technische Zuverlässigkeit und Geschwindigkeit.“Ob das zurückgegebene Ergebnis fachlich richtig ist, muss zusätzlich geprüft werden. Auch ein vollständig ausgefülltes Prüfergebnis im richtigen Format kann einen falsch erkannten Betrag enthalten.Fehlen Pflichtangaben, widersprechen sich kritische Werte oder ist die Zuordnung zum Vorgang nicht eindeutig, sollte die automatische Weiterverarbeitung angehalten werden. Der betroffene Fall erhält einen nachvollziehbaren Status und wird zur manuellen Prüfung weitergeleitet.Dabei sollte auch überwacht werden, wie viele Vorgänge auf eine Prüfung warten und wie lange ihre Bearbeitung dauert.“Wachsende Rückstände können dazu führen, dass sich der gesamte Prozess verzögert, obwohl die API weiterhin schnell antwortet.Bei der manuellen Prüfung werden die Angaben mit dem Originaldokument abgeglichen und wenn notwendig korrigiert. Für besonders kritische Werte kann eine zusätzliche Freigabe vorgesehen werden.Anschließend sollte der Vorgang an einem eindeutig festgelegten Verarbeitungsschritt fortgesetzt werden. Bereits erfolgreich ausgeführte Folgeaktionen dürfen dadurch nicht erneut ausgelöst werden. Fehler analysieren, dann nachbessern!. . Damit sich Fehler nachvollziehen und beheben lassen, sollte das Fehlerprotokoll die Auftragskennung, den Zeitpunkt, den betroffenen Verarbeitungsschritt und eine konkrete Fehlerbeschreibung enthalten.Ebenso hilfreich sind Angaben dazu, welche Prüfungen fehlgeschlagen sind, wie viele Versuche stattgefunden haben und welche Folgeaktionen bereits ausgeführt wurden. Auch die Entscheidung über das weitere Vorgehen sollte dokumentiert werden.Vollständige Dokumentinhalte oder vertrauliche Angaben sollten dabei nicht unnötig in das Protokoll übernommen werden.Erfasst werden sollten die Informationen, die für die Untersuchung erforderlich sind. Der Zugriff darauf sollte auf die zuständigen Personen beschränkt bleiben.“Die dokumentierten Fehler können anschließend genutzt werden, um Prüfungen anzupassen und zusätzliche Testfälle aufzunehmen. So lässt sich nach einer Korrektur gezielt untersuchen, ob die Ursache behoben wurde und der betroffene Ablauf wieder zuverlässig funktioniert. Betriebsziele und Meldepflichten unterscheiden!. . Das interne SLO ist von der vertraglichen Leistungsvereinbarung mit dem Anbieter, dem Service Level Agreement (SLA), zu unterscheiden. Für das SLA gelten die jeweils vereinbarten Messgrößen, Ausschlüsse und Folgen bei einer Abweichung.Wird das interne Betriebsziel verfehlt, liegt deshalb nicht automatisch auch ein Verstoß gegen die vertragliche Vereinbarung vor.Gesondert zu bewerten sind außerdem die Anforderungen der europäischen Verordnung DORA zur digitalen operationalen Resilienz im Finanzsektor.“Artikel 17 behandelt das Management und die Aufzeichnung IKT bezogener Vorfälle, Artikel 18 deren Klassifizierung und Artikel 19 die Meldung schwerwiegender IKT bezogener Vorfälle.Die Kriterien und Schwellenwerte für die Klassifizierung werden durch die Delegierte Verordnung (EU) 2024/1772 konkretisiert.Ein fehlgeschlagener Test oder ein verfehltes internes Betriebsziel begründet für sich genommen noch keine Meldung eines schwerwiegenden Vorfalls. Maßgeblich sind die tatsächlichen Auswirkungen und die einschlägigen Einstufungskriterien.Das Finanzunternehmen muss daher prüfen, wie der Vorfall einzuordnen ist und welche weiteren Maßnahmen erforderlich sind.Ob Ka I tatsächlich für effizientere Bankprozesse sorgt, zeigt sich somit erst im gesamten Ablauf.“Neben der Geschwindigkeit sollten auch der Prüfaufwand, notwendige Korrekturen und die Bearbeitung von Ausnahmefällen berücksichtigt werden.Wenn Vorgänge bei verlässlicher Qualität insgesamt weniger Zeit und Aufwand benötigen, wird aus der technisch erfolgreichen Integration auch eine tatsächliche Entlastung im Bankbetrieb. Sie hörten einen Beitrag von „Ideal Syka, i6eal“

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

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