Construire des systèmes financiers sécurisés qui résistent aux audits

Les systèmes financiers sécurisés ne se construisent pas en ajoutant la sécurité à la fin. C'est l'erreur la plus courante que je vois quand un engagement fintech commence : une équipe livre le produit principal, puis ajoute TLS, hache quelques mots de passe, et considère que c'est fait. Les auditeurs ne considèrent pas que c'est fait. Pas plus que les régulateurs qui, depuis janvier 2025, appliquent la loi européenne sur la résilience opérationnelle numérique avec des tests de pénétration menés par les menaces et des exigences strictes sur la chaîne d'approvisionnement des tiers ICT. La contrainte est réelle, et elle façonne chaque décision dès la première migration de schéma.

Le chiffrement n'est pas une fonctionnalité qu'on ajoute plus tard

Chaque plateforme financière que j'ai construite traite le chiffrement comme une infrastructure, pas comme un ticket de sprint. Les données en transit obtiennent TLS 1.2 au minimum, avec épinglage de certificat sur les clients mobiles quand le modèle de menace le justifie. Les données au repos obtiennent un chiffrement au niveau des champs sur tout ce qui se qualifie comme sensible selon la norme applicable, qu'il s'agisse de données de cartes PCI DSS, de détails de compte adjacents à PSD2, ou de numéros d'identification fiscale.

La plateforme de services financiers que j'ai construite pour un client fintech exécutait l'intégration de passerelle de paiement sur plusieurs banques acquéreuses. Les temps de réponse ont baissé de 30 pour cent après une refonte architecturale, mais la contrainte plus difficile était la justesse sous charge. Une transaction qui chiffre incorrectement ne fait pas que échouer. Elle peut corrompre une entrée de grand livre qu'un auditeur trouvera six mois plus tard. Donc la couche de chiffrement a été testée indépendamment, avec des vecteurs de texte chiffré connus, avant de toucher à tout trafic de production.

La gestion des clés est l'endroit où la plupart des équipes font des compromis. Faire tourner les clés sans interruption nécessite un magasin de clés versionnées et un chemin de migration pour les enregistrements existants. J'ai vu des équipes sauter cette étape et ensuite faire face à une constatation de conformité parce que leurs clés de chiffrement étaient plus anciennes que la fenêtre de rotation autorisée. Construisez le mécanisme de rotation avant d'en avoir besoin.

La conception pilotée par la conformité change le schéma

Les réglementations comme PCI DSS et DORA ne gouvernent pas seulement ce que vous chiffrez. Elles gouvernent ce que vous stockez, combien de temps vous le stockez, qui peut le lire, et quelle piste d'audit vous laissez derrière vous. Ces exigences doivent vivre dans le modèle de données, pas dans un document de politique.

Sur la plateforme OptimalTax, un système d'automatisation fiscale du secteur public, le moteur de calcul devait produire des résultats avec 99 pour cent de précision par rapport aux tables fiscales officielles. Ce nombre n'est pas du marketing. C'était un seuil contractuel avec l'autorité publique. Le schéma devait porter une piste d'audit complète : chaque entrée, chaque calcul intermédiaire, chaque sortie, avec horodatages et attribution d'utilisateur. Ajouter rétroactivement ce genre de journal d'audit à un schéma existant est coûteux. Le concevoir dès le départ coûte presque rien de plus.

Le même principe s'applique à la rétention des données. Les dossiers financiers ont des fenêtres de rétention obligatoires. Les données personnelles ont des fenêtres de rétention maximales selon le RGPD. Ces deux exigences peuvent entrer en conflit, et la résolution doit être codée dans le système, pas gérée par un processus manuel que quelqu'un oublie d'exécuter.

Analytique en temps réel sur les charges de travail transactionnelles

Une plateforme réglementée a toujours besoin d'être rapide. La conformité n'excuse pas les tableaux de bord lents ou les signaux de fraude retardés. Le défi architectural est que les charges de travail OLTP et les requêtes OLAP se battent pour les mêmes ressources si vous les laissez faire.

L'approche que j'utilise est la séparation des répliques de lecture avec un pipeline piloté par les événements alimentant un magasin analytique. Les opérations d'écriture frappent la base de données principale. Les analytiques gourmandes en lecture frappent une réplique ou un entrepôt dédié, alimenté par un flux d'événements de domaine. Cela garde le chemin transactionnel propre et donne à la couche analytique un schéma qu'elle peut optimiser indépendamment.

Sur la plateforme de paiements, cette séparation était ce qui rendait possible la notation de risque en temps réel. Les requêtes de détection de fraude pouvaient s'exécuter sur un flux d'événements dénormalisé sans verrouiller la table des comptes. La latence sur les décisions de risque a baissé à un niveau où l'équipe produit pouvait offrir une confirmation de paiement instantanée. C'est un résultat commercial, mais il a été rendu possible par une décision architecturale prise tôt dans la construction.

Ce que DORA exige vraiment des équipes d'ingénierie

La portée d'application de DORA est plus large que ce que la plupart des équipes d'ingénierie réalisent. Ce n'est pas seulement les systèmes propres de l'institution financière. Cela couvre chaque fournisseur tiers ICT dans la chaîne d'approvisionnement. Si vous construisez une plateforme qu'une entité réglementée utilisera, votre posture de sécurité fait partie de son obligation de conformité.

Cela signifie que vos dépendances comptent. Une bibliothèque de traitement des paiements avec une CVE connue est une constatation de conformité, pas seulement un élément de dette technique. Votre pipeline de déploiement compte. Un endpoint CI/CD non authentifié est un risque de chaîne d'approvisionnement selon le modèle de menace de DORA. Les tests de pénétration menés par les menaces, que DORA impose pour les institutions importantes, sonderont ces surfaces.

La réponse pratique est de traiter vos intégrations tierces avec le même examen que vous appliquez à votre propre code. Audits de dépendances à chaque construction. Artefacts signés. Infrastructure en tant que code qui peut être examinée et versionnée. Ce ne sont pas des pratiques exotiques. Ce sont les bases pour toute équipe opérant dans ou à proximité des marchés financiers européens réglementés.

Les systèmes financiers sécurisés ont besoin d'un propriétaire technique

La chose la plus difficile à propos de la construction dans ce secteur n'est pas le chiffrement ou la cartographie de la conformité. C'est l'attention soutenue. Un système financier sécurisé qui était correct en janvier peut avoir une constatation critique en juin si personne ne surveille l'arbre des dépendances, le calendrier de rotation des clés, ou les conseils réglementaires en évolution.

C'est l'argument en faveur d'un leadership technique qui reste proche du produit. Sur les engagements où j'ai servi en tant que CTO fractionnaire, la posture de conformité est un point à l'ordre du jour permanent, pas un livrable ponctuel. L'équipe a besoin de quelqu'un qui connaît à la fois le contexte réglementaire et la base de code assez bien pour repérer quand une refonte de routine crée une nouvelle exposition.

La fintech est le secteur où le coût d'une erreur est le plus lisible. Une clé de chiffrement mal configurée, un journal d'audit manquant, une bibliothèque tierce qui n'a pas été examinée : chacun de ces éléments a un nombre attaché, que ce nombre soit une amende, un coût de remédiation, ou un contrat d'entreprise perdu.

Si vous construisez dans cet espace et voulez voir comment ces décisions se sont déroulées en production, le travail fintech est un point de départ raisonnable. L'image plus complète de ce que j'ai construit dans tous les secteurs se trouve sur la page de travail. Si l'ajustement semble bon, le formulaire de contact est le moyen le plus rapide de commencer une conversation.