Val Kyrix

Banque privée

• déplacement d'un maximum de traitements data vers la base de données pour des gains de performance considérables et un meilleur suivi des data
• réécriture des procédures stockées, implémentation de fonctions .NET dans SQL Server, optimisation des tables (indexes, partitions)
• simplification du client lourd, gestion optimisée de la mémoire, passage en asynchrone et multi-threading, migration .NET 8.0 / WPF
• migration vers de nouveaux serveurs, processus complexe pour déplacer les applications sans interrompre les services ou casser des fonctionnalités
• migration de la messagerie Exchange vers le cloud Azure Office 365 et refonte des composants services sur la nouvelle architecture
• refonte de la gestion des droits SQL avec les groupes Active Directory, permissions au niveau des colonnes, dynamic masking pour les données confidentielles et hautement sensibles
• sécurisation et modernisation d'un code legacy, résolution des breaking changes, tests de non-régression, amélioration des livraisons pour plus de fluidité et de robustesse
• création d'API REST ASP.NET pour un nouveau backend et réduire les sollicitations directes aux bases de données
• interventions sur des outils Excel / VBA pour la clientèle
• interventions sur un module de passages d'ordres Bloomberg
• reportings cross-assets et indicateurs ESG
• transparisation des OPC multi-critères
• intégration des VL du valorisateur (C)
• transmission des virements au partenaire (N)

Risk / P&L

• L'objectif était de permettre aux équipes risk de calibrer et valider les paramètres pour obtenir les bons scénarios dans le cadre des stress tests.
• Il était techniquement irréaliste d'effectuer ces analyses directement avec la base Hadoop qui contenait tout l'historique des trades et des risks, surtout que plusieurs itérations sont nécessaires pour trouver les bons paramètres.
• L'existant permettait de construire des cubes OLAP (une itération) mais contenait trop d'erreurs d'intégration (trades manquants) et surtout il fallait plus de 100 heures pour obtenir des cubes partiels (quand il n'y avait pas de plantage), ce qui donnait une moyenne d'une livraison par mois et nuisait au travail des équipes risks qui souhaitaient pouvoir recalibrer tous les jours.
• Nous avons donc choisi de revoir tout le process et de tout simplifier pour découpler un maximum et optimiser chaque phase.
• À commencer par le module d'extraction des données qu'on a rendu indépendant et optimisé en requêtant plus intelligemment les scopes, et en rapatriant toutes les données brutes csv dans la base de données avec des bulk inserts massifs.
• Ensuite pour calculer les risks stressés on a mis en place un pipeline de calcul haute performance avec TPL Dataflow, les scénarios, et les librairies de pricing. Certaines fonctions .NET ont pu être implémentées directement dans SQL Server pour accroître davantage les performances.
• Tout cela nous permis de générer des cubes complets en moins de 12h et de livrer plusieurs fois par semaine.
• De mon côté j'ai eu un projet supplémentaire qui consistait en une extraction similaire pour identifier les trades sensibles. Cet outil a été réalisé en Python.

Cross Assets

• Une partie de la mission a consisté en de la maintenance évolutive, .NET Framework, WinForms, C#, Oracle.

• Participation aux campagnes de tests de non-régression pour assurer la fiabilité de l'application.
• Une autre partie de la mission, plus importante, a consisté à la reprise d'un outil utilisé par le front office pour le rebalancement des hedge funds, avec synchronisation des positions avec le client (L) et le clearer (C).
• L'outil en question était un outil stand-alone développé en ASP.NET Core Razor. Il était exploité quotidiennement par le trading, 3 fois par jour, pour couvrir les positions de (L) tout en optimisant certains paramètres comme la fiscalité, les dividendes, et en permettant de faire de l'arbitrage selon les assets, avec notamment des stratégies de prêt/emprunt. Outil extrêmement critique.
• À l'origine il était prévu d'intégrer cet outil dans (X) pour qu'il soit pris en charge par toute l'équipe (X). Toutefois, la criticité et les multiples défaillances de l'outil ont nécessité des interventions quotidiennes qui ont nui aux efforts de migration.
• Il est apparu par ailleurs que le niveau de performance exigé pour faire tourner l'outil n'était pas compatible avec les performances de (X) qui étaient bien en-deça.
• Finalement cette mission aura consisté en beaucoup de support niveau 1, astreintes, résolution de bugs et tentatives de migration.