Under Reg SCI, capacity and stress testing evidence is part of the annual SCI review.
For compliance and systems teams at US exchanges, clearing agencies, and other market infrastructures covered by Regulation SCI.
The SEC’s Regulation Systems Compliance and Integrity (Reg SCI) has governed the core technology of US market infrastructure since its compliance date on 3 November 2015. It requires the entities that run the market’s plumbing to keep their systems capable, resilient, and available, and to prove it. Capacity and stress testing sit near the center of that obligation.
Rule 1001(a) is the anchor. It requires written policies and procedures reasonably designed to ensure that SCI systems have adequate capacity, integrity, resiliency, availability, and security. Rule 1001(a)(2) then names what those policies must cover, including current and future capacity planning and periodic capacity stress tests to confirm the systems can process transactions in an accurate, timely, and efficient manner.
Most Reg SCI coverage online is written by law firms and reads like a compliance summary. This piece covers the engineering side that a summary skips: what capacity and stress testing evidence an SCI review expects, and how to produce it with a tool built for the job. LoadView is a cloud-based load and stress testing platform, and the sections below map each item an SCI reviewer looks for to the LoadView capability that generates it.
Reg SCI does not apply to every market participant. It applies to “SCI entities,” a defined set that runs systems the market as a whole depends on:
The obligations scale with how central a system is. Rule 1000 splits systems into “SCI systems,” and the tighter subset of “critical SCI systems,” with the heaviest requirements landing on the systems whose failure would most disrupt the market. In 2023 the SEC proposed amendments to widen the set of covered entities, so a firm sitting near the current boundary should track that proposal rather than assume it stays outside scope.
Three parts of the rule drive testing work, and they reinforce each other:
For an exchange matching engine, a clearing system, or a market-data feed, “adequate capacity” is not a static number. Message rates climb on volatile days, options volumes spike around expirations, and a single news event can push order traffic well past a normal session. Reg SCI expects an SCI entity to plan for that headroom and to ground its capacity planning in measured limits, not to discover the ceiling during a live surge.
An SCI review works from artifacts. When it examines capacity and resilience, expect it to look for records like these:
The first row is where programs lose the most ground. Without documented performance SLAs, a stress test has no pass/fail line, and a reviewer sees a chart with no standard behind it. Write the targets first: peak message rate per system, latency ceilings at that rate, and the error-rate limit that counts as a failure.
Rows two and three are about timing and severity. Stress testing before a major change shows capacity is checked before the market depends on it, and pushing past projected peaks turns the breaking point into a number you record rather than a surprise you meet on a volatile open. Rows four through seven are the ongoing record: dated reports, current and future capacity planning, the fix-and-re-test trail when a reviewer asks “what did you do about it,” and a cadence that keeps pace as volumes rise.
Each row of that list maps to something LoadView does directly. The table pairs the artifact a reviewer asks for with the LoadView capability that produces it.
SCI systems span two tiers, and LoadView covers both. For order-entry gateways, market-data feeds, and clearing interfaces, API load testing drives the service endpoints at rate. For the web-facing systems an SCI entity and its participants run (member portals, issuer and participant dashboards, status and reporting sites), real-browser load testing measures what a user actually experiences. And high-concurrency load testing is what puts exchange-scale message rates on either tier.
Two testing shortcuts weaken the evidence an SCI review is built to inspect.
The first is testing below realistic peaks. A capacity test that tops out near an average session says little about a volatile open or an expiration-day spike. Reg SCI asks for capacity that covers current and future volume, so the test has to reach projected peak and beyond, which is where transaction concurrency testing at rate produces evidence a reviewer can rely on.
The second is measuring only the origin. For the web-facing systems in scope, a protocol-only test that fires raw HTTP requests reports throughput, not what a member sees. It skips the JavaScript, the authentication redirect, and the rendered screen. Real-browser testing runs the flow through actual Chromium instances, so the response times in the report are the times a real participant would see under load—the number that matters when the question is whether people can keep working during a surge.
A tool reporting “one million messages per second” tells a reviewer about raw throughput. It does not, on its own, show the matching engine stayed within its latency ceiling or that the member portal stayed usable. The evidence has to measure the thing the rule cares about.
Protocol-level tests measure the endpoint; real-browser tests measure the member-facing workflow under load.
You do not need a new tool category to satisfy the capacity obligation. You need tests that map to the evidence list and a record you can hand to a reviewer. Here is the sequence in LoadView:
Because LoadView is fully cloud-hosted, there is no load-generation infrastructure to stand up or defend to a reviewer, and the artifacts line up with what an SCI review examines, in the order it examines them.
Reg SCI fixes some cadences and leaves others to a risk-based judgment. The annual items are set by rule; the capacity testing rhythm is yours to set within the “periodic” standard the rule uses.
The rule’s word for capacity testing is “periodic,” not a fixed interval, so the answer a reviewer accepts is one your own risk assessment supports and your records show you followed. In practice, many entities run capacity stress tests at least annually to line up with the SCI review, more often for systems with fast-growing or volatile message rates, and always ahead of a material change or a known peak event such as an index rebalance or a large IPO. A reviewer is less interested in a specific interval than in whether the cadence matches the risk and whether you kept to it.
Testing evidence does not stay in a drawer. Several Reg SCI obligations turn it into something you file with the SEC or share with members.
A capacity-driven outage is a “systems disruption,” one of the three SCI event types alongside systems compliance issues and systems intrusions. Under Rule 1002, once responsible SCI personnel have a reasonable basis to conclude an SCI event occurred, the sequence is set: prompt notification to the SEC, a written notification on Form SCI within 24 hours, updates until the event is resolved, and a final report after resolution and the close of the investigation. Events with no or de minimis impact are reported quarterly instead, within 30 calendar days of quarter-end, and Rule 1002(c) also requires promptly sharing information about major events with affected members or participants.
Capacity testing works both sides of this. It lowers the odds of a reportable disruption, and when one happens anyway, your test history is part of the root-cause record the final report is built on.
Within 30 calendar days after each quarter, an SCI entity files a report describing completed, ongoing, and planned material systems changes (Rule 1003(a)). The capacity test you run around each change is the evidence that it was checked before it shipped.
The SCI review goes to senior management first, and the entity then submits the report to the SEC, with any management response, within 60 calendar days of that submission (Rule 1003(b)). Your capacity and stress test reports are among the artifacts the review draws on.
A test report is only useful as evidence if it still exists when a reviewer asks for it. Rule 1005 sets the retention floor.
SCI entities make, keep, and preserve the records that show their Reg SCI compliance. For SCI SROs, Rule 1005 ties that to the existing SRO recordkeeping rule (Rule 17a-1); for SCI entities that are not SROs, it sets the requirement directly. Either way, the standard is to preserve the records for at least five years, with the first two years in a place that is readily accessible.
For capacity work, that means keeping more than the headline pass or fail:
Keeping test configurations and results in one place, exportable on demand, is what turns a five-year retention rule from a scramble into a lookup. LoadView stores completed test results and exports the report for each run, so the artifact you file is the same one you can retrieve two, three, or five years later.
See how LoadView produces the capacity and stress testing evidence an SCI review asks for. Schedule a LoadView demo to size a test for your peak message rates and export the reports your reviewers will ask for.
Reg SCI does not hand you a testing checklist, but Rule 1001(a)(2) puts capacity planning and periodic capacity stress tests in writing, and the annual SCI review inspects the result. The systems that matter are the ones the market depends on, and the standard is whether they process transactions accurately and on time under real volume.
Set capacity and latency targets, test to projected peak and beyond on both the API and web tiers, record dated reports, and re-test as message rates grow. LoadView generates each of those artifacts from tests you would want to run regardless, so an SCI review of your capacity work becomes a matter of handing over records you already keep.
In effect, yes. Rule 1001(a) requires policies and procedures reasonably designed to ensure SCI systems have adequate capacity, integrity, resiliency, availability, and security, and Rule 1001(a)(2) states those policies must include current and future capacity planning and periodic capacity stress tests to confirm the systems can process transactions in an accurate, timely, and efficient manner. Load and stress testing are the practical way to generate that evidence.
SCI entities include self-regulatory organizations such as national securities exchanges, registered clearing agencies, FINRA, and the MSRB, plus SCI alternative trading systems that meet volume thresholds, plan processors, and certain exempt clearing agencies. The SEC proposed amendments in 2023 to expand the set of covered entities, so firms near that boundary should track it.
An SCI review typically looks for documented capacity and performance requirements, capacity stress testing before major systems changes, peak and beyond-peak stress testing, test reports showing response times, throughput, and error rates, current and future capacity planning documentation, records of actions taken when bottlenecks were found, and periodic re-testing as volumes grow.
Rule 1003(b) requires an SCI review at least once each calendar year, and Rule 1004 requires business continuity and disaster recovery plan testing at least once every 12 months for designated members and participants. Capacity stress testing is periodic and should also follow major systems changes and volume growth.
Under Rule 1002, once responsible SCI personnel have a reasonable basis to conclude that an SCI event (a systems disruption, systems compliance issue, or systems intrusion) has occurred, the SCI entity notifies the SEC promptly, files a written notification on Form SCI within 24 hours, provides updates until the event is resolved, and submits a final report after resolution. Events with no or de minimis impact are reported quarterly, within 30 calendar days of quarter-end.
Rule 1005 requires SCI entities to make, keep, and preserve records of their Regulation SCI compliance for at least five years, with the first two years in a readily accessible place. For capacity work, that covers dated test reports, the requirements each test graded against, capacity planning documents, remediation records, and the related Form SCI and SCI review filings.
LoadView produces the capacity and stress testing evidence an SCI review asks for. It runs load and stress tests against web-facing SCI systems in real browsers and against order and market-data endpoints as API tests, shapes load with configurable load curves for peak and beyond-peak runs, injects load from multiple US regions, and exports timestamped performance reports with response times, throughput, and error rates for the review file.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。