Comment la banque a-t-elle fait faillite ?

Comment la banque a-t-elle fait faillite ?

L’échec d’une migration de l’infrastructure informatique a entraîné la corruption de 1,3 milliard de dossiers clients bancaires. Tout cela était dû à des tests insuffisants et à une attitude frivole à l'égard des systèmes informatiques complexes. Cloud4Y raconte comment cela s'est produit.

En 2018 anglais Banque BST Il s'est rendu compte que son « divorce » de deux ans avec le groupe bancaire Lloyds (les deux sociétés ont fusionné en 1995) coûtait trop cher. TSB était toujours lié à son ancien partenaire par le biais de systèmes informatiques de Lloyds clonés à la hâte. Pire encore, la banque a dû payer une « pension alimentaire », soit des frais de licence annuels de 127 millions de dollars.

Peu de gens aiment donner de l'argent à leurs ex, c'est pourquoi le 22 avril 2018 à 18h00, le BST a entamé la dernière étape d'un plan de 18 mois censé tout changer. Il était prévu de transférer des milliards de dossiers clients vers le système informatique de la société espagnole Banco Sabadell, qui a racheté TSB pour 2,2 milliards de dollars en 2015.

Deux semaines avant Noël 2, le PDG de Banco Sabadell, José Olu, a parlé de l'événement à venir lors d'une réunion festive du personnel dans une prestigieuse salle de conférence de Barcelone. L'outil de migration le plus important devait être une nouvelle version du système développé par Banco Sabadell : Proteo. Il a même été renommé Proteo2017UK spécifiquement pour le projet de migration du TSB.

Lors de la présentation de Proteo4UK, le directeur exécutif de Banco Sabadell, Jaime Guardiola Romojaro, s'est vanté que le nouveau système est un projet à grande échelle sans équivalent en Europe, sur lequel ont travaillé plus de 1000 XNUMX spécialistes. Et que sa mise en œuvre donnera un élan significatif à la croissance de Banco Sabadell au Royaume-Uni.

Le 22 avril 2018 a été fixé comme jour de migration. C'était un dimanche soir tranquille au milieu du printemps. Les systèmes informatiques de la banque étaient en panne car les dossiers étaient transférés d'un système à un autre. Avec le rétablissement de l’accès du public aux comptes bancaires dimanche soir, on pourrait s’attendre à ce que la banque reprenne du service lentement et en douceur.

Mais alors qu'Olyu et Guardiola Romojaro diffusaient joyeusement depuis la scène la mise en œuvre du projet Proteo4UK, les employés responsables du processus de migration étaient très nerveux. Le projet, qui a duré 18 mois, accusait un retard considérable et dépassait le budget. Il n'y avait pas de temps pour effectuer des tests supplémentaires. Mais transférer toutes les données de l’entreprise (qui, rappelons-le, représentent des milliards d’enregistrements) vers un autre système est une tâche herculéenne.

Il s’est avéré que les ingénieurs étaient nerveux pour une bonne raison.

Comment la banque a-t-elle fait faillite ?
Un talon sur le site que les clients ont consulté trop longtemps

Vingt minutes après que le TSB ait ouvert l'accès aux comptes, étant pleinement convaincu que la migration s'était déroulée sans problème, les premiers rapports faisant état de problèmes sont arrivés.

Les économies des gens ont soudainement disparu de leurs comptes. Des achats de montants insignifiants ont été enregistrés par erreur comme des dépenses de plusieurs milliers de dollars. Certaines personnes se sont connectées à leurs comptes personnels et ont vu non pas leurs comptes bancaires, mais ceux de personnes complètement différentes.

À 21h00, des représentants du BST ont informé le régulateur financier local (la UK Financial Conduct Authority, FCA) que la banque était en difficulté. Mais la FCA l’a déjà remarqué : TSB a vraiment fait une grosse erreur et les clients ont été ridiculisés. Et bien sûr, ils ont commencé à se plaindre réseaux sociaux (et de nos jours, lâcher quelques lignes sur Twitter ou Facebook n'est pas particulièrement difficile). A 23h30, la FCA a été contactée par un autre régulateur financier, la Prudential Regulatory Authority (PRA), qui a également senti que quelque chose n'allait pas.

Bien après minuit, ils réussirent à joindre l'un des représentants de la banque. Et posez-leur la seule question : « qu’est-ce qui se passe ?

Il a fallu du temps pour comprendre l'ampleur de la tragédie, mais nous savons désormais que 1,3 milliard de dossiers de 5,4 millions de clients ont été endommagés lors de la migration. Pendant au moins une semaine, les clients n’ont pas pu gérer leur argent depuis leur ordinateur ou leur appareil mobile. Ils n’ont pas pu rembourser le prêt et de nombreux clients de la banque ont vu leur historique de crédit entaché, ainsi que des frais de retard.

Comment la banque a-t-elle fait faillite ?
Voici à quoi ressemblait la banque en ligne des clients TSB

Lorsque les problèmes ont commencé à apparaître, presque immédiatement après, les représentants des banques ont insisté sur le fait que les problèmes étaient « intermittents ». Trois jours plus tard, une déclaration a été publiée indiquant que tous les systèmes étaient normaux. Mais les clients ont continué à signaler des problèmes. Ce n'est que le 26 avril 2018 que le directeur général de la banque, Paul Pester, a admis que TSB était « à genoux » alors que l'infrastructure informatique de la banque continuait à rencontrer un « problème de bande passante » empêchant environ un million de clients d'accéder aux services bancaires en ligne.

Deux semaines après le début de la migration, l'application de banque en ligne rencontrait toujours des erreurs internes liées à la base de données SQL.
Les difficultés de paiement, notamment celles liées aux factures professionnelles et hypothécaires, ont persisté pendant quatre semaines. Et les journalistes omniprésents ont découvert que le TSB avait rejeté une offre d'aide du Lloyds Banking Group au tout début de la crise migratoire. De manière générale, des problèmes liés à la connexion aux services en ligne et à la possibilité de transférer de l'argent ont été observés jusqu'au 3 septembre.

Un peu d'histoire

Comment la banque a-t-elle fait faillite ?
Le premier guichet automatique a ouvert le 27 juin 1967 près de Barclays à Enfield

Les systèmes informatiques bancaires deviennent de plus en plus complexes à mesure que les besoins des clients et les attentes de la banque augmentent. Il y a environ 40 à 60 ans, nous aurions été heureux de nous rendre dans notre agence bancaire locale pendant les heures de bureau pour déposer de l'argent ou le retirer au caissier.

Le montant d’argent sur le compte était directement lié aux espèces et aux pièces que nous donnions à la banque. Notre comptabilité à domicile pouvait être suivie avec un stylo et du papier, et les systèmes informatiques n'étaient pas accessibles aux clients. Les employés de la banque ont placé les données des livrets et autres supports dans des appareils qui comptaient l'argent.

Mais en 1967, dans le nord de Londres, pour la première fois Etait installé un guichet automatique qui ne se trouvait pas dans les locaux de la banque. Et cet événement a changé le secteur bancaire. La commodité des utilisateurs est devenue une référence pour le développement des institutions financières. Et cela a aidé les banques à devenir plus sophistiquées dans leur travail avec les clients et leur argent. Après tout, alors que les systèmes informatiques n'étaient accessibles qu'aux employés de banque, ils se contentaient de l'ancienne façon « papier » d'interagir avec les clients. Ce n’est qu’avec l’avènement des distributeurs automatiques puis de la banque en ligne que le grand public a pu accéder directement aux systèmes informatiques des banques.

Les guichets automatiques n’étaient qu’un début. Bientôt, les gens ont pu éviter la file d'attente à la caisse en appelant simplement la banque par téléphone. Cela nécessitait des cartes spéciales insérées dans un lecteur capable de déchiffrer les signaux multifréquences à double tonalité (DTMF) transmis lorsque l'utilisateur appuyait sur la touche « 1 » (retirer de l'argent) ou « 2 » (dépôt de fonds).

Internet et les services bancaires mobiles ont rapproché les clients des systèmes centraux qui alimentent les banques. Malgré des limitations et des paramètres variables, tous ces systèmes doivent interagir efficacement les uns avec les autres et avec le mainframe, en vérifiant le solde des comptes, en effectuant des transferts d'argent, etc.

Peu de clients pensent à la complexité du chemin d'information lorsque, par exemple, vous vous connectez à une banque en ligne pour consulter ou mettre à jour les informations sur l'argent de votre compte. Lorsque vous vous connectez, ces données sont transmises via un ensemble de serveurs ; lorsque vous effectuez une transaction, le système duplique ces données dans l'infrastructure backend, qui fait ensuite le gros du travail : transférer de l'argent d'un compte à un autre pour payer des factures, effectuer des paiements. paiements et poursuivre les abonnements.

Multipliez maintenant ce processus par plusieurs milliards. Selon les données compilées par la Banque mondiale avec l'aide de la Fondation Bill & Melinda Gates, Pour cent 69 les adultes du monde entier ont un compte bancaire. Chacune de ces personnes a des factures à payer. Quelqu'un paie une hypothèque ou transfère de l'argent pour des clubs d'enfants, quelqu'un paie un abonnement Netflix ou loue un serveur cloud. Et tous ces gens utilisent plus d’une banque.

Les nombreux systèmes informatiques internes d’une banque (mobile banking, distributeurs automatiques, etc.) ne doivent pas simplement interagir les uns avec les autres. Ils doivent interagir avec d’autres systèmes bancaires au Brésil, en Chine et en Allemagne. Un guichet automatique français devrait pouvoir distribuer de l'argent se trouvant sur une carte bancaire émise quelque part en Bolivie.

L’argent a toujours été mondial, mais jamais le système n’a été aussi complexe. Le nombre de façons d'utiliser les systèmes informatiques bancaires augmente, mais les anciennes méthodes sont toujours utilisées. Le succès d'une banque dépend en grande partie de la « maintenabilité » de son infrastructure informatique et de l'efficacité avec laquelle la banque peut faire face à une panne soudaine à cause de laquelle le système sera inactif.

Aucun test - préparez-vous aux problèmes

Comment la banque a-t-elle fait faillite ?
Le PDG de Banco de Sabadell, Jaime Guardiola (à gauche), était convaincu que tout se passerait bien. N'a pas fonctionné.

Les systèmes informatiques du BST n'étaient pas très efficaces pour résoudre les problèmes rapidement. Il y a bien sûr eu des problèmes logiciels, mais en réalité la banque a « fait faillite » en raison de la complexité excessive de ses systèmes informatiques. Selon le rapport, préparé dès les premiers jours de la panne massive, « la combinaison de nouvelles applications, l’utilisation accrue de microservices combinées à l’utilisation de deux centres de données actifs/actifs ont conduit à des risques complexes en production ».

Certaines banques, comme HSBC, opèrent à l'échelle mondiale et disposent donc également de systèmes interconnectés très complexes. Mais ils sont régulièrement testés, migrés et mis à jour, selon un responsable informatique HSBC à Lancaster. Il considère HSBC comme un modèle sur la façon dont les autres banques devraient gérer leurs systèmes informatiques : en y consacrant du personnel et en y consacrant leur temps. Mais en même temps, il admet que pour une petite banque, en particulier celle qui n'a pas d'expérience en matière de migration, accomplir cette tâche correctement est une tâche très difficile.

La migration du TSB a été difficile. Et, selon les experts, le personnel de la banque ne pourrait tout simplement pas atteindre un tel niveau de complexité en termes de qualifications. De plus, ils n’ont même pas pris la peine de vérifier leur solution ou de tester la migration au préalable.

Lors d'un discours au Parlement britannique sur les problèmes bancaires, Andrew Bailey, directeur général de la FCA, a confirmé ces soupçons. Un mauvais code n’a probablement causé que les problèmes initiaux au TSB, mais les systèmes interconnectés du réseau financier mondial signifiaient que ses erreurs étaient perpétuées et irréversibles. La banque a continué de constater des erreurs inattendues ailleurs dans son architecture informatique. Les clients recevaient des messages dénués de sens ou sans rapport avec leurs problèmes.

Les tests de régression pourraient aider à prévenir un désastre en détectant le mauvais code avant qu'il ne soit mis en production et en causant des dommages en créant des bogues qui ne pourraient pas être annulés. Mais la banque a décidé de se lancer dans un champ de mines dont elle ignorait même l’existence. Les conséquences étaient prévisibles. Un autre problème était « l’optimisation » des coûts. Comment s’est-il manifesté ? Le fait est qu’il avait été décidé auparavant de supprimer les copies de sauvegarde stockées chez Lloyds, car elles « mangeaient » trop d’argent.

Les banques britanniques (et d'autres aussi) s'efforcent d'atteindre un niveau de disponibilité de quatre neuf, soit 99,99 %. En pratique, cela signifie que le système informatique doit être disponible à tout moment, avec jusqu'à 52 minutes d'indisponibilité par an. Le système des « trois neuf », 99,9 %, ne diffère pas beaucoup à première vue. Mais en réalité, cela signifie que le temps d’arrêt atteint 8 heures par an. Pour la banque, « quatre neuf » est une bonne chose, mais « trois neuf » ne l’est pas.

Mais chaque fois qu’une entreprise modifie son infrastructure informatique, elle prend des risques. Après tout, quelque chose peut mal tourner. Réduire les modifications peut aider à éviter les problèmes, tandis que les modifications requises nécessitent des tests minutieux. Et les régulateurs britanniques ont focalisé leur attention sur ce point.

Le moyen le plus simple d’éviter les temps d’arrêt consiste peut-être simplement à effectuer moins de modifications. Mais chaque banque, comme toute autre entreprise, est obligée d’introduire de plus en plus de fonctionnalités utiles pour ses clients et pour sa propre activité afin de rester compétitive. Dans le même temps, les banques sont toujours tenues de prendre soin de leurs clients, de protéger leur épargne et leurs données personnelles et d'offrir des conditions confortables d'utilisation des services. Il s’avère que les organisations sont obligées de consacrer beaucoup de temps et d’argent à maintenir la santé de leur infrastructure informatique, tout en proposant simultanément de nouveaux services.

Le nombre de défaillances technologiques signalées dans le secteur des services financiers au Royaume-Uni a augmenté de 187 % entre 2017 et 2018, selon les données publiées par la Financial Conduct Authority du Royaume-Uni. Le plus souvent, les échecs sont dus à des problèmes de fonctionnement de nouvelles fonctionnalités. Dans le même temps, il est essentiel que les banques garantissent le fonctionnement constant et ininterrompu de tous les services et un reporting quasi instantané des transactions. Les clients sont toujours nerveux lorsque leur argent traîne quelque part. Et un client nerveux à propos de l’argent est toujours un signe de problèmes.

Quelques mois après la faillite du TSB (au moment où le PDG de la banque avait démissionné), les régulateurs financiers britanniques et la Banque d'Angleterre a publié un document pour discuter des questions de durabilité opérationnelle. Ils ont donc essayé de poser la question de savoir jusqu’où les banques sont allées dans leur quête d’innovation et si elles peuvent garantir le fonctionnement stable du système dont elles disposent actuellement.

Le document proposait également des modifications à la législation. Il s'agissait de tenir les personnes au sein de l'entreprise responsables de ce qui ne va pas dans les systèmes informatiques de cette entreprise. Les parlementaires britanniques l'ont expliqué ainsi : « Lorsque vous êtes personnellement responsable et que vous pouvez faire faillite ou aller en prison, cela changera considérablement votre attitude à l'égard du travail, notamment en augmentant le temps consacré à la question de la fiabilité et de la sécurité. »

Les résultats de

Chaque mise à jour et chaque correctif se résume à une gestion des risques, surtout lorsque des centaines de millions de dollars sont impliqués. Après tout, si quelque chose ne va pas, cela peut coûter cher en termes d’argent et de réputation. Cela semble évident. Et l’échec de la banque lors de la migration aurait dû leur apprendre beaucoup de choses.

Avait. Mais il ne m’a pas appris. En novembre 2019, TSB, qui a retrouvé sa rentabilité et améliorait lentement sa réputation, a « ravi » ses clients nouvel échec dans le domaine des technologies de l'information. Le deuxième coup dur porté à la banque signifie qu’elle sera contrainte de fermer 82 succursales en 2020 pour réduire ses coûts. Ou il ne pouvait tout simplement pas économiser sur les informaticiens.

L’avarice en informatique a finalement un coût. Le BST a déclaré une perte de 134 millions de dollars en 2018, contre un bénéfice de 206 millions de dollars en 2017. Les coûts post-migration, y compris l'indemnisation des clients, la correction des transactions frauduleuses (qui ont fortement augmenté pendant le chaos bancaire) et l'assistance de tiers, se sont élevés à 419 millions de dollars. Le fournisseur informatique de la banque a également été facturé 194 millions de dollars pour son rôle dans la crise.

Cependant, quelles que soient les leçons tirées de la faillite bancaire du BST, des perturbations continueront de se produire. Ils sont inévitables. Mais avec des tests et un bon code, les plantages et les temps d’arrêt peuvent être considérablement réduits. Cloud4Y, qui aide souvent les grandes entreprises à migrer vers une infrastructure cloud, comprend l'importance de passer rapidement d'un système à un autre. Par conséquent, nous pouvons effectuer des tests de charge et utiliser un système de sauvegarde à plusieurs niveaux, ainsi que d'autres options qui vous permettent de vérifier tout ce qui est possible avant de commencer la migration.

Que pouvez-vous lire d'autre sur le blog ? Cloud4Y

L'énergie solaire salée
Les pentesters à la pointe de la cybersécurité
La théorie du grand flocon de neige
Internet sur des ballons
Des oreillers sont-ils nécessaires dans un centre de données ?

Abonnez-vous à notre Telegram-channel, pour ne pas rater le prochain article ! Nous n'écrivons pas plus de deux fois par semaine et uniquement pour affaires.

Source: habr.com

Ajouter un commentaire