Capital Markets – Pourquoi et comment mettre en place le contrôle des Static Data ?
Par définition, les Static Data concernent les données de marché dont la fréquence de mise à jour est faible à nulle c’est-à-dire que la donnée est rarement modifiée (Exemple : Isin, Devise d’instrument, classification, date de maturité pour une obligation, Ticker & Place pour une action...).
Qu’elles soient administrées dans un référentiel In-House, Solution Éditeur, Service externalisé…, nous vous donnons quelques raisons qui justifient la mise en place d’un contrôle des Static Data (S.D) :
- Risque opérationnel (impacts sur P&L et Indicateurs de risque) à la suite d’une erreur de S.D
- La complexité de la valorisation de certains actifs
- Les besoins règlementaires
- La certification interne des données pour avoir une gouvernance très claire
La phase de contrôle des S.D est une étape du cycle de vie de ces dernières. Nous vous proposons d’aborder ce cycle et de mettre en exergue les différents contrôles.
La demande de création d’un instrument pour un besoin d’investissement est un cas d’usage récurent d’intégration de S.D pour l’instrument, son émetteur dans une plateforme de data Management.
Le Cycle de vie des S.D se compose des phases :
Nous retenons donc 3 phases pour les contrôles :
Contrôle technique et normalisation des données :
Lors de cette étape, une vérification technique des données est effectuée à l’exemple des : formats de dates et montants, champs obligatoires par type d’instrument dans le dictionnaire de données, données en doublon, cohérence de certaines données...
Exemple : pour une obligation, les informations Isin*, devise, nominal, date d’émission, date de maturité ... sont obligatoires pour garantir l’affectation d’un identifiant d’instrument unique.
Aussi dans cette phase, les données seront normalisées (cas très fréquent en Multi-Sourcing) pour respecter le dictionnaire interne et avoir une référence unique.
A l’issue de cette étape, les données comportant des anomalies seront mises à l’écart et remontées en exception pour partage avec les utilisateurs.
(*) : A noter le cas particulier des émissions obligataires en marché primaire, le code Isin est potentiellement en cours de création ce qui nécessite un processus adapté pour la création de ces obligations dans votre référentiel. Un rapprochement permettra l’association de l’instrument initialement sans Isin et sa version avec Isin.
Pré-contrôle fonctionnel :
L’objectif de cette phase est de vérifier la cohérence des S.D.Certaines données seront contrôlées à travers des règles standards.
Exemple de règle dans le cadre de création, mise à jour d’une obligation :
- Isin valide ?
- LEI valide ?
- Date de coupon précèdent valide ?
- Cohérence Date d’émission-maturité ?
- Présence de l’émetteur dans le référentiel* ?
(*) : l’objectif de ce contrôle est de détecter la nécessité d’enrichir votre référentiel émetteur en synchronisation avec celui des instruments.
Contrôle de la version pré-validée des S.D :
Votre Silver copy, Pre Master à présent construite, vous pouvez procéder à des contrôles avant de promulguer cette version en Golden copy pour validation officielle.
Ces contrôles se focaliseront sur la variation des champs sensibles :
- Changement des champs (Isin, Devise, Ticker, Place...) utilisés pour générer un identifiant unique d’instrument.
- Changement des champs calculés (Classification d’instrument) ayant un impact fort sur votre référentiel et les systèmes asservis.
- Changement d’un lien externe : identifiant Issuer/Émetteur
Ce contrôle des champs sensibles en amont est crucial car dans la majorité des cas, la modification d’une static data sensible nécessitera la fermeture/réouverture des positions dans le système de tenue de position avec potentiellement des impacts sur le P&L.
A l’issue de cette étape, les données sans anomalies peuvent être automatiquement validées. Les données ayant un voir plusieurs contrôles en échec seront marquées pour validation manuelle. Cette dernière peut se décliner en :
- Rapprochement (Matching) de faux doublons.
- Chargement de données plus fiables et acceptées par une gouvernance interne.
- Acceptation de la donnée.
Conseil d’implémentation : regrouper vos contrôles dans une librairie pour faciliter la maintenance, l’enrichissement, la documentation.
Vous avez à présent un aperçu des phases de contrôles des Static Data pour transformer les données brutes en données Golden validées.
Nous restons à votre disposition pour échanger sur ce sujet, vous accompagner dans vos projets avec nos atouts : expertise, savoir-faire, divers retours d’expériences. Vous pouvez nous contacter : contact@neovd.fr
