De nombreux processus opérationnels bancaires impliquent à la fois la filière finance, la filière risques et la trésorerie. C’est le cas, par exemple, d’un processus désormais au cœur de l’actualité, celui de la gestion du risque de liquidité et du financement. Défini par le règlement CRBF 97-02 modifié comme étant le risque, pour l’établissement assujetti, de ne pas pouvoir faire face à ses engagements ou de ne pas pouvoir dénouer ou compenser une position en raison de la situation du marché, le risque de liquidité est, le plus souvent, piloté par la direction financière, supervisé par la direction des risques et mis en œuvre, pour partie, par la trésorerie :
- la direction financière assure la mise en œuvre de la politique de liquidité définie par la direction générale et le comité ALM. Elle réalise le pilotage des risques structurels, la coordination des trésoreries, la gestion opérationnelle du refinancement et le pilotage des réserves ;
- la trésorerie pilote la gestion de la liquidité à court terme dans le cadre des orientations fixées par la direction générale ;
- la direction des risques valide le dispositif, contrôle les modèles utilisés et réalise le suivi du respect des limites et règles fixées.
Trois systèmes d’information distincts
La gestion du risque de liquidité et de financement est un parfait exemple démontrant la capacité de ces trois filières à mettre en place des processus opérationnels transversaux. Pour autant, on peut s’interroger sur les raisons de l’absence d’une telle transversalité en ce qui concerne leurs systèmes d’information. Chaque filière dispose en effet souvent de son propre système d’information, adapté sur mesure à ses besoins et alimenté par son propre système de collecte de flux.
La direction financière dispose de son système comptable alimenté en données par les applicatifs de gestion des différents métiers de la banque. Ces applicatifs de gestion intègrent une partie de la complexité comptable pour être en mesure de délivrer une information financière pertinente en temps et en heure. La granularité de l’information transmise est directement liée à la complexité du plan de comptes et du détail inclus dans la clé comptable. Elle se limite le plus souvent aux besoins de la comptabilité financière et analytique.
La direction des risques dispose de sa base des risques, également alimentée en données par les applicatifs de gestion. Ceux-ci transmettent aux bases risques l’ensemble des engagements bilan et hors-bilan générés par les activités de la banque. La granularité de l’information collectée est plus élevée que celle requise par la direction financière, car les besoins risques requièrent une information très détaillée sur l’ensemble des contrats.
La trésorerie, pour ses besoins de modélisation des cash-flows, doit également collecter une information très détaillée sur les contrats. Elle fait donc également appel aux applicatifs de gestion comme source d’information.
Des efforts coûteux de rapprochement
Chaque filière a ainsi mis en place son propre système de collecte de flux à partir des mêmes sources amont, à savoir les systèmes de gestion des métiers de la banque, pour alimenter son système d’information, ce qui génère des efforts incessants et coûteux de rapprochement de données entre les trois types d’information produites pour en garantir la fiabilité.
L’idée d’un entrepôt de données (ou datawarehouse) commun à ces trois filières pour l’alimentation de leurs systèmes d’information n’est pas nouvelle. Les gains attendus en termes de qualité, d’exhaustivité et de cohérence des informations sont les principales motivations, à juste titre, derrière les projets visant à mettre en place de tels outils. À ce titre, la crise financière et la vague réglementaire qui lui fait suite vont constituer des catalyseurs significatifs dans la mise en place de ces bases de données.
En effet, les autorités de supervision exigent désormais des établissements bancaires des informations plus complexes, produites dans des délais resserrés et présentant des convergences croissantes, remettant ainsi en cause la viabilité d’un triple système de collecte d’information.
La complexification des informations requises
La complexification des informations requises par les régulateurs a connu une accélération brutale avec l’enchaînement successif de réglementations de plus en plus contraignantes faisant suite aux crises financières. La CRD 4 illustre parfaitement ce phénomène : la déclinaison européenne des accords dits de Bâle III sous la forme d’une directive et d’un règlement, proposés par la Commission européenne en juillet 2011 et dont l’adoption par le Parlement européen et le Conseil est anticipée pour le second semestre 2012, délègue à l’Autorité bancaire européenne la production d’un reporting réglementaire européen adapté aux exigences de Bâle III. Les premiers modèles publiés par l’ABE en décembre 2011 s’avèrent bien plus détaillés et plus riches que les précédents modèles : le nombre des « templates »
Un raccourcissement des délais de production des états
Par ailleurs, les délais de production des états réglementaires se réduisent. À ce titre, les établissements bancaires devront désormais publier les nouveaux états FINREP et COREP dans un délai de 30 jours ouvrés, à comparer aux délais significativement plus longs imposés par les régulateurs locaux pour les actuelles versions des états – en France, les états doivent être remis à l’ACP dans les deux mois suivant la date d’arrêté, à l’exception des états arrêtés au 30 juin, qui sont remis dans les trois mois suivant leur date d’arrêté.
La convergence entre les référentiels comptables et les référentiels risques
Parallèlement à cette complexification et à ce raccourcissement des délais, une troisième tendance est également de nature à remettre en cause l’organisation actuelle en silos des systèmes de collecte : il s’agit de la convergence entre les référentiels comptables et les référentiels risques. Encore timide, celle-ci se traduit notamment par le rapprochement effectué par les normes IFRS vers les référentiels bâlois. Les nouvelles règles de provisionnement qui devraient être intégrées dans la version finale d’IFRS 9 feront référence à la notion de « perte estimée », par opposition à la notion actuelle de « perte avérée » sous IAS 39. Cette notion de « perte estimée » (expected loss) est également celle utilisée dans les référentiels bâlois. Les définitions données par les deux référentiels sont assez proches (estimation des pertes pouvant être encourues lors de l’octroi d’un crédit), même si, dans l’état actuel des choses, de nombreuses divergences subsistent encore entre les deux notions (notamment sur les horizons sur lesquels portent les pertes estimées). De même, les informations requises par IFRS 7 en termes de risque de crédit sont relativement proches de celles exigées pour les besoins de communication prudentielle baloise. Les synergies entre les besoins comptables et les besoins risques sont ainsi confirmées.
Un système unique de collecte des flux
Dans ce contexte de renforcement de la réglementation, le système unique de collecte des flux apparaît comme étant le mieux armé pour faire face aux défis à venir, et notamment celui de l’optimisation des ressources et des moyens. En effet, une organisation en silos des systèmes de collecte requerra des ressources de plus en plus importantes en termes de réconciliations au fur et à mesure que les reportings à produire gagneront en complexité. De plus, les synergies nouvellement créées par la convergence des référentiels comptables et risques ne pourront être pleinement exploitées dans un tel système.
L’architecture d’un système unique de collecte des flux doit être développée autour d’une base de données unique et alimentée par les applicatifs de gestion des différents métiers de la banque. L’alimentation de cette base sera cadencée au rythme des événements de gestion (ou « événements métier ») qui ponctueront la vie des contrats: attribution d’une ligne de crédit, achat/vente de titres, conclusion d’un contrat dérivé, etc. Les systèmes de gestion seront ainsi soulagés de la tâche qui leur est actuellement injustement attribuée, laquelle consiste à générer des événements non liés à la gestion, c'est-à-dire des événements techniques liés à des besoins purement comptables ou risques –le réescompte des intérêts courus non échus est un exemple de ces événements techniques purement comptables ne correspondant à aucun événement de gestion relatif à la vie du contrat. Ils pourront ainsi se concentrer sur leurs fonctions principales et gagner en efficacité. En contrepartie, ils devront fournir une information relative aux contrats suffisamment détaillée pour couvrir l’ensemble des besoins des différentes filières.
Filtrer l’information transmise
Cette information alimentera donc la base de données unique, ou base de « contrats », qui elle-même alimentera les applicatifs des filières comptable, risques et trésorerie situées en aval. Cette seconde alimentation sera cadencée par les événements de gestion et par les événements techniques purement comptables ou risques, événements que la base « contrat » devra donc être en mesure de générer. Une couche d’enrichissement entre la base « contrat » et les applicatifs situés en aval devra être implémentée pour transcoder les flux émis par la première en un langage compréhensible par les seconds (par exemple, ajout des comptes impactés et du sens débit/crédit pour les flux alimentant les systèmes comptables). Ces flux d’alimentation proposeront un niveau de détail calibré sur les besoins respectifs des filières finance, risques et trésorerie. Il sera en effet inutile de transmettre l’ensemble des informations contenues dans la base « contrat », dans la mesure où les systèmes situés en aval n’ont pas besoin de l’intégralité de l’information relative à chaque transaction ; de plus gérer une telle masse de données au niveau des systèmes aval alourdirait considérablement les traitements informatiques et le temps machine requis pour la réalisation des requêtes utilisateurs.
Pour réduire ses coûts
Un tel projet nécessite des investissements et peut sembler aujourd’hui antinomique avec une politique de réduction des coûts entreprise suivie par la majorité des établissements bancaires pour faire face à leur baisse de rentabilité. Mais une telle approche d’optimisation contribue parfaitement à court terme aux objectifs d’une politique de réduction des coûts. Par ailleurs, l’accélération du calendrier des réformes réglementaires (voir Graphique) constitue également une opportunité unique pour repenser en profondeur son système d’information. Il serait dommage de ne pas la saisir.
![[Web Only] Tarifs bancaires : les banques amortissent l’inflation](http://www.revue-banque.fr/binrepository/480x320/0c0/0d0/none/9739565/MEBW/gettyimages-968963256-frais-bancaires_221-3514277_20240417171729.jpg "[Web Only] Tarifs bancaires : les banques amortissent l’inflation")
