![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| La norme
Bâle II impacte les SI et les processus bancaires
Après
l'euro et le passage à l'an 2000, l'informatique d'entreprise est
confrontée à de nouveaux chantiers : l'application des normes
comptables IAS et celle des normes Bâle II. Ceux-ci touchent autant
les systèmes d'information que les processus internes des entreprises.
Ces chantiers touchent non seulement les systèmes d'informations, mais aussi les processus internes des entreprises. Les banques seront, elles, doublement impactées puisque soumises aux deux nouvelles normes. Le comité de Bâle, émanation des pays du G10 (2) auxquels s'est associé le Luxembourg, a défini en 1988 les normes régissant le montant des fonds propres réglementaires pour les établissements financiers. La seconde version, dénommée Bâle II, est en cours de définition, et l'adoption des nouvelles normes est prévue pour fin 2003. Celles-ci sont basées sur les « best practices » des acteurs du domaine. Elles posent le principe d'une estimation précise des risques pour déterminer les ratios de fonds propres nécessaires, par opposition à l'approche forfaitaire de la version précédente (ratio Cooke). Selon Stéphane Le Blévec, consultant Bâle II chez SAS France, « la norme Bâle II introduit réellement une culture de la gestion du risque, risque de marché, risque de crédit et surtout risque opérationnel au sein des établissements financiers. Au-delà de l'aspect informatique, ce chantier concerne donc les processus en eux-mêmes et impacte les directions opérationnelles ». Les banques sont souvent inégales devant la gestion des risques : « si les établissements de crédit à la consommation ou certaines banques généralistes sont véritablement avancés dans ce domaine, d'autres ont des progrès à faire », confirme Philippe Bernard, consultant SAS. Une mise en application qui pourrait modifier les positions concurrentielles
des banques Ce principe pose néanmoins des problèmes concernant ses modalités d'application. Tout d'abord, il faut disposer de suffisamment de données historiques, ce qui peut défavoriser les banques les plus petites, et celles qui prennent le moins de risques (s'il n'y a pas suffisamment de défauts, le modèle ne fonctionne pas). Ensuite, il faut que ces données soient recueillies par le système d'information bancaire. Enfin, les données doivent être intégrées entre elles au sein d'un «datamart» risque. Ce dernier enjeu est crucial, en particulier dans le cas des grandes banques qui disposent souvent d'un système d'information très hétérogène évoluant depuis des dizaines d'années. Il faudra donc pouvoir transformer les données de leur format d'origine vers un format permettant leur insertion dans le « datamart ». Les banques auront tout de même le choix entre différents degrés de conformité à la norme, qui déterminent les types de données et la durée sur laquelle ces données doivent être recueillies. De plus, il peut s'avérer nécessaire de modifier les applications bancaires pour recueillir des données indispensables à la mise en place de ces modèles statistiques. Les problématiques de volumétrie entrent également en jeu, sachant que les «datawarehouse» contiennent souvent plusieurs teraoctets de données. Le choix des solutions et des outils d'intégration, ainsi que celui des collaborateurs devant conduire le chantier seront donc particulièrement importants dans l'optique d'une transition sans douleur. (1) Comité des Etablissements de Crédit et des Entreprises
d'Investissement
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
| Recherche | Données Personnelles | Mentions légales | Privacy Statement | Copyright 2008 SAS Institute Inc. All Rights Reserved |