Contrôles de risque pre-trade dans le chemin de l'ordre

Un ordre arrive à la gateway. Avant de partir vers la place de marché, quelque chose doit décider si le compte a le droit de l'envoyer. Cette décision s'exécute sur chaque ordre, y compris l'immense majorité qui est parfaitement saine : son coût est payé par tout le trafic normal, et pas seulement par les rejets.

C'est la contrainte à nommer en premier. Un contrôle de risque placé dans le chemin de l'ordre est une taxe sur la saisie d'ordres. La question d'ingénierie n'est pas de rendre le contrôle astucieux, mais de le rendre assez petit pour que les traders ne le sentent pas, et assez honnête pour qu'il refuse encore les ordres qu'il doit refuser.

Ce qui a réellement sa place dans le chemin de l'ordre

Le hot path répond à exactement une question : cet ordre peut-il être envoyé maintenant, au vu de ce que nous savons actuellement de ce compte. Les contrôles qui répondent à cette question restent dedans. Ceux qui répondent à une autre question sortent.

• Limites de position et d'exposition - la position résultante sur l'instrument, le groupe et le compte, comparée aux bornes configurées
• Marge ou pouvoir d'achat - si le compte a encore de la place pour l'ordre sous le modèle de marge courant
• Bornes fat-finger - taille d'ordre, notionnel et écart de prix par rapport à une référence, pour attraper la faute de frappe avant la place de marché
• État de l'instrument et du compte - négociation suspendue, compte restreint, close-only, produit non activé pour ce compte
• État du kill switch - un unique drapeau qui prime sur tout ce qui précède
• Garde-fous contre les doublons et le self-trade là où la place de marché n'en fournit pas

Tout le reste tourne à côté du chemin, sur le même état, sans retenir l'ordre. Cela alimente les limites que le hot path applique, mais ne se place pas entre le trader et la place de marché.

• Analytique de risque de portefeuille - scénarios, stress tests, exposition corrélée entre comptes
• Le re-calibrage du modèle de marge quand les paramètres changent, et tout recalcul qui touche l'ensemble du carnet
• La surveillance et la détection de motifs, qui exigent un historique que le hot path ne porte délibérément pas
• Le reporting, la réconciliation et tout ce qui parle à une base de données ou à un service externe
• L'examen du crédit et de la contrepartie, qui opère par nature sur une horloge plus lente

Où vit l'état des positions, et pourquoi la base n'est pas sur le chemin

L'état dont un contrôle pre-trade a besoin - positions courantes, ordres en cours, marge utilisée et disponible, configuration des limites - vit dans la mémoire du processus qui prend la décision. Pas dans un cache devant une base, pas derrière un appel réseau. Dans le processus.

La raison n'est pas seulement la vitesse, même si une requête est des ordres de grandeur plus coûteuse qu'une lecture dans un tableau local. La raison, c'est la justesse. Une base détient la position telle qu'elle a été écrite. Le contrôle de risque a besoin de la position incluant les ordres envoyés il y a un instant, pas encore exécutés, acquittés ni persistés. Si vous lisez depuis le stockage, vous vérifiez contre un passé déjà dépassé par votre propre flux.

En pratique, cela façonne le processus comme tout composant à faible latence :

• Un seul écrivain par compte. Les comptes sont shardés entre les instances de risque pour que l'état d'un compte ne soit jamais en contention, et aucun verrou n'est pris sur le chemin de l'ordre
• Structures plates et préallouées - tableaux de taille fixe indexés par id de compte et d'instrument, résolus au démarrage de la session, et non des recherches de hash sur des chaînes construites par ordre
• Aucune allocation, aucune E/S et aucun log bloquant sur le chemin de décision ; l'enregistrement d'audit est confié à un autre thread via une file
• La configuration qui change sans redémarrage est basculée comme un instantané immuable entier, pour que le contrôle ne lise jamais une limite à moitié mise à jour

La base de données est l'endroit où la position est enregistrée. Ce n'est pas l'endroit où la position est connue.

Recalcul incrémental, pas une passe complète

Un recalcul complet de l'exposition et de la marge d'un compte parcourt chaque position et chaque ordre en cours. Ce coût croît avec la taille du carnet, ce qui rendrait le contrôle de risque plus lent précisément pour les clients qui négocient le plus. Le hot path ne recalcule donc pas. Il applique un delta.

Le compte porte des agrégats courants - exposition nette et brute par instrument et par groupe, marge utilisée, notionnel en vol. Un ordre entrant produit un petit changement de ces agrégats, les valeurs modifiées sont comparées aux limites, et l'ordre est accepté ou rejeté. Le travail est proportionnel à l'ordre, pas au portefeuille.

• À l'envoi, l'effet le plus défavorable de l'ordre est réservé sur les agrégats, pour que deux ordres en vol ne puissent pas tenir tous les deux dans la même marge restante
• En cas de rejet, d'annulation ou d'expiration, la réservation est libérée ; en cas d'exécution, elle est remplacée par la variation de position réalisée
• Les exécutions partielles ajustent les deux côtés en une seule étape, et c'est là que vivent réellement la plupart des bugs de ce genre de moteur
• Les règles de netting et de regroupement sont résolues au chargement de l'instrument, pas par ordre : le delta se réduit à une poignée d'opérations arithmétiques

Le recalcul complet a toujours lieu - selon une planification, quand les paramètres de marge changent, et comme auto-contrôle périodique face au résultat incrémental. Il tourne hors du chemin, sur une copie, et son résultat est soit basculé, soit signalé comme écart. Un état incrémental qui dérive silencieusement de l'état réel est pire que pas de contrôle du tout : la comparaison n'est donc pas optionnelle.

Le kill switch est un chemin séparé

Un kill switch sert précisément quand quelque chose va déjà mal. Cela exclut de le bâtir sur la machinerie qui peut elle-même être en cause. C'est un chemin séparé, avec ses propres règles.

• C'est un unique drapeau atomique lu en tête du contrôle, avant de toucher l'état des positions, la marge ou les données d'instrument - il fonctionne donc même quand celles-ci sont périmées, absentes ou cassées
• Il est déclenché par plusieurs sources indépendantes : une action d'opérateur, une condition automatisée, la perte du flux de données de marché ou d'exécutions dont dépend l'état de risque
• Il échoue en position fermée. Si le processus de risque ne peut pas établir qu'il détient un état valide, la gateway se comporte comme si le switch était activé
• Il a des portées - toute la firme, un desk, un compte, une stratégie - parce qu'un switch qui ne peut que tout arrêter est utilisé trop tard
• L'activer tient en une action et une confirmation, pas en un déploiement de configuration ; le désactiver est délibéré et toujours consigné

Arrêter les nouveaux ordres est la moitié facile. La moitié difficile, c'est ce que le switch fait aux ordres déjà en attente sur la place de marché : retirer les cotations et annuler les ordres en cours doit rester possible pendant que le chemin d'envoi est désactivé. Ce chemin d'annulation mérite ses propres tests, car il est exercé le pire jour, pas un jour normal.

Le redémarrage, et comment l'état revient

L'état en mémoire est une vue dérivée d'un enregistrement durable. C'est ce qui rend un redémarrage survivable. Chaque événement qui change l'état de risque - un ordre accepté, une réservation libérée, une exécution appliquée, une limite modifiée, le switch activé - est ajouté à un journal sur la machine locale avant toute action en aval.

• Au démarrage, le processus rejoue le journal pour reconstruire les agrégats, puis se réconcilie avec la place de marché et la drop copy de compensation pour les positions et les ordres en cours
• Tant que la réconciliation n'est pas terminée, le compte n'est pas ouvert à la négociation. Un moteur de risque qui accepte des ordres alors qu'il cherche encore la position n'est pas un moteur de risque
• Un écart entre l'état rejoué et la vue de la place de marché arrête ce compte et lève une alerte ; il n'est jamais résolu en privilégiant discrètement un côté
• Un hot standby suit le même journal : un failover restaure un état chaud au lieu d'un replay à froid, et le standby est vérifié en étant promu régulièrement plutôt qu'en théorie

Le temps de reprise dépend alors de la longueur du journal et de la disponibilité de la drop copy, pas de la taille du carnet, et le mode de défaillance de chaque inconnue est le même : refuser de trader le compte.

Ce que cette conception ne vous donne pas

Les limites honnêtes méritent d'être dites clairement, car elles décident si cette architecture convient tout court :

• Le contrôle n'est correct que dans la mesure où le flux d'exécutions l'est. Si la drop copy ou les rapports d'exécution prennent du retard, l'exposition est sous-estimée, et la bonne réponse est de basculer vers des limites conservatrices ou d'activer le switch plutôt que de continuer à trader sur un état périmé
• Les modèles de marge de portefeuille réellement non additifs résistent à l'évaluation incrémentale. Ce qui marche : une borne incrémentale conservatrice sur le chemin plus un modèle complet hors du chemin ; le prix à payer est que certains ordres sont rejetés alors qu'un modèle complet les aurait autorisés
• Le switch protège de votre propre flux, pas du marché. Il ne peut pas empêcher un gap ou un slippage sur des positions que vous détenez déjà
• Un état in-process signifie que le moteur de risque et la gateway d'ordres partagent le même sort. Cela achète de la latence et vous coûte la possibilité de les mettre à l'échelle indépendamment
• Le sharding à écrivain unique par compte complique les limites inter-comptes, et les contrôles à l'échelle de la firme exigent une couche d'agrégation plus lente, avec sa propre péremption
• C'est plus de travail opérationnel qu'un contrôle adossé à une base : journaux, réconciliation, exercices de promotion du standby. Si la saisie d'ordres n'est pas sensible à la latence, cette complexité ne vaut pas son prix

amBrain construit ce type de chemin de risque pre-trade pour des brokers et des prop firms, avec les hot paths écrits en Rust. L'équipe travaille sur des infrastructures de trading depuis Erevan, en Arménie, depuis 2019.