Mon équipe et moi représentons la direction du développement commercial avec les partenaires de Rosbank. Aujourd'hui, nous aimerions parler de l'expérience réussie de l'automatisation d'un processus métier bancaire à l'aide d'intégrations directes entre systèmes, de l'intelligence artificielle en termes de reconnaissance d'images et de texte basée sur GreenOCR, la législation RF, et la préparation d'échantillons pour la formation.
Alors, commençons. Rosbank dispose d'un processus métier pour ouvrir un compte pour un emprunteur représenté par une banque partenaire. Le processus existant, suivant toutes les exigences réglementaires et les exigences du groupe Société Générale, avant l'automatisation prenait jusqu'à 20 minutes de temps opérationnel par client. Le processus comprend la réception de numérisations de documents par le back-office, la vérification de l'exactitude du remplissage de chaque document et l'affichage des champs de document dans les systèmes d'information de la banque, un certain nombre d'autres chèques, et seulement à la toute fin - l'ouverture d'un compte. C'est exactement le processus derrière le bouton "Ouvrir un compte".
Les principaux champs du document - nom, prénom, patronyme, date de naissance du client, etc. - sont contenus dans presque tous les types de documents reçus et sont dupliqués lorsqu'ils sont saisis dans différents systèmes de la Banque. Le document le plus complexe - le questionnaire KYC (de Know Your Customer - connaissez votre client) - est un format A4 imprimable rempli d'une police de 8 points et contient environ 170 champs de texte et cases à cocher, ainsi que des vues tabulaires.
Que devons-nous faire?
Notre objectif principal était de minimiser le temps nécessaire pour ouvrir un compte.
L'analyse du processus a montré qu'il fallait:
- Réduire le nombre de vérifications manuelles de chaque document;
- Automatiser le remplissage des mêmes champs dans différents systèmes bancaires;
- Réduire le mouvement des scans de documents entre les systèmes;
Pour résoudre les problèmes (1) et (2), il a été décidé d'utiliser la solution de reconnaissance d'images et de texte basée sur GreenOCR déjà implémentée dans la banque (le nom de travail est "Recognizer"). Les formats des documents utilisés dans le processus métier ne sont pas standard, l'équipe a donc été confrontée à la tâche de développer les exigences pour le «reconnaissant» et de préparer des exemples pour la formation du réseau neuronal (échantillons).
Pour résoudre les problèmes (2) et (3), il a fallu affiner les systèmes et l'intégration intersystème.
Notre équipe dirigée par Julia Aleksashina
- Alexander Bashkov - développement de systèmes internes (.Net)
- Valentina Sayfullina - analyse commerciale, tests
- Grigory Proskurin - intégration entre systèmes (.Net)
- Ekaterina Panteleeva - analyse commerciale, tests
- Sergey Frolov - Gestion de projet, analyse de la qualité des modèles
- Participants d'un fournisseur externe ( Smart Engines en collaboration avec Philosophy.it )
Formation de reconnaissance
L'ensemble de documents client utilisés dans le processus métier comprenait:
- Passeport;
- Consentement - formulaire imprimé A4, 1 litre;
- Procuration - formulaire imprimé A4, 2 l;
- Questionnaire KYC - formulaire A4 imprimé, 1 litre;
Pour commencer, les documents ont été soigneusement étudiés et les exigences ont été développées, qui incluaient non seulement le travail du module de reconnaissance avec des champs dynamiques, mais aussi le travail avec du texte statique, des champs avec des données manuscrites, en général, la reconnaissance de documents le long du périmètre et d'autres améliorations.
La reconnaissance du passeport a été incluse dans la fonctionnalité de boîte du système GreenOCR et n'a pas nécessité de modifications.
Pour le reste des types de documents, à la suite de l'analyse, les attributs et signes nécessaires ont été déterminés que le "dispositif de reconnaissance" devrait renvoyer. Dans le même temps, les points suivants ont dû être pris en compte, ce qui a compliqué le processus de reconnaissance et a nécessité une complication notable des algorithmes utilisés:
- , . , «» ;
- 8- . , ;
- ( ) ;
- ;
- , , ;
- ;
Au départ, la tâche ne nous semblait pas trop compliquée et avait l'air assez standard:
Exigences -> Fournisseur -> Modèle -> Tester le modèle -> Démarrage du processus
En cas d'échec des tests, le modèle est renvoyé au fournisseur pour se recycler.
Chaque jour, nous recevons un grand nombre de scans de documents et la préparation d'un échantillon pour la formation d'un modèle n'aurait pas dû être un problème. Tout traitement de données personnelles doit être conforme aux exigences de la loi fédérale «sur les données personnelles» N152-FZ. Le consentement des clients au traitement des données personnelles des clients n'est disponible qu'au sein de Rosbank. Nous ne pouvons pas transférer les documents du client au fournisseur pour entraîner le modèle.
Trois moyens de résoudre le problème ont été envisagés:
- , , , , ;
- . , – () , ;
- () . , , , , , ;
Après avoir analysé les options proposées avec l'équipe, concernant la rapidité de leur mise en œuvre et les risques éventuels, nous avons choisi la troisième option - la manière d'imiter des documents pour former le modèle. Le principal avantage de ce processus est la possibilité de couvrir la plus large gamme possible de dispositifs de numérisation afin de réduire le nombre d'itérations pour l'étalonnage et l'affinement du modèle.
Les modèles de documents ont été mis en œuvre au format html. Un tableau de données de test et une macro ont été préparés rapidement et efficacement, remplissant les modèles avec des données synthétisées et automatisant l'impression. Ensuite, nous avons généré des formulaires imprimables au format pdf et attribué un identifiant unique à chaque fichier pour vérifier les réponses reçues du "décodeur".
La formation du réseau de neurones, le marquage des zones et la personnalisation des formulaires se sont déroulés du côté du vendeur.
En raison du délai limité, la formation du modèle a été divisée en 2 étapes.
Lors de la première étape, le modèle a été formé à la reconnaissance des types de documents et à la reconnaissance "grossière" du contenu des documents eux-mêmes:
Exigences -> Fournisseur -> Préparation des données de test -> Collecte de données -> Formation du modèle à la reconnaissance de formulaire -> Test des formulaires -> Mise en place du modèle
À la deuxième étape il y avait une formation détaillée du modèle pour reconnaître le contenu de chaque type de documents. La formation et la mise en œuvre du modèle à la deuxième étape peuvent être décrites par le schéma suivant, qui est le même pour tous les types de documents:
Préparation des données de test dans différentes résolutions -> Collecte et transmission des données au fournisseur -> Formation du modèle -> Test du modèle -> Calibrage du modèle -> Mise en œuvre du modèle -> Vérification des résultats au combat -> Identification des cas de problème -> Simulation des cas de problème et transfert au fournisseur -> Répétition des étapes des tests
Il convient de noter que, malgré la très large couverture de la gamme des appareils de numérisation utilisés, un certain nombre d'appareils n'étaient toujours pas présentés dans les exemples de formation du modèle. Par conséquent, l'introduction du modèle dans la bataille s'est déroulée en mode pilote et les résultats n'ont pas été utilisés pour l'automatisation. Les données obtenues pendant le travail en mode pilote n'ont été enregistrées dans la base de données que pour une analyse et une analyse plus poussées.
Essai
Étant donné que la boucle de formation du modèle était du côté du fournisseur et n'était pas connectée aux systèmes de la banque, après chaque cycle de formation, le modèle était transféré par le fournisseur à la banque, où il a été testé sur un environnement de test. En cas de réussite de la vérification, le modèle a été transféré dans l'environnement de certification, où il a été testé par régression, puis dans l'environnement industriel, afin d'identifier les cas particuliers qui n'ont pas été pris en compte lors de la formation du modèle.
Au périmètre de la banque, les données ont été soumises au modèle, les résultats ont été enregistrés dans la base de données. L'analyse de la qualité des données a été réalisée à l'aide du tout-puissant Excel - en utilisant des tableaux croisés dynamiques, une logique avec des formules et leurs combinaisons vlookup, hlookup, index, len, match et comparaison de chaînes caractère par caractère via la fonction if.
Les tests à l'aide de documents simulés nous ont permis d'exécuter le maximum de scénarios de test et d'automatiser le processus autant que possible.
Tout d'abord, en mode manuel, nous avons vérifié le retour de tous les champs pour vérifier la conformité avec les exigences d'origine pour chaque type de document. Ensuite, nous avons vérifié les réponses du modèle lors du remplissage dynamique de blocs de texte de différentes longueurs. L'objectif était de tester la qualité des réponses lorsque le texte se déplace de ligne en ligne et de page en page. A la fin, nous avons vérifié la qualité des réponses dans les champs en fonction de la qualité du document numérisé. Pour l'étalonnage de la plus haute qualité du modèle, des numérisations de documents à basse résolution ont été utilisées.
Une attention particulière aurait dû être accordée au document le plus complexe contenant le plus grand nombre de champs et de cases à cocher - le questionnaire KYC. Pour lui, des scripts spéciaux pour remplir le document ont été préparés à l'avance et des macros automatisées ont été écrites, ce qui a permis d'accélérer le processus de test, de vérifier toutes les combinaisons de données possibles et de donner rapidement des commentaires au fournisseur pour calibrer le modèle.
Intégration et développement interne
La révision nécessaire des systèmes de la banque et l'intégration intersystème ont été effectuées au préalable et affichées sur les environnements de test de la banque.
Le scénario réalisé comprend les étapes suivantes:
- Réception de numérisations entrantes de documents;
- Envoi des scans reçus au "module de reconnaissance". L'envoi est possible en mode synchrone et asynchrone avec jusqu'à 10 threads;
- Recevoir une réponse du "reconnaisseur", vérifier et valider les données reçues;
- Sauvegarde du scan original du document dans la bibliothèque électronique de la banque;
- Initiation dans les systèmes de la banque du traitement des données reçues du «reconnaissant» et vérification ultérieure par l'employé;
Résultat
Pour le moment, la formation du modèle est terminée, des tests et une mise en œuvre réussis du processus commercial dans l'environnement de production de la banque ont été effectués. L'automatisation réalisée a permis de réduire le temps moyen d'ouverture d'un compte de 20 minutes à 5 minutes. Une étape à forte intensité de main-d'œuvre du processus métier de reconnaissance et de saisie des données de document, qui était auparavant effectuée manuellement, a été automatisée. Dans le même temps, la probabilité d'erreurs causées par le facteur humain est fortement réduite. De plus, l'identité des données extraites du même document dans différents systèmes de la banque est garantie.