What SEC Reg SCI Expects From Your Capacity and Stress Testing

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.

What This Guide Covers

1. Who Regulation SCI Applies To
2. Where Capacity and Stress Testing Fit Into Reg SCI
3. The Evidence an SCI Review Expects
4. How LoadView Supports Reg SCI Capacity and Stress Testing
5. Why Undersized or Protocol-Only Tests Don’t Satisfy a Reviewer
6. How to Produce Reg SCI-Ready Testing Evidence
7. How Often to Run Capacity and Stress Tests
8. What Reg SCI Requires You to Report
9. How Long to Keep the Records
10. The Bottom Line
11. Frequently Asked Questions

Who Regulation SCI Applies To

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:

• Self-regulatory organizations, including national securities exchanges, registered clearing agencies, FINRA, and the MSRB.
• SCI alternative trading systems, meaning larger ATSs that cross volume thresholds in NMS or non-NMS stocks.
• Plan processors and certain exempt clearing agencies.

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.

Where Capacity and Stress Testing Fit Into Reg SCI

Three parts of the rule drive testing work, and they reinforce each other:

• Rule 1001(a): capacity and resilience. Policies must ensure SCI systems have adequate capacity, and must include current and future capacity planning plus periodic capacity stress tests. This is the direct home of load and stress testing.
• Rule 1003(b): the annual SCI review. Each SCI entity conducts a review of its Reg SCI compliance at least once each calendar year, carried out by objective, qualified personnel, and covering systems penetration testing and an assessment of controls. Your capacity testing evidence is part of what that review examines.
• Rule 1004: business continuity and disaster recovery testing. SCI entities test their BC/DR plans, including participation by designated members or participants, at least once every 12 months.

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.

The Evidence an SCI Review Expects

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.

How LoadView Supports Reg SCI Capacity and Stress Testing

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.

Why Undersized or Protocol-Only Tests Don’t Satisfy a Reviewer

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.

How to Produce Reg SCI-Ready Testing Evidence

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:

1. Write capacity and performance requirements per system. Set peak message rate, latency ceilings, and an error-rate limit for each SCI system, get them approved, and enter them as pass/fail thresholds so results grade themselves.
2. Build the test to match the real interface. Drive order and market-data endpoints with web application load testing and API tests, and script member-facing portals with the EveryStep recorder so the web tier is exercised the way a participant uses it.
3. Test to projected peak, then past it. Configure load curve types to hold at projected peak for the capacity test, then a stepped curve beyond it for the stress test, covering both “can we handle the day” and “where do we break.”
4. Inject load from the regions you serve. Run from multiple US geo-distributed load injection zones so latency is measured where members actually connect.
5. Keep the report. Export the performance test reports with percentiles, throughput, error rates, load profile, and timestamp, and file them for the SCI review. Use the same reports to pinpoint performance bottlenecks when a run misses its bar.
6. Re-test on a schedule, after change, and for BC/DR. Repeat capacity stress tests after major systems changes and as message rates grow, and fold them into your CI/CD pipeline. Pair the load work with disaster recovery testing so the Rule 1004 exercise runs against a system you have already load-tested.

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.

How Often to Run Capacity and Stress Tests

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.

What Reg SCI Requires You to Report

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.

SCI Events on Form SCI

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.

Quarterly Material Systems Changes

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 Annual SCI Review Report

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.

How Long to Keep the Records

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:

• The dated performance reports, with response times, throughput, error rates, and the load profile that produced them.
• The capacity and performance requirements each test graded against.
• Capacity planning documents and the growth assumptions behind them.
• The remediation trail when a test found a bottleneck: what changed and the re-test result.
• The related Form SCI filings and the SCI review reports themselves.

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.

The Bottom Line

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.

Frequently Asked Questions