Können Sie Ihren KYC-Daten vertrauen? Gewährleistung der Genauigkeit durch Beobachtbarkeit

Guten Morgen. Guten Morgen, guten Nachmittag, guten Abend. Herzlich willkommen zum Webinar. Es freut mich, dass bereits einige Teilnehmer zugeschaltet sind. Ich bedanke mich bei allen Frühaufstehern, die pünktlich erschienen sind, aber wir werden die Sitzung in etwa zwei Minuten beginnen. Es ist gerade volle Stunde, aber wir werden in ein paar Minuten loslegen. Ich sehe, dass einige Teilnehmer aus dem Warteraum nach und nach der Sitzung beitreten.

Wir möchten also allen genügend Zeit geben, sich auf die Sitzung einzustimmen. Ihr habt also noch ein bisschen Zeit, euch einen Kaffee oder euer Lieblingsgetränk zu holen. Und wie gesagt: Wir freuen uns, dass ihr an der Sitzung teilnehmt. Wir hoffen auf eine produktive Sitzung. Wir werden in Kürze beginnen. Vielen Dank für eure Geduld. Ich sehe, dass gerade noch ein paar weitere Teilnehmer hinzukommen.

Herzlich willkommen an alle neuen Teilnehmer, die sich der Sitzung angeschlossen haben. Wir werden in Kürze beginnen. Ich sehe noch ein paar weitere Teilnehmer im Warteraum. Wir möchten jedem die Möglichkeit geben, das Webinar von Anfang an mitzuverfolgen. Keine Sorge, wir haben reichlich Zeit. Ich glaube, wir haben nur etwa 45 Minuten eingeplant, sodass Sie sogar noch ein wenig Zeit für den Rest Ihres Tages zurückgewinnen. Aber wir fangen gleich an.

Nochmals vielen Dank für Ihre Teilnahme. Also gut, Scarlett, ich bin etwa zwei Minuten über der Zeit. Ich sehe, glaube ich, noch eine Person, die versucht, sich einzuloggen, und ich werde langsam sprechen – okay, dann fangen wir an. Nochmals: Guten Morgen, guten Nachmittag, guten Abend, je nachdem, von wo aus Sie zugeschaltet sind. Willkommen zu unserem dritten und letzten Webinar dieser Reihe. Darauf werden wir noch etwas näher eingehen. Falls dies Ihr erstes Webinar bei uns ist: Schön, dass Sie dabei sind.

An alle, die wieder dabei sind, um die Reihe abzuschließen: Herzlich willkommen zurück. Mein Name ist John Wisencay. Ich werde heute Ihr Moderator sein. Bevor ich das Wort an unsere Referentin Scarlett übergebe, möchte ich noch ein paar organisatorische Hinweise für diejenigen geben, die zum ersten Mal an unserer Webinar-Reihe teilnehmen. Nur ein paar kurze Anmerkungen. Wir haben leider alle Teilnehmer stummgeschaltet, damit wir ein möglichst effektives Webinar durchführen können. Da wir eine große Teilnehmerzahl haben, wollten wir sicherstellen, dass wir das Webinar mit stummgeschalteten Mikrofonen beginnen.

Sollten Sie im Laufe des Webinars Fragen haben, können Sie gerne unser Q&A-Fenster nutzen. Für diejenigen, die Zoom noch nicht kennen: Das Q&A-Fenster finden Sie am unteren Rand Ihres Bildschirms. Dort sehen Sie wahrscheinlich einen kleinen Kreis mit drei Schaltflächen und einem „Mehr“-Symbol. Wenn Sie darauf klicken, wird „Q&A“ angezeigt. Dort können Sie gerne Ihre Fragen eingeben. Ich habe ein Team zur Verfügung, und Hal steht bereit, um Ihre Fragen zu beantworten. Ich werde ihn gleich vorstellen.

Diese Sitzung wird aufgezeichnet oder wird gerade aufgezeichnet. Das Team wird dafür sorgen, dass ihr die Aufzeichnung nach der Sitzung erhaltet. Wie bereits erwähnt, wird die Sitzung etwa 45 Minuten dauern, und alle heute vorgestellten Ressourcen werden euch nach der Veranstaltung per E-Mail zugeschickt. Noch eine letzte Anmerkung: Bei technischen Problemen könnt ihr euch gerne per E-Mail an mich wenden. Ich werde versuchen, diese gemeinsam mit Ihnen zu lösen. Lassen Sie uns also ganz kurz das heutige Team vorstellen. Wie bereits erwähnt, heiße ich John Wisencay.

Ich leite hier das Sales-Engineering-Team. Ich bin nur ein kleiner Teil des Ganzen. Unsere Hauptreferentin und die Person, um die es heute geht, ist Scarlett Webbe. Sie wird unsere Referentin und Moderatorin sein. Und wie bereits erwähnt, ist Hal Shriver hier, um die Frage-und-Antwort-Runde zu leiten und zu unterstützen. Wenn Sie also Fragen haben, zögern Sie bitte nicht, diese dort einzutippen – wir werden dafür sorgen, dass Ihre Fragen beantwortet werden. Nächste Folie.

Wie ich bereits zu Beginn der Sitzung erwähnt habe, ist dies das dritte Webinar einer dreiteiligen Reihe. Falls Sie zum ersten Mal dabei sind, machen Sie sich keine Sorgen. Wir haben diese Sitzungen so konzipiert, dass sie für sich allein stehen. Aber um die Sitzungen noch einmal hervorzuheben: Sie können sich auch nachträglich dafür anmelden und die Aufzeichnung abrufen, sodass Sie nicht das Gefühl haben müssen, etwas zu verpassen. Wir haben das Ganze im Wesentlichen um drei Komponenten herum aufgebaut, die sich gut in unser Gesamtportfolio einfügen. Unsere erste Sitzung fand bereits im Juni statt, in der wir die Aktivierungsebene vorgestellt haben. Dabei handelte es sich um einen Überblick über unseren KI-Analysten.

Anschließend sind wir mit unserer Data-Intelligence-Plattform in die sogenannte Kontextschicht eingestiegen. Diese Sitzung fand vor etwa drei Wochen statt. Hier können Sie Informationen sammeln und in einen Kontext einordnen. Und wir werden diese Sitzung heute mit der Vertrauensschicht abschließen und uns eingehend mit unserer Beobachtbarkeit befassen. Das sind also die drei Webinare, die wir anbieten, und heute konzentrieren wir uns auf Beobachtbarkeit. Ich übergebe nun das Wort an unsere Referentin, Scarlett. Scarlett, bitte übernehmen Sie. Vielen Dank, John.

Bevor wir uns mit der Beobachtbarkeit befassen, möchte ich diese Sitzung kurz mit dem vorherigen Datenkatalog „Know Your Datenkatalog verknüpfen. In dieser Sitzung haben wir uns auf Actian Data Intelligence als die von John erwähnten Kontextschichten konzentriert. Der „Know Your Customer“-Onboarding-Prozess (KYC) wurde als der obligatorische Prozess definiert, den Finanzinstitute anwenden, um die Identität eines Kunden zu überprüfen und das Risiko zu bewerten, bevor jemand ein Konto eröffnen darf. Wir haben die fünf Schritte dieses Prozesses durchgesprochen: Kontoeröffnung, Identitätsprüfung, Adressprüfung, Risikobewertung sowie Genehmigung und Onboarding. Das Wichtigste, was uns der Katalog lieferte, war der geschäftliche Kontext. Wir konnten nach „KYC-Onboarding“ suchen, die Hierarchie des Glossars einsehen, jeden Teilprozess verstehen, Verantwortliche identifizieren und die Geschäftssprache mit den zugrunde liegenden technischen Datenbeständen verknüpfen. Ein Gedanke aus dieser Sitzung, den es meiner Meinung nach wert ist, weiterzuführen, ist, dass der Katalog eine Brücke zwischen der Geschäftssprache und den technischen Datenbeständen darstellt.

Sie beantwortet die Frage: Wo ist dieser Geschäftsprozess tatsächlich in unseren Daten abgebildet? Außerdem haben wir die Medaillon-Architektur hinter dem KYC-Prozess kennengelernt. Die Bronze-Ebene besteht aus Rohdaten der Kunden, wo Daten zur Kontoeröffnung, Identitätsprüfung und Adressüberprüfung zunächst gespeichert werden. Die Silber-Ebene umfasst vorbereitete Kundendaten, in der wir die Aufzeichnung externen Watchlists und Sanktionsinformationen anreichern und einen Risikofaktor zuweisen. Die Gold-Ebene führt Kundenkonto- und Transaktionsdaten zusammen, damit Teams potenziell verdächtige Aktivitäten kennzeichnen können. Der Katalog zeigte zudem Qualitätsindikatoren direkt in der Datenherkunft an. Das war der Vorgeschmack für heute.

Im Katalog verwandeln diese Indikatoren die Abstammungsstruktur von einer statischen Datenkarte in eine Art „lebendige Risikokarte“. Und heute werfen wir einen Blick hinter die Kulissen der Actian Beobachtbarkeit , die diese Signale erzeugt, diese Probleme erkennt und Teams dabei unterstützt, sie zu untersuchen und entsprechend zu handeln. In Demo heutigen Demo also darum, eine Frage zu beantworten: Können wir den Daten vertrauen, auf denen KYC-Entscheidungen basieren? Für eine Bank ist diese Frage von entscheidender Bedeutung, da KYC nicht nur ein Berichtsworkflow ist. Es entscheidet darüber, ob ein Kunde zugelassen wird, ob ein Risiko eskaliert wird, ob potenziell verdächtige Transaktionen markiert werden und ob nachgelagerte Teams Vertrauen in das von ihnen verwendete Kundenprofil haben. Während wir diesen Ablauf durchgehen, werden wir zeigen, wie Beobachtbarkeit KYC-Daten über diese Ebenen hinweg Beobachtbarkeit , Zuverlässigkeitsprobleme frühzeitig erkennt, Onboarding-Daten auf Aktualität, Schema, Offenlegung personenbezogener Daten und Formatprobleme überprüft, mithilfe von Daten-Binning risikoreiche und zugelassene Kundengruppen voneinander trennt und die Ursachenanalyse durch Investigator beschleunigt. Bevor wir nun zum Produkt übergehen, möchte ich kurz auf die Architektur eingehen, da sie für diesen use case von Bedeutung ist.

KYC-Daten können sensibel sein. Sie können Kundenkennungen, Adressdaten, Felder zur Identitätsprüfung und Informationen zur Risikobewertung umfassen. Aus architektonischer Sicht ist daher entscheidend, dass Actian Data Beobachtbarkeit zu den Daten Beobachtbarkeit , dort, wo sie sich befinden. In diesem Beispiel befinden sich unsere KYC-Daten in Snowflake. Bevor wir zur Demo übergehen, möchte ich kurz darauf eingehen, warum die Architektur so wichtig ist, denn dies ist ein wesentliches Unterscheidungsmerkmal der Beobachtbarkeit. Im Zentrum der Plattform steht eine entkoppelte Spark-SQL-Verarbeitungs-Engine. Das bedeutet, dass wir Daten profilieren, Regeln anwenden, Anomalien erkennen und Qualitäts-KPIs überwachen können, ohne die Rechenlast auf die zugrunde liegende Datenquelle zurückzuverlagern.

Unabhängig davon, ob sich die Daten in Snowflake, S3, BigQuery, Kafka, Delta Lake oder einem anderen Teil der Pipeline befinden, kann Actian sie direkt an ihrem Speicherort analysieren und die Beobachtbarkeit zurück an die Anwendung übermitteln. Das ist besonders wichtig, da moderne Datenpipelines nicht nur aus bereinigten Data-Warehouse-Tabellen bestehen. Oft enthalten sie bereits zu Beginn des Datenflusses Rohdaten sowie semistrukturierte und unstrukturierte Daten. Da unsere Engine entkoppelt und auf Spark basiert, können wir diese verschiedenen Datentypen und Pipeline-Stufen übergreifend betrachten – nicht nur die endgültigen, bereinigten Tabellen, die den nachgelagerten Nutzern angezeigt werden. Heute Demo unsere Demo daher auf KYC-Daten in Snowflake, die eine Medallion-Architektur durchlaufen. Die wichtigste Erkenntnis ist jedoch, dass Actian darauf ausgelegt ist, Probleme viel früher in der Pipeline zu erkennen, bevor sie sich weiter unten in den Compliance-Workflows zu größeren Problemen ausweiten. Das ist wichtig, da wir große Tabellen und Rohdaten überwachen können, ohne dass Teams sensible KYC-Daten in ein anderes System kopieren müssen, nur um festzustellen, ob diese vertrauenswürdig sind.

Nachdem wir nun die Architektur erläutert haben und erklärt haben, warum die entkoppelte Spark-Verarbeitungs-Engine für die Überwachung von Daten entlang der gesamten Pipeline wichtig ist, wollen wir dies nun in den KYC-Geschäftsablauf einbringen, den wir heute demonstrieren werden. Wir bleiben dabei bei demselben KYC-Onboarding-Prozess. Also noch einmal: Kontoeröffnung, Identitätsprüfung, Adressprüfung, Risikobewertung und Genehmigung. Anstatt uns jedoch auf den Geschäftskontext und die Datenherkunft zu konzentrieren, werden wir uns heute auf die Vertrauenswürdigkeit konzentrieren – darauf, ob die Daten, die jeden Schritt dieses Prozesses durchlaufen, vollständig, aktuell, gültig sind und sich wie erwartet verhalten. In der Demo werden wir KYC-Daten über eine Medallion-Architektur hinweg überwachen, und zwar in den Ebenen der Rohkundendaten, der Staging-Kundendaten und der Gold-Transaktionsdaten. Wir werden uns ansehen, wie Actian Data Beobachtbarkeit Zuverlässigkeitsprobleme Beobachtbarkeit , bevor sie sich auf diese Workflows auswirken, Onboarding-Felder wie Identitäts- und Adressdaten validiert sowie Probleme in Bezug auf Schema, Aktualität, Format und Risiko kennzeichnet. Wir werden außerdem zeigen, wie durch Daten-Binning risikoreiche Kundengruppen von genehmigten Datensätzen getrennt werden können, und anschließend mit „Investigator“ die genauen Felder, Datensätze und Segmente identifizieren, die das Risiko verursachen.

Das Ziel ist einfach: Wir wollen nicht nur verstehen, wie Actian Daten entlang der gesamten Pipeline überwachen kann, sondern auch erkennen, wie dies Teams dabei hilft, festzustellen, ob KYC-Daten tatsächlich vertrauenswürdig sind. Bevor wir uns also direkt mit Actian und Beobachtbarkeit befassen, möchte ich dort ansetzen, wo ein Nutzer, ein Datenverwalter oder ein Governance-Team das Problem innerhalb von Actian und Data Intelligence möglicherweise zuerst bemerkt. Hier betrachten wir den Datensatz mit den zusammengefassten Transaktionsdaten, der sich in der „Gold“-Ebene Ihrer KYC-Pipeline befindet. Hier wurden die Transaktionsinformationen zu Kundenkonten zusammengeführt, um Betrugserkennung nachgelagerte Betrugserkennung Compliance-Prüfung zu unterstützen. Auf der Registerkarte „Datenqualität“ bietet uns Actian Data Intelligence eine geschäftsorientierte Übersicht über den Zustand dieses Datensatzes. Wir sehen, dass es insgesamt 12 Prüfungen gibt. 10 wurden bestanden, zwei sind fehlgeschlagen.

Auf den ersten Blick lässt sich daraus erkennen, dass dieser Datensatz größtenteils in Ordnung ist, dass es jedoch einige spezifische Zuverlässigkeitsprobleme gibt, die berücksichtigt werden müssen, bevor wir ihm bei KYC- oder betrugsbezogenen Entscheidungen voll und ganz vertrauen können. Was mir an dieser Ansicht gefällt, ist, dass sie die Prüfungen in Kategorien gruppiert, die für das Unternehmen von Bedeutung sind: Beständigkeit, Vollständigkeit, Aktualität, Betrug und Gültigkeit. Anstatt also einen Compliance-Analysten oder einen Datenverwalter zu bitten, rohe SQL-Abfragen, Protokolle oder Pipeline-Warnmeldungen zu interpretieren, können diese sofort erkennen, dass die meisten meiner Prüfungen erfolgreich sind, ich jedoch eine fehlgeschlagene Betrugsprüfung und eine fehlgeschlagene Gültigkeitsprüfung habe. Das ist ein viel besser umsetzbarer Ausgangspunkt. Die naheliegende Frage lautet also: Was ist die Ursache für diese fehlgeschlagenen Prüfungen? An dieser Stelle wechseln wir vom Kontext zur Untersuchung. Actian Data Intelligence zeigt uns, welche vertrauenswürdige Geschäftsressource betroffen ist, und liefert uns den geschäftlichen Kontext dazu.

Actian Data Beobachtbarkeit uns, warum das Problem aufgetreten ist, welche Datensätze oder Felder betroffen sind und welche Maßnahmen wir als Nächstes ergreifen müssen. Und wir können Beobachtbarkeit aus dem Datenkatalog heraus zu Actian Data Beobachtbarkeit wechseln. Und jetzt befinden wir uns in Actian Data Beobachtbarkeit. Wir konzentrieren uns auf dasselbe „Transactions Roll-up“-Asset. Das haben wir uns gerade in Actian Data Intelligence angesehen. Hier wird das Vertrauenssignal also umsetzbar. Das ist Investigator.

Es handelt sich um eine interaktive Arbeitsumgebung, die Analysten, Ingenieure oder Geschäftsanwender nutzen, um Beobachtbarkeit zu untersuchen, zu diagnostizieren und zu beheben, sobald Anomalien erkannt werden. Hier können wir die Überwachungsergebnisse genauer unter die Lupe nehmen. Wir können Trends im Zeitverlauf anzeigen. Wir können das Ausmaß des Problems erkennen und nachvollziehen, ob es sich um ein einmaliges Ereignis oder ein wiederkehrendes Muster handelt. Für dieses Szenario – nämlich KYC – könnte das bedeuten, welche Transaktionsarten das Risikoproblem verursachen, welche Risikobandbreiten überrepräsentiert sind oder welche Kundendatensätze mit verdächtigen Transaktionsbeträgen in Verbindung stehen. Was hier also geschieht, ist, dass Personen mit einem hohen Risikobetrag und einem hohen Transaktionsbetrag von über 10.000 US-Dollar markiert werden. Anstatt also zu sagen, dass die Transaktionszusammenfassung eine Betrugsprüfung nicht bestanden hat, können wir sagen: „Hier sind die genauen Muster und Datensätze, die diesen Fehler verursacht haben, und hier ist eine Teilmenge der Daten, die überprüft werden muss.“ Das ist also die Schnittstelle zwischen Datenintelligenz und Beobachtbarkeit.

Actian Data Beobachtbarkeit uns die operative Vertrauensebene, sodass Datensätze aktuell, vollständig und gültig sind und sich wie erwartet verhalten – und wenn dies nicht der Fall ist: Was genau ist die Ursache des Problems? Für KYC ist dieser Zusammenhang entscheidend. Das bedeutet, dass Teams nicht nur Compliance-Daten dokumentieren, sondern kontinuierlich die Daten validieren, die die Kundenaufnahme, die Risikobewertung, Betrugserkennung und die behördliche Überprüfung unterstützen. Nachdem wir nun mit Investigator die spezifischen Datensätze, Werte und Muster untersucht haben, die dieses Problem verursachen, werde ich wieder zur Übersichtsseite zurückkehren. Der Grund, warum ich gerne hierher zurückkehre, ist, dass Investigator uns zwar die detaillierte Ansicht der Grundursache liefert, die Übersichtsseite uns jedoch die operative Kommandozentrale bietet. Sie hilft uns zu verstehen, wie dieses einzelne Problem in den Gesamtzustand der KYC-Pipeline passt. Was ist also sonst noch offen?

Was wurde abgeschlossen? Was wurde gelöst? Welche Assets sind betroffen, und wo liegen die Risiken mit der höchsten Priorität in der gesamten Umgebung? Wir sind also von der Warnmeldung zu den Details übergegangen und kehren nun wieder zur Übersicht zurück. So können ein Datenteam, ein Compliance-Team oder ein Betriebsleiter das Gesamtbild erfassen und entscheiden, was als Nächstes Aufmerksamkeit erfordert. Innerhalb dieses Kontrollzentrums für Datenzuverlässigkeit erhalten wir also – anstatt mit einer einzelnen Tabelle oder Regel zu beginnen – einen operativen Überblick darüber, was im gesamten KYC-Datenbestand geschieht. In dieser Demo konzentrieren wir uns nun ausschließlich auf KYC-Assets in Snowflake.

Die Arten von Informationen, auf die ich hier besonders hinweisen möchte, sind die Gesamtzahl der Vorfälle, der Schweregrad bzw. die Auswirkungen, der Zeitpunkt der Vorfallerfassung sowie die Trends im Zeitverlauf. Dies ist für Data-Operations-Teams nützlich, da es Antworten auf folgende Fragen liefert: Was ist ausgefallen? Wo ist der Ausfall aufgetreten? Wie lange ist der Vorfall bereits offen? Und wer muss darauf reagieren? Dabei ist es wichtig zu beachten, dass nicht jedes Problem die gleichen geschäftlichen Auswirkungen hat. Eine Schemaänderung in einer nicht kritischen Spalte mag zwar nur eine Warnung darstellen, doch die Offenlegung personenbezogener Daten (PII) bei fehlenden Identitätsfeldern, ein unerwarteter Volumenrückgang oder Risikofaktorwerte außerhalb der genehmigten Bereiche sind weitaus schwerwiegender, da sie sich auf Onboarding, Compliance, Überprüfung oder Betrugserkennung auswirken können.

Die Übersicht dient also dazu, dass Teams sich schnell einen Überblick über den Zustand des KYC-Datenflusses verschaffen können, bevor sie sich mit einem bestimmten Vermögenswert näher befassen. Ich werde diesen Vorfall hier öffnen, damit wir von der Übersicht zu den Details eines bestimmten Zuverlässigkeitsproblems übergehen können. Zu diesem Zeitpunkt weiß ein Dateningenieur oder ein Datenbetriebsanalyst vielleicht bereits, dass etwas nicht stimmt, benötigt aber dennoch Unterstützung dabei, zu verstehen, wo er ansetzen soll. Handelt es sich um ein Problem an der Datenquelle? Hängt es mit einer Transformation zusammen? Ist es auf ein Feld, ein Kundensegment oder einen Durchlauf beschränkt? Genau hier kommt unser Beobachtbarkeit ins Spiel.

Anstatt die Details des Vorfalls, Trends, Überwachungsergebnisse und den Kontext der Ressourcen manuell zusammenzufügen, kann ich den Beobachtbarkeit nutzen, um die gesammelten Informationen zusammenzufassen und die Untersuchung zu lenken. Die Frage, die ich mir dabei stelle, lautet: Was ist die wahrscheinliche Ursache dieses Vorfalls? Und was der Beobachtbarkeit hier leistet, ist, die Beobachtbarkeit in einen Untersuchungsansatz zu übersetzen. Er kann den Vorfall zusammenfassen, die betroffene Ressource hervorheben, auf die Felder oder Muster hinweisen, die zum Problem beitragen, und den Teams helfen zu verstehen, was als Nächstes überprüft werden muss. Anstatt also mit einer generischen Warnmeldung zu beginnen, die besagt, dass etwas fehlgeschlagen ist, erhalten wir eine gezieltere Erfahrung bei der Ursachenanalyse. Wir können erkennen, ob es sich um ein Datenqualitätsproblem in der Quelle, um ein Transformationsproblem, um ein Problem in der Pipeline oder um einen Verstoß gegen Geschäftsregeln im Zusammenhang mit KYC-Schwellenwerten handelt. Der geschäftliche Mehrwert liegt hier in der Geschwindigkeit und der Priorisierung.

„Ask AI“ hilft dem Team, schneller von der Erkennung eines Vorfalls zur Untersuchung des Vorfalls überzugehen. Es bietet dem Datenbetrieb einen Ausgangspunkt, liefert Compliance-Teams eine klare Erklärung der geschäftlichen Auswirkungen und reduziert den Hin- und Her-Austausch zwischen den Teams, die versuchen, die tatsächliche Bedeutung der Warnmeldung zu interpretieren. Natürlich können wir uns weiterhin den Monitor selbst genauer ansehen, aber wir können „Investigator“ nutzen, um die genauen Datensätze und Werte zu überprüfen. Dabei fangen wir nicht bei Null an, sondern haben bereits den Kontext. Lassen Sie uns also kurz einen Überblick über die übrigen Komponenten gewinnen, die wir uns heute ansehen werden. Wie ich bereits erwähnt habe, umfasst die Bronze-Ebene die Rohdaten der Kunden; dabei handelt es sich um die Daten, die erfasst werden, wenn der Kunde mit der Kontoregistrierung beginnt und Identitäts- sowie Adressdaten angibt. Im Bereich „Staging Customer“ führen wir die Risikobewertung anhand externer Prüfungen wie Watchlists, Sanktionslisten oder anderer Risikomodelle ein.

Und dann die oberste Ebene: Hier haben wir Transaktionen und Transaktionszusammenfassungen, bei denen wir das Kundenrisiko mit dem Transaktionsverhalten kombinieren. Das eröffnet uns einen klaren Weg. Erstens: Vertrauen wir den eingehenden Rohdaten der Kunden? Zweitens: Vertrauen wir der Risikobewertung und der Genehmigungslogik? Und drittens: Vertrauen wir den Transaktionssignalen, die zur Erkennung potenziell verdächtigen Verhaltens verwendet werden? Wir beginnen also mit den Rohdaten der Kunden in der Bronze-Ebene. Dies ist der früheste Punkt in der Migration, und hier lassen sich auch viele Probleme erkennen, bevor sie sich ausbreiten.

In dieser Phase geben Kunden Daten zur Kontoeröffnung sowie Angaben zur Identitätsprüfung ein; sind die Rohdaten hier fehlerhaft, wird jede nachfolgende Entscheidung fragwürdig. Auf der Profiling-Seite können wir den Zustand jedes Datensatzes auf Attribut- oder Spaltenebene einsehen. Dazu gehören Vollständigkeit, Duplikate, Richtigkeit, Eindeutigkeit, Kardinalität, eindeutige Werte, leere Felder jeglicher Art sowie weitere Profiling-Statistiken. Anstatt zu sagen: „Wir glauben, dass die Kundentabelle in Ordnung aussieht“, verfügen wir nun über ein quantifiziertes Bild des Zustands der Daten. Für KYC gehören zu den besonders wichtigen Prüfungen in dieser Ebene die erforderlichen Identitätsfelder, die ausgefüllt sein müssen. Sind Adressfelder vorhanden? Entsprechen Felder wie Sozialversicherungsnummer und Kreditkartennummer den erwarteten Formaten?

Sind die Kunden-IDs eindeutig? Hat sich das Schema unerwartet geändert? Und ist die Anzahl der Neuregistrierungen im Vergleich zum normalen Verhalten zurückgegangen oder stark angestiegen? Hier Beobachtbarkeit von Echtzeitdaten Beobachtbarkeit , den Prozess nach vorne zu verlagern. Wir warten nicht ab, bis ein nachgelagertes dashboard ein Compliance-Bericht Unstimmigkeiten aufzeigt. Wir erkennen Probleme so früh wie möglich nach der Datenerfassung. Schauen wir uns nun eine der Warnmeldungen zu einem dieser Rohkundendaten genauer an.

Auf der Seite „Trends und Warnmeldungen“ können wir den Verlauf dieses Assets sowie die spezifischen Warnmeldungen einsehen, die bei jedem Scan generiert wurden. Die Plattform überwacht das erwartete Verhalten im Zeitverlauf, sodass wir untersuchen, was sich geändert hat, wann es sich geändert hat und wie signifikant die Änderung war. Betrachten wir beispielsweise die Offenlegung personenbezogener Daten – das Problem, das die Plattform identifizieren kann, sind sensible Muster, die an Stellen auftreten, an denen sie nicht vorkommen sollten, wie beispielsweise in Freitextnotizen. Betrachten wir ein Formatproblem, wie etwa die Struktur von Sozialversicherungsnummern, Adressen, Geburtsdaten oder anderen Onboarding-Faktoren. Bei der Betrachtung von Volumen oder Aktualität können wir erkennen, ob Kundenregistrierungsdaten verspätet oder unvollständig sind. Und wenn wir „Investigator“ aufrufen, geht es um mehr als nur einen roten oder grünen Status. „Investigator“ bietet uns einen interaktiven Arbeitsbereich, um die Datensätze, Felder, Werte und Segmente zu verstehen, die den Alarm ausgelöst haben.

Das ist der Unterschied zwischen einer irrelevanten Warnmeldung und einer umsetzbaren Untersuchung. Das Team kann erkennen, welche Felder betroffen sind, welche Werte das Problem verursachen, wann die Anomalie und welche Datensätze betroffen sind. Von hier aus kann es die Detaildaten exportieren, ein Ticket erstellen oder den Fall direkt an das zuständige Incident-Team weiterleiten. Für einen KYC-Workflow ist das entscheidend, denn man möchte nicht, dass ein Analyst manuell Snowflake durchforstet, um festzustellen, ob es sich um ein Problem mit den Rohdaten, der Pipeline oder der Transformation handelt. Man möchte die Ursache schnell isolieren und den nachgelagerten Prozess schützen. Wechseln wir nun von der Bronze- zur Silber-Ebene. Hier wird der KYC-Prozess für Kunden in der Staging-Phase risikorientierter.

Wir prüfen nicht mehr, ob der Kunde das Formular korrekt ausgefüllt hat. Zu diesem Zeitpunkt Aufzeichnung der Aufzeichnung bereits mit Risikoinformationen aus externen Quellen wie Beobachtungslisten, Sanktionslisten oder anderen Überprüfungsprozessen angereichert. In dieser Demo werden wir uns den Risikofaktor-Score ansehen. Ein niedrigerer Wert steht für ein akzeptables Risikoniveau. Ein höherer Wert deutet auf einen Kunden hin, der möglicherweise einer zusätzlichen Prüfung bedarf oder nicht automatisch genehmigt werden sollte. Und in der Realität stehen Ihre Daten nie still. Sie entwickeln sich ständig weiter, da sich Anträge, Kunden und Geschäftsprozesse ändern.

Deshalb versagen statische Qualitätsregeln so schnell. Sie benötigen Maschinelles Lernen Überwachungsinstrumente, die sich an die Daten selbst anpassen und Veränderungen bereits im Vorfeld erkennen, bevor sie zu kostspieligen Problemen im weiteren Verlauf führen. Es geht darum, Vertrauen aufzubauen, das mit Ihren Daten mitwächst, und nicht nur eine Momentaufnahme zu erstellen. Und wir bieten hier 16 sofort einsatzbereite Monitore, die bereits beim ersten Scan automatisch auf Ihre Assets angewendet werden. Maschinelles Lernen von Actian lernen also automatisch Muster in Ihren Daten, ohne dass Sie benutzerdefinierte Regeln schreiben müssen. Sie analysieren die Daten bei jedem Scan, um Normalverteilungen, Zusammenhänge und Trends zu ermitteln. Sobald das Modell trainiert ist, überprüft es die eingehenden Daten kontinuierlich in Echtzeit oder im Batch-Verfahren.

Die automatisierten Prüfungen bieten in vielerlei Hinsicht einen Mehrwert. Wenn Sie als Data Engineer tätig sind, sparen Sie dadurch Zeit, da Sie keine Ad-hoc-Regeln mehr erstellen müssen. Und wenn wir uns beispielsweise diesen Risikofaktor „zu hoch“ ansehen, wollen wir die Bestandteile eines Monitors einmal genauer betrachten und aufschlüsseln. Ein Monitor besteht also aus drei Teilen. Da ist zum einen die Metrik, also das, was Sie messen. Dann gibt es den Schwellenwert: Wie legt man fest, wann etwas zu einer Anomalie wird? Dafür gibt es drei Möglichkeiten.

Maschinelles Lernen, lernt also aus Datenmustern. Es gibt relative prozentuale Abweichungen zwischen Zeiträumen sowie festgelegte Bereiche und explizite Minimal- und Maximalwerte. Und der dritte Teil ist die Aktion. Wen möchten Sie benachrichtigen, wenn etwas schiefgeht oder die Datensätze die Überwachungskriterien nicht erfüllen? Es werden Maschinelles Lernen bereitgestellt, wodurch die Notwendigkeit entfällt, diese Schwellenwerte manuell zu definieren. In diesem Beispiel hier betrachten wir also eine Aufzeichnung für Aufzeichnung . In diesem Ausdruck hier sehen wir also, dass wir Ihre Risikofaktorwerte von 1 bis 11 verwenden, die für eine automatisierte Genehmigung als akzeptabel gelten, während Werte über 12 als hohes Risiko behandelt werden.

Das bedeutet nun nicht, dass die Daten im herkömmlichen Sinne fehlerhaft sind. Es bedeutet vielmehr, dass die Daten uns etwas operativ Wichtiges mitteilen. Diese Kundengruppe sollte abgetrennt, überprüft oder von der nachgelagerten Genehmigung ausgeschlossen werden. Und dies ist ein hervorragendes Beispiel dafür, warum Datenqualität und Beobachtbarkeit einen geschäftlichen Kontext Beobachtbarkeit . Eine Zahl wie 13 ist an sich nicht ungültig. Sie ist für diesen spezifischen KYC-Genehmigungsworkflow ungültig, weil sie die akzeptable Risikoschwelle der Bank überschreitet. Und wenn wir dies in Investigator öffnen, können wir die Verteilung der Werte sehen, die zu diesem Verstoß führen.

Das sind also die Werte 1 bis 16, und wir können sehen, wie viele Datensätze in diese Risikobandbreiten fallen. Hier hilft uns Investigator dabei, den Schritt von der Erkennung zum Verständnis zu machen. Wir können einen bestimmten Wert auswählen, beispielsweise den Risikofaktor 13, und sehen dann die Datensätze, die mit diesem Wert in Verbindung stehen. Dadurch erhält das KYC-Operations-Team eine konkrete Gruppe zur Überprüfung anstelle einer vagen Warnmeldung wie „Problem mit Risikofaktor erkannt“. Eine weitere wichtige Funktion ist das Daten-Binning. In diesem KYC-Workflow können wir Datensätze anhand des Schwellenwerts für den Risikofaktor trennen. Kunden mit einem akzeptablen Risikobereich können bis zum genehmigten Schwellenwert weiterverarbeitet werden. Kunden innerhalb eines nicht akzeptablen Bereichs können zur weiteren Überprüfung in einen ungültigen oder einen Hochrisikopfad geleitet werden.

Und das ist wichtig, denn der Prozess muss nicht zum Stillstand kommen, nur weil einige Datensätze einer Überprüfung bedürfen. Die einwandfreien Datensätze können weiterbearbeitet werden, während die risikobehafteten Datensätze zur Überprüfung zurückgestellt werden. Für eine Bank trägt dies dazu bei, die Betriebskontinuität zu wahren, ohne das Compliance-Risiko zu vernachlässigen. Dies ist ein Kontrollpunkt zwischen der Silber- und der Gold-Ebene. Wir nutzen Beobachtbarkeit nur, um zu erkennen, dass eine Risikoschwelle überschritten wurde, sondern auch, um die betroffenen Datensätze zu isolieren und zu verhindern, dass sie unbemerkt die genehmigte Kundenbasis kontaminieren. Fahren wir nun also mit der Gold-Ebene fort. An dieser Stelle hat der KYC-Prozess – lassen Sie mich hier kurz weitermachen. Der KYC-Prozess hat ...

Das tut mir leid. Meine Magic Mouse ist da gerade ein bisschen durchgedreht. Enthält sowohl Transaktionsdaten als auch Informationen zum Transaktions-Rollup. Transaktionen stellen also die Aktivitäten auf Transaktionsebene dar, und die Transaktionszusammenfassung liefert uns eine aggregierte Ansicht, die Kundenrisikofaktoren und Transaktionsverhalten kombiniert. Dies ist nützlich für Betrugs- und Geldwäschebekämpfungsszenarien, da verdächtige Aktivitäten selten nur ein isolation Feld betreffen. Es handelt sich in der Regel um ein Muster, das sich über das Kundenprofil, den Risikowert, die Transaktionsart und den Transaktionsbetrag erstreckt. Schauen wir uns also die verdächtige Transaktion oder den Geldwäschefall einmal genauer an.

Die Logik, die wir hier anwenden, besagt, dass bestimmte Kombinationen zur Überprüfung markiert werden sollten. Beispielsweise sollte ein Kunde mit einer Risikobewertung oberhalb eines akzeptablen Schwellenwerts eskaliert werden, aber auch ein Kunde mit geringerem Risiko kann verdächtige Aktivitäten auslösen, wenn bestimmte Transaktionsarten oder Transaktionsbeträge vorliegen, die über einem Schwellenwert liegen, wie beispielsweise Barzahlungen, Zelle-Zahlungen oder Auslandsüberweisungen über 10.000 $. Und wenn wir in Investigator gehen, können wir die Werte und Kombinationen sehen, die den Alarm auslösen. Eine Möglichkeit, dies zu veranschaulichen, besteht darin, den Risikofaktor mit dem Transaktionsbetrag zu gruppieren oder zu aggregieren. So kann das Team schnell erkennen, ob sich das Problem auf ein bestimmtes Risikoband, eine bestimmte Transaktionsart oder einen bestimmten Betragsbereich konzentriert. Der wichtige Punkt ist, dass Beobachtbarkeit uns nicht nur Beobachtbarkeit , dass der „Gold“-Datensatz eine Prüfung nicht bestanden hat. Sie hilft uns zu verstehen, warum dies geschehen ist.

Ob es sich um Kunden oder Transaktionen handelt und ob das Problem bereits im Vorfeld bei der Kundenaufnahme, bei der Risikoanreicherung oder bei der Transaktionsverarbeitung entstanden ist – darin liegt die Stärke der Überwachung entlang der gesamten KYC-Pipeline. Wir können bei verdächtigem Transaktionsverhalten in der „Gold“-Stufe ansetzen und die Untersuchung bis zu den zugrunde liegenden Risikofaktoren und dem Rohprofil des Kunden zurückverfolgen. Oder wir können Probleme bereits früher in der „Bronze“- oder „Silber“-Stufe erkennen, bevor sie überhaupt im Transaktionsworkflow auftauchen. Für die Compliance bedeutet das eine schnellere Triage. Für das Data Engineering bedeutet das weniger manuelle Untersuchungen. Für das Unternehmen bedeutet es mehr Vertrauen in die Zuverlässigkeit der Daten, die zur Kundenfreigabe und zur Kennzeichnung verdächtiger Aktivitäten verwendet werden.

Sobald ein Problem untersucht wurde, stellt sich also die Frage: Wie gelangt es an das richtige Team, damit dieses Maßnahmen ergreifen kann? Beobachtbarkeit von Actian Beobachtbarkeit Alarmierung und operative Arbeitsabläufe. So können Teams Probleme nach Richtlinie, Asset, Verantwortlichem, Schweregrad oder Kanal weiterleiten. Das können E-Mail, Slack, Teams, JIRA, ServiceNow oder ein anderer Prozess sein, den das Unternehmen nutzt. Das Ziel ist es, nicht noch mehr „Lärm“ zu erzeugen. Das Ziel ist es, Warnmeldungen umsetzbar zu machen. Ein Problem mit personenbezogenen Daten (PII) von hoher Auswirkung in den Rohdaten eines Kunden sollte nicht genauso behandelt werden wie eine Profilabweichung von geringer Auswirkung in einem nicht kritischen Feld.

Ein Verstoß gegen den Schwellenwert für Hochrisikofaktoren bei Kunden in der Staging-Phase sollte an das für die KYC-Prüfung zuständige Team weitergeleitet werden. Ein verdächtiges Transaktionsmuster und eine Zusammenfassung von Transaktionen müssen möglicherweise an die Betrugsbekämpfung oder die Compliance-Abteilung weitergeleitet werden. Nach der Behebung kann die Plattform die Daten erneut scannen und den Vorfall auf der Grundlage der tatsächlichen Daten aktualisieren. Das bedeutet also, dass die Lösung davon abhängt, ob die Daten wieder in einen akzeptablen Zustand zurückgeführt wurden, und nicht nur davon, dass jemand ein Ticket geschlossen hat. Fassen wir also zusammen, was wir besprochen haben. Erstens haben wir vertrauenswürdige KYC-Daten über die gesamte Pipeline hinweg überwacht: Rohdaten zur Kunden-Onboarding, Risikobewertung von Kunden in der Staging-Phase und die Überwachung von „Gold“-Transaktionen. Zweitens haben wir Compliance-Risiken frühzeitig auf der „Bronze“-Ebene erkannt.

Das bedeutet, Probleme hinsichtlich Aktualität, Schema, personenbezogener Daten, Vollständigkeit und Format zu erkennen, bevor sie weiterverarbeitet werden. Auf der „Silber“-Ebene bedeutet dies, Kunden zu identifizieren, die Risikogrenzen überschreiten, bevor sie genehmigt werden. Und auf der „Gold“-Ebene bedeutet dies, verdächtige Transaktionsmuster zu kennzeichnen, die Kundenrisiko und Transaktionsverhalten kombinieren. Drittens haben wir die Untersuchung beschleunigt. „Investigator“ hilft Teams dabei, den Sprung von „etwas ist fehlgeschlagen“ zu „hier sind die Felder, Werte, Datensätze und Segmente, die das Problem verursachen“ zu schaffen. Das ist es, was Beobachtbarkeit einem dashboard einen operativen Arbeitsablauf verwandelt. Die wichtigste Erkenntnis ist also ganz einfach.

Der Katalog liefert den KYC-Teams den nötigen Kontext. Beobachtbarkeit von Actian Beobachtbarkeit kontinuierliches Vertrauen. Und gemeinsam helfen sie Unternehmen dabei, nicht nur zu verstehen, wohin die KYC-Daten fließen, sondern auch, ob diese Daten in jedem Schritt vertrauenswürdig sind. Tolle Arbeit, Scarlett. Gut gemacht. Sehr informativ und ein perfekter Abschluss der Reihe. An alle, die live dabei sind: Wenn Sie Fragen haben, können Sie diese gerne in das Q&A-Feld eingeben, und wir werden sie hier in kurzer Zeit beantworten.

Ich möchte Ihnen gerne unsere Kontaktdaten mitteilen. Ich weiß, dass viele von Ihnen sich diese Aufzeichnungen erst nach der Veranstaltung ansehen. Und auch für diejenigen, die sich die Aufzeichnung gerade ansehen: Falls Sie Fragen haben oder weitere Informationen benötigen, möchte ich Ihnen unsere Kontaktdaten mitteilen. Nicht nur meine eigenen, sondern auch die von Scarlett, unserer Moderatorin, und von Hal. Noch einmal: Bei Fragen, wenn Sie weitere Informationen benötigen oder etwas zum Inhalt wissen möchten, können Sie sich gerne an uns wenden. Noch ein kleiner Aufruf zum Handeln, sowohl für diejenigen, die an der Veranstaltung teilgenommen haben, als auch für diejenigen, die sich die Aufzeichnung ansehen. Wie wir bereits in unserer ersten Sitzung erwähnt haben, bieten wir eine 14-tägige kostenlose Testversion unseres Actian AI Analyst an.

Das ist eine großartige Möglichkeit für Sie, sich intensiv damit auseinanderzusetzen und erste praktische Erfahrungen mit unserer Technologie zu sammeln. Es ist sehr leicht zu erlernen, und viele unserer Kunden profitieren sofort von dieser 14-tägigen Testversion. Sie erhalten uneingeschränkten Zugriff auf die Plattform – es gibt keinerlei Einschränkungen. Und falls Sie zum ersten Mal dabei sind: Wie ich bereits erwähnt habe, ist dies Teil einer dreiteiligen Reihe. Wir schließen die Reihe hier mit dem Thema „Trust Layer“ ab. Wenn Sie sich jedoch für eine Anmeldung interessieren, können Sie dies tun und sich die vorherigen Webinare On Demand ansehen. Besuchen Sie einfach unsere Website, klicken Sie auf den Bereich „Veranstaltungen“, melden Sie sich für diese Sitzungen an und erhalten Sie Zugang zu den beiden vorherigen KYC-Aufzeichnungen.

Und damit kommen wir nun zu den Fragen. Noch einmal: Alle Teilnehmer dieser Sitzung, die Fragen haben, können diese gerne eintippen. Sehr gut. Ich glaube, wir haben gerade eine Frage erhalten. Scarlett, hoffentlich kannst du diese Frage live beantworten. Es sieht also so aus, als hätten wir folgende Frage: „Inwiefern Beobachtbarkeit Actian Data Beobachtbarkeit von herkömmlichen Datenqualitäts-Tools oder Tools zur Pipeline-Überwachung?“ Eine wirklich gute Frage. Einer der größten Unterschiede bei Actian Data Beobachtbarkeit dass wir nicht einfach am Ende der Pipeline sitzen und prüfen, ob Daten eine vordefinierte Regel erfüllt oder nicht.

Wie ich bereits zu Beginn der Präsentation erwähnt habe, nutzt die Plattform eine entkoppelte Spark-Verarbeitungs-Engine, um Daten in großem Maßstab zu profilieren und zu analysieren. Dies ermöglicht es Unternehmen, Daten über verschiedene Quellen und Phasen des Datenlebenszyklus hinweg zu überwachen, ohne auf ein einzelnes Data Warehouse beschränkt zu sein oder auf SQL-basierte Prüfungen angewiesen zu sein. Dies unterstützt zudem einen „Shift-Left“-Ansatz für Beobachtbarkeit. Anstatt also abzuwarten, bis fehlerhafte Daten einen dashboard oder ein KI-Modell erreichen, können Teams die Daten bereits viel früher in der Pipeline überwachen. Wenn die Daten beispielsweise in einer Roh- oder Bronze-Ebene landen und während ihres Durchlaufs durch die Transformations- und Verbrauchsschichten weiterhin überwacht werden, gibt dies dem Team die Möglichkeit, Probleme näher an der Stelle zu identifizieren, an der sie entstanden sind. Außerdem kombinieren wir automatisierte Überwachung – wie Aktualität, Volumen, Schema, Top-Drifts, Aufzeichnung und Verteilungsänderungen – mit spezifischer Geschäftslogik zusätzlich zu den Datenqualitätsregeln. So können wir sowohl unerwartete Verhaltensänderungen in den Daten als auch bekannte Geschäftsbedingungen erkennen, die durchgesetzt werden müssen. Der praktische Unterschied besteht meiner Meinung nach darin, dass eine Pipeline immer noch erfolgreich abgeschlossen werden kann – hmm …

aus Sicht der Infrastruktur und liefern dennoch unvollständige, verspätete oder falsche Daten. Actian Data Beobachtbarkeit darauf, die Zuverlässigkeit der Daten zu überprüfen, die diese Pipeline durchlaufen, und dies so frühzeitig zu tun, dass Teams die Probleme untersuchen und beheben können, bevor sie Auswirkungen auf nachgelagerte Prozesse haben. Großartig. Danke, Scarlett. Mm-hmm. Da kommt noch eine Frage herein. Ich glaube, du hast das schon kurz angesprochen.

Ich erinnere mich natürlich an die Alarmierung und die Ursachenanalyse, aber diese konkrete Frage dreht sich darum, wie Actian Teams tatsächlich dabei unterstützt, den Schritt von der reinen Alarmierung zur Ursachenanalyse zu vollziehen. Das ist eine weitere gute Frage, die häufig aufkommt, wenn ich mit Kunden spreche. Der Schlüssel liegt darin, dass Actian Data Beobachtbarkeit darauf ausgelegt Beobachtbarkeit , Teams den Kontext hinter einem Problem zu liefern und ihnen nicht nur mitzuteilen, dass ein Monitor rot leuchtet. Wenn also Anomalie erkannt Anomalie , können Teams bei dem Monitor ansetzen, der die Warnmeldung ausgelöst hat, und sich dann die zugrunde liegenden Profiling-Informationen sowie das bisherige Verhalten ansehen, um genau zu verstehen, was sich geändert hat. Gab es einen plötzlichen Rückgang der Aufzeichnung ? Gab es bei einem bestimmten Attribut einen unerwarteten Anstieg an Nullwerten? Da Actian – wie bereits erwähnt – über diese Spark-Verarbeitungs-Engine zum Profiling der Daten verfügt, können wir tiefer in die Materie einsteigen, als wenn wir uns lediglich die Ausführungsprotokolle der Pipeline ansehen würden.

Und Teams können Probleme auf Asset- und Attributebene untersuchen, indem sie mit „Investigator“ tiefer in die Datensätze einsteigen, die zu dem Problem beitragen. Und wenn Sie dann noch mehr Kontext benötigen oder vielleicht nicht so technisch versiert sind, können Sie unseren Beobachtbarkeit nutzen, der Ihnen eine geführte Ursachenanalyse ermöglicht. Ich würde die Ursachenanalyse also nicht als einen „Zauberknopf“ darstellen, der Ihnen automatisch genau sagt, wer was kaputtgemacht hat. Der wahre Mehrwert liegt darin, dass Actian Data Beobachtbarkeit Anomalie , den Kontext rund um die Daten durch Profiling, Datenuntersuchung und Überwachung über den gesamten Lebenszyklus hinweg Beobachtbarkeit . Und es liefert den Teams die notwendigen Erkenntnisse, um schnell von der Feststellung „Etwas ist kaputt“ zu der Erkenntnis zu gelangen: „Das hat sich geändert, hier hat es sich geändert und welche Daten sind tatsächlich betroffen.“ Das ist großartig. Es sieht so aus, als hätten wir noch zwei weitere Fragen.

Noch einmal, liebe Kollegen: Wenn ihr weitere Fragen habt, schreibt sie bitte einfach in den Chat. Wir werden sie dann live beantworten. Diese hier betrifft geschäftskritische Dateninitiativen und insbesondere die Frage, wie „Actian Data Beobachtbarkeit solche Initiativen Beobachtbarkeit . Ja. Eine wirklich gute Frage. Was wir also wirklich erreichen wollen, ist, Beobachtbarkeit den Initiativen zu verknüpfen, die dem Unternehmen bereits am Herzen liegen. Lassen Sie mich daher ein weiteres Beispiel außerhalb des KYC-Bereichs anführen, nämlich die Versicherungsbranche.

Im Versicherungswesen könnte es sich dabei um die Risikoprüfung, die Schadenbearbeitung, die Preisgestaltung, die aufsichtsrechtliche Berichterstattung oder die Verbesserung des Customer-Experience handeln. All diese Prozesse hängen von der Verfügbarkeit genauer, vollständiger und zeitnaher Daten ab. Denken Sie zum Beispiel einmal an die Risikoprüfung. Ein Versicherer kombiniert möglicherweise Vertragsinformationen, Schadenshistorie, Kundendaten, Objektdetails und Daten zu Risiken durch Dritte, um eine Entscheidung zu treffen. Und wenn einer dieser Datensätze unvollständig oder verspätet ist oder sich plötzlich auf unerwartete Weise ändert, kann sich das direkt darauf auswirken, wie das Risiko bewertet und wie eine Police preislich gestaltet wird. Actian Data Beobachtbarkeit Teams daher, die Daten hinter diesen Prozessen genauer im Blick zu behalten und Probleme zu erkennen, bevor sie zu einem geschäftlichen Problem werden. Anstatt also erst dann ein Problem zu entdecken, wenn eine Prämie falsch berechnet wurde, sich eine Schadensabwicklung verzögert hat oder ein aufsichtsrechtlicher Bericht überarbeitet werden musste, erhalten Teams bereits frühzeitig einen Hinweis darauf, dass etwas in den zugrunde liegenden Daten Aufmerksamkeit erfordert.

Es geht also im Wesentlichen darum, dem Unternehmen zu helfen, mit mehr Zuversicht zu agieren. Das Datenteam kann Probleme früher erkennen, und das Unternehmen hat größeres Vertrauen in die Daten, auf die sich wichtige Entscheidungen stützen – wie im Versicherungsfall die Risikobewertung, die Auszahlung von Versicherungsleistungen und die Betreuung der Kunden. Großartig. Vielen Dank. Mm-hmm. Ich habe noch eine Frage an Sie. Es sieht so aus, als würde es hier um ERP-Migrationen gehen.

Kann Actian Data Beobachtbarkeit konkret bei einer ERP-Migration Beobachtbarkeit und möglicherweise fehlerhafte Zuordnungen erkennen? Ja. Also, Data Beobachtbarkeit – und das gilt, wie ich sagen würde, für jede Beobachtbarkeit – ist so konzipiert und ausgelegt, dass sie Data Warehouses, Datenbanken und Objektspeicher überwacht, aber nicht unbedingt Anwendungen, und dafür gibt es eine ganze Reihe von Gründen. Was ich bei einer ERP-Migration häufig beobachte, ist, dass wir im Allgemeinen prüfen, wo die Daten in einer unstrukturierten Umgebung landen, beispielsweise im Objektspeicher. Sei es nun S3, Google Cloud , Blob oder ein anderer Ort. Vielleicht verschieben Sie die Daten in ein Cloud wie Databricks oder Snowflake. An diesem Punkt würden wir mit der Überwachung der Daten beginnen.

Und an dieser Stelle, würde ich sagen, liegt oft gerade in der Profiling-Komponente unserer Plattform der immense Mehrwert für viele Kunden, die sich in einem Migrationsprozess befinden. Die Möglichkeit, ein vollständiges Profil strukturierter, semistrukturierter oder unstrukturierter Daten zu erstellen und einfach ein grundlegendes Verständnis dafür zu gewinnen, wie es um die tatsächlichen Gegebenheiten Ihrer Daten steht. Oftmals verfügen sie noch nicht einmal über die entsprechenden Tools. Auf dieser Grundlage können Sie dann Ihre kritischen Datenelemente identifizieren und anschließend gute Daten in Ihre neuen Systeme übernehmen. Die Möglichkeit, diese umfassende Profilierung über unsere Spark-Verarbeitungs-Engine zu nutzen, um die tatsächliche Situation Ihrer Daten als ersten Schritt einer Migration wirklich zu verstehen, ist meiner Meinung nach ein Schlüsselelement bei solchen Projekten. Das ist großartig. Vielen Dank, Scarlet.

Ja. Das waren dann auch schon die letzten Fragen, die ich derzeit in unserem Chat sehe. Zum Abschluss möchte ich mich bei Ihnen allen für Ihre Teilnahme bedanken. Ich werde etwas langsamer sprechen, für den Fall, dass noch weitere Fragen aufkommen sollten. Nur zur Information: Diese Aufzeichnung wird zusammen mit weiteren Materialien sowohl an die Teilnehmer als auch an alle, die sich angemeldet hatten, verschickt. Noch einmal: Wenn Sie Fragen haben, wenden Sie sich bitte jederzeit an das Team. Wir sind gerne für Sie da.

Und damit möchten wir uns für die Teilnahme bedanken. Scarlet, das hast du heute toll gemacht. Al, danke für deine Unterstützung. Macht’s gut, ihr alle.