Dans le cadre de la lutte contre le blanchiment de capitaux et le financement du terrorisme, les banques doivent se soumettre à différentes réglementations. KYC (pour Know Your Customer) est l’une d’entre elles et elle exige un système informatique sur mesure pour y répondre. Mais KYC, qu’est-ce que c’est ? Il s’agit d’un processus légal permettant de vérifier l’identité d’un client, qu’il soit privé ou commercial. Et quand on parle de pilotage de processus, il n’est pas rare de voir Jira pointer le bout de son nez !

Nous allons donc voir dans cet article comment l’on peut aider les SI (systèmes informatiques) bancaires à piloter ce processus stratégique avec Jira et quelques Apps de la Marketplace Atlassian. Nous nous appuyons sur les développements de solution que nous avons fait dans de nombreuses organisations bancaires, clients de Valiantys, sur ce sujet.

L’architecture choisie dans Jira

Dans cette première partie, nous allons voir un exemple d’implémentation qui a pu être réalisée. Cela reste néanmoins qu’une interprétation de la réglementation pour une entreprise donnée, et cette implémentation et très dépendante de son contexte d’application.

Pour mieux appréhender la lecture de la suite de cet article, nous allons poser les choix d’architectures suivants:

Demandes, Projets, Champs Personnalisés, Groupes et Utilisateurs :

1. Un Dossier KYC sera modélisé par une Demande Jira, cette demande fera toujours référence à un identifiant client unique.

2. Chaque Région Administrative sera vue dans Jira comme étant un Projet Jira distinct.

3. Les Différentes Données utiles à la validation et au déroulé du processus KYC seront toutes rapatriées dans Jira dans des Champs Personnalisés dédiés.

4. Les Agences bancaires seront vues comme des Groupes Jira et pourront éventuellement être extraite de l’Active Directory. Ce choix permettra notamment un cloisonnement des données

5. Enfin chaque acteur du processus (Front Office, Middle Office, Back Office …) aura son propre Utilisateur Jira

Workflow de Validation

Élément central de cette implémentation et atout principal de Jira, le moteur de Workflow nous a permis de modéliser le processus KYC directement dans Jira. Ce workflow dépend évidemment de l’organisation de votre société.

Collecte des données (et contraintes RGPD …)

Comme vu en introduction, la collecte et le stockage des données sont les points clés d’une implémentation KYC.

Affichage des données Clients

Bien que certaines Apps de la Markeplace Atlassian nous permettraient d’atteindre cet objectif (Insight par exemple), la plupart des organisations bancaires disposent déjà d’outils de CBS (Core Banking System).

Nous bénéficions donc de cet ensemble de données déjà disponibles pour aider au maximum le conseiller clientèle dans la gestion de ce processus, parfois vu comme une contrainte pour le front office.

Le premier challenge technique est donc d’interroger ce CBS, d’en extraire un lot de données défini et d’afficher ces données dans la demande Jira (Dossier KYC). L’App Elements Connect vient tout naturellement se greffer au projet KYC dans Jira. En effet, cette App nous permet d’interroger le CBS de façon sécurisée (via API Rest), mais également d’afficher ces données en lecture seule dans Jira.

Anonymisation des Utilisateurs

Pour répondre aux exigences RGPD (Règlement général sur la protection des données), Atlassian a introduit de nouvelles fonctionnalités vous permettant de facilement anonymiser vos données. Voir cette page : GDPR Changes in Jira.

Escalades hiérarchiques et organisationnelles

Lors de l’entrée en relation entre la banque et son nouveau client, la banque doit procéder à un certain nombre de tâches qui permettent à la fois de recueillir les informations ayant trait au client, mais également de contrôler la véracité de ces informations.

Les données ayant été stockées dans le CBS, Jira va porter le workflow de validation. Ainsi, en fonction de règles métiers définies (présence sur des listes de sanctions, pays à risques, personne politiquement exposée (PPE)…), le chemin de validation que devra suivre le dossier ne sera pas le même.

Grâce au moteur de Workflow Jira, nous pouvons implémenter l’ensemble des règles métiers (conditions, post fonctions, validations …)

Exemple de scénario :

1. Initialisation du dossier KYC basé sur les données clients

2. Récupération des données clients dans la demande Jira

3. Escalade au responsable d’agence → Conformité → Direction Régionale

4. Validation du dossier

Confidentialité des données

Les données affichées dans le dossier KYC étant souvent sensibles, il est nécessaire de mettre en place un cloisonnement des données. Sur ce point, plusieurs fonctionnalités natives de Jira sont très utiles :

– Schéma de permission et Rôle de projet : Premier niveau de cloisonnement proposé. Ici on créé les rôles métiers afin d’y associer les groupes d’utilisateurs adéquats. Ainsi, on retrouve dans Jira les rôles (Conseiller Clientèle, Responsable d’Agence, Back Office Officer …)

– Permission basée sur un champ de type Groupe : Comme vu dans la présentation de l’architecture de Jira, les groupes d’utilisateurs permettent de gérer l’affectation des utilisateurs dans leur agence respective. On profite également de cette configuration pour restreindre l’accès des dossiers à l’agence d’affectation du conseiller clientèle. Cette règle sera également appliquée à la hiérarchie. Ainsi, un Conseiller Clientèle ne verra que les dossiers de son agence, un membre de la direction régionale verra l’ensemble des dossiers de la région et un membre de la conformité aura accès à l’ensemble des dossiers.

– Niveau de sécurité de demande : Dans certains cas (Client PPE, Salariés de la banque…), un niveau d’habilitation peut être demandé au conseiller clientèle. Certains dossiers ne doivent pas lui être accessibles. Pour ce dernier niveau de visibilité, nous profitons de la fonctionnalité de demande. Le niveau de sécurité étant basé sur une combinaison de champs Elements Connect provenant du CBS.

Pilotage de la performance

Dernier point fort de notre implémentation KYC dans Jira, c’est le pilotage des équipes. En effet, on peut stocker les dossiers dans Jira pour en piloter la performance. Cela permet aux différentes entités (agences, directions…) de produire des rapports en temps réel sur le nombre de dossiers traités, mais également aux managers d’anticiper la future charge de travail de leurs équipes.

Exemple de reporting :

1. Combien de dossier ont été traités par l’agence XX ?

2. Parmi ces dossiers, quelle est la répartition Particulier / Pro ?

3. Quelle direction régionale gère le plus de dossiers ?

4. Combien de dossiers devront être traités par le Back Office le mois prochain (en prenant un taux de validation de 80%) ?

5. Quelle agence est en sous-effectif ?

Adaptation des libellés

Afin d’intégrer le jargon du métier et de la société dans laquelle cette solution est déployée, nous utilisons deux outils indispensables à l’adaptation ergonomique de Jira :

1. In Product Translation: Cet outil gratuit est développé et maintenu par Atlassian et nous permet de traduire un grand nombre d’éléments de l’IHM . Dans notre exemple métier, nous avons pu faire disparaître le terme (trop) générique de Demande en le remplaçant par le terme Dossier.

2. Script Fragments (fonctionnalité de Script Runner) : Cette fonctionnalité permet de masquer les fonctionnalités Jira inutiles dans ce contexte d’utilisation. Ces fonctionnalités apportent du bruit et créent de la confusion pour les utilisateurs.

Conclusion

Cet article n’est qu’un exemple d’implémentation du processus KYC réalisés chez certains clients. La modularité de Jira nous permet évidemment d’adapter l’outil très facilement aux spécificités de chaque organisation. Il faut retenir qu’avec une petite sélection d’Apps et surtout la puissance de Jira (notamment de son moteur de Workflow), on peut très rapidement créer un outil de pilotage de processus stratégique très performant. Nos consultants déploient tous les jours des solutions Jira personnalisées, alors si vous avez des challenges de process métier, on peut en parler.