La banque Finama gère ses risques

Quelle démarche adopter pour se conformer aux normes de Bâle II ? La banque française Finama, qui gère 32,8 millions d’opérations en moyens de paiement par an, a choisi le progiciel Kim’hotline de Kimoce, une société spécialisée dans la gestion des événements dans des infrastructures. Et le paramétrage de l’outil n’a demandé que 10 jours, en 2004.  »

Mais l’essentiel du travail s’est fait en amont » précise Nicolas Etienne, responsable du projet de gestion des risques dans l’établissement, lors de sa présentation, ce 12 mai.  » Nous avions défini exactement ce que nous voulions« . 400 procédures Et c’est cette étape qui prend du temps. Tout d’abord, la mécanique des activités de la banque qui a été démontée, pièce par pièce : Objectif : la construction d’un référentiel. Pour ce faire, les processus opérationnels et de support ont été identifiés de la manière la plus fine possible. Et, pour chacun de ces processus, un pilote, responsable de la gestion des risques pour son activité, a été nommé. Sur cette base, 400 procédures décrivent l’enchaînement des tâches. Et ce n’est jamais fini. « Il faut les entretenir » souligne Nicolas Etienne, « d’autant que la banque est en expansion, et que ses activités évoluent« . 682 risques Dans un deuxième temps, de nombreuses catégories de salariés de l’établissement ont été mises à contribution, pour définir tous les risques existants. « Nous avons discuté avec les dirigeants, les services d’audit, pour les grands risques. Puis, sur le plan opérationnel, les pilotes ont identifié 80% des risques. Et enfin, les fiches de progrès, les rapports d’erreur, en fait, sont générés par les acteurs de base, sans filtre hiérarchique « . Au total, la banque a identifié 682 risques, répartis suivant les catégories de Bâle II. Un outil Ce n’est qu’une fois son référentiel construit, que l’établissement s’est posé la question de l’outil informatique. Pour se tourner finalement vers un logiciel qu’elle exploite depuis plusieurs années capable de gérer les incidents dans son parc informatique. « Nous voulions un produit qui s’adapte à notre projet, et non l’inverse« , explique son responsable. « Il devait être en mesure de gérer plusieurs référentiels, celui des risques, des processus, ou des contrôles, une expérience dans la gestion des incidents. Mais il fallait également qu’il soit évolutif : par exemple, nous avons intégré la gestion des ordres du ‘front office’, que nous n’avions pas identifié au départ. Autre exigence, celle du cloisonnement des données. Nous ne tenons pas à ce que tous accèdent aux risques liés aux procédures prud’hommales, par exemple. Et enfin, nous voulions être libres de faire des reportings comme nous l’entendons. » Cette possibilité est possible avec cet outil qui propose un générateur d’états, Crystal Report, mais qui est doté d’une fonction requête qui permet d’extraire les données. Cette souplesse caractérise le produit de Kimoce, développé en Java ou en C++, compatible avec l’ensemble des architectures existantes, et qui vise actuellement le marché des petites et moyennes banques.