Détecter une fraude bancaire sur mobile

Dans un cas typique de fraude en ligne, le voleur effectue plusieurs transactions, ce qui entraîne une perte de milliers de dollars. C’est pourquoi la détection des fraudes doit se produire en quasi-temps réel. Plus de 800 millions de personnes utilisent des applications mobiles. À mesure que ce nombre augmente, la fraude bancaire mobile évolue également. L’industrie financière connaît une augmentation de 100 pour cent d’une année à l’autre pour les pertes causées par l’accès à partir de plateformes mobiles. Mais il y existe des recours. Cet article présente une solution qui utilise la technologie Azure pour prédire une transaction bancaire mobile frauduleuse en deux secondes. L’architecture présentée ici est basée sur une solution réelle.

Défis : Rares cas de fraude et de règles rigides

La plupart des fraudes mobiles se produisent lorsqu’une attaque d’échange de SIM est utilisée pour compromettre un numéro de téléphone mobile. Le numéro de téléphone est cloné et le criminel reçoit les notifications SMS et les appels envoyés à l’appareil mobile de la victime. Le criminel obtient ensuite les informations d’identification de connexion à l’aide de l’ingénierie sociale, du hameçonnage, du vishing (utilisation d’un téléphone pour hameçonnage) ou d’une application téléchargée infectée. Avec ces informations, le criminel peut emprunter l’identité d’un client bancaire, s’inscrire pour l’accès mobile et générer immédiatement des transferts de fonds et des retraits.

La fraude mobile est difficile à détecter et coûteuse pour les consommateurs et les banques. La première difficulté est que c’est rare. Moins de 1 pour cent de toutes les transactions sont frauduleuses. Il peut donc falloir du temps à une équipe de gestion des fraudes ou des cas pour passer au crible les transactions potentiellement frauduleuses et identifier celles qui le sont. Un deuxième défi est que de nombreuses solutions de surveillance des fraudes reposent sur des moteurs basés sur des règles. Traditionnellement, les moteurs basés sur des règles sont efficaces pour détecter les modèles établis de transactions similaires à la fraude générées à partir d’adresses IP risquées ou de plusieurs transactions générées dans un bref délai sur un nouveau compte. Mais les moteurs basés sur des règles ont une limitation significative : les règles ne s’adaptent pas rapidement aux nouveaux types d’attaques ou celles en évolution. Ils sont limités des manières suivantes :

• La détection n’est pas en temps réel, ainsi la fraude est détectée après une perte financière.
• Les règles sont binaires et limitées. Elles ne prennent pas en charge la complexité et les combinaisons de variables d’entrée qui peuvent être évaluées. Cette limitation entraîne un nombre élevé de faux positifs.
• Les règles sont codées en dur dans la logique métier. L’organisation des règles, l’incorporation de nouvelles sources de données ou l’ajout de nouveaux modèles de fraude nécessitent généralement des modifications d’application qui affectent un processus métier. La propagation des changements tout au long d’un processus métier peut être fastidieuse et coûteuse.

Les modèles IA peuvent considérablement améliorer les taux de détection des fraudes et les temps de détection. Les banques utilisent ces modèles avec d’autres approches pour réduire les pertes. Le processus décrit ici est basé sur trois éléments :

• Modèle IA qui agit sur un ensemble dérivé de caractéristiques comportementales
• Une méthodologie de Machine Learning
• Un processus d’évaluation de modèle semblable à celui utilisé par un gestionnaire de fraude pour évaluer un portefeuille

Contexte opérationnel

Pour la banque sur laquelle cette solution est basée, car les clients ont augmenté l’utilisation des services numériques, il y a eu un pic de fraudes sur le canal mobile. Il était temps pour la banque de reconsidérer son approche de la détection et de la prévention des fraudes. Cette solution a commencé par des questions qui ont affecté leur processus de fraude et leurs décisions :

• Quelles activités ou transactions sont probablement frauduleuses ?
• Quels comptes sont compromis ?
• Quelles activités ont besoin d’une enquête approfondie et d’une gestion des cas ?

Pour que la solution apporte de la valeur, il faut comprendre clairement comment la fraude bancaire mobile devient évidente dans l’environnement opérationnel :

• Quels types de fraudes sont perpétués sur la plateforme ?
• Comment est-ce validé ?
• Quels sont les modèles d’activités et de transactions frauduleuses ?

Les réponses à ces questions ont conduit à une compréhension des types de comportements qui peuvent signaler une fraude. Les attributs de données ont été mappés aux messages, collectés à partir des passerelles d’application mobile, qui ont été corrélés aux comportements identifiés. Le comportement du compte le plus pertinent pour déterminer la fraude a ensuite été profilé.

Le tableau suivant identifie les types de compromission, les attributs de données susceptibles de signaler la fraude et les comportements pertinents pour la banque :

* Indicateur le plus courant de compromission. Il précède les compromissions financières et non financières.

La dimension comportementale est essentielle pour détecter la fraude mobile. Les profils basés sur le comportement peuvent contribuer à établir des modèles de comportement typiques pour un compte. L’analytique peut signaler une activité qui semble être en dehors de la norme. Voici quelques exemples de types de comportements qui peuvent être profilés :

• Combien de comptes sont associés à l’appareil ?
• Combien d’appareils sont associés au compte ? Combien de fois sont-ils supprimés ou ajoutés ?
• À quelle fréquence l’appareil ou le client se connecte-t-il ?
• Combien de fois le client change-t-il de mot de passe ?
• Quel est le montant moyen de transfert monétaire ou de retrait du compte ?
• À quelle fréquence les retraits du compte sont-ils effectués ?

La solution utilise une approche basée sur les éléments suivants :

• Ingénierie des fonctionnalités pour créer des profils comportementaux pour les clients et les comptes.
• Azure Machine Learning pour créer un modèle de classification des fraudes pour un comportement suspect ou incohérent de compte.
• Services Azure pour le traitement des événements en temps réel et les workflows de bout en bout.

Architecture de haut niveau

Téléchargez un fichier Visio de cette architecture.

Dataflow

Il existe trois flux de travail dans cette architecture :

• Un pipeline piloté par les événements ingère et traite les données de journal, crée et gère les profils de compte comportemental, incorpore un modèle de classification des fraudes et produit un score prédictif. La plupart des étapes de ce pipeline commencent par une fonction Azure. Les fonctions Azure sont utilisées, car elles sont serverless, facilement mises à l’échelle et planifiées. Cette charge de travail nécessite le traitement de millions de transactions mobiles entrantes et leur évaluation pour la fraude en quasi-temps réel.

• Un flux de travail de formation de modèle combine des données historiques locales et des données de journal ingérées. Cette charge de travail est orientée vers les lots et utilisée pour la formation et la reformation des modèles. Azure Data Factory orchestre les étapes de traitement, notamment :

  • Chargement des données de fraude historiques étiquetées à partir de sources locales.
  • Archivage des jeux de caractéristiques des données et de l’historique des scores pour toutes les transactions.
  • Extraction d’événements et de messages dans un format structuré pour l’ingénierie des fonctionnalités et la reformation et l’évaluation des modèles.
  • Formation et reformation d’un modèle de fraude via Azure Machine Learning.

• Le troisième flux de travail s’intègre aux processus métier du back-end. Vous pouvez utiliser Azure Logic Apps pour vous connecter et vous synchroniser avec un système local pour créer un cas de gestion des fraudes, suspendre l’accès au compte ou générer un contact téléphonique.

Au cœur de cette architecture se trouvent le pipeline de données et le modèle d’IA, qui sont abordés plus en détail plus loin dans cet article.

La solution s’intègre à l’environnement local de la banque à l’aide d’un bus de service d’entreprise (ESB) et d’une connexion réseau performante.

Pipeline de données et automatisation

Lorsqu’un criminel a accès à un compte bancaire via une application mobile, la perte financière peut se produire en quelques minutes. La détection efficace de l’activité frauduleuse doit se faire pendant que le criminel interagit avec l’application mobile et avant qu’une transaction monétaire ne se produise. Le temps nécessaire pour réagir à une transaction frauduleuse influence directement la quantité de pertes financières qui peuvent être évitées. Plus la détection a lieu plus tôt, moins la perte financière sera importante.

Moins de deux secondes, et idéalement beaucoup moins, est le temps maximum pour évaluer le risque de fraude après qu’une activité bancaire mobile est transmise pour traitement. Voici ce qui doit se produire pendant ces deux secondes :

• Collectez un événement JSON complexe.
• Validez, authentifiez, analysez et transformez le JSON.
• Créez des caractéristiques de compte à partir des attributs de données.
• Soumettez la transaction pour l’inférence.
• Récupérez le score de fraude.
• Synchronisez-vous avec un système de back-end de gestion des cas.

Les temps de latence et de réponse sont essentiels dans une solution de détection des fraudes. L’infrastructure sous-jacente doit être rapide et évolutive.

Traitement des événements

Les événements de télémétrie provenant des passerelles d’application mobile et Internet de la banque sont formatés en tant que fichiers JSON avec un schéma librement défini. Ces événements sont diffusés en tant que données de télémétrie d’application vers Azure Event Hubs, où une fonction Azure dans un App Service Environment dédié orchestre le traitement.

Le diagramme suivant illustre les interactions fondamentales d’une fonction Azure au sein de cette infrastructure :

Téléchargez un fichier Visio de cette architecture.

Dataflow

1. Ingérez la charge utile d’événement JSON brute à partir d’Event Hubs et authentifiez-la à l’aide d’un certificat SSL récupéré à partir d’Azure Key Vault.
2. Coordonnez la désérialisation, l’analyse, le stockage et la journalisation des messages JSON bruts dans Azure Data Lake et l’historique des transactions financières des utilisateurs dans Azure SQL Database.
3. Mettez à jour et récupérez les profils de compte d’utilisateur et d’appareil à partir de SQL Database et de Data Lake.
4. Appelez un point de terminaison Azure Machine Learning pour exécuter un modèle prédictif et obtenir un score de fraude. Conservez le résultat d’inférence dans un lac de données pour l’analytique opérationnelle.
5. Connectez Power BI à Data Lake via Azure Synapse Analytics pour un tableau de bord d’analytique opérationnelle en temps réel.
6. Publiez les résultats marqués en tant qu’événement dans un système local pour une enquête et une activité de gestion plus approfondies.

Prétraitement des données et transformation du JSON

Dans le scénario du monde réel sur lequel cette solution est basée, le prétraitement des données était une étape intégrale du formatage des données pour le développement et la formation des modèles de Machine Learning. Il y avait des années d’événements historiques de la banque mobile et de la banque par Internet, y compris les données de transaction de la télémétrie de la passerelle d’application au format JSON. Il y avait des centaines de milliers de fichiers qui contenaient de nombreux événements qui devaient être désérialisés et aplatis et nettoyés pour former le modèle Machine Learning.

Chaque passerelle d’application produit des données de télémétrie à partir de l’interaction d’un utilisateur, en capturant des informations comme le système d’exploitation, les métadonnées d’appareil mobile, les données de compte et les requêtes et réponses de transaction. Il y avait des variantes entre les fichiers JSON et les attributs, et les types de données étaient disparates et incohérents. Une autre complication avec les fichiers JSON était que les attributs et les types de données pouvaient changer de façon inattendue à mesure que les mises à jour des applications étaient poussées vers les passerelles et que des fonctionnalités étaient supprimées, modifiées ou ajoutées. Les défis liés à la transformation des données avec les schémas sont les suivants :

• Un fichier JSON peut inclure une ou plusieurs interactions de téléphone mobile. Chaque interaction doit être extraite en tant que message distinct.
• Les champs peuvent être nommés ou représentés différemment.
• Certains caractères comme les nouvelles lignes ou les retours chariot sont incorporés de manière incohérente dans les messages.
• Des attributs, comme les adresses e-mail, peuvent être manquants ou partiellement formatés.
• Il peut y avoir des propriétés et des valeurs complexes, imbriquées.

Un pool Spark est utilisé dans le cadre du chemin d’accès froid pour traiter les fichiers JSON historiques, et pour désérialiser, aplatir et extraire des attributs d’appareil et de transaction. Chaque fichier JSON est validé et analysé, et les attributs de transaction sont extraits et conservés sur un lac de données et partitionnés en fonction de la date de la transaction.

Ces attributs sont utilisés ultérieurement pour créer des caractéristiques pour le classifieur de fraude. La puissance de cette solution s’appuie sur la capacité des données JSON à être normalisées, jointes et agrégées avec des données historiques pour créer des profils de comportement.

Traitement et caractérisation en quasi-temps réel avec SQL Database

Dans cette solution, les événements sont générés à partir de plusieurs sources, notamment des enregistrements d’authentification, des informations client et des données démographiques, des enregistrements de transactions et des données de journal et d’activité à partir d’appareils mobiles. SQL Database est utilisé pour effectuer l’analyse des données en temps réel, le prétraitement et la caractérisation, car le langage SQL est connu de nombreux développeurs.

La fonctionnalité HTAP est nécessaire pour récupérer l’historique du comportement du compte utilisateur pour un appareil particulier au cours des sept jours précédents afin de calculer les caractéristiques en quasi-temps réel avec une faible latence. Dans SQL Database, ces fonctionnalités de traitement transactionnel/analytique hybride (HTAP) sont utilisées :

• Des tables à mémoire optimisée stockent les profils de compte. Les tables à mémoire optimisée présentent des avantages par rapport aux tables SQL traditionnelles, car elles sont créées et accessibles dans la mémoire principale. La latence et la surcharge de l’accès au disque sont évitées. L’exigence pour cette solution est de traiter 300 messages JSON/seconde. Les tables optimisées en mémoire fournissent ce niveau de débit.
• Les tables optimisées en mémoire sont plus efficacement accessibles à partir des procédures stockées compilées en mode natif. Contrairement aux procédures stockées interprétées, les procédures stockées compilées en mode natif sont compilées lorsqu’elles sont créées pour la première fois.
• Une table temporelle est une table qui gère automatiquement l’historique des modifications. Lorsqu’une ligne est ajoutée ou mise à jour, elle est versionnée et écrite dans la table d’historique. Dans cette solution, les profils de compte sont stockés dans une table temporelle qui a une stratégie de rétention de 7 jours, de sorte que les lignes sont automatiquement supprimées après la période de rétention.

Cette approche offre également ces avantages :

• Accès aux données archivées pour l’analytique opérationnelle, la reformation du modèle Machine Learning et la validation contre la fraude
• Archivage des données simplifié dans un stockage à long terme
• Scalabilité via le partitionnement des données et l’utilisation d’une base de données élastique

Gestion des schémas d’événement

L’automatisation de la gestion des schémas est un autre défi qui doit être résolu pour cette solution. JSON est un format de fichier flexible et portable, en partie parce qu’un schéma n’est pas stocké avec les données. Lorsque des fichiers JSON doivent être analysés, désérialisés et traités, un schéma qui représente la structure du JSON doit être codé quelque part pour valider les propriétés de données et les types de données. Si le schéma n’est pas synchronisé avec le message JSON entrant, la validation JSON échoue et les données ne sont pas extraites.

Le défi survient lorsque la structure des messages JSON change en raison d’une nouvelle fonctionnalité de l’application. Dans sa solution d’origine, la banque pour laquelle cette solution a été créée a déployé plusieurs passerelles d’application, chacune ayant sa propre interface utilisateur, ses propres fonctionnalités, sa propre télémétrie et sa propre structure de messages JSON. Lorsque le schéma n’était pas synchronisé avec les données JSON entrantes, les incohérences créaient des pertes de données et des retards de traitement pour la détection des fraudes.

La banque ne disposait pas d’un schéma formel défini pour ces événements, et les fluctuations constantes de la structure des fichiers JSON ont créé une dette technique à chaque itération de la solution. Cette solution résout ce problème en établissant un schéma pour ces événements et en utilisant Azure Schema Registry. Azure Schema Registry fournit un référentiel central de schémas pour les événements et une flexibilité pour les producteurs et les applications consommatrices afin d’échanger des données sans avoir à gérer et partager le schéma. Le framework de gouvernance simple qu’il introduit pour les schémas réutilisables et la relation qu’il définit entre les schémas par le biais des constructions de regroupement (groupes de schémas) peuvent éliminer une dette technique importante, renforcer la conformité et assurer la rétrocompatibilité entre des schémas changeants.

Conception de fonctionnalités pour le Machine Learning

Les caractéristiques permettent de profiler le comportement du compte en agrégeant l’activité sur différentes échelles de temps. Elles sont créées à partir des données dans les journaux d’activité de l’application qui représentent le comportement transactionnel, non transactionnel et d’appareil. Le comportement transactionnel inclut les activités de transaction monétaire comme les paiements et les retraits. Le comportement non transactionnel inclut les actions utilisateur comme les tentatives de connexion et les modifications de mot de passe. Le comportement d’appareil inclut les activités qui impliquent un appareil mobile, comme l’ajout ou la suppression d’un appareil. Les caractéristiques sont utilisées pour représenter le comportement actuel et passé du compte, notamment :

• Nouvelle tentative d’inscription d’utilisateur à partir d’un appareil spécifique.
• Tentatives de connexion réussies et infructueuses.
• Demandes d’ajout de tiers payeurs ou bénéficiaires.
• Demandes d’augmentation des limites de compte ou de carte de crédit.
• Modifications de mot de passe.

Une table de profil de compte contient les attributs des transactions JSON, comme l’ID du message, le type de transaction, le montant du paiement, le jour de la semaine et l’heure du jour. Les activités sont regroupées sur plusieurs périodes de temps, comme une heure, un jour et sept jours, et stockées sous forme d’historique de comportement pour chaque compte. Chaque ligne de la table représente un seul compte. Voici quelques-unes des caractéristiques :

Une fois les caractéristiques du compte calculées et le profil mis à jour, une fonction Azure appelle le modèle de Machine Learning pour le scoring via une API REST afin de répondre à cette question : Quelle est la probabilité que ce compte soit en état de fraude, sur la base du comportement que nous avons vu ?

AutoML

AutoML est utilisé dans la solution, car il est rapide et facile à utiliser. AutoML peut être un point de départ utile pour accélérer la découverte et la formation, car il ne nécessite pas de connaissances ou de configuration spécialisées. Il automatise les tâches itératives et fastidieuses du développement de modèles Machine Learning. Les scientifiques des données, les analystes et les développeurs peuvent l’utiliser pour créer des modèles de Machine Learning avec une évolutivité, une efficacité et une productivité élevées tout en maintenant la qualité des modèles.

AutoML peut effectuer les tâches suivantes dans un processus Machine Learning :

• Fractionner des données en jeux de données de formation et de validation
• Optimiser la formation en fonction d’une métrique choisie
• Effectuer une validation croisée
• Générer des fonctionnalités
• Imputer des valeurs manquantes
• Effectuer un encodage à chaud et utiliser différents utilitaires de mise à l’échelle

Déséquilibre des données

La classification des fraudes est difficile en raison du déséquilibre de classe grave. Dans un jeu de données de fraude, il y a beaucoup plus de transactions non frauduleuses que de transactions frauduleuses. En règle générale, moins de 1 % d’un jeu de données contient des transactions frauduleuses. S’il n’est pas réglé, ce déséquilibre peut causer un problème de crédibilité du modèle, car toutes les transactions pourraient finir par être classées comme non frauduleuses. Le modèle pourrait complètement manquer toutes les transactions frauduleuses et malgré tout obtenir un taux de précision de 99 %.

AutoML peut vous aider à redistribuer les données et à créer un meilleur équilibre entre les transactions frauduleuses et non frauduleuses :

• AutoML prend en charge l’ajout d’une colonne de pondération en entrée, ce qui a pour effet de pondérer les lignes des données à la hausse ou à la baisse, ce qui peut rendre une classe moins importante. Les algorithmes utilisés par AutoML détectent un déséquilibre lorsque le nombre d’échantillons dans la classe minoritaire est égal ou inférieur à 20 % du nombre d’échantillons dans la classe majoritaire. Par la suite, AutoML exécute l’expérience avec des données sous-échantillonnées pour vérifier si l’utilisation de poids de classe résout ce problème et améliore les performances. S’il détermine que les performances sont meilleures suite à l’expérience, la solution est appliquée.
• Vous pouvez utiliser une métrique de mesure des performances qui gère mieux les données déséquilibrées. Par exemple, si votre modèle doit être sensible aux faux négatifs, utilisez recall. Lorsque le modèle doit être sensible aux faux positifs, utilisez precision. Vous pouvez également utiliser un score F1. Ce score est la moyenne harmonique entre precision et recall, il n’est donc pas affecté par un nombre élevé de vrais positifs ou de vrais négatifs. Vous devrez peut-être calculer manuellement certaines métriques pendant votre phase de test.

Alternativement, pour augmenter le nombre de transactions classées comme frauduleuses, vous pouvez utiliser manuellement une technique appelée Suréchantillonnage minoritaire synthétique (SMOTE). SMOTE est une technique statistique qui utilise le bootstrapping et le plus proche voisin k (KNN) pour produire des instances de la classe minoritaire.

Apprentissage du modèle

Pour la formation du modèle, le SDK Python attend des données au format de dataframe pandas ou sous forme de jeu de données tabulaire Azure Machine Learning. La valeur que vous souhaitez prédire doit se trouver dans le jeu de données. Vous transmettez la colonne y en tant que paramètre lorsque vous créez le travail de formation.

Voici un exemple de code, avec des commentaires :

data = https://automlsamplenotebookdata.blob.core.windows.net/automl-sample-notebook-data/creditcard.csv
dataset = Dataset.Tabular.from_delimited_files(data)
training_data, validation_data = dataset.random_split(percentage=0.7)
label_column_name = "Class"

automl_settings = {
    "n_cross_validations": 3, # Number of cross validation splits.
    "primary_metric": "average_precision_score_weighted", # This is the metric that you want to optimize.
    "experiment_timeout_hours": 0.25, # Percentage of an hour you want this to run.
    "verbosity": logging.INFO, # Logging info level, debug, info, warning, error, critical.
    "enable_stack_ensemble": False, # VotingEnsembled is enabled by default.
}

automl_config = AutoMLConfig(
    task="classification",
    debug_log="automl_errors.log",
    training_data=training_data,
    label_column_name=label_column_name,
    **automl_settings,
)

local_run = experiment.submit(automl_config, show_output=True)

Dans le code :

1. Chargez le jeu de données dans un jeu de données tabulaire Azure Machine Learning ou un dataframe pandas.
2. Fractionnez le jeu de données en 70 % de formation et 30 % de validation.
3. Créez une variable pour la colonne que vous souhaitez prédire.
4. Commencez à créer les paramètres AutoML.
5. Configurez AutoMLConfig.
   1. task est le type de Machine Learning que vous souhaitez effectuer : classification ou regression. Dans ce cas, utilisez classification.
   2. debug_log est l’emplacement où les informations de débogage sont écrites.
   3. training_data est l’objet dataframe ou tabulaire dans lequel les données de formation sont chargées.
   4. label_column_name est la colonne que vous voulez prédire.
6. Exécutez le travail Azure Machine Learning.

Évaluation du modèle

Un bon modèle produit des résultats réalistes et exploitables. C’est l’un des défis des modèles de détection des fraudes. La plupart des modèles de détection des fraudes produisent une décision binaire pour déterminer si une transaction est frauduleuse. La décision est basée sur deux facteurs :

• Score de probabilité compris entre 0 et 100 retourné par l’algorithme de classification
• Seuil de probabilité établi par l’entreprise. Une valeur supérieure au seuil est considérée comme frauduleuse, et non frauduleuse sinon.

La probabilité est une métrique standard pour n’importe quel modèle de classification. Mais elle est généralement insuffisante dans un scénario de fraude pour les décisions sur le blocage d’un compte afin d’éviter d’autres pertes.

Dans cette solution, des métriques au niveau du compte sont créées et prises en compte dans la décision de savoir si l’entreprise doit agir et bloquer un compte. Les métriques au niveau du compte sont définies en fonction de ces métriques standard du secteur :

Ces métriques sont des points de données précieux pour un responsable des fraudes. Le responsable les utilise pour obtenir une image plus complète du risque de compte et décider du recours.

Opérationnalisation et reformation du modèle

Les modèles prédictifs doivent être mis à jour régulièrement. Au fil du temps, et lorsque de nouvelles données et différentes sont disponibles, un modèle prédictif doit être reformé. Cela est particulièrement vrai pour les modèles de détection des fraudes dans lesquels de nouveaux modèles d’activité criminelle sont fréquents. Cela devient également nécessaire lorsque les données de télémétrie des journaux d’applications mobiles changent en raison des modifications envoyées vers la passerelle d’application. Pour fournir une reformation dans cette solution, chaque transaction envoyée pour l’analyse et les métriques d’évaluation de modèle correspondantes sont journalisées. Au fil du temps, les performances du modèle sont surveillées. Lorsqu’il semble se dégrader, un workflow de reformation est déclenché. Plusieurs services Azure sont utilisés dans le workflow de reformation :

• Vous pouvez utiliser Azure Synapse Analytics ou Azure Data Lake pour stocker les données client historiques. Vous pouvez utiliser ces services pour stocker les transactions frauduleuses connues chargées à partir de sources locales et de données archivées à partir du service web Azure Machine Learning, notamment les transactions, les prédictions et les métriques d’évaluation de modèle. Les données nécessaires à la reformation sont stockées dans ce magasin de données.

• Vous pouvez utiliser Data Factory ou des pipelines Azure Synapse pour orchestrer le flux de données et le processus de reformation, notamment :

  • Extraction des données historiques et des fichiers journaux à partir de systèmes locaux.
  • Processus de désérialisation du JSON.
  • Logique de prétraitement des données.

  Pour plus de détails, consultez Reformation et mise à jour de modèles Microsoft Azure Machine Learning avec Azure Data Factory.

• Vous pouvez utiliser des déploiements bleu-vert dans Azure Machine Learning. Pour plus d’informations sur le déploiement d’un nouveau modèle avec un temps d’arrêt minimal, consultez Déploiement sécurisé pour les points de terminaison en ligne.

Composants

• Azure Functions fournit des fonctions de code serverless pilotées par les événements et une expérience de développement de bout en bout.
• Event Hubs est un service d’ingestion de données en temps réel complètement managé. Vous pouvez l’utiliser pour diffuser des millions d’événements par seconde à partir de n’importe quelle source.
• Key Vault protège les clés de chiffrement et autres secrets utilisés par les applications et services cloud.
• Azure Machine Learning est un service de classe Entreprise pour le cycle de vie de Machine Learning de bout en bout.
• AutoML est un processus d’automatisation des tâches répétitives et chronophages du développement de modèles Machine Learning.
• Azure SQL Database est un service de base de données relationnelle toujours à jour et complètement managé, conçu pour le cloud.
• Azure Synapse Analytics est un service d’analytique illimité, qui réunit l’intégration de données, l’entreposage de données d’entreprise et des fonctionnalités analytiques pour le Big Data.

Considérations techniques

Pour sélectionner les composants technologiques appropriés pour une infrastructure basée sur le cloud en continu pour la détection des fraudes, vous devez comprendre les exigences actuelles, qui peuvent être vagues. Les choix technologiques de cette solution sont basés sur des considérations susceptibles de vous aider à prendre des décisions similaires.

Ensembles de compétences

Considérez les ensembles de compétences technologiques actuels des équipes qui conçoivent, implémentent et gèrent la solution. Les technologies cloud et IA étendent les choix disponibles pour l’implémentation d’une solution. Par exemple, si votre équipe possède des compétences en science des données de base, Azure Machine Learning est un bon choix pour la création du modèle et le point de terminaison. La décision d’utiliser Event Hubs est un autre exemple. Event Hubs est un service géré facile à configurer et à entretenir. Il existe des avantages techniques à utiliser une alternative comme Kafka, mais cela peut nécessiter une formation.

Environnement opérationnel hybride

Le déploiement de cette solution s’étend sur un environnement local et l’environnement Azure. Les services, réseaux, applications et communications doivent fonctionner efficacement sur les deux infrastructures pour soutenir la charge de travail. Les décisions technologiques comprennent les suivantes :

• Comment les environnements sont-ils intégrés ?
• Quelles sont les exigences de connectivité réseau entre le centre de données Azure et l’infrastructure locale ? Azure ExpressRoute est utilisé, car il fournit des lignes doubles, une redondance et le basculement. Le VPN de site à site ne fournit pas la sécurité ou la qualité de service (QoS) nécessaires pour la charge de travail.
• Comment les scores de détection des fraudes s’intègrent-ils aux systèmes de back-end ? Les réponses de scoring doivent s’intégrer aux workflows de fraude de back-end pour automatiser la vérification des transactions avec les clients ou d’autres activités de gestion des cas. Vous pouvez utiliser Azure Functions ou Logic Apps pour intégrer des services Azure à des systèmes locaux.

Sécurité

L’hébergement d’une solution dans le cloud crée de nouvelles responsabilités de sécurité. Dans le cloud, la sécurité est une responsabilité partagée entre un fournisseur cloud et un locataire client. Les responsabilités de charge de travail varient selon que la charge de travail est un service SaaS, PaaS ou IaaS. Pour plus d’informations, consultez Responsabilité partagée dans le cloud.

Que vous adoptiez une approche confiance zéro ou que vous vous efforciez d’appliquer les exigences de conformité réglementaire, la sécurisation d’une solution de bout en bout exige une planification et une réflexion approfondies. Pour la conception et le déploiement, nous vous recommandons d’adopter des principes de sécurité conformes à une approche de confiance zéro. L’adoption de principes comme vérifier explicitement, utiliser l’accès au moindre privilège et supposer une violation renforce la sécurité de la charge de travail.

Vérifier explicitement est le processus d’examen et d’évaluation de différents aspects d’une demande d’accès. Voici quelques-uns de ces principes :

• Utilisez une plateforme d’identité forte comme Microsoft Entra ID.
• Comprenez le modèle de sécurité pour chaque service cloud et comment les données et l’accès sont sécurisés.
• Si possible, utilisez des identités managées et des principaux de service pour contrôler l’accès aux services cloud.
• Stockez les clés, secrets, certificats et artefacts d’application comme les chaînes de base de données, URL de point de terminaison REST et clés API dans Key Vault.

L’utilisation de l’accès au moindre privilège permet de s’assurer que les autorisations ne sont accordées que pour répondre à des besoins commerciaux spécifiques d’un environnement approprié à un client approprié. Voici quelques-uns de ces principes :

• Compartimentez les charges de travail en limitant l’accès d’un composant ou d’une ressource via des attributions de rôles ou un accès réseau.
• Interdisez l’accès public aux points de terminaison et aux services. Utilisez des points de terminaison privés pour protéger vos services, sauf si votre service nécessite un accès public.
• Utilisez des règles de pare-feu pour sécuriser les points de terminaison de service ou isoler les charges de travail à l’aide de réseaux virtuels.

Supposer une violation est une stratégie pour guider les décisions de conception et de déploiement. La stratégie consiste à supposer qu’une solution a été compromise. Il s’agit d’une approche permettant de renforcer la résilience dans une charge de travail en planifiant la détection, la réponse et la correction d’une menace de sécurité. Pour les décisions de conception et de déploiement, cela implique que :

• Les composants de charge de travail sont isolés et segmentés afin qu’une compromission d’un composant réduise l’impact sur les composants en amont ou en aval.
• La télémétrie est capturée et analysée de manière proactive pour identifier les anomalies et les menaces potentielles.
• L’automatisation est en place pour détecter, répondre à et corriger une menace.

Voici quelques recommandations à prendre en compte :

• Chiffrez les données au repos ou en déplacement.
• Activer l’audit pour les services.
• Capturez et centralisez les journaux d’audit et les données de télémétrie dans un seul espace de travail de journal pour faciliter l’analyse et la corrélation.
• Permettez à Microsoft Defender pour le cloud d’analyser les configurations potentiellement vulnérables et de fournir un avertissement précoce concernant les problèmes de sécurité potentiels.

La mise en réseau est l’un des facteurs de sécurité les plus importants. Par défaut, les points de terminaison d’espace de travail Azure Synapse sont des points de terminaison publics. Cela signifie qu’ils sont accessibles à partir de n’importe quel réseau public. Nous vous recommandons donc vivement de désactiver l’accès public à l’espace de travail. Envisagez de déployer Azure Synapse avec la fonctionnalité de réseau virtuel managé activée pour ajouter une couche d’isolation entre votre espace de travail et les autres services Azure. Pour plus d’informations sur les réseaux virtuels managés et d’autres facteurs de sécurité, consultez le Livre blanc sur la sécurité d’Azure Synapse Analytics : Sécurité réseau.

Téléchargez un fichier Visio de cette architecture.

Des conseils de sécurité spécifiques à chaque composant de solution de la solution bancaire sont inclus dans le tableau suivant. Pour un bon point de départ, passez en revue le Benchmark de sécurité Azure, qui inclut des bases de référence de sécurité pour chacun des services Azure individuels. Les recommandations de base de référence de sécurité peuvent vous aider à sélectionner les paramètres de configuration de sécurité pour chaque service.

Pour plus d’informations, consultez Centre d’orientation sur la confiance zéro.

Extensibilité

La solution doit fonctionner de bout en bout lors des heures de pointe. Un workflow de diffusion en continu pour gérer des millions d’événements arrivants en continu demande un débit élevé. Prévoyez de créer un système de test qui simule le volume et l’accès concurrentiel pour garantir que les composants technologiques sont configurés et paramétrés pour répondre aux latences requises. Les tests de scalabilité sont particulièrement importants pour ces composants :

• Ingestion de données pour gérer les flux de données simultanés. Dans cette architecture, Event Hubs est utilisé, car plusieurs instances peuvent être déployées et affectées à différents groupes de consommateurs. Une approche de scale-out est une meilleure option, car la mise à l’échelle peut entraîner un verrouillage. Une approche de scale-out est également mieux adaptée si vous envisagez de développer la détection des fraudes à partir de la banque mobile pour inclure un canal bancaire Internet.
• Infrastructure permettant de gérer et de planifier le flux de processus. Azure Functions est utilisé pour orchestrer le workflow. Pour améliorer le débit, les messages sont traités par lots dans des micro-lots et traités via une seule fonction Azure plutôt que de traiter un message par appel de fonction.
• Processus de données à faible latence pour gérer l’analyse, le prétraitement, les agrégations et le stockage. Dans la solution réelle sur laquelle cet article est basé, les capacités des fonctions SQL optimisées en mémoire répondent aux exigences d’extensibilité et d’accès concurrentiel.
• Scoring de modèle pour gérer les demandes simultanées. Avec les services web Azure Machine Learning, vous avez deux options pour la mise à l’échelle :
  • Sélectionnez un niveau web de production pour prendre en charge la charge de travail d’accès concurrentiel de l’API.
  • Ajoutez plusieurs points de terminaison à un service web si vous devez prendre en charge plus de 200 requêtes simultanées.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Kate Baroni | Ingénieure client principale
• Michael Hlobil | Directeur principal de l’ingénierie client
• Cedric Labuschagne | Responsable des programmes techniques
• Frank Garofalo | Ingénieur client principal
• Shep Sheppard | Ingénieur principal du service

Autre contributeur :

• Mick Alberts | Rédacteur technique

Étapes suivantes

• Un pipeline Big Data rapide, serverless et optimisé par une seule fonction Azure
• Envisager Azure Functions pour un scénario de flux de données serverless
• Considérations relatives au réseau pour App Service Environment
• Hubs d'événements
• Key Vault
• Azure Machine Learning

Ressources associées

• Conception de l’architecture IA
• Comparer les produits et les technologies de Machine Learning Microsoft
• Guide des performances et de la mise à l’échelle pour Event Hubs avec Azure Functions
• Surveillance d’Azure Functions et d’Event Hubs
• Présentation des pipelines Azure Machine Learning