Pouvez-vous vous fier à vos données KYC ? Garantir leur exactitude grâce à observabilité des données

Bonjour. Bonjour, bon après-midi, bonsoir. Bienvenue à ce webinaire. Je suis ravi de voir que certains participants se connectent. Je remercie tous ceux qui sont arrivés à l’heure, mais nous allons commencer la session dans environ deux minutes. C’est l’heure pile, mais nous allons démarrer dans quelques minutes. Je vois que certaines personnes présentes dans la salle d’attente rejoignent progressivement la session.

Nous souhaitons donc laisser à chacun suffisamment de temps pour se connecter à la session. Vous avez donc encore un peu de temps pour aller chercher votre café ou votre boisson préférée. Et comme je l’ai dit, nous sommes ravis de vous voir participer à cette session. Nous espérons que celle-ci sera fructueuse. Nous allons commencer d’ici peu. Merci de votre patience. Je vois que quelques participants supplémentaires viennent de se connecter.

Bienvenue aux nouveaux participants qui viennent de rejoindre la session. Nous allons commencer d’ici peu. Je vois qu’il y a encore quelques personnes dans la salle d’attente. Nous souhaitons donner à chacun la possibilité d’écouter le webinaire depuis le début. Ne vous inquiétez pas, nous avons largement le temps. Je crois que nous n’avons prévu qu’environ 45 minutes, ce qui vous permettra même de gagner un peu de temps. Mais nous allons commencer d’ici peu.

Encore une fois, merci de votre présence. Bon, Scarlett, j’ai déjà dépassé de deux minutes le temps imparti. Je crois voir une autre personne qui essaie de se connecter ; je vais parler lentement, et très bien, on va commencer. Encore une fois, bonjour, bon après-midi ou bonsoir, selon l’endroit d’où vous nous rejoignez. Bienvenue à notre troisième et dernier webinaire de cette série. Nous en parlerons un peu plus en détail. Si c'est votre premier webinaire avec nous, nous sommes ravis de vous accueillir.

À ceux qui reviennent pour clôturer cette série, bienvenue à nouveau. Je m’appelle John Wisencay. Je serai votre animateur aujourd’hui. Avant de céder la parole à notre intervenante, Scarlett, je voudrais aborder quelques points d’ordre pratique à l’intention de ceux qui découvrent notre série de webinaires. Juste quelques petites précisions. Nous avons, malheureusement, mis tout le monde en mode « muet » afin de garantir le bon déroulement de ce webinaire. Nous avons un grand nombre de participants, nous avons donc préféré commencer le webinaire avec le son coupé.

Tout au long de ce webinaire, si vous avez des questions, n’hésitez pas à utiliser notre rubrique « Questions-réponses ». Pour ceux qui découvrent Zoom, cette rubrique se trouve en bas de votre écran. Vous voyez sans doute un petit cercle comportant trois boutons et un « Plus ». Si vous cliquez dessus, vous verrez apparaître « Questions-réponses ». N’hésitez pas à y saisir vos questions. Je suis entouré d’une équipe, et Hal est à votre disposition pour répondre à vos questions. Je vais vous le présenter dans un instant.

Cette session sera enregistrée ou est en cours d'enregistrement. L'équipe veillera à ce que cet enregistrement vous soit transmis après la session. Comme je l'ai dit, la session durera environ 45 minutes, et toutes les ressources abordées aujourd'hui vous seront envoyées par e-mail après l'événement. Une dernière chose : en cas de problème technique, n'hésitez pas à me contacter à mon adresse e-mail. Je m'efforcerai de les résoudre avec vous. Très rapidement, présentons l'équipe d'aujourd'hui. Comme je l'ai mentionné, je m'appelle John Wisencay.

Je dirige l'équipe d'ingénierie commerciale ici. Je ne suis qu'un petit rouage de l'ensemble. Notre intervenante principale et la personne qui va retenir votre attention aujourd'hui est Scarlett Webbe. C'est elle qui prendra la parole et animera la présentation. Et comme je l'ai mentionné, Hal Shriver est là pour gérer et support de questions-réponses. Donc, si vous avez des questions, n'hésitez pas, encore une fois, à les saisir dans la fenêtre prévue à cet effet, et nous veillerons à y répondre. Diapositive suivante.

Comme je l’ai mentionné plus tôt au début de la session, il s’agit du troisième webinaire d’une série en trois parties. Si c’est la première fois que vous participez, ne vous inquiétez pas. Nous avons conçu ces sessions pour qu’elles puissent être suivies indépendamment les unes des autres. Mais pour vous permettre de les découvrir, vous pouvez également revenir en arrière, vous y inscrire et obtenir l’enregistrement ; vous n’avez donc pas l’impression de passer à côté de quoi que ce soit. Nous avons toutefois structuré cette série autour de trois composantes qui s’intègrent parfaitement à notre offre globale. Notre première session a eu lieu en juin, et nous y avons mis en avant la couche d’activation. Il s’agissait d’une présentation générale de notre analyste IA.

Nous sommes ensuite passés à ce que nous appelons notre « couche contextuelle » grâce à notre plateforme d’intelligence des données. Nous avons animé cette session il y a environ trois semaines. C’est là que vous pouvez rassembler vos informations et en comprendre le contexte. Et nous allons conclure cette session aujourd’hui avec la couche de confiance, et nous allons approfondir notre observabilité des données. Voilà donc les trois webinaires que nous proposons, et aujourd’hui, nous allons nous concentrer sur observabilité des données. Je cède donc la parole à notre intervenante, Scarlett. Scarlett, à vous ! Merci, John.

Avant d’aborder la observabilité , je voudrais faire un bref lien entre cette session et le précédent catalogue de données « Know Your Customer ». Lors de cette session, nous nous étions concentrés sur l’intelligence des données Actian, qui correspond aux couches contextuelles mentionnées par John. Le processus d’intégration « Know Your Customer » (ou KYC) a été défini comme la procédure obligatoire à laquelle les institutions financières ont recours pour vérifier l’identité d’un client et évaluer les risques avant de lui permettre d’ouvrir un compte. Nous avons passé en revue les cinq étapes de ce processus : l’ouverture de compte, la vérification d’identité, la vérification d’adresse, l’évaluation des risques, ainsi que l’approbation et l’intégration. L’élément essentiel que nous a apporté ce catalogue, c’est le contexte métier. Nous pouvions rechercher « intégration KYC », consulter la hiérarchie du glossaire, comprendre chaque sous-processus, identifier les responsables et relier le langage métier aux ressources de données techniques sous-jacentes. L’une des idées de cette session qui, selon moi, mérite d’être retenue est que le catalogue fait le pont entre le langage métier et les ressources de données techniques.

Cela répond à la question suivante : où ce processus métier est-il réellement représenté dans nos données ? Nous avons également découvert l’architecture en médaillon qui sous-tend le processus KYC. La couche « bronze » correspond aux données brutes des clients, où sont d’abord enregistrées les données relatives à la création de compte, à la vérification d’identité et à la vérification d’adresse. La couche « argent » correspond aux données clients en attente de enregistrement , où nous enrichissons enregistrement listes de surveillance externes et d’informations sur les sanctions, puis attribuons un facteur de risque. La couche « or » rassemble les données relatives aux comptes clients et aux transactions afin que les équipes puissent signaler toute activité potentiellement suspecte. Le catalogue affichait également des indicateurs de qualité directement dans la traçabilité. Voilà pour l’avant-goût d’aujourd’hui.

Dans le catalogue, ces indicateurs transforment la lignée de données, qui passe d’une carte de données statique à une carte des risques plus dynamique. Et aujourd’hui, nous allons aller dans les coulisses pour examiner la observabilité des données Actian qui génère ces signaux, détecte ces problèmes et aide les équipes à les analyser et à y remédier. La démonstration d’aujourd’hui vise donc à répondre à une question : pouvons-nous faire confiance aux données qui sous-tendent les décisions KYC ? Pour une banque, cette question est cruciale, car le KYC n’est pas seulement un workflow de reporting. Il détermine si un client est approuvé, si le risque est reclassé à un niveau supérieur, si des transactions potentiellement suspectes sont signalées, et si les équipes en aval ont confiance dans le profil client qu’elles utilisent. Au fur et à mesure que nous parcourrons ce flux, nous montrerons comment observabilité des données d’Actian observabilité les données KYC à travers ces différentes couches, détecte précocement les problèmes de fiabilité, valide les données d’intégration en termes d’actualité, de schéma, d’exposition des données à caractère personnel et de problèmes de format, utilise le regroupement des données pour séparer les populations de clients à haut risque et celles approuvées, et accélère l’analyse des causes profondes grâce à Investigator. Avant de passer au produit, je voudrais consacrer une minute à l’architecture, car elle revêt une importance particulière pour ce cas d'usage.

Les données KYC peuvent être sensibles. Elles peuvent inclure des identifiants client, des données d’adresse, des champs de vérification d’identité et des informations de notation des risques. Du point de vue de l’architecture, l’élément clé est donc que observabilité des données d’Actian observabilité aux données là où elles se trouvent. Dans cet exemple, nos ressources KYC se trouvent dans Snowflake. Avant de passer à la démonstration, je voudrais prendre un instant pour expliquer pourquoi l’architecture est importante, car il s’agit là d’un facteur de différenciation majeur pour observabilité des données d’Actian. Au cœur de la plateforme se trouve un moteur de traitement Spark SQL découplé. Cela signifie que nous pouvons profiler les données, appliquer des règles, détecter des anomalies et surveiller les indicateurs clés de performance (KPI) de qualité sans répercuter cette charge de calcul sur la source de données sous-jacente.

Ainsi, que les données se trouvent dans Snowflake, S3, BigQuery, Kafka, Delta Lake ou à un autre maillon du pipeline, Actian peut les analyser là où elles se trouvent et renvoyer les observabilité vers l’application. Cela revêt une importance capitale, car les pipelines de données modernes ne se composent pas uniquement de tables de data warehouse nettoyées. Ils incluent souvent des données brutes, semi-structurées et non structurées en amont du flux. Notre moteur étant découplé et basé sur Spark, nous pouvons examiner ces différents types de données et ces différentes étapes du pipeline, et pas seulement les tables finales validées que voient les utilisateurs en aval. Aujourd’hui, notre démonstration se concentre donc sur les données KYC dans Snowflake, qui transitent par une architecture Medallion. Mais le point essentiel à retenir est qu’Actian est conçu pour détecter les problèmes bien plus tôt dans le pipeline, avant qu’ils ne deviennent des problèmes plus graves en aval dans les workflows de conformité. C’est important car nous pouvons surveiller de grandes tables et des données brutes sans obliger les équipes à copier des données KYC sensibles dans un autre système simplement pour déterminer si elles sont fiables.

Maintenant que nous avons abordé l’architecture et expliqué pourquoi le moteur de traitement Spark découplé est essentiel pour la surveillance des données tout au long du pipeline, intégrons cela au flux métier KYC que nous allons présenter aujourd’hui. Nous resterons ancrés dans le même processus d’intégration KYC. Donc, pour rappel : enregistrement du compte, vérification d’identité, vérification d’adresse, évaluation des risques et validation. Mais au lieu de nous concentrer sur le contexte métier et la traçabilité, nous allons aujourd’hui nous intéresser à la fiabilité : les données transitant par chaque étape de ce processus sont-elles complètes, à jour, valides et se comportent-elles comme prévu ? Au cours de la démonstration, nous surveillerons les données KYC à travers une architecture en « médaillon », couvrant les données clients brutes, les données clients en zone de transit et les couches de transactions « gold ». Nous verrons comment observabilité des données d’Actian observabilité les problèmes de fiabilité avant qu’ils n’affectent ces workflows, valide les champs d’intégration tels que les données d’identité et d’adresse, et signale les problèmes liés au schéma, à l’actualité, au format et aux risques. Nous montrerons également comment le regroupement des données permet de séparer les populations de clients à haut risque des enregistrements approuvés, puis d’utiliser Investigator pour identifier les champs, enregistrements et segments précis à l’origine du risque.

L'objectif est simple : passer de la compréhension de la manière dont Actian peut observer les données tout au long du pipeline à la mise en évidence de la façon dont cela aide les équipes à déterminer si les données KYC sont réellement fiables. Avant d’aborder directement Actian et observabilité des données, je souhaite donc commencer par le point où un utilisateur métier, un responsable des données ou une gouvernance est susceptible de remarquer le problème pour la première fois au sein d’Actian et de Data Intelligence. Nous examinons ici l’ensemble de données agrégées des transactions, qui se trouve dans la couche « gold » de votre pipeline KYC. C’est là que les informations relatives aux transactions des comptes clients ont été regroupées pour support détection des fraudes les contrôles de conformité support . Dans l’onglet « Qualité des données », Actian Data Intelligence nous offre une vue conviviale de l’état de cet ensemble de données. Nous pouvons constater qu’il y a 12 contrôles au total. Dix ont été validés, deux ont échoué.

En un coup d’œil, cela nous indique que cet ensemble de données est globalement fiable, mais qu’il présente certains problèmes de fiabilité spécifiques qui doivent être pris en compte avant de pouvoir s’y fier pleinement pour la prise de décision en matière de KYC ou de lutte contre la fraude. Ce que j’apprécie dans cette vue, c’est qu’elle regroupe les contrôles en catégories pertinentes pour l’entreprise : cohérence, exhaustivité, actualité, fraude et validité. Ainsi, plutôt que de demander à un analyste de conformité ou à un responsable des données d’interpréter du code SQL brut, des journaux ou des alertes de pipeline, ceux-ci peuvent immédiatement constater que la plupart de mes contrôles sont réussis, mais qu’un contrôle de fraude et un contrôle de validité ont échoué. C’est un point de départ bien plus exploitable. La question qui se pose alors naturellement est la suivante : qu’est-ce qui est à l’origine de ces contrôles ayant échoué ? C’est là que nous passons du contexte à l’investigation. Actian Data Intelligence nous indique quelle ressource métier de confiance est affectée et nous fournit le contexte métier qui l’entoure.

Actian Data observabilité nous observabilité pourquoi le problème s'est produit, quels enregistrements ou champs sont concernés, et quelles mesures nous devons prendre ensuite. Nous pouvons accéder à Actian Data observabilité depuis le catalogue de données. Nous sommes désormais dans Actian Data observabilité. Nous nous concentrons sur ce même actif de regroupement des transactions. Nous venions justement de le consulter dans Actian Data Intelligence. C’est donc ici que le signal de confiance devient exploitable. Voici Investigator.

Il s’agit d’un espace de travail interactif que les analystes, les ingénieurs ou les utilisateurs métier utilisent pour explorer, diagnostiquer et résoudre observabilité des données dès qu’une anomalie est détectée. Ici, nous pouvons approfondir l’analyse des résultats de surveillance. Nous pouvons visualiser les tendances au fil du temps. Nous pouvons évaluer l’ampleur du problème et déterminer s’il s’agit d’un événement ponctuel ou d’un schéma récurrent. Dans le cas présent, à savoir le KYC, cela pourrait signifier identifier les types de transactions à l’origine du problème de risque, les tranches de risque surreprésentées ou les fiches clients associées à des montants de transactions suspects. Concrètement, le système signale ici les personnes présentant un montant à haut risque ainsi qu’un montant de transaction supérieur à 10 000 $. Ainsi, au lieu de dire que le regroupement des transactions a échoué à un contrôle anti-fraude, nous pouvons dire : « Voici les schémas et les dossiers précis à l’origine de cet échec, et voici un sous-ensemble de données qui doit être examiné. » Il s’agit donc du relais entre l’intelligence des données et observabilité des données.

observabilité des données d'Actian nous observabilité cette couche de confiance opérationnelle : elle garantit que les enregistrements sont à jour, complets, valides et se comportent comme prévu ; et lorsque ce n'est pas le cas, elle permet d'identifier précisément la cause du problème. Pour le KYC, ce lien est essentiel. Cela signifie que les équipes ne se contentent pas de consigner des données de conformité, mais qu'elles valident en permanence les données qui sous-tendent l'intégration des clients, la notation des risques, détection des fraudes et les contrôles réglementaires. Maintenant que nous avons utilisé Investigator pour analyser en détail les enregistrements, valeurs et schémas spécifiques à l’origine de ce problème, je vais revenir à la page de synthèse. Si j’apprécie particulièrement cette page, c’est parce qu’Investigator nous offre une vue détaillée de la cause première, tandis que la page de synthèse constitue notre centre de contrôle opérationnel. Elle nous aide à comprendre comment ce problème s’inscrit dans le contexte plus large de la santé du pipeline KYC. Quels autres problèmes sont donc en cours ?

Quels incidents ont été clôturés ? Quels problèmes ont été résolus ? Quels sont les actifs concernés, et où se situent les risques les plus prioritaires dans l’ensemble de l’environnement ? Nous sommes donc passés de l’alerte aux détails, et nous revenons maintenant à la vue d’ensemble. Ainsi, une équipe chargée des données, une équipe de conformité ou un responsable des opérations peut avoir une vision globale de la situation et décider des prochaines actions à mener. Ainsi, au sein de cette tour de contrôle dédiée à la fiabilité des données, au lieu de commencer par une seule table ou une seule règle, cela nous offre une vue opérationnelle de ce qui se passe dans l’ensemble du parc de données KYC. Pour cette démonstration, nous allons nous concentrer uniquement sur les actifs KYC dans Snowflake.

Les types d’informations que je souhaite mettre en avant ici sont le nombre total d’incidents, leur gravité ou leur impact, l’heure de création de l’incident, ainsi que les tendances au fil du temps. Ces données sont utiles aux équipes chargées de l’exploitation des données, car elles permettent de répondre aux questions suivantes : « Qu’est-ce qui ne fonctionne pas ? », « Où se situe le problème ? », « Depuis combien de temps l’incident est-il ouvert ? » et « Qui doit intervenir ? ». Cela revêt une importance particulière, car tous les problèmes n’ont pas le même impact sur l’activité. Une modification de schéma dans une colonne non critique peut constituer un simple avertissement, mais l’exposition de données à caractère personnel (PCI) avec des champs d’identité manquants, une baisse inattendue du volume ou des valeurs de facteurs de risque hors des plages approuvées sont bien plus graves, car elles peuvent affecter l’intégration, la conformité, la révision ou détection des fraudes.

La vue d'ensemble permet donc aux équipes de se faire rapidement une idée de l'état du flux de données KYC avant d'approfondir l'analyse d'un actif spécifique. Je vais ouvrir cet incident ici afin que nous puissions passer de la vue d'ensemble aux détails d'un problème de fiabilité spécifique. À ce stade, un ingénieur de données ou un analyste des opérations de données peut se douter qu’il y a un problème, mais il a tout de même besoin d’aide pour savoir par où commencer. S’agit-il d’un problème au niveau de la source de données ? Est-il lié à une transformation ? Est-il limité à un champ, à un segment de clientèle ou à une exécution ? C’est là que notre observabilité des données prend toute son utilité.

Plutôt que de rassembler manuellement les détails de l’incident, les tendances, les résultats de surveillance et le contexte des actifs, je peux utiliser observabilité des données pour m’aider à synthétiser ce que nous observons et à orienter l’enquête. La question que je me pose ici est la suivante : quelle est la cause première probable de cet incident ? Et ce que fait ici observabilité des données, c’est aider à traduire les observabilité en un parcours d’enquête. Il peut résumer l’incident, mettre en évidence l’actif affecté, signaler les champs ou les schémas qui contribuent au problème, et aider les équipes à comprendre ce qu’il faut vérifier ensuite. Ainsi, au lieu de partir d’une alerte générique indiquant qu’une défaillance s’est produite, nous bénéficions d’une expérience d’analyse des causes profondes plus guidée. Nous pouvons déterminer s’il s’agit d’un problème de qualité des données au niveau de la source, d’un problème de transformation, d’un problème au niveau du pipeline, ou encore d’une violation des règles métier liée aux seuils KYC. Et la valeur métier réside ici dans la rapidité et la hiérarchisation des priorités.

Ask AI aide l'équipe à passer plus rapidement de la détection d'un incident à son enquête. Il fournit aux équipes chargées des opérations de données un point de départ, donne aux équipes de conformité une explication claire de l'impact sur l'activité et réduit les allers-retours entre les équipes qui tentent d'interpréter la signification réelle de l'alerte. Bien sûr, nous pouvons toujours explorer le moniteur lui-même, mais nous pouvons utiliser Investigator pour valider les enregistrements et les valeurs exacts concernés. Mais désormais, nous ne partons plus d’une page blanche, nous partons du contexte. Voyons donc rapidement les autres éléments que nous allons examiner aujourd’hui. Comme je l’ai mentionné précédemment, le niveau « bronze » correspond aux données brutes des clients ; il s’agit des données collectées lorsque le client commence à créer son compte et fournit ses informations d’identité et d’adresse. Au niveau « Staging » (préparation), c’est là que nous introduisons la notation des facteurs de risque à partir de vérifications externes telles que les listes de surveillance, les listes de sanctions ou d’autres modèles de risque.

Et puis, au niveau supérieur, nous avons les transactions et les regroupements de transactions, où nous combinons le risque client avec le comportement transactionnel. Cela nous offre une approche claire. Premièrement, faisons-nous confiance aux données brutes sur les clients qui nous parviennent ? Deuxièmement, faisons-nous confiance à la notation de risque et à la logique d’approbation ? Et troisièmement, faisons-nous confiance aux signaux transactionnels utilisés pour détecter les comportements potentiellement suspects ? Nous commencerons donc par les données brutes sur les clients au niveau « bronze ». Il s’agit du tout premier maillon du parcours des données KYC, et c’est également à ce stade que de nombreux problèmes peuvent être détectés avant qu’ils ne s’aggravent.

À ce stade, les clients fournissent des informations d’enregistrement de compte et des détails de vérification d’identité ; si les données brutes sont erronées à ce niveau, toutes les décisions en aval deviennent discutables. Depuis la page de profilage, nous pouvons évaluer l’intégrité de chaque entité au niveau des attributs ou des colonnes. Cela inclut l’exhaustivité, les doublons, l’exactitude, l’unicité, la cardinalité, les valeurs distinctes, les champs vides de toute nature et d’autres statistiques de profilage. Au lieu de dire « Nous pensons que la table des clients semble correcte », nous disposons désormais d’un aperçu quantifié de l’état des données. Pour le KYC, certains des contrôles essentiels à ce niveau consistent à vérifier que les champs d’identité obligatoires sont renseignés. Les champs d’adresse sont-ils présents ? Des champs tels que le numéro de sécurité sociale et le numéro de carte bancaire respectent-ils les formats attendus ?

Les identifiants client sont-ils uniques ? Le schéma a-t-il subi une modification inattendue ? Et le volume de nouvelles inscriptions a-t-il baissé ou connu un pic par rapport au comportement habituel ? C’est là que observabilité active des données observabilité « shift left ». Nous n’attendons pas qu’un tableau de bord de lutte contre la fraude tableau de bord un rapport de conformité en aval présente des anomalies. Nous détectons les problèmes aussi près que possible du moment de l’ingestion. Examinons maintenant de plus près l’une des alertes provenant des données brutes sur les clients.

Sur la page « Tendances et alertes », nous pouvons consulter l'historique de cet actif ainsi que les alertes spécifiques générées lors de chaque analyse. La plateforme surveille le comportement attendu au fil du temps ; nous examinons donc ce qui a changé, quand cela s’est produit et quelle était l’ampleur de ce changement. Par exemple, si nous nous intéressons à l’exposition des données à caractère personnel (PII) : le problème que la plateforme peut identifier réside dans l’apparition de modèles sensibles à des endroits où ils ne devraient pas se trouver, tels que les notes libres. Si nous examinons un problème de format, tel que la structure des numéros de Sécurité sociale, des adresses, des dates de naissance ou d’autres éléments liés à l’intégration des clients. Si nous examinons le volume ou l’actualité des données, nous pouvons détecter si les données d’inscription des clients sont en retard ou incomplètes. Et lorsque nous accédons à Investigator, cela va bien au-delà d’un simple statut « rouge » ou « vert ». Investigator nous offre un espace de travail interactif permettant de comprendre les enregistrements, les champs, les valeurs et les segments à l’origine de l’alerte.

C'est là toute la différence entre une alerte bruyante et une enquête permettant d'agir concrètement. L'équipe peut voir quels champs sont concernés, quelles valeurs sont à l'origine du problème, quand anomalie et quels enregistrements sont impliqués. À partir de là, elle peut exporter les données détaillées, créer un ticket ou acheminer directement l'information vers l'équipe chargée des incidents compétente. Pour un workflow KYC, c’est essentiel, car vous ne voulez pas qu’un analyste passe manuellement au crible Snowflake pour tenter de déterminer si le problème provient des données brutes, du pipeline ou de la transformation. Vous souhaitez isoler rapidement la cause et protéger le processus en aval. Passons maintenant du niveau « bronze » au niveau « argent ». C’est à ce stade que le processus KYC pour les clients en phase de « staging » devient davantage axé sur les risques.

Nous ne vérifions plus si le client a correctement rempli le formulaire. À ce stade, le enregistrement du client enregistrement été enrichi d’informations sur les risques provenant de sources externes telles que des listes de surveillance, des listes de sanctions ou d’autres processus de filtrage. Dans cette démonstration, nous allons examiner le score des facteurs à haut risque. Un score faible correspond à un niveau de risque acceptable. Un score élevé indique qu’un client pourrait nécessiter un examen plus approfondi ou ne devrait pas être automatiquement approuvé. Et en réalité, vos données ne restent jamais figées. Elles évoluent constamment au fur et à mesure que les demandes, les clients et les processus métier changent.

C’est pourquoi les règles de qualité statiques perdent si rapidement leur efficacité. Vous avez besoin de moniteurs basés sur l’apprentissage automatique qui s’adaptent aux données elles-mêmes, en détectant les changements en amont avant qu’ils ne se transforment en problèmes coûteux en aval. Il s’agit d’instaurer une confiance qui évolue au rythme de vos données, et non pas simplement d’en capturer un instantané. Et nous disposons ici de 16 moniteurs prêts à l’emploi qui s’appliquent automatiquement à votre ressource dès la première analyse. Ainsi, les moniteurs basés sur l’apprentissage automatique d’Actian apprennent automatiquement les modèles présents dans vos données sans que vous ayez à rédiger de règles personnalisées. Ils analysent les données à chaque analyse pour déterminer les distributions normales, les relations et les tendances. Une fois le modèle entraîné, il vérifie en continu les données entrantes, en temps réel ou par lots.

Les contrôles automatisés apportent une valeur ajoutée à plusieurs égards. Si vous êtes ingénieur de données, cela vous fait gagner du temps, car vous n’avez plus à rédiger de règles ad hoc. Et si l’on prend, par exemple, ce facteur de risque élevé qui est trop élevé, examinons et décomposons les éléments d’un moniteur. Un moniteur se compose donc de trois parties. Il y a la métrique, c’est-à-dire ce que vous mesurez. Il y a ensuite le seuil : comment détermine-t-on à partir de quand une situation devient une anomalie? Et il existe trois façons de procéder.

Basé sur l'apprentissage automatique, il tire donc des enseignements des tendances observées dans les données. Vous disposez d'écarts relatifs et en pourcentage entre les périodes, ainsi que de plages prédéfinies et de valeurs minimales et maximales explicites. Et le troisième volet concerne l'action. Qui souhaitez-vous avertir lorsqu'un problème survient ou que les enregistrements ne respectent pas ce seuil de surveillance ? Le système fournit des valeurs de référence issues de l'apprentissage automatique, ce qui réduit la nécessité de définir manuellement ces seuils. Dans cet exemple, nous examinons une règle enregistrement . Dans cette expression, nous utilisons des valeurs de facteur de risque comprises entre 1 et 11, considérées comme acceptables pour une validation automatisée, tandis que les valeurs supérieures à 12 sont traitées comme présentant un risque élevé.

Cela ne signifie pas pour autant que les données soient erronées au sens traditionnel du terme. Cela signifie qu’elles nous fournissent des informations importantes sur le plan opérationnel. Cette population de clients doit être isolée, examinée ou exclue du processus de validation en aval. C’est là un excellent exemple illustrant pourquoi la qualité des données et observabilité un contexte métier. Un chiffre comme 13 n’est pas invalide en soi. Il est invalide pour ce workflow spécifique d’approbation KYC workflow il dépasse le seuil de risque acceptable de la banque. Et si nous ouvrons cela dans Investigator, nous pouvons voir la répartition des valeurs à l’origine de cette violation.

Ainsi, de 1 à 16, nous pouvons voir le nombre d’enregistrements qui se situent dans ces tranches de risque. C’est là qu’Investigator nous aide à passer de la détection à la compréhension. Nous pouvons sélectionner une valeur spécifique, comme un facteur de risque de 13, et voir les enregistrements associés à cette valeur. Cela fournit à l’équipe chargée des opérations KYC un ensemble concret de dossiers à examiner, plutôt qu’une alerte vague indiquant « Problème de facteur de risque détecté ». Une autre fonctionnalité importante est le regroupement des données. Dans ce workflow KYC, nous pouvons trier les dossiers en fonction du seuil du facteur de risque. Les clients dont le niveau de risque se situe dans une fourchette acceptable peuvent passer au seuil d’approbation. Ceux dont le niveau de risque se situe dans une fourchette inacceptable peuvent être orientés vers un parcours « invalide » ou « à haut risque » pour un examen supplémentaire.

Et cela est important, car le pipeline n’a pas à s’arrêter simplement parce que certains enregistrements nécessitent une attention particulière. Les enregistrements valides peuvent continuer à avancer tandis que ceux présentant un risque élevé sont mis de côté pour être examinés. Pour une banque, cela permet de préserver la continuité opérationnelle sans pour autant négliger le risque de conformité. Il s’agit d’un point de contrôle situé entre les couches « argent » et « or ». Nous utilisons observabilité seulement pour détecter qu’un seuil de risque a été franchi, mais aussi pour isoler les enregistrements concernés et les empêcher de contaminer silencieusement la population de clients approuvés. Passons donc maintenant à la couche « or ». À ce stade, le processus KYC… Laissez-moi venir par ici. Le processus KYC a compris…

Désolé pour ça. Ma Magic Mouse s'est un peu détraquée à ce moment-là. Contient à la fois les informations relatives aux transactions et celles issues de leur agrégation. Ainsi, les transactions représentent l’activité au niveau de la transaction, tandis que le résumé des transactions nous offre une vue agrégée qui combine le facteur de risque du client et le comportement transactionnel. Cela s’avère utile dans les scénarios de lutte contre la fraude et le blanchiment d’argent, car une activité suspecte se limite rarement à un seul élément pris isolement. Il s’agit généralement d’un schéma qui s’observe à travers le profil du client, le score de risque, le type de transaction et le montant de celle-ci. Examinons donc cette transaction suspecte ou ce cas de blanchiment d’argent.

Le raisonnement que nous suivons ici est que certaines combinaisons doivent être signalées pour examen. Par exemple, un client dont le score de risque dépasse un seuil acceptable doit faire l’objet d’une escalade, mais même un client à faible risque peut présenter une activité suspecte s’il effectue certains types de transactions ou des montants supérieurs à un seuil défini, tels que les paiements en espèces, les virements Zelle ou les virements internationaux supérieurs à 10 000 $. Et si nous accédons à Investigator, nous pouvons voir les valeurs et les combinaisons à l’origine de l’alerte. Une façon d’illustrer cela consiste à regrouper ou à agréger le facteur de risque et le montant de la transaction. L’équipe peut ainsi identifier rapidement si le problème se concentre sur une fourchette de risque, un type de transaction ou une plage de montants particuliers. Le point important est que observabilité ne observabilité pas observabilité nous signaler que l’ensemble de données « gold » a échoué à une vérification. Elle nous aide à comprendre pourquoi il a échoué.

Lorsqu’il s’agit de clients ou de transactions, et que le problème ait pris naissance en amont, lors de l’intégration du client, lors de l’enrichissement des données de risque ou lors du traitement des transactions. C’est là toute la puissance de la surveillance tout au long du pipeline KYC. Nous pouvons partir d’un comportement transactionnel suspect identifié au niveau « or » et remonter la piste jusqu’aux facteurs de risque sous-jacents et au profil brut du client. Ou bien nous pouvons détecter les problèmes plus tôt, aux niveaux « bronze » ou « argent », avant même qu’ils n’apparaissent dans le workflow des transactions. Pour la conformité, cela se traduit par un triage plus rapide. Pour l’ingénierie des données, cela signifie moins d’enquêtes manuelles. Pour l’entreprise, cela renforce la confiance dans la fiabilité des données utilisées pour approuver les clients et signaler les activités suspectes.

Ainsi, une fois qu’un incident a fait l’objet d’une enquête, la question suivante est de savoir comment le transmettre à l’équipe compétente pour qu’elle y donne suite. observabilité des données d’Actian observabilité les alertes et les workflows opérationnels. Les équipes peuvent ainsi acheminer les incidents en fonction d’une politique, d’un actif, d’un responsable, d’un niveau de gravité ou d’un canal. Il peut s’agir d’un e-mail, de Slack, de Teams, de JIRA, de ServiceNow ou de tout autre processus utilisé par l’organisation. L’objectif n’est pas de générer davantage de bruit. L’objectif est de rendre les alertes exploitables. Un problème lié aux données à caractère personnel (PII) à fort impact concernant un client brut ne doit pas être traité de la même manière qu’un décalage de profil à faible impact dans un champ non critique.

Tout dépassement du seuil de risque élevé lors de la mise en attente des clients doit être signalé à l’équipe chargée de la vérification KYC. Un schéma de transactions suspect ou un regroupement de transactions peut devoir être transmis au service de lutte contre la fraude ou au service de conformité. Et une fois les mesures correctives mises en œuvre, la plateforme peut réanalyser les données et mettre à jour l’incident en fonction des données réelles elles-mêmes. Cela signifie donc que la résolution dépend du retour des données à un état acceptable, et non pas simplement du fait que quelqu’un ait clôturé un ticket. Récapitulons donc ce que nous avons abordé. Premièrement, nous avons surveillé les données KYC fiables tout au long du pipeline : les données brutes d’intégration des clients, la notation des risques des clients en phase de validation, et la surveillance des transactions « or ». Deuxièmement, nous avons détecté les risques de conformité à un stade précoce, au niveau « bronze ».

Cela implique de détecter les problèmes liés à l’actualité des données, au schéma, aux données à caractère personnel, à l’exhaustivité et au format avant qu’ils ne se répercutent en aval. Au niveau « argent », cela signifie identifier les clients qui dépassent les seuils de risque avant qu’ils ne soient validés. Et au niveau « or », cela signifie signaler les schémas de transactions suspects qui combinent le risque client et le comportement transactionnel. Troisièmement, nous avons accéléré les enquêtes. Investigator aide les équipes à passer d’un simple « ça n’a pas marché » à l’identification précise des champs, valeurs, enregistrements et segments à l’origine du problème. C’est ce qui transforme observabilité tableau de bord un workflow opérationnel. La grande leçon à retenir est donc simple.

Le catalogue fournit un contexte aux équipes KYC. observabilité des données d'Actian leur observabilité une confiance continue. Ensemble, ces deux éléments aident les organisations à comprendre non seulement où circulent les données KYC, mais aussi si ces données sont fiables à chaque étape. Bravo, Scarlett. Très bien. C'était très instructif et c'est une excellente façon de conclure cette série. Alors, pour ceux qui nous suivent en direct, si vous avez des questions, n'hésitez pas à les saisir dans le panneau de questions-réponses, et nous y répondrons ici dans un instant.

Je tenais à vous communiquer nos coordonnées. Je sais que beaucoup d’entre vous regardent ces enregistrements après l’événement. Et d’ailleurs, pour ceux qui regardent l’enregistrement, si vous avez des questions ou besoin d’informations supplémentaires, je tenais à vous communiquer nos coordonnées. Non seulement les miennes, mais aussi celles de Scarlett, qui était notre intervenante, et celles de Hal. Encore une fois, si vous avez des questions, besoin d’informations supplémentaires ou de contenu, n’hésitez pas à nous contacter. Un petit appel à l’action à l’intention de ceux qui ont participé à la session ou qui regardent l’enregistrement. Comme nous l’avons mentionné lors de notre première session, nous proposons un essai gratuit de 14 jours pour notre Actian AI Analyst.

C'est un excellent moyen pour vous de vous plonger dans le sujet et de commencer à vous familiariser concrètement avec notre technologie. Elle est très facile à prendre en main, et bon nombre de nos clients en tirent immédiatement profit grâce à cette période d'essai de 14 jours. Vous bénéficiez d'un accès complet à la plateforme, sans aucune restriction. Et si vous nous rejoignez pour la première fois, j'ai mentionné tout à l'heure que cela fait partie d'une série en trois volets. Nous terminons ici avec la couche de confiance. Mais si vous souhaitez vous inscrire, vous pouvez le faire et visionner les webinaires précédents à la demande. Il vous suffit de vous rendre sur notre site web, de cliquer sur la rubrique « Événements », de vous inscrire à ces sessions et d’accéder aux deux enregistrements précédents sur le KYC.

Sur ce, je pense que nous allons passer aux questions. Encore une fois, pour les participants à cette session, si vous avez des questions, n’hésitez pas à les saisir. Parfait. Je crois que nous venons de recevoir une question. Scarlett, j’espère que tu pourras y répondre en direct. Il semble que nous ayons : « En quoi observabilité des données d’Actian observabilité des outils traditionnels de qualité des données ou des outils de surveillance des pipelines ? » Très bonne question. L’une des principales différences avec observabilité des données d’Actian observabilité que nous ne nous contentons pas de nous placer à la fin du pipeline pour vérifier si les données ont respecté ou non une règle prédéfinie.

Comme je l’ai mentionné plus tôt dans cette présentation, la plateforme utilise un moteur de traitement Spark découplé pour profiler et analyser les données à grande échelle, ce qui permet aux organisations de surveiller les données provenant de différentes sources et à différentes étapes du cycle de vie des données, sans être limitées à un seul entrepôt de données ni dépendre de contrôles basés sur SQL. Cela favorise également une approche « shift left » en matière observabilité des données. Ainsi, au lieu d’attendre que ces données erronées atteignent un tableau de bord ou un modèle d’IA, les équipes peuvent surveiller les données bien plus tôt dans le pipeline. Par exemple, si les données aboutissent dans une couche « brute » ou « bronze » et font l’objet d’une surveillance continue à mesure qu’elles progressent à travers les couches de transformation et de consommation, cela donne à l’équipe la possibilité d’identifier les problèmes plus près de leur point d’origine. Nous combinons également la surveillance automatisée — telle que la fraîcheur, le volume, le schéma, les dérives majeures, enregistrement et les changements de distribution — avec une logique métier spécifique, en plus des règles de qualité des données. Nous pouvons ainsi détecter à la fois les changements de comportement inattendus dans les données et les conditions métier connues qui doivent être respectées. La différence concrète, je dirais, est qu’un pipeline peut toujours s’exécuter avec succès depuis… Hmm…

d’un point de vue infrastructurel, tout en fournissant des données incomplètes, retardées ou erronées. observabilité des données d’Actian observabilité précisément à valider la fiabilité des données transitant par ce pipeline, et ce suffisamment tôt pour que les équipes puissent examiner et résoudre les problèmes avant qu’ils n’aient des répercussions en aval. Parfait. Merci, Scarlett. Mm-hmm. Une autre question vient d’arriver. Je crois que tu en as déjà un peu parlé.

Je pense bien sûr aux alertes et à l’analyse des causes profondes, mais cette question précise porte sur la manière dont Actian aide concrètement les équipes à passer du simple stade de l’alerte à celui de l’analyse des causes profondes. C’est une autre bonne question, qui revient souvent lorsque je m’entretiens avec des clients. L’essentiel, c’est qu’Actian Data observabilité conçu pour fournir aux équipes le contexte d’un problème, et pas seulement pour leur signaler qu’un indicateur est passé au rouge. Ainsi, anomalie détectée, les équipes peuvent commencer par examiner le moniteur qui a déclenché l’alerte, puis se pencher sur les informations de profilage sous-jacentes et le comportement historique pour comprendre exactement ce qui a changé. Y a-t-il eu une baisse soudaine des enregistrement ? Un attribut particulier a-t-il connu une augmentation inattendue du nombre de valeurs nulles ? Comme Actian dispose, je le rappelle, de ce moteur de traitement Spark pour profiler les données, nous pouvons aller plus loin que la simple consultation des journaux d’exécution du pipeline.

Les équipes peuvent examiner les problèmes au niveau des actifs et des attributs à l’aide d’Investigator pour approfondir l’analyse des enregistrements à l’origine du problème. Et si vous avez besoin d’encore plus de contexte, ou si vous n’êtes pas très à l’aise avec les aspects techniques, vous pouvez utiliser notre observabilité des données pour bénéficier d’une expérience guidée d’analyse des causes profondes. Je ne présenterais donc pas l’analyse des causes profondes comme un bouton magique qui vous indique automatiquement et précisément qui a causé quel problème. La véritable valeur réside dans le fait qu’Actian Data observabilité capable de réunir anomalie , le contexte autour des données grâce au profilage, l’investigation des données et la surveillance tout au long du cycle de vie. Et cela fournit aux équipes les éléments de preuve dont elles ont besoin pour passer rapidement de « quelque chose ne fonctionne plus » à « voici ce qui a changé, où cela a changé et quelles données sont réellement affectées ». C’est parfait. Il semble que nous ayons encore deux questions.

Encore une fois, chers collègues, si vous avez d’autres questions, n’hésitez pas à les poser par écrit. Nous y répondrons en direct. Celle-ci porte sur les initiatives liées aux données stratégiques et, plus précisément, sur la manière dont observabilité des données d’Actiansupport d’initiatives. Oui. Très bonne question. Ce que nous souhaitons vraiment, c’est relier observabilité des données observabilité initiatives qui comptent déjà pour l’entreprise. Je vais donc prendre un autre exemple en dehors du KYC, celui de l’assurance.

Dans le secteur de l’assurance, cela peut concerner la souscription, le traitement des sinistres, la tarification, les déclarations réglementaires ou l’amélioration expérience client. Tous ces processus reposent sur des données précises, complètes et actualisées. Prenons l’exemple de la souscription. Un assureur peut être amené à croiser les informations relatives à la police, l’historique des sinistres, les données clients, les détails des biens assurés et les données de tiers concernant les risques pour prendre une décision. Et si l’un de ces ensembles de données est incomplet, en retard ou subit soudainement une modification inattendue, cela peut avoir une incidence directe sur l’évaluation du risque et la tarification de la police. observabilité des données d’Actian observabilité donc les équipes observabilité surveiller de plus près les données qui sous-tendent ces processus et observabilité identifier les problèmes avant qu’ils ne se transforment en problèmes opérationnels. Ainsi, au lieu de découvrir un problème parce qu’une prime a été mal calculée, qu’un sinistre a été retardé ou qu’un rapport réglementaire a dû être retravaillé, les équipes disposent d’un signal précoce indiquant qu’un élément des données sous-jacentes nécessite une attention particulière.

La valeur ajoutée réside donc avant tout dans le fait d’aider l’entreprise à fonctionner avec davantage de confiance. L’équipe chargée des données peut ainsi détecter les problèmes plus tôt, et l’entreprise accorde davantage de confiance aux données qui sous-tendent des décisions cruciales telles que, dans le cas des assurances, la tarification des risques, le règlement des sinistres et le service client. Parfait. Merci. Mm-hmm. J’ai encore une question à vous poser. On dirait que celle-ci va porter sur les migrations ERP.

Plus précisément, observabilité des données d’Actian peut-elle observabilité une migration ERP et éventuellement détecter des mappages défectueux ? Oui. observabilité des données – et cela vaut, je dirais, pour toute observabilité – est configurée et conçue pour surveiller les entrepôts de données, les bases de données et le stockage objet, mais pas nécessairement les applications, et il existe toute une série de raisons qui expliquent pourquoi il en est ainsi. Ce que je constate souvent lors d’une migration ERP, c’est que l’on examine généralement où les données sont stockées dans un environnement non structuré, tel que le stockage objet. Qu’il s’agisse de S3, de Google Cloud Storage, de Blob ou d’un autre service. Peut-être les transférez-vous vers un entrepôt cloud comme Databricks ou Snowflake. C’est à ce moment-là que nous commençons à surveiller les données.

Et à partir de là, je dirais que c’est souvent dans le module de profilage de notre plateforme que de nombreux clients engagés dans des projets de migration trouvent une immense valeur ajoutée. Le fait de pouvoir établir un profil complet des données structurées, semi-structurées ou non structurées et d’avoir simplement une compréhension de base de la réalité de vos données. Souvent, ils ne disposent même pas de ces outils. À partir de là, vous pouvez identifier vos éléments de données critiques, puis aller de l’avant en intégrant des données de qualité dans vos nouveaux systèmes. Le fait de pouvoir tirer parti de ce profilage complet via notre moteur de traitement Spark, dans le but de vraiment comprendre la réalité de vos données en tant que première étape d’une migration, est donc, je dirais, un élément clé dans ce type de projets. C’est formidable. Merci, Scarlet.

Oui. Voilà, ce sont les dernières questions que je vois pour l'instant dans notre panel. Pour conclure, merci à tous d'avoir participé. Je vais parler lentement, au cas où il y aurait d'autres questions. Je tiens à vous informer que cet enregistrement, ainsi que d'autres documents, seront envoyés aux participants et à toutes les personnes qui se sont inscrites. Encore une fois, si vous avez des questions, n'hésitez pas à contacter l'équipe. Nous sommes là pour support.

Sur ce, nous vous remercions de votre participation. Scarlet, bravo pour ton excellent travail aujourd’hui. Al, merci pour ton support. Prenez soin de vous, tout le monde.