L'entrée en vigueur de réglementations telles que MiFID II et Dodd-Frank approche, pourtant les établissements bancaires risquent fort de ne pas être prêts. Les régulateurs veulent que les banques soient en mesure de reconstituer leurs opérations. Malheureusement, sans les bons outils, cela revient à essayer de reconstituer un grain de raisin une fois le champagne en bouteille. Pour se conformer rapidement à des impératifs réglementaires exigeants et en évolution, il est indispensable que les données transactionnelles soient d'excellente qualité, accessibles et interrogeables.
Déployer un référentiel de transactions (c'est-à-dire une sorte de « caverne d'Ali Baba » où les données sont intégrées et stockées dans un seul endroit, avec une vue unique) permet aux banques de respecter plus facilement les réglementations existantes et à venir. En concentrant de vastes quantités de données transactionnelles structurées ou non dans un référentiel centralisé, il est possible de garder une trace uniforme, cohérente et transparente de chaque événement transactionnel afin de fournir aux auditeurs et aux régulateurs une piste d'audit complète.

Quelles règles doivent donc suivre le référentiel de transactions pour garantir la compilation en toute sécurité de données d'excellente qualité, qu'ils s'agisse d'informations financières ou concernant le risque ?

Règle numéro 1 : SQL/NoSQL

SQL ou NoSQL, telle est la question : tant les bases de données SQL que NoSQL (pas seulement SQL) ont leur place dans les banques et les institutions financières. Toutefois, dans l'environnement multi-format et multimédia actuel, où 80 % des données ne sont pas structurées, une base de données SQL conçue pour des données structurées peut-elle offrir l'agilité et la souplesse requises ?
La rigidité d'un modèle relationnel basé sur schéma ne se prête pas à la nature changeante, à la variété et à la complexité des données transactionnelles. Chaque système transactionnel distinct s'accompagne d'un nouveau schéma nécessitant de complexes interfaces pour rapprocher des champs disparates. Lorsque les inévitables changements se produisent, il suffit, au mieux, que tout soit à nouveau testé. Toutefois, le plus souvent, il est nécessaire de revoir la conception du tout au tout. Autre contrainte des bases de données relationnelles : les développeurs doivent déjà connaître le type de requêtes susceptible d'être effectué par la suite dès la phase de décision. Notre expérience a montré que les bases de données relationnelles ne disposent tout simplement pas de l'agilité requise pour intégrer les données stratégiques réparties sur plusieurs silos.

Il est bien entendu crucial de choisir l'option NoSQL la plus adaptée : les bases de données NoSQL ultra-flexibles sont légion, mais lorsqu'elles sont « open source », elles n'offrent pas toutes les fonctionnalités d'entreprise permettant de sécuriser les données et d'empêcher les modifications ou les pertes. Il s'agit notamment de la sécurité de classe gouvernementale, l'élasticité, la haute disponibilité, la reprise après sinistre avec réplication avancée ainsi que la conformité ACID, qui va devenir votre prochaine règle d'or.

Règle numéro 2 : conformité ACID

L'acronyme ACID (Atomicité, Cohérence, Isolation et Durabilité) fait référence à un ensemble de propriétés qui assurent la fiabilité du traitement des transactions d'une base de données. Les applications stratégiques, dont celles impliquant des données financières ou sensibles, exigent une cohérence transactionnelle. Les risques commerciaux associés aux systèmes non conformes aux propriétés ACID sont énormes, à moins que le service informatique ait les moyens d'entreprendre la mission extrêmement complexe et gourmande en ressources d'intégrer la conformité ACID à ses applications.
Une banque d'investissement majeure partenaire de MarkLogic traite plus de 100 000 transactions complexes par jour, ce qui se traduit en moyenne par 32 millions d'opérations actives à tout moment. Imaginez la pagaille si les données de cette institution n'étaient pas tenues constamment à jour, 100 % exactes et entièrement cohérentes.

Règle numéro 3 : évolutivité

Grâce au référentiel de transactions, non seulement les banques peuvent éviter de lourdes amendes réglementaires, mais aussi faire des économies, car elles n'ont plus besoin de développer et de tenir à jour plusieurs systèmes différents. Dans le nouvel univers Enterprise NoSQL, la plate-forme s'appuie sur une architecture de base mise à l'échelle. Résultat ? Un coût de transaction réduit. Autre avantage : le référentiel de transactions permettant une meilleure gestion des risques, le capital que doit posséder la banque pour satisfaire les autorités de régulation est en général moins élevé.
Par ailleurs, le système peut également être rapidement adapté, étendu et optimisé pour répondre à l'évolution des besoins réglementaires et de l'activité sans avoir à refondre les schémas ou recommencer le processus Extraire, Transformer et Charger (ETL,Extract/Transform/Load) .

Règle numéro 4 : sémantique

L'agrégation de données financières et de risques d'excellente qualité est l'un des impératifs du nouvel environnement réglementaire bancaire. La sémantique facilite la localisation des faits et des relations cachés, la création de concepts et de catégories, ainsi que la mise en contexte.
Vous pouvez ainsi prendre des décisions plus éclairées, minimiser les risques et transmettre des informations plus précises en alliant documents, informations et données liées dans une architecture unique.

Règle numéro 5 : recherche

La fonction de recherche, tout comme la possibilité d'interroger les données, est une composante essentielle des logiciels de base de données. En effet, à quoi bon regrouper toutes ses informations dans les moindres détails, si elles sont complètement inexploitables faute de pouvoir les localiser ?
Avec une base de données dotée d'une fonction de recherche « native », les banques et institutions financières peuvent tirer parti des pétaoctets de données stockées sur plusieurs systèmes existants, car elles ont accès à des informations et résultats exploitables. En revanche, une solution de recherche « en pièce rapportée » est susceptible de retarder les résultats, faire baisser les performances et la précision et opacifier les nuances des données, dans la mesure où celles-ci doivent être déchiquetées. Cela vaut également pour les fonctionnalités de recherche tierces.
En modernisant la recherche et l'analyse de ses données transactionnelles et KPI, une autre banque internationale partenaire de MarkLogic a pu bénéficier de nouveaux atouts en termes de stratégie d'entreprise, tels que la découverte de tendances dans le processus transactionnel.

Règle numéro 6 : bitemporalité

En conjuguant innovation technologique et analyses bancaires, une banque d'investissement de premier plan qui travaille avec MarkLogic au déploiement d'un référentiel de transactions, s'est aperçu qu'il serait bientôt essentiel de savoir très précisément quelles informations étaient disponibles à quel moment. Suite à cette prise de conscience, une nouvelle fonctionnalité à l'importance croissante, appelée « gestion bitemporelle des données », a été mise au point. La fonction bitemporelle de MarkLogic permet aux banques d'atténuer les risques « en remontant dans le temps par la technologie ». L'horodatage et la consultation des différentes versions d'un document permet d'identifier les changements et de suivre l'évolution des données au fil du temps sans avoir à recharger les versions de sauvegarde. Ce processus est crucial pour maintenir et démontrer la conformité aux processus d'analyse des données Dodd-Frank, par exemple.
Les fonctions bitemporelles donnent aux banques et institutions financières les moyens de respecter les exigences réglementaires, fournir une piste d'audit claire et améliorer la gestion des risques ainsi que l'analyse décisionnelle, tout en faisant des économies.

Serez-vous prêt ?

Les banques doivent agir dès maintenant pour mettre de l'ordre dans leurs déclarations numériques et échapper à de lourdes amendes, parfaitement évitables.
Quelques-unes des principales banques mondiales ont déjà déployé avec succès des référentiels de transactions avec une base de données NoSQL pour rationaliser leurs rapports réglementaires. Dans la foulée, elles ont également créé de nouveaux services générateurs de revenus, diminué leurs risques et amélioré leurs processus.
Il est vrai que les régulateurs s'intéressent plus au résultat qu'au parcours suivi pour y parvenir : la possibilité de vérifier chaque donnée (des historiques de conversations sur messagerie instantanée aux analyses en passant par les transactions individuelles) à tout moment. Cela dit, un référentiel de transactions qui s'appuie sur une base de données NoSQL Enterprise n'en reste pas moins une solution éprouvée, au développement et au déploiement rapides.

Afin de minimiser les risques et maintenir la conformité, votre base de données doit pouvoir respecter ces règles d'or : conformité ACID, bitemporalité, NoSQL, recherche, sémantique et évolutivité.

Lisez gratuitement :

FINYEAR

Le quotidien Finyear :
- Finyear Quotidien

Sa newsletter quotidienne :
- Finyear Newsletter
Recevez chaque matin par mail la newsletter Finyear, une sélection quotidienne des meilleures infos et expertises en Finance innovation & Digital transformation.

Ses 5 lettres mensuelles digitales :
- Le Directeur Financier
- Le Trésorier
- Le Credit Manager
- The Chief FinTech Officer
- The Chief Digital Officer

Finyear magazine trimestriel digital :
- Finyear Magazine

Un seul formulaire d'abonnement pour choisir de recevoir un ou plusieurs médias Finyear

BLOCKCHAIN DAILY NEWS

Le quotidien Blockchain Daily News :
- Blockchain Daily News

Sa newsletter quotidienne :
- Blockchain Daily News Newsletter
Recevez chaque matin par mail la newsletter Blockchain daily News, une sélection quotidienne des meilleures infos et expertises en Blockchain révolution.

Sa lettre mensuelle digitale :
- The Chief Blockchain Officer