Ce que le règlement SEC Reg SCI attend de vos tests de capacité et de résistance

En vertu de Reg SCI, les preuves de capacité et de tests de résistance font partie de la revue annuelle SCI.

Pour les équipes de conformité et des systèmes des bourses américaines, des agences de compensation et d’autres infrastructures de marché couvertes par le Règlement SCI.

Le règlement Systems Compliance and Integrity (Reg SCI) de la SEC régit la technologie centrale des infrastructures de marché américaines depuis sa date de conformité du 3 novembre 2015. Il exige que les entités qui gèrent l’infrastructure du marché maintiennent leurs systèmes capables, résilients et disponibles, et qu’elles le prouvent. Les tests de capacité et de résistance sont au cœur de cette obligation.

La règle 1001(a) est le pilier. Elle exige des politiques et procédures écrites raisonnablement conçues pour assurer que les systèmes SCI disposent d’une capacité, intégrité, résilience, disponibilité et sécurité adéquates. La règle 1001(a)(2) nomme ensuite ce que ces politiques doivent couvrir, incluant la planification de la capacité actuelle et future et des tests périodiques de résistance de capacité pour confirmer que les systèmes peuvent traiter les transactions de manière précise, rapide et efficace.

La plupart des contenus sur Reg SCI en ligne sont rédigés par des cabinets d’avocats et ressemblent à un résumé de conformité. Cet article couvre le côté ingénierie que le résumé omet : quelles preuves de capacité et de test de résistance une revue SCI attend, et comment les produire avec un outil adapté. LoadView est une plateforme de tests de charge et de résistance basée sur le cloud, et les sections ci-dessous associent chaque élément recherché par un examinateur SCI à la capacité LoadView qui le génère.

Ce Que Ce Guide Couvre

1. À Qui S’Applique Le Règlement SCI
2. Où Les Tests de Capacité et de Résistance S’inscrivent Dans Reg SCI
3. Les Preuves Qu’Une Revue SCI Attend
4. Comment LoadView Soutient Les Tests de Capacité et de Résistance Reg SCI
5. Pourquoi Les Tests Sous-Dimensionnés Ou Seulement De Protocole Ne Convainquent Pas Un Examineur
6. Comment Produire Des Preuves De Test Prêtes Pour Reg SCI
7. À Quelle Fréquence Réaliser Les Tests De Capacité Et De Résistance
8. Ce Que Reg SCI Vous Oblige à Signaler
9. Combien De Temps Conserver Les Documents
10. En Résumé
11. Questions Fréquemment Posées

À Qui S’Applique Le Règlement SCI

Reg SCI ne s’applique pas à tous les participants du marché. Il s’applique aux « entités SCI », un ensemble défini qui gère les systèmes dont dépend le marché dans son ensemble :

• Organismes d’autorégulation, y compris les bourses nationales de valeurs, les agences de compensation enregistrées, FINRA et le MSRB.
• Systèmes alternatifs de négociation SCI, c’est-à-dire les ATS plus grands dépassant certains seuils de volumes sur les actions NMS ou non-NMS.
• Les planificateurs et certaines agences de compensation exemptées.

Les obligations dépendent de la centralité d’un système. La règle 1000 divise les systèmes en « systèmes SCI » et le sous-ensemble plus strict des « systèmes SCI critiques », les exigences les plus lourdes s’appliquant aux systèmes dont la panne perturberait le plus le marché. En 2023, la SEC a proposé des amendements pour élargir l’ensemble des entités concernées, donc une entreprise proche de la limite actuelle devrait suivre cette proposition plutôt que d’assumer qu’elle reste hors du champ d’application.

Où Les Tests de Capacité et de Résistance S’inscrivent Dans Reg SCI

Trois parties de la règle motivent le travail de test et se renforcent mutuellement :

• Règle 1001(a) : capacité et résilience. Les politiques doivent assurer que les systèmes SCI ont une capacité adéquate et inclure la planification de la capacité actuelle et future ainsi que des tests réguliers de résistance de capacité. C’est le cœur des tests de charge et de résistance.
• Règle 1003(b) : revue annuelle SCI. Chaque entité SCI réalise une revue de sa conformité au Reg SCI au moins une fois par an, menée par du personnel qualifié et objectif, couvrant les tests de pénétration des systèmes et une évaluation des contrôles. Vos preuves de test de capacité font partie de ce qui est examiné.
• Règle 1004 : tests de continuité des activités et de reprise après sinistre. Les entités SCI testent leurs plans BC/DR, y compris la participation des membres ou participants désignés, au moins une fois tous les 12 mois.

Pour un moteur de correspondance boursière, un système de compensation ou un flux de données de marché, « capacité adéquate » n’est pas un chiffre statique. Les taux de messages augmentent les jours volatils, les volumes d’options culminent aux échéances, et un simple événement d’actualité peut pousser le trafic de commandes bien au-delà d’une session normale. Reg SCI attend d’une entité SCI qu’elle planifie cette marge supplémentaire et fonde sa planification de capacité sur des limites mesurées, pas qu’elle découvre le plafond lors d’une montée en charge en direct.

Les Preuves Qu’Une Revue SCI Attend

Une revue SCI travaille à partir d’artefacts. Lorsqu’elle examine la capacité et la résilience, attendez-vous à ce qu’elle recherche des documents comme ceux-ci :

La première ligne est là où les programmes perdent le plus de terrain. Sans SLA de performance documentés, un test de résistance n’a pas de critère succès/échec, et un examinateur voit un graphique sans référence standard derrière. Écrivez d’abord les objectifs : taux de messages au pic par système, plafonds de latence à ce taux, et limite de taux d’erreur représentant un échec.

Les lignes deux et trois concernent le timing et la gravité. Le test de résistance avant un changement majeur montre que la capacité est vérifiée avant que le marché en dépende, et pousser au-delà des pics projetés transforme le point de rupture en un chiffre enregistré au lieu d’une surprise lors d’un début volatile. Les lignes quatre à sept forment le registre continu : rapports datés, planification actuelle et future de capacité, la traçabilité des corrections et retests quand un examinateur demande « qu’avez-vous fait à ce sujet », et un rythme qui suit la montée des volumes.

Comment LoadView Soutient Les Tests de Capacité et de Résistance Reg SCI

Chaque ligne de cette liste correspond à une fonction directe de LoadView. Le tableau associe l’artefact demandé par un examinateur à la capacité LoadView qui le produit.

Les systèmes SCI couvrent deux couches, et LoadView gère les deux. Pour les passerelles d’entrée de commandes, les flux de données de marché et les interfaces de compensation, les tests de charge API sollicitent les points de service au débit. Pour les systèmes orientés web qu’une entité SCI et ses participants gèrent (portails membres, tableaux de bord émetteurs et participants, sites de statut et de rapport), les tests de charge en navigateur réel mesurent ce que l’utilisateur expérimente effectivement. Et les tests de charge haute-concurrence permettent d’atteindre les taux de messages à l’échelle d’une bourse sur n’importe quelle couche.

Pourquoi Les Tests Sous-Dimensionnés Ou Seulement De Protocole Ne Convainquent Pas Un Examineur

Deux raccourcis de test affaiblissent les preuves qu’une revue SCI cherche à inspecter.

Le premier est de tester en dessous des pics réalistes. Un test de capacité qui plafonne près d’une session moyenne dit peu sur un début volatil ou un pic de jour d’échéance. Reg SCI demande une capacité couvrant le volume actuel et futur, donc le test doit atteindre le pic projeté et au-delà, ce que les tests de concurrence de transaction à débit produisent comme preuve fiable.

Le second est de ne mesurer que l’origine. Pour les systèmes orientés web en scope, un test uniquement protocolaire qui envoie des requêtes HTTP brutes rapporte le débit, pas ce qu’un membre voit. Il saute le JavaScript, la redirection d’authentification, et l’écran rendu. Les tests en navigateur réel font passer le flux par de vraies instances Chromium, donc les temps de réponse dans le rapport sont ceux que verrait un participant réel sous charge—le chiffre important pour savoir si les utilisateurs peuvent continuer à travailler lors d’un pic.

Un outil qui rapporte « un million de messages par seconde » informe un examinateur sur le débit brut. Il ne montre pas, à lui seul, que le moteur de correspondance est resté sous son plafond de latence ni que le portail membre est resté utilisable. Les preuves doivent mesurer ce que la règle demande.

Les tests de niveau protocole mesurent le point de terminaison ; les tests en navigateur réel mesurent le workflow côté membre sous charge.

Comment Produire Des Preuves De Test Prêtes Pour Reg SCI

Vous n’avez pas besoin d’une nouvelle catégorie d’outil pour satisfaire l’obligation de capacité. Vous avez besoin de tests compatibles avec la liste de preuves et d’un dossier à remettre à un examinateur. Voici la séquence dans LoadView :

1. Rédigez les exigences de capacité et de performance par système. Définissez le taux de messages au pic, les plafonds de latence et la limite du taux d’erreur pour chaque système SCI, faites-les approuver, et saisissez-les comme seuils de réussite/échec pour que les résultats s’évaluent automatiquement.
2. Construisez le test pour correspondre à l’interface réelle. Testez les points de terminaison des ordres et des données de marché avec des tests de charge d’application web et API, et créez des scripts pour les portails membres avec le registreur EveryStep pour que la couche web soit testée comme l’utilise un participant.
3. Testez jusqu’au pic projeté, puis au-delà. Configurez les types de courbes de charge pour maintenir le pic projeté lors du test de capacité, puis ajoutez une courbe graduée au-delà pour le test de résistance, couvrant à la fois « pouvons-nous gérer la journée » et « où cassons-nous ».
4. Injectez la charge depuis les régions que vous servez. Exécutez depuis plusieurs zones géodistribuées aux États-Unis pour mesurer la latence là où les membres se connectent réellement.
5. Conservez le rapport. Exportez les rapports de tests de performance avec percentiles, débit, taux d’erreur, profil de charge et horodatage, et conservez-les pour la revue SCI. Utilisez les mêmes rapports pour identifier les goulets d’étranglement quand un test ne passe pas le seuil.
6. Retestez selon un calendrier, après un changement, et pour BC/DR. Répétez les tests de résistance de capacité après des changements majeurs des systèmes et à mesure de la croissance des taux de messages, et intégrez-les dans votre pipeline CI/CD. Associez les tests de charge aux tests de reprise après sinistre pour que l’exercice de la règle 1004 s’appuie sur un système déjà testé en charge.

Parce que LoadView est entièrement hébergé dans le cloud, il n’y a pas d’infrastructure de génération de charge à déployer ou à justifier devant un examinateur, et les artefacts correspondent à ce qu’une revue SCI examine, dans l’ordre où elle les examine.

À Quelle Fréquence Réaliser Les Tests De Capacité Et De Résistance

Reg SCI précise certaines fréquences et laisse d’autres à l’appréciation basée sur le risque. Les éléments annuels sont fixés par la règle ; le rythme des tests de capacité est à votre discrétion dans la norme « périodique » utilisée par la règle.

Le terme utilisé par la règle pour les tests de capacité est « périodique », pas un intervalle fixe, donc la réponse qu’un examinateur accepte est celle que votre propre évaluation des risques soutient et que vos dossiers montrent que vous avez suivie. En pratique, de nombreuses entités effectuent des tests de résistance de capacité au moins une fois par an pour coïncider avec la revue SCI, plus souvent pour des systèmes avec des taux de messages en forte croissance ou volatiles, et toujours avant un changement important ou un pic connu comme un rééquilibrage d’indice ou une grande IPO. Un examinateur s’intéresse moins à un intervalle spécifique qu’à si le rythme correspond au risque et si vous l’avez respecté.

Ce Que Reg SCI Vous Oblige à Signaler

Les preuves de test ne restent pas dans un tiroir. Plusieurs obligations Reg SCI les transforment en quelque chose que vous déposez auprès de la SEC ou partagez avec les membres.

Événements SCI sur le formulaire SCI

Une panne causée par la capacité est une « perturbation des systèmes », un des trois types d’événements SCI avec les problèmes de conformité système et les intrusions système. Selon la règle 1002, dès que le personnel SCI responsable a une base raisonnable pour conclure qu’un événement SCI s’est produit, la procédure est lancée : notification rapide à la SEC, notification écrite sur le formulaire SCI dans les 24 heures, mises à jour jusqu’à résolution, et rapport final à la clôture de l’enquête. Les événements sans impact ou à impact négligeable sont rapportés trimestriellement, dans les 30 jours calendaires suivant la fin du trimestre, et la règle 1002(c) exige aussi le partage rapide d’informations sur les événements majeurs avec les membres ou participants concernés.

Les tests de capacité agissent sur ces deux fronts. Ils réduisent les chances d’une perturbation déclarable, et lorsqu’elle survient malgré tout, votre historique de tests fait partie du registre des causes racines sur lequel le rapport final se fonde.

Changments Matériels des Systèmes Trimestriels

Dans les 30 jours calendaires suivant chaque trimestre, une entité SCI dépose un rapport décrivant les changements matériels aux systèmes complétés, en cours et planifiés (règle 1003(a)). Le test de capacité que vous réalisez autour de chaque changement est la preuve que cela a été vérifié avant déploiement.

Rapport Annuel de la Revue SCI

La revue SCI est d’abord envoyée à la haute direction, puis l’entité soumet le rapport à la SEC avec toute réponse de la direction, dans les 60 jours calendaires suivant la soumission (règle 1003(b)). Vos rapports de tests de capacité et de résistance font partie des artefacts sur lesquels la revue s’appuie.

Combien De Temps Conserver Les Documents

Un rapport de test est utile comme preuve uniquement s’il existe encore lorsque l’examinateur le demande. La règle 1005 fixe le minimum de conservation.

Les entités SCI produisent, conservent et préservent les documents montrant leur conformité au Reg SCI. Pour les OAR SCI, la règle 1005 renvoie à la règle de tenue de registres OAR existante (règle 17a-1) ; pour les entités SCI non-OAR, elle fixe l’exigence directement. Dans tous les cas, la norme est de conserver les documents au moins cinq ans, dont les deux premières en accès facile.

Pour le travail de capacité, cela signifie conserver plus que la note de réussite ou échec :

• Les rapports de performance datés, avec temps de réponse, débit, taux d’erreur et profil de charge ayant produit ces mesures.
• Les exigences de capacité et de performance contre lesquelles chaque test a été évalué.
• Les documents de planification de capacité et les hypothèses de croissance associées.
• La traçabilité de remédiation lorsqu’un test a trouvé un goulot d’étranglement : ce qui a changé et le résultat du retest.
• Les dépôts du formulaire SCI liés et les rapports de revue SCI eux-mêmes.

Garder configurations et résultats de test en un lieu unique, exportable à la demande, transforme une règle de conservation de cinq ans d’une précipitation en une consultation simple. LoadView stocke les résultats de tests complétés et exporte le rapport à chaque exécution, ainsi l’artefact que vous déposez est le même que vous pourrez récupérer deux, trois ou cinq ans plus tard.

Voyez comment LoadView produit les preuves de tests de capacité et de résistance demandées lors d’une revue SCI. Planifiez une démo LoadView pour dimensionner un test selon vos pics de taux de messages et exporter les rapports que vos examinateurs demanderont.

En Résumé

Reg SCI ne vous fournit pas une liste de contrôle de test, mais la règle 1001(a)(2) inscrit la planification de capacité et les tests périodiques de résistance de capacité, et la revue annuelle SCI inspecte le résultat. Les systèmes importants sont ceux dont dépend le marché, et le critère est qu’ils traitent les transactions de manière précise et en temps réel sous charge réelle.

Fixez des objectifs de capacité et de latence, testez jusqu’au pic projeté et au-delà sur les couches API et web, enregistrez des rapports datés, et refaites des tests à la montée des taux de messages. LoadView génère chacun de ces artefacts à partir de tests que vous voudriez de toute façon exécuter, faisant de la revue SCI de votre travail de capacité une simple remise des dossiers que vous gardez déjà.

Questions Fréquemment Posées