AML AI est configuré pour évaluer le risque de blanchiment d'argent pour une gamme d'activités à la fois, avec des ensembles de données, des versions de moteur et des modèles distincts pour les banques commerciales et de services aux particuliers.
Lorsque vous créez un ensemble de données à utiliser avec une LoB, vous devez inclure plusieurs tables. Chaque tableau doit couvrir une période suffisamment longue. Cette page présente les tables dont vous aurez besoin et explique comment déterminer la période que chacune doit couvrir.
Tables à utiliser
L'ensemble de données BigQuery utilisé avec AML AI doit contenir les tables suivantes :
- Partie : toutes les parties concernées par cette gamme de produits.
- Secteur d'activité "Retail" : tous les clients de la banque de détail qui ont détenu des comptes à un moment donné au cours de la période requise.
- LOB commercial : tous les clients des banques commerciales (entités juridiques et physiques) qui ont détenu des comptes à un moment donné au cours de la période requise
- Notez que certains clients peuvent être représentés dans les deux ensembles de données. Par exemple, les travailleurs indépendants peuvent avoir à la fois des comptes commerciaux et de vente au détail.
- AccountPartyLink : historique complet des comptes détenus par les différentes parties. Cela devrait couvrir tous les comptes de produits et services lorsque l'une des parties du tableau "Partie" était le titulaire principal du compte à un moment donné de la période requise.
- Transaction : toutes les transactions des comptes figurant dans le tableau AccountPartyLink pour la période requise.
- RiskCaseEvent : tous les événements de cas à risque (voir les valeurs de type d'événement) pour tout cas à risque et toute partie dans la table "Partie" avec un AML_PROCESS_START (début de l'enquête) dans la plage de temps requise. Ce tableau peut inclure des événements dont l'heure est antérieure ou postérieure à la période requise.
- PartySupplementaryData : (le cas échéant) Pour 0 à 100 valeurs party_supplementary_data_id uniques, incluez un historique complet des valeurs de ces champs pour toutes les parties de la table "Party" pour la période requise.
Utiliser des données supplémentaires
Consultez Données supplémentaires si vous disposez de données supplémentaires sur les parties (qui ne sont pas couvertes par le schéma) et qui sont pertinentes pour identifier le risque de blanchiment d'argent.
Plage de dates de l'ensemble de données
La période que doit couvrir une table d'un ensemble de données peut être calculée comme suit pour une opération donnée. Vous devez savoir :
- Heure de fin. Il s'agit de la dernière heure à partir de laquelle les libellés sont utilisés et à partir de laquelle les données sont utilisées pour générer des caractéristiques pour l'optimisation.
- Version du moteur (consultez la liste des versions du moteur) que vous allez utiliser.
- Opération que vous allez effectuer : réglage, entraînement, prédiction ou backtesting.
- Pour les opérations de prédiction ou de backtesting, le nombre de périodes pour lesquelles vous effectuerez l'opération, à spécifier dans l'appel d'API.
Vous devez d'abord déterminer le nombre de périodes que l'opération utilisera. Il s'agit du nombre de mois consécutifs se terminant au cours du dernier mois calendaire complet précédant l'heure de fin spécifiée, pour lesquels AML AI évalue les caractéristiques du modèle.
- Pour les opérations de prédiction et de backtest, il s'agit du nombre de périodes de prédiction ou de backtest spécifiées dans l'appel d'API.
- Pour les autres opérations, cela dépend de la version du moteur et de l'opération. Par exemple, les versions du moteur v004.010 utilisent 18 périodes pour le réglage et 15 pour l'entraînement.
Ensuite, vous devez déterminer la période d'analyse pour chaque table. Il s'agit du nombre maximal de mois de données nécessaires à l'IA AML pour calculer les caractéristiques du modèle pour une période donnée à partir de ce tableau.
- Par exemple, pour les versions de moteur v004.010, cela correspond à 13 mois pour les tables Transaction et AccountPartyLink, 12 mois pour la table RiskCaseEvent et 0 mois pour les tables Party et PartySupplementaryData.
L'ensemble de données devra couvrir la période d'analyse pour toutes les périodes utilisées par l'opération choisie. Cette valeur peut varier selon la version du moteur, mais elle est généralement de 18 pour le réglage, de 15 pour l'entraînement et configurable pour la prédiction ou le backtesting. Vous pouvez calculer le nombre de mois calendaires complets de données précédant l'heure de fin dont vous aurez besoin pour une opération donnée à l'aide de la formule suivante :
- nombre de périodes + période d'analyse - 1
En reprenant l'exemple ci-dessus pour les versions de moteur v004.010, vous aurez besoin de 30 mois de données pour toute opération d'IA AML.
- 18 + 13 – 1 = 30 mois de données provenant des tables "Transaction" et "AccountPartyLink".
- 18 mois de données de la table "Événements liés aux cas à risque" + 12 mois de données de la table "Événements liés aux cas à risque" - 1 mois de données de la table "Événements liés aux cas à risque" = 29 mois de données de la table "Événements liés aux cas à risque" ainsi que tous les événements plus récents liés aux cas à risque dans la table.
- Cela représente 18 + 0 – 1 = 17 mois de données provenant des tables Party et PartySupplementaryData.
Nous vous recommandons de disposer d'un ensemble de données unique couvrant au moins 36 mois lorsque vous effectuez un premier test d'échantillon d'AML AI. Cela permet d'effectuer toutes les opérations ci-dessus et d'évaluer le modèle pendant quelques mois supplémentaires au-delà des trois mois minimum requis pour le backtesting.