alternative trading system'' is appropriate? Why or why not? Do
commenters believe that the proposed volume thresholds for the
different asset classes under the proposed definition of SCI ATS are
appropriate? Specifically, are the proposed average daily dollar volume
thresholds of five percent or more in any NMS stock and 0.25 percent or
more in all NMS stocks, or one percent or more in all NMS stocks,
appropriate? Would higher or lower daily dollar volume thresholds for
NMS stocks be more appropriate? \136\ Please explain and provide data
in support. Alternatively, would a different threshold measurement be
more appropriate (e.g., transaction volume, share volume, etc.)? If so,
which and at what threshold level? \137\ Please explain and provide
data in support.
---------------------------------------------------------------------------

    \136\ For example, based on data from FINRA's Order Audit Trail
System, if the threshold were instead to be set at five percent or
more in any NMS stock and 0.5 percent or more in all NMS stocks, the
Commission preliminarily estimates that approximately nine ATSs
would satisfy the thresholds, accounting for approximately 84
percent of the dollar-volume market share of all ATSs trading NMS
stocks (i.e., not including NMS stocks traded on SROs). If the
threshold were instead to be set at five percent or more in any NMS
stock and one percent or more in all NMS stocks, the Commission
preliminarily estimates that approximately three ATSs would satisfy
the thresholds, accounting for approximately 38 percent of the
market share. Further, if the threshold were instead to be set at
0.25 percent in all NMS stocks, the Commission preliminarily
estimates that approximately ten ATSs would satisfy the threshold.
If the threshold were instead to be set at 0.5 percent in all NMS
stocks, the Commission preliminarily estimates that approximately
nine ATSs would satisfy the threshold.
    \137\ For example, based on data collected from Form ATS-R for
the second quarter of 2012 and consolidated NMS stock share volume
from the first six months of 2012, if the threshold were instead to
be set at 0.25 percent of average daily NMS stock consolidated share
volume, the Commission preliminarily estimates that approximately 15
ATSs would satisfy the threshold, accounting for approximately 14
percent of the total average daily consolidated share volume. If the
threshold were instead to be set at 0.5 percent of average daily NMS
stock consolidated share volume, the Commission preliminarily
estimates that approximately 12 ATSs would satisfy the threshold,
accounting for approximately 13 percent of the total average daily
consolidated share volume. If the threshold were instead to be set
at one percent of average daily NMS stock consolidated share volume,
the Commission preliminarily estimates that approximately 6 ATSs
would satisfy the threshold, accounting for approximately nine
percent of the total average daily consolidated share volume. Based
on consolidated NMS stock share volume from the first six months of
2012, the Commission estimates that the equity securities exchanges
with the smallest volume each account for approximately 0.2 percent
to 0.4 percent of the total average daily consolidated share volume.
---------------------------------------------------------------------------

    4. The Commission notes that, unlike the threshold levels
applicable to NMS stocks currently in Rule 301(b)(6) of Regulation ATS,
the proposed thresholds for NMS stocks are based on average daily
dollar volume in an individual NMS stock and/or all NMS stocks. Do
commenters believe that these are appropriate standards? Why or why
not? If not, what should be the appropriate standard, and why? Do
commenters believe the proposed thresholds of five percent or more in
any NMS stock and 0.25 percent or more in all NMS stocks would prevent
a situation in which an ATS that has a large volume in one NMS stock
and little volume in other NMS stocks would be covered by proposed
Regulation SCI? How common is it for an ATS to trade illiquid NMS
stocks without also trading more liquid NMS stocks? Please provide any
data relevant to this question.
    5. Should the SCI ATS thresholds be triggered only with respect to
certain NMS stocks, for example, only with respect to the most liquid
NMS stocks? If so, how should the Commission define the ``most liquid''
NMS stocks? For example, should the thresholds be triggered only for
the 500 most liquid NMS stocks? The 100 most liquid NMS stocks? Another
amount? Why or why not? Please describe your reasoning. Further, what
would be the appropriate threshold measurement (e.g., average daily
share volume, average daily dollar volume, or another measurement)?
Please explain.
    6. Is the proposed five percent threshold level appropriate for
non-NMS stocks, municipal securities (approximately $550 million in
daily dollar volume or 1,900 in daily transaction volume based on data
from the first six months of 2012), and corporate debt securities
(approximately $900 million in daily dollar volume or 2,100 in daily
transaction volume based

on data from the first six months of 2012)? Why or why not? Please
explain and provide data in support. If not, what should be the
appropriate thresholds and why?
    7. As with NMS stocks, the proposed five percent thresholds for
non-NMS stocks are to be calculated by reference to daily dollar
volume, though the proposed threshold would only be with reference to
all such stocks (as opposed to average daily dollar volume in
individual NMS stocks and/or all NMS stocks). Do commenters believe
that this is the appropriate standard for non-NMS stocks? Why or why
not?
    8. Do commenters agree with the Commission's assessment that there
is less automation among markets that trade non-NMS stocks, municipal
securities, and corporate debt securities as compared to markets that
trade NMS stocks? Why or why not? What is the current level of
automation in these markets?
    9. Do commenters believe that there should be different thresholds
for NMS stocks than non-NMS stocks, municipal securities, and corporate
debt securities? Why or why not? Do commenters believe that the
proposed two-pronged thresholds are appropriate for municipal
securities and corporate debt securities? Why or why not? Would the
proposed two-pronged approach be relevant or appropriate for securities
other than municipal and corporate debt securities? Why or why not?
    10. Do commenters believe that the Commission's estimates of the
current number of ATSs that would meet the proposed thresholds are
accurate? Why or why not? If not, please provide any data or estimates
that commenters believe would more accurately reflect the number of
ATSs that would meet the proposed thresholds.
    11. The Commission is also considering whether it should instead
adopt a definition for SCI ATS that is based solely on a single type of
threshold measurement (such as average daily dollar volume), which
would be simpler and provide consistency across different asset
classes, rather than the differing types of threshold tests for NMS
stocks, non-NMS stocks, municipal securities, and corporate debt
securities currently proposed. In particular, the Commission is
considering whether it would be appropriate to solely use a threshold
based on a percentage of average daily dollar volume for all asset
classes. Would a threshold based on a percentage of average daily
dollar volume be an appropriate single measure that the Commission
should use for all asset classes (i.e., NMS stocks, non-NMS stocks,
municipal securities, and corporate debt securities) within the
definition of SCI ATS? Why or why not? If so, would it be appropriate
for the Commission to adopt the same dollar volume threshold
measurement that applies for all of the asset classes? Why or why not?
Please explain. If so, what would be an appropriate threshold
measurement? For example, would five percent of the asset class's total
average daily dollar volume be appropriate? Should the measurement be
higher or lower? Please be specific and explain. Or, rather than a
threshold measurement that is based on a percentage of the asset
class's total average daily dollar volume, would a fixed average daily
dollar volume threshold, such as $500 million, be appropriate? If so,
should such a threshold be higher or lower than $500 million? Why or
why not? Should such a fixed dollar threshold be different for
different asset classes? Why or why not? If so, what should such
thresholds be for each asset class? Please be specific. What are the
advantages and disadvantages of a percentage-based threshold versus a
fixed dollar threshold? Please explain.
    12. Would it be appropriate for the Commission to adopt a single
dollar volume threshold measurement that applies across all asset
classes? For example, if an ATS trades both municipal securities and
corporate debt securities, should its trading volume in both asset
classes be aggregated to determine whether it exceeded the threshold
measurement? Why or why not?
    13. The proposed SCI ATS thresholds are to be calculated by
reference to executions ``during at least four of the preceding six
calendar months,'' the measurement period and method that is currently
used in Regulation ATS. Do commenters believe this is the appropriate
time frame and method to be included in Regulation SCI? Why or why not?
If not, is there a more appropriate approach? If so, what should it be
and why?
    14. With respect to calculating the proposed thresholds for
securities other than NMS stocks (i.e., non-NMS stocks, municipal
securities, and corporate debt securities), would ATSs have available
appropriate data with which to determine whether the proposed
thresholds have been met? FINRA, through its OTC Reporting Facility and
its Trade Reporting and Compliance Engine (``TRACE'') \138\ facility,
collects data on transactions in non-NMS stocks and corporate debt
securities, and the MSRB collects data on transactions in municipal
securities. Do commenters believe that FINRA, the MSRB, or another
appropriate entity should be required to disseminate data in a format
and frequency sufficient to enable ATSs to determine if they have met
the proposed thresholds? Is there another mechanism or structure that
could provide data in a format and frequency sufficient to enable ATSs
to determine whether the proposed thresholds have been met? Please
explain.
---------------------------------------------------------------------------

    \138\ TRACE is an automated system that, among other things,
accommodates reporting and dissemination of transaction reports for
over-the-counter secondary market transactions in eligible fixed
income securities, in accordance with the FINRA Rule 6700 series.
---------------------------------------------------------------------------

    15. Are there ATSs or types of ATSs that would satisfy the proposed
definition of SCI ATS that commenters believe should not be subject to
proposed Regulation SCI? If so, please explain. Are there ATSs or types
of ATSs that would not satisfy the proposed definition of SCI ATS that
commenters believe should be subject to proposed Regulation SCI? If so,
please explain. For example, should ATSs that execute transactions in
U.S. treasuries and/or repurchase agreements be subject to proposed
Regulation SCI? Why or why not? If a parent company owns multiple ATSs
for a given asset class (e.g., NMS stocks), should the trading volumes
of these ATSs be aggregated for purposes of determining whether the
ATSs exceed the proposed thresholds? Why or why not? If so, how should
such aggregation work? What are the advantages or disadvantages of such
an approach? Please explain.
    16. Do commenters believe that, for purposes of Regulation SCI, the
proposed definition of plan processor is appropriate? Why or why not?
Is it appropriate to limit the definition of plan processor to entities
within the meaning of plan processor in Rule 600(b)(55) of Regulation
NMS? Why or why not? Do commenters believe the proposed definition is
sufficiently clear? Are there any other entities similar to the plan
processors of SCI Plans that commenters believe should be made subject
to the requirements of proposed Regulation SCI? If so, please describe
and explain why.
    17. Do commenters believe that the proposed definition of ``exempt
clearing agency subject to ARP'' is appropriate? Why or why not? Are
there other exempt clearing agencies that should be included in the
proposed definition of SCI entity? Why or why not? Is it appropriate to
limit the definition of SCI entity with respect to exempt clearing
agencies to those with exemptions that

contain conditions that relate to the Commission's Automation Review
Policies or any Commission regulation that supersedes or replaces such
policies? Why or why not?
    18. What are the current practices of the proposed SCI entities
with respect to the subject matter covered by the ARP policy
statements? How many of them have practices that are consistent with
ARP? How do they differ? Please be specific.
2. Definition of SCI Systems and SCI Security Systems
    The Commission is proposing that Regulation SCI cover the systems
of SCI entities, which would include both SCI systems and, where
applicable, SCI security systems. Proposed Rule 1000(a) would define
the term ``SCI systems'' to mean ``all computer, network, electronic,
technical, automated, or similar systems of, or operated by or on
behalf of, an SCI entity, whether in production, development, or
testing, that directly support trading, clearance and settlement, order
routing, market data, regulation, or surveillance,'' and the term ``SCI
security systems'' to mean ``any systems that share network resources
with SCI systems that, if breached, would be reasonably likely to pose
a security threat to SCI systems.''
    Thus, for purposes of all of the provisions of proposed Regulation
SCI, the proposed definition of SCI systems would cover all systems of
an SCI entity that directly support trading, clearance and settlement,
order routing, market data, regulation, and surveillance. In addition,
the proposed definition of SCI security systems is designed to cover
other types of systems if they share network resources with SCI systems
and, if breached, would be reasonably likely to pose a security threat
to SCI systems. Unlike SCI systems, only certain provisions of proposed
Regulation SCI would apply to SCI security systems.\139\
---------------------------------------------------------------------------

    \139\ Specifically, under proposed Rule 1000(a), SCI security
systems are included in the proposed definitions of ``material
systems change,'' ``responsible SCI personnel,'' ``SCI review,'' and
``systems intrusion.'' For purposes of security standards, proposed
Rule 1000(b)(1) would also apply to SCI security systems. In
addition, with respect to systems intrusions, proposed Rules
1000(b)(3)-(5) would apply to SCI security systems. Further, because
of the definitions of material systems change and SCI review,
proposed Rules 1000(b)(6) and (7) would apply to SCI security
systems. Finally, proposed Rules 1000(c) and (f), relating to
recordkeeping and access, respectively, would apply to SCI security
systems.
---------------------------------------------------------------------------

    The Commission preliminarily believes that the proposed definition
of SCI systems would reach those systems traditionally considered to be
core to the functioning of the U.S. securities markets, namely trading,
clearance and settlement, order routing, market data, regulation, and
surveillance systems.\140\ The proposed definition would also apply to,
for example, such systems of exchange-affiliated routing brokers that
are facilities of national securities exchanges or such systems
operated on behalf of national securities exchanges. It would also
apply to regulatory systems,\141\ including systems for the regulation
of the over-the-counter market, systems used to carry out regulatory
services agreements, and similar future systems, including the
Consolidated Audit Trail repository.\142\ In addition, if an SCI entity
contracts with a third party to operate its systems (such as those that
use execution algorithms) on behalf of the SCI entity, such systems
would also be covered by the proposed definition of SCI systems if they
directly support trading, clearance and settlement, order routing,
market data, regulation, or surveillance. Therefore, systems covered by
the proposed definition of SCI systems would not be limited only to
those owned by the SCI entity, but also could include those operated by
or on behalf of the SCI entity.
---------------------------------------------------------------------------

    \140\ See ARP I, supra note 1.
    \141\ SCI entities that are obligated to comply with Section 31
of the Exchange Act (15 U.S.C. 78ee), and Rule 31 thereunder (17 CFR
240.31), employ various systems to generate, process, transmit, or
store electronic messages related to securities transactions. Such
systems may include matching engines, transaction data repositories,
trade reporting systems, and clearing databases.
    \142\ See Consolidated Audit Trail Adopting Release, supra note
131.
---------------------------------------------------------------------------

    Based on Commission staff's experience with the ARP Inspection
Program, the Commission believes that some SCI systems of SCI entities
may in some cases be highly interconnected with SCI security systems
because the SCI systems and SCI security systems share network
resources. As a result, the Commission is concerned that a security
issue or systems intrusion with respect to SCI security systems would
be reasonably likely to cause an SCI event with respect to SCI systems.
Because certain SCI security systems of an SCI entity may present
likely vulnerable entry points to an SCI entity's network, the
Commission preliminarily believes that it is important that the
provisions of proposed Regulation SCI relating to security standards
and systems intrusions apply to SCI security systems.\143\
---------------------------------------------------------------------------

    \143\ See supra note 139.
---------------------------------------------------------------------------

    The proposed definition of SCI security systems does not identify
the types of systems that would be covered, but rather describes them
in terms of their connectivity and potential ability to undermine the
integrity of SCI systems. However, examples of SCI security systems
that could be highly interconnected with SCI systems and therefore be
reasonably likely to pose a threat to SCI systems may include systems
pertaining to corporate operations (e.g., systems that support web-
based services, administrative services, electronic filing, email
capability and intranet sites, as well as financial and accounting
systems) that are typically accessed by an array of users (e.g.,
employees or executives of the SCI entity) authorized to view non-
public information. In certain cases, such systems would likely offer
insight into the vulnerabilities of an SCI entity if they were, for
example, accessed by a hacker. The Commission is concerned that the
breach of such systems would likely lead to disruption of an SCI
entity's general operations and, ultimately, its market-related
activities. Similarly, systems by which an SCI entity provides a
service to issuers, participants, or clients (e.g., transaction
services, infrastructure services, and data services) may be accessed
by employees or other representatives of the issuer, participant, or
client organization, and may, in some instances, provide a point of
access (and thus share network resources) to an SCI entity's SCI
systems. Accordingly, the Commission is proposing that the term SCI
security systems include any systems that share network resources with
SCI systems that, if breached, would be reasonably likely to pose a
security threat to SCI systems, but only for the limited provisions of
proposed Regulation SCI noted above.\144\
---------------------------------------------------------------------------

    \144\ See id.
---------------------------------------------------------------------------

    In light of the above concerns, the proposed definitions of SCI
systems and SCI security systems together are intended to reach all of
the systems that would be reasonably likely to impact an SCI entity's
operational capability and the maintenance of fair and orderly markets,
rather than reaching solely SCI systems. Because of the dependence of
today's securities markets on highly sophisticated electronic trading
and other technology, including complex regulatory and surveillance
systems, as well as systems relating to clearance and settlement, the
provision of market data, and order routing, the Commission
preliminarily believes that the proposed definitions of SCI systems and
SCI security systems are appropriate to help ensure the capacity,
integrity, resiliency, availability, and security of an SCI entity's
systems.

Request for Comment
    19. The Commission requests comment generally on the proposed
definitions of SCI systems and SCI security systems.
    20. Do commenters believe that the proposed definitions
appropriately capture the scope of systems of SCI entities that would
be reasonably likely to impact the protection of investors and the
maintenance of fair and orderly markets? Specifically, do the proposed
definitions of SCI systems and SCI security systems capture the
components of the critical systems infrastructure of SCI entities in a
comprehensive manner? Are the proposed definitions sufficiently clear?
    21. Are there any systems of SCI entities that should be included
but would not be captured by the proposed definitions? Please explain.
Are there any systems of SCI entities that should be excluded from the
proposed definitions? Please explain.
    22. By including in the proposed definition of ``SCI systems''
those systems operated ``on behalf of'' an SCI entity, systems operated
by a third party under contract from an SCI entity and systems operated
by affiliates of an SCI entity that are utilized by such SCI entity
would also be included in the proposed definition of SCI systems. Do
commenters agree that such systems should be included? Please explain.
Should the requirements under proposed Regulation SCI apply differently
to systems that are operated on behalf of an SCI entity? Why or why
not? Please explain.
    23. Do commenters agree with the proposal to distinguish between
SCI systems and SCI security systems for purposes of triggering the
various provisions of proposed Regulation SCI? For example, are the
requirements that would apply to SCI security systems appropriate? Why
or why not? If not, which requirements of proposed Regulation SCI
should apply to SCI security systems and why? Should the requirements
under proposed Regulation SCI apply differently to different types of
systems, as proposed? Or, should SCI security systems be subject to all
of the requirements of proposed Regulation SCI? Why or why not?
    24. Alternatively, should SCI security systems be excluded entirely
from the application of proposed Regulation SCI? Why or why not? The
Commission is proposing its approach to distinguish between SCI systems
and SCI security systems because it preliminarily believes that the
interconnected nature of technology infrastructure today creates the
potential for systems other than SCI systems to expose vulnerable
points of entry that could lead to a security breach or intrusion into
SCI systems. In light of this potential, the Commission is proposing,
as discussed further below, that the following provisions of proposed
Regulation SCI apply to the SCI security systems of an SCI entity: (1)
For purposes only of the policies and procedures relating to systems
security, proposed Rule 1000(b)(1) would apply to its SCI security
systems; (2) proposed Rules 1000(b)(3)-(5) (relating to SCI events and
taking corrective action, Commission notification, and dissemination of
information to members or participants, respectively) would apply to
SCI security systems only with respect to systems intrusions; and (3)
proposed Rule 1000(b)(6) would require an SCI entity to report a
material systems change in a SCI security system only to the extent
that it materially affects the security of such system.\145\
---------------------------------------------------------------------------

    \145\ See infra Sections III.C.1, III.C.3, and III.C.4. In
addition, the scope of the applicability of proposed Rules
1000(b)(7), 1000(b)(8), and 1000(c)-(f) to SCI security systems
would be determined by the provisions of the proposed Rules
1000(b)(1), and (3)-(6). See infra Sections III.C.5, III.C.6, and D.
---------------------------------------------------------------------------

    25. The goal of this proposed approach is to ensure that SCI
systems, as the core systems of an SCI entity, are adequately secure
and protected from systems intrusions. However, the Commission
recognizes that there may be alternative ways to achieve this goal,
including those that do not extend the scope of the proposed rule
beyond the core systems that are defined as ``SCI systems,'' and that
focus the Commission's oversight on those systems. For example, one
alternative would be to limit the scope of the proposed rule to SCI
systems, but clarify that policies and procedures reasonably designed
to ensure that SCI systems have adequate levels of security necessarily
would require an assessment of security vulnerabilities created by
other systems that share network resources with SCI systems, and
appropriate steps to address those vulnerabilities. Specifically, under
such an alternative, the defined term ``SCI security systems,'' and all
references to them and any associated obligations, would be eliminated
from the proposed rule text described herein, and clarifying guidance
would be provided with respect to the security of SCI systems as noted
above. With such an alternative, consideration also would need to be
given to whether or not an SCI entity should notify the Commission (and
potentially its members or participants) of a systems intrusion with
respect to these non-SCI systems, or a systems change that materially
impacts the security of such systems. Accordingly, the Commission
solicits commenters' views on this or any other potential alternative
approaches that would not include a definition of SCI security systems
within the scope of the proposed rule.
    26. If the Commission were to determine to eliminate the proposed
definition of SCI security systems from proposed Regulation SCI, what
would be the likely effect of such elimination on the ability of
proposed Regulation SCI to ensure that SCI systems are adequately
secure and protected from systems intrusions? Please explain.
Specifically, if the Commission eliminated the proposed definition of
SCI security systems from proposed Regulation SCI, and its direct
oversight of systems that share network resources with SCI systems,
would the Commission's ability to assure adequate security for SCI
systems be materially weakened? Why or why not? Would such an
alternative reduce compliance burdens for SCI entities, and improve the
efficiency of Commission oversight without materially undermining its
effectiveness?
    27. If the Commission were to determine to eliminate the proposed
definition of SCI security systems from proposed Regulation SCI, would
it be appropriate, for example, for the Commission to interpret the
requirement of proposed Rule 1000(b)(1) that would require an SCI
entity to have ``policies and procedures reasonably designed to ensure
that its SCI systems have levels of * * * security * * * adequate to
maintain the SCI entity's operational capability and promote the
maintenance of fair and orderly markets'' to require that an SCI
entity's SCI systems be protected from security threats by other
systems with which they share network resources? Why or why not? Please
explain.
    28. If the Commission were to determine to eliminate the proposed
definition of SCI security systems from proposed Regulation SCI, should
the Commission still require an SCI entity to report to the Commission
an intrusion into any system (and not just SCI systems) of an SCI
entity? Why or why not? If the Commission were to determine to
eliminate the proposed definition of SCI security systems from proposed
Regulation SCI, should the Commission require an SCI entity to notify
members and participants of an intrusion into any system of an SCI
entity? Why or why not? If the Commission were to determine to
eliminate the proposed definition of SCI

security systems from proposed Regulation SCI, are there any other
changes to the rule that would be appropriate? What are they, and why
would they be appropriate? Please describe in detail.
3. SCI Events
    Pursuant to the current ARP policy statements and Regulation ATS, a
key element of the ARP Inspection Program has been to encourage ARP
participants to notify Commission staff of significant systems
disruptions so that the staff can work with the affected entity to help
ensure that the disruption is addressed promptly and effectively, and
that appropriate steps are taken to reduce the likelihood of future
problems. Commission staff has previously sought to provide guidance
and clarification on what should be considered a ``significant system
outage'' for purposes of reports to Commission staff. Specifically, in
the 2001 Staff ARP Interpretive Letter, Commission staff provided
examples of situations for which an outage is deemed significant and
thus should be reported.\146\ The examples listed in that letter
included: (1) Outages resulting in a failure to maintain any service
level agreements or constraints; (2) disruptions of normal operations,
e.g., switchover to back-up equipment with zero hope of near-term
recovery of primary hardware; (3) the loss of use of any system; (4)
the loss of transactions; (5) outages resulting in excessive back-ups
or delays in processing; (6) the loss of ability to disseminate vital
information; (7) outage situations communicated to other external
entities; (8) events that are (or will be) reported or referred to the
entity's board of directors or senior management; (9) events that
threaten systems operations even though systems operations are not
disrupted; for example, events that cause the entity to implement a
contingency plan; and (10) the queuing of data between system
components or queuing of messages to or from customers of such duration
that a customer's usual and customary service delivery is
affected.\147\
---------------------------------------------------------------------------

    \146\ See 2001 Staff ARP Interpretive Letter, supra note 35.
    \147\ See id.
---------------------------------------------------------------------------

    The Commission believes that guidance in the 2001 Staff ARP
Interpretive Letter regarding what constitutes a significant systems
outage has been useful over the years to the entities that received the
2001 Staff ARP Interpretive Letter, but understands that Commission
action in this area would help SROs and other entities by providing
definitive guidance through a formal rulemaking process that includes
notice and comment. Furthermore, the Commission believes the term
``significant systems outage'' in plain usage denotes a category of
systems problems that is considerably narrower than those the
Commission believes could pose risks to the securities markets and
market participants. Therefore, the Commission proposes to specify the
types of events that would be required to be reported to the Commission
and the types of systems problems that would trigger notice
requirements on the part of an SCI entity. Specifically, the Commission
is proposing to define the term ``SCI event'' in Rule 1000(a) as ``an
event at an SCI entity that constitutes: (1) A systems disruption; (2)
a systems compliance issue; or (3) a systems intrusion.'' As discussed
in detail below, the proposed rule would define each of these terms
used in the proposed definition of SCI event.
a. Systems Disruption
    The Commission proposes that the term ``systems disruption'' be
defined to mean ``an event in an SCI entity's SCI systems that results
in: (1) A failure to maintain service level agreements or constraints;
(2) a disruption of normal operations, including switchover to back-up
equipment with near-term recovery of primary hardware unlikely; (3) a
loss of use of any such system; (4) a loss of transaction or clearance
and settlement data; (5) significant back-ups or delays in processing;
(6) a significant diminution of ability to disseminate timely and
accurate market data; or (7) a queuing of data between system
components or queuing of messages to or from customers of such duration
that normal service delivery is affected.'' The proposed definition is
similar, but not identical, to the definition of ``significant systems
outage'' in the 2001 Staff ARP Interpretive Letter.\148\
---------------------------------------------------------------------------

    \148\ See supra note 35. The Commission believes that the term
``systems disruption'' is a more appropriate term to describe the
types of events captured within the proposed definition and thus is
proposing to use the term ``systems disruption,'' rather than the
term ``systems outage,'' the term used in the ARP Inspection
Program.
---------------------------------------------------------------------------

    As proposed, a systems disruption would be an event in an SCI
entity's SCI systems that manifests itself as a problem measured by
reference to one or more of seven elements. The first proposed element,
a failure to maintain service level agreements or constraints, is
unchanged from the 2001 Staff ARP Interpretive Letter. This would
include, for example, a failure or inability of the SCI entity to honor
its contractual obligations to provide a specified level or speed of
service to users of its SCI systems. A trading market could, for
example, contract to maintain its trading system without delays over a
specific threshold, e.g., 100 milliseconds, and its failure to honor
that obligation would thus be a systems disruption.
    The second proposed element, ``a disruption of normal operations,
including switchover to back-up equipment with near-term recovery of
primary hardware unlikely'' differs from the element in the 2001 Staff
ARP Interpretive Letter (disruption of normal operations, e.g.,
switchover to back-up equipment with zero hope of near-term recovery of
primary hardware). This modification is intended to convey that the
Commission preliminarily believes that an SCI entity should be required
to notify Commission staff of a SCI systems problem that involves a
switchover to backup equipment, even if a determination that no
recovery is possible has not been made because the probability that
such switchover may continue indefinitely is significant. The
Commission also intends that this proposed element, a ``disruption of
normal operations,'' would capture problems with SCI systems such as
programming errors, testing errors, systems failures, or if a system
release is backed out after it is implemented in production.
    The third proposed element, ``a loss of use of any such system,''
is unchanged from the 2001 Staff ARP Interpretive Letter and would
cover situations in which an SCI system is broken, offline, or
otherwise out of commission. For example, the Commission intends that a
failure of primary trading or clearance and settlement systems, even if
immediately replaced by backup systems without any disruption to normal
operations, would be covered under this third proposed element. The
Commission preliminarily believes the language of the fourth proposed
element, ``a loss of transaction or clearance and settlement data,'' is
more precise than the language in the 2001 Staff ARP Interpretive
Letter, which lists ``loss of transactions'' as an example of a systems
outage.
    Similarly, the language of the fifth and sixth proposed elements is
intended to be more precise than the comparable language in the fifth
and sixth examples enumerated in the 2001 Staff ARP Interpretive
Letter. The Commission is not at this time proposing to quantify what
would constitute a ``significant back-up or delay in processing'' or a
``significant diminution of ability to disseminate timely and accurate
market data'' because it preliminarily believes that the varying
circumstances that

could give rise to such events, and the range of SCI systems
potentially impacted, make precise quantification impractical.\149\
These proposed elements are intended to include, for example,
circumstances in which a problem with an SCI system results in a
slowdown or disruption of operations that would adversely affect
customers, impair quotation or price transparency, or impair accurate
and timely regulatory reporting. Instances in which message traffic is
throttled (i.e., slowed) by an SCI entity for any market participant,
without a corresponding provision in the SCI entity's rules, user
agreements, or governing documents, as applicable, would also be
covered here.\150\ Further, the Commission preliminarily believes that
if customers or systems users, for example, have complained or inquired
about a slowdown or disruption of operations, including, for example, a
slowdown or disruption in their receipt of market data, then such
circumstance would be indicative of a problem at an SCI entity that
results in ``significant back-ups or delays in processing'' or a
``significant diminution of ability to disseminate timely and accurate
market data,'' that should be considered a ``systems disruption.'' The
fifth and sixth elements of the proposed definition of systems
disruption are also intended to cover the entry, processing, or
transmission of erroneous or inaccurate orders, trades, price-reports,
other information in the securities markets or clearance and settlement
systems, or any other significant deterioration in the transmission of
market data in an accurate, timely, and efficient manner. For example,
it is possible that an SCI system of an SCI entity that disseminates
market data could, as a result of a programming or testing error in
another system of the SCI entity, be overwhelmed with erroneous market
data to such an extent that the SCI entity's SCI systems are no longer
able to disseminate market data in a timely and accurate manner.
---------------------------------------------------------------------------

    \149\ The Commission is, however, soliciting comment on whether
it would be appropriate to adopt quantitative criteria in connection
with the definition of ``systems disruption.''
    \150\ However, if an SCI entity's rules or governing documents
provided for such throttling in specified scenarios as a part of
normal operations, such throttling would not be covered as such a
situation would not represent an unexpected back-up or delay in
processing but rather would be part of the SCI entity's normal
operation.
---------------------------------------------------------------------------

    Finally, the seventh proposed element, ``a queuing of data between
system components or queuing of messages to or from customers of such
duration that normal service delivery is affected,'' is proposed to be
included because the Commission preliminarily believes that queuing of
data between system components of SCI systems is often a warning signal
of significant disruption of normal system operations.
    Although the 2001 Staff ARP Interpretive Letter lists ``a report or
referral of an event to the entity's board of directors or senior
management'' and ``an outage situation communicated to other external
entities'' as examples of a significant systems outage, the Commission
is not proposing to include such reports or communications in the
definition of systems disruption because it preliminarily believes
these examples are more likely to be indicia of whether information
about a systems disruption or other systems problem warrants
dissemination to the SCI entity's members or participants.\151\
Further, although the 2001 Staff ARP Interpretive Letter lists ``a
serious threat to systems operations even though systems operations are
not disrupted'' as an example of a significant systems outage, the
Commission has not included that example as an element in the proposed
definition of systems disruption because it preliminarily believes that
such a threat would more likely be indicative of a systems intrusion or
systems compliance issue.\152\
---------------------------------------------------------------------------

    \151\ See infra Section III.B.4.d, discussing whether an SCI
event is a ``dissemination SCI event.''
    \152\ See infra Sections III.B.3.b and III.B.3.c, discussing the
proposed definition of systems compliance issue and systems
intrusion, respectively.
---------------------------------------------------------------------------

Request for Comment
    29. The Commission requests comment generally on the proposed
definition of ``systems disruption.'' Do commenters believe that it is
appropriate to limit the proposed definition of ``systems disruption''
to SCI systems? Why or why not? Do commenters believe the proposed
definition of ``systems disruption'' is too broad? Why or why not?
Please explain.
    30. Do commenters believe that there should be minimum thresholds
associated with the circumstances specified in any elements of the
proposed definition of systems disruption--e.g., quantitative criteria
describing when an event fitting the description of one of the elements
of the proposed definition would meet the definition of SCI event? If
so, what should such minimum thresholds be and to which elements of the
definition of ``systems disruption'' should such minimum thresholds
apply? Please explain. Should systems disruptions affecting different
types of SCI systems be treated differently? For example, should
trading systems have a different quantitative criteria than systems
dedicated to surveillance? Please be specific with respect to which
categories of SCI systems might deserve different treatment, and what
such quantitative criteria might be and why.
    31. Do commenters believe the term ``transaction or clearance and
settlement data,'' as used in paragraph (4) of the proposed definition
of ``systems disruption,'' is appropriate? Why or why not? Should other
types of data be included, in addition to transaction and clearance and
settlement data? For example, should customer account data, regulatory
data, and/or audit trail data be included? Why or why not?
    32. Do commenters believe that there should be exceptions to the
proposed definition of systems disruption? If so, what should such
exceptions be and why? For example, should the proposed definition of
systems disruption include a de minimis exception? If so, what types of
systems problems should be considered de minimis and what criteria
should be used to determine whether a systems problem is de minimis?
Should the proposed definition of systems disruption include a
materiality threshold? If so, what types of systems problems should be
considered material and what criteria should be used to determine
whether a systems problem is material? Should the definition of systems
disruption exclude regular planned outages occurring during the normal
course of business?
    33. Should the proposed definition be expanded, narrowed, or
otherwise modified in any way? For example, should the proposed
definition include quantitative criteria that establish a minimum
deviation from normal performance levels, such as a tenfold increase or
greater in latency for queuing of data, for an event to be considered
an SCI event? Would a minimum deviation of 100 milliseconds from normal
system performance levels be an appropriate indication of system
degradation? Or, would a larger or smaller deviation be more
appropriate? Why or why not? For example, would the choice of a
specific threshold help to balance the tradeoff between the costs of
over-reporting systems disruptions and the costs of failing to report
systems disruptions that could lead to significant negative
consequences? Should different quantitative criteria be used across
different SCI systems? For example, a limited pause in the operations
of a clearing system may not raise the same issues as a similar pause
in the operation of a market data feed. If commenters believe that
different criteria should be maintained, please be specific and provide
examples of what

the appropriate minimum deviations should be for such systems.
    34. Are there other types of circumstances that should be included
that are not part of the proposed definition? If so, please describe
and explain. For example, if an SCI SRO or SCI ATS suspects a
technology error originating from a third party (such as an SCI SRO's
member firm or an SCI ATS's subscriber) that has the potential to
disrupt the market, should that type of discovery be included in the
definition of systems disruption? Why or why not? Is there additional
guidance that commenters would find helpful to determine whether an
event would meet the proposed definition of systems disruption?
    35. How often do SCI entities currently experience systems
disruptions?
b. Systems Compliance Issue
    The Commission proposes that the term ``systems compliance issue''
be defined as ``an event at an SCI entity that has caused any SCI
system of such entity to operate in a manner that does not comply with
the federal securities laws and rules and regulations thereunder or the
entity's rules or governing documents, as applicable.'' \153\
Circumstances covered by the proposed definition would include, for
example, situations in which a lack of communication between an SCI
SRO's information technology staff and its legal or regulatory staff
regarding SCI systems design or requisite regulatory approvals resulted
in one or more SCI systems operating in a manner not in compliance with
the SCI SRO's rules and, thus, in a manner other than how the users of
the SCI SRO's SCI systems, as well as market participants generally,
have been informed that such systems would operate. Another example of
a systems compliance issue could arise when a change to an SCI system
is made by information technology staff that results in the system
operating in a manner that fails to comply with the federal securities
laws and rules thereunder.
---------------------------------------------------------------------------

    \153\ As discussed in infra Section III.C.2, one of the elements
of the safe harbor in proposed Rule 1000(b)(2)(ii)(A) would require
that an SCI entity establish policies and procedures that provide
for ongoing monitoring of SCI systems functionality to detect
whether SCI systems are operating in the manner intended. This
element would require that each SCI entity establish parameters for
detection of a systems compliance issue, and is not intended to
suggest one set of parameters for all SCI entities.
---------------------------------------------------------------------------

    The phrase ``operate in a manner that does not comply with * * *
the entity's rules or governing documents'' would mean that an SCI
entity is operating in a manner that does not comply with the entity's
applicable rules and other documents, whether or not filed with the
Commission. Generally, such rules or other documents are made available
to the public and/or to members, clients, users, and/or participants in
the SCI entity.\154\ Specifically, for an SCI SRO, this phrase would
include operating in a manner that does not comply with the SCI SRO's
rules as defined in the Exchange Act and the rules thereunder.\155\ For
a plan processor, this phrase would include operating in a manner that
does not comply with an applicable effective national market system
plan. For an SCI ATS or exempt clearing agency subject to ARP, this
phrase would include operating in a manner that does not comply with
documents such as subscriber agreements and any rules provided to
subscribers and users and, for ATSs, described in their Form ATS
filings with the Commission.\156\
---------------------------------------------------------------------------

    \154\ For example, each SCI SRO is required to publish its rules
on its publicly available Web site. See 15 U.S.C. 78s(b)(2)(E). Each
plan processor is also required to post amendments to its national
market system plan on its Web site. See 17 CFR 242.608. Subscriber
agreements and other similar documents that govern operations of SCI
ATSs and exempt clearing agencies subject to ARP are generally not
publicly available, but are provided to subscribers and users of
such entities.
    \155\ The rules of an SCI SRO are defined in Sections 3(a)(27)
and (28) of the Exchange Act to include, among other things, its
constitution, articles of incorporation, and bylaws. See 15 U.S.C.
78c(a)(27)-(28). See also Exchange Act Rule 19b-4(c), 17 CFR
240.19b-4(c).
    \156\ See 17 CFR 242.301(b) for a description of the filing
requirements for ATSs.
---------------------------------------------------------------------------

Request for Comment
    36. The Commission requests comment generally on the proposed
definition of ``systems compliance issue.'' Do commenters believe it
would be appropriate to define ``systems compliance issue'' to mean any
instance in which an SCI system operates in a manner that does not
comply with the federal securities laws and rules and regulations
thereunder, or the entity's rules or governing documents, as
applicable? Why or why not? If the proposed definition is not
appropriate, what would be an appropriate definition? Do commenters
believe that it is appropriate to limit the proposed definition of
``systems compliance issue'' to SCI systems? Why or why not? Please
explain.
    37. Do commenters believe that there should be exceptions to the
proposed definition of systems compliance issue? If so, what should
such exceptions be and why? For example, should the proposed definition
of systems compliance issue include a de minimis exception? If so, what
types of systems compliance issues should be considered de minimis and
what criteria should be used to determine whether a systems compliance
issue is de minimis? Should the proposed definition of systems
compliance issue include a materiality threshold? If so, what types of
systems compliance issues should be considered material and what
criteria should be used to determine whether a systems compliance issue
is material?
    38. Do commenters believe other types of documents or agreements
should be included in the definition? If so, please specify the types
of documents or agreements and explain why.
    39. How often do SCI entities currently experience systems
compliance issues?
c. Systems Intrusion
    The Commission proposes that ``systems intrusion'' be defined as
``any unauthorized entry into the SCI systems or SCI security systems
of an SCI entity.'' The proposed definition is intended to cover all
unauthorized entry into SCI systems or SCI security systems by
outsiders, employees, or agents of the SCI entity, regardless of
whether the intrusions were part of a cyber attack, potential criminal
activity, or other unauthorized attempt to retrieve, manipulate or
destroy data, or access or disrupt systems of SCI entities. The
proposed definition of systems intrusion would cover the introduction
of malware or other attempts to disrupt SCI systems or SCI security
systems of SCI entities provided that such systems were actually
breached. In addition, the proposed definition is intended to cover
unauthorized access, whether intentional or inadvertent, by employees
or agents of the SCI entity that result from weaknesses in the SCI
entity's access controls and/or procedures. The proposed definition
would not, however, cover unsuccessful attempts at unauthorized entry.
An unsuccessful systems intrusion by definition is much less likely
than a successful intrusion to disrupt the systems of an SCI entity.
Moreover, because it is impossible to prevent attempted intrusions, the
Commission preliminarily believes at this time that the focus of this
aspect of proposed Regulation SCI should be on successful unauthorized
entry.
Request for Comment
    40. The Commission requests comment generally on the proposed
definition of ``systems intrusion.'' Is the proposed definition
sufficiently clear? If not, why not? Do commenters believe that it is
appropriate to apply the proposed definition of ``systems

intrusion'' to both SCI systems and SCI security systems? Why or why
not? Please explain.
    41. Do commenters believe it is appropriate to exclude from the
proposed definition of systems intrusion an attempted intrusion that
did not breach systems or networks? Why or why not? Should significant,
sophisticated, repeated, and/or attempted intrusions, even if
unsuccessful, be included? Why or why not? If yes, please explain what
categories of attempted intrusions should be covered by the proposed
rule and why.
    42. Should the proposed definition of systems intrusion be expanded
to include the unauthorized use or unintended release of information or
data, for example, by an employee or agent of an SCI entity? Why or why
not? If so, should the definition be limited to the unauthorized use of
non-public or confidential information or should it apply to any
unauthorized use of information or data? The Commission recognizes that
including in the definition all instances of unauthorized use or
unintended release of information or data may be broad and solicits
comment generally on how the definition might be more narrowly defined
to encompass those types of events that commenters believe would be
appropriate to be included in proposed Regulation SCI.
    43. How often do SCI entities currently experience known systems
intrusions or known attempted systems intrusions?
d. Dissemination SCI events
    The Commission proposes that the term ``dissemination SCI event''
be defined as ``an SCI event that is a: (1) Systems compliance issue;
(2) systems intrusion; or (3) systems disruption that results, or the
SCI entity reasonably estimates would result, in significant harm or
loss to market participants.'' \157\
---------------------------------------------------------------------------

    \157\ See proposed Rule 1000(a).
---------------------------------------------------------------------------

    As discussed below in Section III.C.3, proposed Rule 1000(b)(5)
includes requirements for disseminating information regarding certain
SCI events to members or participants.\158\ Specifically, only
information relating to dissemination SCI events would be required to
be disseminated to members or participants pursuant to proposed Rule
1000(b)(5).\159\ The Commission recognizes that public disclosure of
each and every systems issue (such as very brief outages or minor
disruptions of normal systems operations where the effects on trading,
market data, and clearance and settlement are immaterial) could be
counterproductive, potentially overwhelming the public with
information, masking significant issues that might arise, and thus
preliminarily believes that requiring the dissemination of information
about dissemination SCI events to members or participants would promote
dissemination of information to persons who are most directly affected
by such events and who would most naturally need, want, and be able to
act on the information, without creating a separate regulatory standard
governing when broader public disclosure should be made.
---------------------------------------------------------------------------

    \158\ Proposed Rule 1000(b)(5) would require the dissemination
of specified information relating to dissemination SCI events and
specify the nature and timing of such dissemination, with a delay in
dissemination permitted for certain systems intrusions. See infra
Section III.C.3.c.
    \159\ See infra note 235.
---------------------------------------------------------------------------

    In the case of a dissemination SCI event, the Commission
preliminarily believes that dissemination to members or participants of
the nature of the event and the steps being taken to remedy it would be
necessary to help ensure that potentially impacted market participants,
and others that might be evaluating whether to use the affected
systems, have basic information about the event so that they might be
able to better assess what, if any, next steps they might deem prudent
to take in light of the event.\160\
---------------------------------------------------------------------------

    \160\ However, as discussed below, the Commission recognizes
that, in the case of systems intrusions, there may be circumstances
in which full prompt dissemination of information to members or
participants of a systems intrusion could hinder an investigation
into such an intrusion or an SCI entity's ability to mitigate it. As
such, the Commission is proposing that dissemination of information
for certain systems intrusions could be delayed in specified
circumstances. Specifically, the Commission is proposing that an SCI
entity disseminate information about a systems intrusion to its
members or participants, unless the SCI entity determines that
dissemination of such information would likely compromise the
security of the SCI entity's SCI systems or SCI security systems, or
an investigation of the systems intrusion, and documents the reasons
for such determination. See proposed Rule 1000(b)(5)(ii) and text
accompanying infra note 174. The Commission preliminarily believes,
however, that an SCI entity should ultimately disseminate
information regarding systems intrusions, and that the provisions of
proposed Rule 1000(b)(5)(ii) permitting a delay in dissemination, if
applicable, should only affect the timing of such dissemination.
    The Commission notes that some Roundtable panelists and
commenters discussed the role that communications and disclosure
should play in mitigation of risk from systems issues. For example,
panelists from Citadel, DE, Nasdaq, Lime, and TDA, among others,
spoke about the role of communications and management involvement in
responding to errors. See discussion of Roundtable, supra Section
I.D. See also text accompanying infra note 238.
---------------------------------------------------------------------------

    Proposed Rule 1000(a) specifies three categories of SCI events that
would constitute a dissemination SCI event. First, any SCI event that
is a systems compliance issue would be a dissemination SCI event.\161\
The Commission preliminarily believes that, if an SCI entity's SCI
systems were operating in a manner not in compliance with the federal
securities laws and rules and regulations thereunder, or the entity's
rules or governing documents, as applicable, the SCI entity should be
required to disseminate that information to all members or
participants, i.e., the users of its SCI systems. In addition, because
SCI entities that are SCI SROs or plan processors are required by the
Exchange Act to comply with their rules, proposing to require
dissemination of information about systems compliance issues to members
or participants should help to reinforce this statutory obligation.
---------------------------------------------------------------------------

    \161\ See supra Section III.B.3.b, discussing the definition of
``systems compliance issue.''
---------------------------------------------------------------------------

    Second, any SCI event that is a systems intrusion would also be a
dissemination SCI event. The Commission preliminarily believes that a
systems intrusion may represent a significant weakness in the security
of an SCI entity's systems and thus warrant dissemination of
information to an SCI entity's members or participants. However,
because detailed information about a systems intrusion may expose an
SCI entity's systems to further probing and attack, an SCI entity would
only be required to provide a summary description of the systems
intrusion, including a description of the corrective action taken by
the SCI entity and when the systems intrusion has been or is expected
to be resolved.\162\ In addition, because immediate dissemination of
information about a systems intrusion may in some cases further
compromise the security of the SCI entity's SCI systems or SCI security
systems, or an investigation of the systems intrusion, an SCI entity in
some cases may be permitted to delay the dissemination of information
about such systems intrusion.\163\
---------------------------------------------------------------------------

    \162\ See infra Section III.C.3.c and proposed Rule
1000(b)(5)(ii).
    \163\ See id.
---------------------------------------------------------------------------

    Finally, the Commission is proposing that any systems disruption
that results, or the SCI entity reasonably estimates would result, in
significant harm or loss to market participants would also be a
dissemination SCI event. Some systems disruptions may have an
immediate, obvious, and detrimental impact on market participants,
hampering the ability of an SCI entity's members or participants to
utilize the SCI entity's SCI systems and, in some cases, making

such systems unusable. At the same time, the Commission recognizes that
disseminating information relating to a single systems disruption that
results in harm or loss to one or a small number of market participants
that is not significant may not warrant the cost of such dissemination.
Furthermore, the Commission preliminarily believes that the proposed
standard is appropriate in that it does not set a specific threshold or
definition of ``significant harm or loss to market participants,'' and
provides an SCI entity with reasonable discretion in estimating whether
a given systems disruption has resulted, or would result, in
significant harm or loss to market participants.\164\ Although the
particular facts and circumstances will differ for each systems
disruption, some systems disruptions would clearly result in
significant harm or loss to market participants and warrant
dissemination of information regarding such systems disruption to the
SCI entity's members or participants, even if the harm or loss, or the
potential harm or loss, is difficult to quantify. For example, if a
market experiences a problem with a trading system such that order
processing and execution in certain securities is halted and members
are not able to confirm transactions in such securities, the Commission
preliminarily believes that such a systems disruption would be a
dissemination SCI event. In contrast, if a trading market or a clearing
agency experienced a momentary power disruption causing a fail over to
the backup data center with no customer, member, or participant impact,
such SCI event would be a systems disruption requiring written notice
to the Commission, but would not be a dissemination SCI event.
---------------------------------------------------------------------------

    \164\ The tradeoffs of setting thresholds are discussed in the
Economic Analysis Section below. See infra Section V.B.
---------------------------------------------------------------------------

Request for Comment
    44. Do commenters believe the proposed definition of
``dissemination SCI event'' is appropriate? Why or why not?
    45. Do commenters believe that a ``systems compliance issue''
should constitute a dissemination SCI event? Why or why not? Please
explain.
    46. Do commenters believe that a ``systems intrusion'' should
constitute a dissemination SCI event? Why or why not? Please explain.
    47. Do commenters believe that systems disruptions that meet the
``significant harm or loss to market participants'' standard should be
included as dissemination SCI events? Why or why not? If not, what
would be an appropriate threshold, and how should it be measured?
Should the term ``significant harm or loss to market participants'' be
further clarified or defined in the rule? Why or why not? If so, what
should such clarification or definition be and why?
    48. Would an alternative measurement, or group of alternative
measurements, for systems disruptions, such as a 50 millisecond pause
in service or some other nonmonetary measure (for example, out of
memory situations, memory overloads, data loss due to an SCI system
exceeding capacity limitations, excessive queuing or throttling), also
be an appropriate and effective means to measure certain events about
which an SCI entity should disseminate information to its members or
participants? If so, what are they and why? Should any such
measurements vary based on the type of SCI system involved? If so, how?
Please be specific.
    49. Are there any other types of systems disruptions that should be
required to be disseminated to members or participants? If so, please
explain why. Should, for example, information relating to a systems
disruptions be required to be disseminated to members or participants
if it affects a certain number of market participants? If so, how
should such a level (number of market participants) be determined?
4. Material Systems Changes
    Rule 1000(a) of proposed Regulation SCI would define ``material
systems change'' as ``a change to one or more: (1) SCI systems of an
SCI entity that: (i) Materially affects the existing capacity,
integrity, resiliency, availability, or security of such systems; (ii)
relies upon materially new or different technology; (iii) provides a
new material service or material function; or (iv) otherwise materially
affects the operations of the SCI entity; or (2) SCI security systems
of an SCI entity that materially affects the existing security of such
systems.'' \165\ This proposed definition of ``material systems
change'' is substantively similar to the definition of ``significant
system change'' discussed in the ARP II Release.\166\
---------------------------------------------------------------------------

    \165\ See proposed Rule 1000(a). See also infra Sections III.C.4
and III.C.6 discussing notices of material systems changes and
reports of material systems changes, respectively.
    \166\ See ARP II Release, supra note 1, at 22592-93. See also
2001 Staff ARP Interpretive Letter, supra note 35 (citing ARP II,
supra note 1, at 22492-93: ``ARP II provides a non-exclusive list of
factors that should be considered in determining whether a system
change is significant and should be reported. The list includes a
change that: (1) Affects existing capacity or security; (2) in
itself raises capacity or security issues, even if it does not
affect other existing systems; (3) relies upon substantially new or
different technology; (4) is designed to provide a new service or
function for SRO members or their customers; or (5) otherwise
significantly affects the operations of the entity.'').
---------------------------------------------------------------------------

    Item (1)(i) of the proposed definition of material systems change
differs from item (1) in the definition in the ARP II Release of
``significant system change,'' as proposed item (1)(i) refers to
changes to an SCI entity's SCI systems that affect not only capacity
and security, but also integrity, resiliency, and availability.\167\
Items (1)(ii) and (1)(iii) in the proposed definition of material
systems change are intended to be substantively identical to items (3)
and (4) of the definition of significant system change in the 2001
Staff ARP Interpretive Letter, generally covering changes to an SCI
entity's SCI systems designed to advance systems development.\168\
Proposed item (1)(iv), covering a change to an SCI entity's SCI systems
that ``otherwise materially affects the operations of the SCI entity,''
is intended to require notification of major systems changes to SCI
systems that are not captured by other elements of paragraph (1) of the
proposed definition. Proposed item (2), covering a change to an SCI
entity's SCI security systems that ``materially affects the existing
security of such systems,'' is intended to ensure that significant
changes that would affect the security of an SCI entity's SCI security
systems (i.e., systems that share network resources with SCI systems
that, if breached, would be reasonably likely to pose a security threat
to SCI systems) \169\ are reported to the Commission.
---------------------------------------------------------------------------

    \167\ Proposed item (1)(i) consolidates items (1) and (2) of the
definition of material systems change in the 2001 Staff ARP
Interpretive Letter. The Commission believes that the addition of
integrity, resiliency, and availability aspects of SCI systems that
are important in today's automated trading environments
appropriately reflects the evolution of the types of systems issues
since the 2001 Staff ARP Interpretive Letter.
    \168\ In addition, each of proposed items (1)(i) through
(1)(iii) are changes that concern the adequacy of capacity
estimates, testing, and security measures taken by an SCI entity,
for which adequate procedures are required by proposed Rule
1000(b)(1). See infra Section III.C.1.
    \169\ See supra Section III.B.2 (discussing definition of SCI
security system).
---------------------------------------------------------------------------

    Examples that the Commission preliminarily believes could be
included within the proposed definition of material systems change are:
Major systems architecture changes; reconfigurations of systems that
would cause a variance greater than five percent in throughput or
storage; the introduction of new business functions or services;
changes to external interfaces; changes that could increase
susceptibility to major outages; changes that could increase risks to
data

security; changes that were, or would be, reported to or referred to
the entity's board of directors, a body performing a function similar
to the board of directors, or senior management; and changes that could
require allocation or use of significant resources. These examples are
cited in the 2001 Staff ARP Interpretive Letter.\170\ Based on
Commission staff's experience working with SROs that have relied on the
guidance provided in the 2001 Staff ARP Interpretive Letter, the
Commission preliminarily believes that such examples could continue to
be relevant guidance to SCI SROs as well as to other SCI entities. In
addition, the Commission preliminarily believes that any systems change
occurring as a result of the discovery of an actual or potential
systems compliance issue, as that term would be defined in proposed
Rule 1000(a), would be material.
---------------------------------------------------------------------------

    \170\ See supra note 35.
---------------------------------------------------------------------------

    Based on its experience with SROs and other entities reporting
significant systems changes in the context of the ARP Inspection
Program, the Commission preliminarily believes that the proposed
definition of material systems change is appropriate for all SCI
entities. The Commission preliminarily believes that proposed items
(1)(i)-(iv) and (2), which would cover changes affecting capacity
estimates, security measures, the use of new technology and new
functionality, could also highlight the need for SCI entities that are
SROs, when applicable, to file a proposed rule change with the
Commission under Section 19(b) of the Exchange Act and SCI entities
that are SROs to file proposed amendments for SCI Plans under Rule 608
of Regulation NMS.\171\ As the Commission noted in ARP II, the purpose
of urging SROs to notify Commission staff of significant system changes
was not to supplant or provide an alternative means for SROs to satisfy
their obligations to file proposed rule changes as required by the
Exchange Act.\172\ Rather, under ARP II, the Commission was primarily
concerned with fulfilling its oversight responsibilities and was also
interested in obtaining a full view and understanding of systems
development at SROs.\173\ Likewise, the proposal to require an SCI
entity to notify the Commission of material systems changes would not
relieve an SCI SRO of any obligation it may have to file a proposed
rule change, the participants of an SCI Plan to file a proposed
amendment to such SCI Plan, or any other obligation any SCI entity may
have under the Exchange Act or rules thereunder.\174\
---------------------------------------------------------------------------

    \171\ Section 19(b)(1) of the Exchange Act requires an SRO to
file proposed rules and proposed rule changes with the Commission in
accordance with rules prescribed by the Commission. See 15 U.S.C.
78s(b)(1). Section 19(b)(1) further requires the Commission to
solicit public comment on any proposed rule change filed by an SRO.
See id. Rule 608(a)(1) of Regulation NMS under the Exchange Act, 17
CFR 242.608(a)(1), permits ``self-regulatory organizations, acting
jointly, [to] file a national market system plan or [to] propose an
amendment to an effective national market system plan.'' Rule 608(b)
of Regulation NMS, 17 CFR 242.608(b), requires the Commission to
publish such proposed national market system plan or national market
system plan amendment for notice and comment, and, in certain
situations, approve such NMS plan or plan amendment before it may
become effective.
    \172\ See ARP II, supra note 1, at 22493. ARP II explained that
because the rule change process pursuant to Section 19(b) of the
Exchange Act and Rule 19b-4 thereunder ``imposes shortened
timeframes for action on proposed rule changes and because not all
systems changes trigger the need for changes to rules of the SROs,''
the rule change process was not providing staff with timely and
complete detail on various significant systems changes occurring at
the SROs. The policy of urging SROs to provide timely and accurate
information on systems changes was intended as an adjunct to, and
not a substitution for the rule change process. See id.
    \173\ See id. at 22493-94, n. 20.
    \174\ See infra request for comment in Section III.C.1.b,
wherein the Commission solicits comment on whether SCI SROs should
be required to provide notice to their members of anticipated
technology deployments prior to implementation and offer their
members the opportunity to test anticipated technology deployments
prior to implementation.
---------------------------------------------------------------------------

Request for Comment
    50. The Commission requests comment generally on the proposed
definition of ``material systems change.'' Is the proposed definition
of material systems change clear? Should the Commission provide
additional guidance on, or further define what would constitute a
``material systems change?'' Are there other factors that should be
included? Please be specific and give examples of types of system
changes that should be included in the proposed definition but
currently are not.
    51. The Commission sets forth above examples of systems changes
that it preliminarily believes could be included within the proposed
definition of material systems change (i.e., major systems architecture
changes; reconfigurations of systems that would cause a variance
greater than five percent in throughput or storage; the introduction of
new business functions or services; changes to external interfaces;
changes that could increase susceptibility to major outages; changes
that could increase risks to data security; changes that were, or would
be, reported to or referred to the entity's board of directors, a body
performing a function similar to the board of directors, or senior
management; and changes that could require allocation or use of
significant resources). Do commenters agree each of these examples
could constitute material systems changes? Why or why not?
    52. Should any of the proposed factors be eliminated or refined? If
so, please explain. Should material systems changes be defined to
include cumulative systems changes over a specified period that might
not otherwise qualify individually as a material systems change? For
example, if systems changes (such as reconfigurations of systems that
would cause a variance greater than five percent in throughput or
storage) occurred that, on their own, each would not constitute a
material systems change but, if grouped together with other similar or
even identical changes (or, alternatively, that occurred repeatedly
over a certain period of time such as a week or a month) could
represent a material system change, should such changes together be
considered a material systems change? If so, what would be the
appropriate number of similar or identical systems changes that should
be considered and/or what would be an appropriate time period to
consider? Should all non-material systems changes count towards this
threshold or should only non-material systems changes of the same or
similar type count? Would cumulative changes over a week be an
appropriate measurement period? Would a 30-day measurement period be
appropriate? Should the period be longer or shorter? Please explain.
    53. Do commenters believe that a change to the SCI systems of an
SCI entity that ``materially affects the existing capacity, integrity,
resiliency, availability, or security of such systems'' should
constitute a material systems change as proposed? Why or why not?
Should a change with respect to any of the proposed characteristics of
such systems (i.e., capacity, integrity, resiliency, availability, or
security) be eliminated or modified? Should any be added? Please
explain.
    54. Should a change to the SCI systems of an SCI entity that
``relies upon materially new or different technology'' constitute a
material systems change as proposed? Why or why not? Is the phrase
``materially new or different'' sufficiently clear? If not, please
explain.
    55. Should a change to an SCI entity's SCI systems that ``provides
a new material service or material function'' constitute a material
systems change as proposed? Why or why not? Is the phrase ``a new
material service or

material function'' sufficiently clear? If not, please explain.
    56. Do commenters believe it is appropriate to include a change to
an SCI entity's SCI systems that ``otherwise materially affects the
operations of the SCI entity'' as proposed? Why or why not? Please
explain.
    57. Do commenters believe that a change to the SCI security systems
of an SCI entity that ``materially affects the existing security of
such systems'' should constitute a material systems change as proposed?
Why or why not? Please explain.
    58. Do commenters believe the rule should include quantitative
criteria or other minimum thresholds for the effect of a change to an
SCI entity's SCI systems or SCI security systems beyond which the
Commission must be notified of the change? Why or why not? If so, what
should such quantitative criteria or other minimum thresholds be and
why?
    59. How often do SCI entities currently make material systems
changes? How often do SCI SROs make material systems changes and what
percentage of the time are such changes filed with the Commission as
proposed rule changes under Section 19 of the Exchange Act?

C. Proposed Rule 1000(b): Obligations of SCI Entities

    Paragraph (b) of proposed Rule 1000 would set forth requirements
that would apply to SCI entities relating to written policies and
procedures, obligations with regard to corrective actions, reporting of
SCI events to the Commission, dissemination of information relating to
certain SCI events to members or participants, reporting of material
systems changes, SCI reviews, and the participation of designated
members or participants of SCI entities in testing the business
continuity and disaster recovery plans of SCI entities.
1. Policies and Procedures To Safeguard Capacity, Integrity,
Resiliency, Availability, and Security \175\
---------------------------------------------------------------------------

    \175\ See infra Sections IV.D.1.a and V.B for discussions
related to current practices of SCI entities.
---------------------------------------------------------------------------

    Proposed Rule 1000(b)(1) would require each SCI entity to
establish, maintain, and enforce written policies and procedures,
reasonably designed to ensure that its SCI systems and, for purposes of
security standards, SCI security systems, have levels of capacity,
integrity, resiliency, availability, and security, adequate to maintain
the SCI entity's operational capability and promote the maintenance of
fair and orderly markets. Proposed Rule 1000(b)(1)(i) would further
provide that such policies and procedures include, at a minimum: ``(A)
The establishment of reasonable current and future capacity planning
estimates; (B) periodic capacity stress tests of such systems to
determine their ability to process transactions in an accurate, timely,
and efficient manner; (C) a program to review and keep current systems
development and testing methodology for such systems; (D) regular
reviews and testing of such systems, including backup systems, to
identify vulnerabilities pertaining to internal and external threats,
physical hazards, and natural or manmade disasters; (E) business
continuity and disaster recovery plans that include maintaining backup
and recovery capabilities sufficiently resilient and geographically
diverse to ensure next business day resumption of trading and two-hour
resumption of clearance and settlement services following a wide-scale
disruption; and (F) standards that result in such systems being
designed, developed, tested, maintained, operated, and surveilled in a
manner that facilitates the successful collection, processing, and
dissemination of market data.'' \176\ Proposed Rule 1000(b)(1)(ii)
would deem an SCI entity's policies and procedures required by proposed
Rule 1000(b)(1) to be reasonably designed if they are consistent with
SCI industry standards.\177\ In particular, for purposes of complying
with proposed Rule 1000(b)(1), if an SCI entity has policies and
procedures that are consistent with such SCI industry standards, as
discussed further in Section III.C.1.b below, such policies and
procedures would be deemed to be reasonably designed and thus the SCI
entity would be in compliance with proposed Rule 1000(b)(1). In
addition, under proposed Rule 1000(b)(1)(ii), compliance with the
identified SCI industry standards would not be the exclusive means to
comply with the requirements of proposed Rule 1000(b)(1).
---------------------------------------------------------------------------

    \176\ See proposed Rule 1000(b)(1)(i)(A)-(F).
    \177\ See infra Section III.C.1.b.
---------------------------------------------------------------------------

a. Proposed Rule 1000(b)(1)(i)
    Proposed Rule 1000(b)(1) would require that an SCI entity have
policies and procedures that address items (i)(A)-(F) for its SCI
systems and, for purposes of security standards, SCI security systems.
Items (A)-(C) enumerated in proposed Rule 1000(b)(1)(i) are
substantively the same as the requirements of Rule 301(b)(6)(ii)(A)-(C)
of Regulation ATS, applicable to significant-volume alternative trading
systems, and trace their origin to the ARP I Release.\178\ With respect
to SCI systems and, as applicable, SCI security systems, proposed item
(A), which would require an SCI entity to establish, maintain, and
enforce policies and procedures for the establishment of reasonable
current and future capacity planning estimates, and proposed item (B),
which would require an SCI entity to establish, maintain, and enforce
policies and procedures for periodic capacity stress tests of such
systems, would help an SCI entity determine its systems' ability to
process transactions in an accurate, timely, and efficient manner, and
thereby help ensure market integrity. Proposed item (C), which would
require an SCI entity to establish, maintain, and enforce policies and
procedures that include a program to review and keep current systems
development and testing methodology for such systems, would help ensure
that the SCI entity continues to monitor and maintain systems capacity
and availability.
---------------------------------------------------------------------------

    \178\ See 17 CFR 242.301(b)(6)(ii)(A)-(C); see also ARP I
Release, supra note 1, at 48706-07.
---------------------------------------------------------------------------

    Proposed item (D), which would require an SCI entity to establish,
maintain, and enforce policies and procedures to review and test
regularly such systems, including backup systems, to identify
vulnerabilities pertaining to internal and external threats, physical
hazards, and natural or manmade disasters, would likewise assist an SCI
entity in ascertaining whether its SCI systems and SCI security systems
are and remain sufficiently secure and resilient. Unlike Rule
301(b)(6)(ii)(D) of Regulation ATS, proposed item (D) includes
``manmade disasters'' in the list of vulnerabilities an SCI entity
would be required to consider and protect against. The Commission
proposes to add ``manmade disasters'' to be clear that acts of
terrorism and sabotage--threats that some SCI entities have faced in
recent history \179\--are threats that an SCI entity must prepare for
in reviewing and testing its systems and operations.
---------------------------------------------------------------------------

    \179\ See, e.g., supra note 61.
---------------------------------------------------------------------------

    Proposed items (B), (C), and (D) would each require, among other
things, the establishment of policies and procedures relating to
various aspects of systems testing, including capacity stress tests,
testing methodology, and tests for systems vulnerabilities to internal
and external threats, physical hazards, and natural or manmade
disasters, respectively. The Commission preliminarily believes that, to
help ensure an effective testing regime, such

policies and procedures would need to address when testing with
members, participants, and other market participants would be
appropriate.\180\
---------------------------------------------------------------------------

    \180\ See also the Commission's request for comment in infra
Sections III.C.1.b and III.C.7, on whether proposed Regulation SCI
should be more prescriptive regarding testing standards and
requirements in light of comments on testing made by Roundtable
panelists and commenters, and the closure of the national securities
exchanges in the wake of Superstorm Sandy, as discussed in the text
accompanying supra notes 78-83.
---------------------------------------------------------------------------

    Proposed item (E), which would require SCI entities to establish,
maintain, and enforce policies and procedures for business continuity
and disaster recovery plans, is substantially similar to a requirement
in Rule 301(b)(6)(ii) of Regulation ATS and ARP I.\181\ However,
proposed item (E) would further require SCI entities to have plans for
maintaining backup and recovery capabilities sufficiently resilient and
geographically diverse to ensure next business day resumption of
trading and two-hour resumption of clearance and settlement services
following a wide-scale disruption. The proposed resiliency and
geographic diversity requirement is designed particularly to help
ensure that an SCI entity would be able to continue operations from the
backup site during a wide-scale disruption resulting from natural
disasters, terrorist activity, or other significant events. For
example, the Commission preliminarily believes that backup sites should
not rely on the same infrastructure components (e.g., transportation,
telecommunications, water supply, and electric power) used by the
primary site.\182\ The proposed next business day trading resumption
standard reflects the Commission's preliminary view that an SCI entity,
being part of the critical infrastructure of the U.S. securities
markets, should have plans to limit downtime caused by a wide-scale
disruption to less than one business day.\183\ Likewise, the proposed
two-hour resumption standard for clearance and settlement services,
which traces its origin to the 2003 Interagency White Paper,\184\
reflects the Commission's preliminary view that an SCI entity that is a
registered clearing agency or an ``exempt clearing agency subject to
ARP'' should have contingency plans to avoid a scenario in which
failure to settle transactions by the end of the day could present
systemic risk to the markets.\185\
---------------------------------------------------------------------------

    \181\ See 17 CFR 242.301(b)(6)(ii)(E); ARP I Release, supra note
1, at 48706.
    \182\ See 2003 Interagency White Paper, supra note 31.
     As discussed further below in Section III.C.1.b, proposed Rule
1000(b)(1) would require an SCI entity to have policies and
procedures that are ``reasonably designed'' and ``adequate to
maintain [its] operational capability and promote the maintenance of
fair and orderly markets.'' Proposed Rule 1000(b)(1)(i)(E) would
require that such policies and procedures include ``business
continuity and disaster recovery plans that include maintaining
backup and recovery capabilities sufficiently resilient and
geographically diverse,'' (emphasis added) to ensure next business
day or two-hour resumption as applicable, following a wide-scale
disruption. While ``sufficient'' geographic diversity would be a
required element of reasonably designed business continuity and
disaster recovery plans, the proposed rule does not specify any
particular minimum distance or geographic location that would be
necessary to achieve the requisite level of geographic diversity.
Instead, the proposed rule focuses on the ability to achieve the
goal of resuming business within the applicable time frame in the
wake of a wide-scale disruption. As noted above, the Commission also
preliminarily believes that an SCI entity should have a reasonable
degree of flexibility to determine the precise nature and location
of its backup site depending on the particular vulnerabilities
associated with those sites, and the nature, size, technology,
business model, and other aspects of its business.
    \183\ Standards with respect to resilient and geographically
remote back-up sites and resumption of operations are discussed in
the 2003 Interagency White Paper and the 2003 Policy Statement on
Business Continuity Planning for Trading Markets, and these
publications are proposed to be designated as industry standards in
the context of contingency planning. See 2003 Interagency White
Paper, supra note 31 and 2003 Policy Statement on Business
Continuity Planning for Trading Markets, supra note 32.
     In addition, the 2003 Policy Statement on Business Continuity
Planning for Trading Markets urged SRO markets and ECNs to ``have a
business continuity plan that anticipates the resumption of trading
* * * no later than the next business day following a wide-scale
disruption.'' See supra note 32, at 56658.
    \184\ See supra note 31. See also infra note 195, discussing
further the 2003 Interagency White Paper.
    \185\ The Commission believes that all clearing agencies that
would be subject to proposed Regulation SCI (i.e., all of the
registered clearing agencies and the current ``exempt clearing
agency subject to ARP'') currently strive to adhere to this
standard.
---------------------------------------------------------------------------

    Proposed item (F) would require SCI entities to have standards that
result in systems being designed, developed, tested, maintained,
operated, and surveilled in a manner that facilitates the successful
collection, processing, and dissemination of market data. As the
Commission previously noted, when Congress mandated a national market
system in 1975, it emphasized that the systems for collecting and
distributing consolidated market data would ``form the heart of the
national market system.'' \186\ As a result of consolidated market
data, the public has ready access to a comprehensive, accurate, and
reliable source of information for the prices and volume of any NMS
stock at any time during the trading day.\187\ This information helps
to ensure that the public is aware of the best displayed prices for a
stock, no matter where they may arise in the national market
system.\188\ It also enables investors to monitor the prices at which
their orders are executed and assess whether their orders received best
execution.\189\ Further, as noted above, one of the findings of the May
6 Staff Report is that ``fair and orderly markets require that the
standards for robust, accessible, and timely market data be set quite
high.'' \190\ The Commission believes that the accurate, timely and
efficient processing of data is similarly important to the proper
functioning of the securities markets. For example, if a clearing
agency were not able to process data accurately, settlements could
potentially be impacted. Similarly, if an exchange does not process
trades accurately, erroneous executions could occur.
---------------------------------------------------------------------------

    \186\ See Concept Release on Equity Market Structure, supra note
42, at 3600 (quoting H.R. Rep. No. 94-229, 94th Cong., 1st Sess. 93
(1975)).
    \187\ See id.
    \188\ See id.
    \189\ See id. The benefits of consolidated market data discussed
here are true for the options markets as well.
    \190\ See May 6 Staff Report, supra note 56, at 8.
---------------------------------------------------------------------------

    Consistent with these goals and Congress's statement, proposed item
(F) would be a new requirement that has no precedent in either Rule
301(b)(6) of Regulation ATS or the ARP policy statements and would
require SCI entities to have ``standards that result in such systems
being designed, developed, tested, maintained, operated, and surveilled
in a manner that facilitates the successful collection, processing, and
dissemination of market data.'' \191\ The Commission preliminarily
believes that proposed item (F) would assist an SCI entity in ensuring
that its market data systems are designed to maintain market integrity.
---------------------------------------------------------------------------

    \191\ This proposed requirement is consistent with Rule 603(a)
of Regulation NMS, which states that any ``* * * broker or dealer
with respect to information for which it is the exclusive source,
that distributes information with respect to quotations for or
transactions in an NMS stock to a securities information processor
shall do so on terms that are fair and reasonable.'' In adopting
Regulation NMS, the Commission stated that Rule 603(a) ``prohibits
an SRO or broker-dealer from transmitting data to a vendor or user
any sooner than it transmits the data to a Network processor.'' Rule
603(a) by its terms applies only to NMS stocks. See supra note 121.
See also 17 CFR 242.603(a).
---------------------------------------------------------------------------

b. Proposed Rule 1000(b)(1)(ii)
    Proposed Rule 1000(b)(1) would generally require that each SCI
entity's policies and procedures be reasonably designed to ensure that
its SCI systems and, for purposes of security standards, SCI security
systems, ``have levels of capacity, integrity, resiliency,
availability, and security, adequate to maintain the SCI entity's
operational capability and promote the maintenance

of fair and orderly markets.'' As discussed above, proposed Rule
1000(b)(1)(i) would also require that an SCI entity have policies and
procedures that address items (A)-(F). The Commission notes that SCI
entities that are ARP participants have been applying the ARP I
principles underlying proposed Rule 1000(b)(1)(i)(A)-(F) for many
years. However, while the items enumerated in proposed Rule
1000(b)(1)(i)(A)-(F) identify the areas that would be required to be
addressed by an SCI entity's policies and procedures, the Commission is
not proposing to prescribe the specific policies and procedures an SCI
entity must follow to comply with the requirements of proposed Rule
1000(b)(1). Instead, the Commission intends to, and preliminarily
believes that the proposed requirements as written would, provide SCI
entities sufficient flexibility, based on the nature, size, technology,
business model, and other aspects of their business, to identify
appropriate policies and procedures that would meet the articulated
standard, namely that they be reasonably designed to ensure that their
systems have levels of capacity, integrity, resiliency, availability,
and security adequate to maintain the SCI entity's operational
capability and promote the maintenance of fair and orderly markets.
However, the Commission also preliminarily believes that it would be
helpful to SCI entities to provide additional guidance about one way in
which they might elect to satisfy this general standard in proposed
Rule 1000(b)(1). Therefore, the Commission is proposing Rule
1000(b)(1)(ii), which would provide that, for purposes of complying
with proposed Rule 1000(b)(1), an SCI entity's policies and procedures
would be deemed to be reasonably designed, and thus satisfy the
requirements of proposed Rule 1000(b)(1), if they are consistent with
current SCI industry standards. Proposed Rule 1000(b)(1)(ii) further
states that such SCI industry standards shall be: (A) comprised of
information technology practices that are widely available for free to
information technology professionals in the financial sector; and (B)
issued by an authoritative body that is a U.S. governmental entity or
agency, association of U.S. governmental entities or agencies, or
widely recognized organization. Proposed Rule 1000(b)(1)(ii) would
additionally provide that compliance with the SCI industry standards
identified in the proposal would not be the exclusive means to comply
with the requirements of paragraph (b)(1). As noted above, the
Commission intends to, and preliminarily believes that the proposed
requirements as written would, provide SCI entities sufficient
flexibility, based on the nature, size, technology, business model, and
other aspects of their business, to identify appropriate policies and
procedures to comply with proposed Rule 1000(b)(1).
    The Commission is proposing this approach because it preliminarily
believes that providing additional guidance on the types of industry
standards that would satisfy the requirements of proposed Rule
1000(b)(1) could assist an SCI entity in determining how to best
allocate resources to maintain its systems' operational capability, and
promote the maintenance of fair and orderly markets.\192\ The
Commission acknowledges that current industry standards applicable to
SCI entities have been developed in a number of areas to help ensure
that systems have adequate capacity, integrity, resiliency,
availability, and security. Accordingly, the current SCI industry
standards that would be deemed to be reasonably designed for purposes
of proposed Rule 1000(b)(1) are not limited to the SCI industry
standards discussed and contained in the publications identified in
Table A below, but rather may be found in a variety of publications,
issued by a range of sources. The Commission acknowledges that an SCI
entity's choice of a current SCI industry standard in a given domain or
subcategory thereof may be different than those contained in the
publications identified in Table A. Further, some of the identified
standards may be more relevant for some SCI entities than others, based
on the nature and amount of their respective activities. Thus, the
Commission's proposed approach is designed to provide a non-exclusive
method of compliance.
---------------------------------------------------------------------------

    \192\ See infra Sections V.B and V.C, discussing market failures
and the anticipated economic benefits of proposed Regulation SCI.
Each SCI entity, to the extent it seeks to rely on SCI industry
standards in complying with proposed Rule 1000(b)(1), would have
discretion to identify those industry standards that provide an
appropriate way for it to comply with the requirements set forth in
the rule, given its technology, business model, and other factors.
---------------------------------------------------------------------------

    The Commission preliminarily believes that the publications set
forth in Table A below \193\ contain examples of SCI industry standards
that an SCI entity may elect to look to in establishing its policies
and procedures under proposed Rule 1000(b)(1). However, as proposed
Rule 1000(b)(1)(ii) makes clear, compliance with such current SCI
industry standards would not be the exclusive means to comply with the
requirements of proposed Rule 1000(b)(1). Thus, as proposed, written
policies and procedures that are consistent with the relevant examples
of SCI industry standards contained in the publications identified in
Table A, would be deemed to be ``reasonably designed'' for purposes of
proposed Rule 1000(b)(1). The publications identified in Table A cover
nine inspection areas, or ``domains,'' that have evolved over the past
20 years of the ARP Inspection Program and that are relevant to SCI
entities' systems capacity, integrity, resiliency, availability, and
security, namely: Application controls; capacity planning; computer
operations and production environment controls; contingency planning;
information security and networking; audit; outsourcing; physical
security; and systems development methodology.
---------------------------------------------------------------------------

    \193\ Each of these publications would meet the proposed
criteria that they be: (i) Information technology practices that are
widely available for free to information technology professionals in
the financial sector; and (ii) issued by an authoritative body that
is a U.S. governmental entity or agency, association of U.S.
governmental entities or agencies, or widely recognized
organization. See proposed Rules 1000(b)(1)(ii).
---------------------------------------------------------------------------

    The publications included in Table A set forth industry standards
that the Commission understands are currently used by information
technology and audit professionals in the financial and government
sectors. These industry standards have been issued primarily by NIST
and FFIEC. NIST, an agency within the U.S. Department of Commerce, has
issued special publications regarding information technology systems.
The FFIEC is a U.S. intergovernmental body that prescribes uniform
principles and practices for the examination of certain financial
institutions by U.S. regulators, and has issued publications on
numerous topics, including development and acquisition of applications,
computer operations, outsourcing technology, business continuity
planning, information security, and internal audits.\194\ In addition
to these standards issued by FFIEC and NIST, financial regulatory
agencies, including the Commission, provided guidance on business
continuity and disaster recovery plans

in the 2003 Interagency White Paper \195\ and the 2003 Policy Statement
on Business Continuity Planning for Trading Markets.\196\
---------------------------------------------------------------------------

    \194\ The federal agencies represented on the FFIEC are the
Board of Governors of the Federal Reserve System, the Federal
Deposit Insurance Corporation, the National Credit Union
Administration, Office of the Comptroller of the Currency, and the
Consumer Financial Protection Bureau.
    \195\ See 2003 Interagency White Paper, supra note 31. In the
2003 Interagency White Paper, which was issued jointly by the
Commission, the Board of Governors of the Federal Reserve System,
and the Office of the Comptroller of the Currency, the agencies
identified a broad consensus on three important business continuity
objectives: (1) Rapid recovery and timely resumption of critical
operations following a wide-scale disruption; (2) rapid recovery and
timely resumption of critical operations following the loss or
inaccessibility of staff in at least one major operating location;
and (3) a high level of confidence, through ongoing use or robust
testing, that critical internal and external continuity arrangements
are effective and compatible. See id. at 17811.
    The agencies also identified sound practices for core clearing
and settlement organizations and firms that play significant roles
in critical financial markets. They stated that in this context,
``core clearing and settlement organizations'' consist of market
utilities that provide clearing and settlement services for critical
financial markets or act as large-value payment system operators and
present systemic risk to the markets should they be unable to
perform. ``Firms that play significant roles in critical financial
markets'' refers to organizations whose participation in one or more
critical financial markets is significant enough that their failure
to settle their own or their customers' material pending
transactions by the end of the day could present systemic risk to
the markets. The sound practices address the risks of a wide-scale
disruption and strengthen the resilience of the financial system.
They also reduce the potential that key market participants will
present systemic risk to one or more critical markets because
primary and back-up processing facilities and staffs are
concentrated within the same geographic region.
    The sound practices are as follows. First, identify clearing and
settlement activities in support of critical financial markets.
These activities include the completion of pending large-value
payments; clearance and settlement of material pending transactions;
meeting material end-of-day funding and collateral obligations
necessary to ensure the performance of pending large-value payments
and transactions; and updating records of accounts. Second,
determine appropriate recovery and resumption objectives for
clearing and settlement activities in support of critical markets.
In this regard, core clearing and settlement organizations are
expected to develop the capacity to recover and resume clearing and
settlement activities within the business day on which the
disruption occurs with the overall recovery goal of two hours after
an event. Third, maintain sufficient geographically dispersed
resources to meet recovery and resumption objectives. The 2003
Interagency White Paper states that back-up arrangements should be
as far away from the primary site as necessary to avoid being
subject to the same set of risks as the primary location and should
not rely on the same infrastructure components used by the primary
site. Fourth, routinely use or test recovery and resumption
arrangements. This includes regular tests of internal recovery and
resumption arrangements as well as cross-organization tests to
ensure the effectiveness and compatibility of recovery and
resumption strategies within and across critical markets. See id. at
17811-13.
    \196\ See supra note 32. The Commission's policy statement
applies more broadly to all ``SRO markets'' and ECNs, not just those
that play ``significant roles in critical financial markets,'' as
discussed in the 2003 Interagency White Paper. Each SRO market and
ECN is expected to (1) have in place a business continuity plan that
anticipates the resumption of trading in the securities traded by
that market no later than the next business day following a wide-
scale disruption; (2) maintain appropriate geographic diversity
between primary and back-up sites in order to assure resumption of
trading activities by the next business day; (3) assure the full
resilience of shared information streams, such as the consolidated
market data stream generated for the equity and options markets; and
(4) confirm the effectiveness of the back-up arrangements through
testing. See id. at 56658.
---------------------------------------------------------------------------

    Also included in Table A is a publication issued by the Institute
of Internal Auditors (``IIA''). The IIA is an international
professional association that has developed and published guidance
setting forth industry best practices in internal auditing for internal
audit professionals. It has more than 175,000 members in 165 countries
and territories around the world.\197\ IIA is also a credentialing
organization, awarding the Certified Internal Auditor (CIA), Certified
Government Auditing Professional (CGAP), Certified Financial Services
Auditor (CFSA), Certification in Control Self-Assessment (CCSA), and
Certification in Risk Management Assurance (CRMA) certifications to
those who meet the requirements.\198\ The Commission preliminarily
believes these factors support identification of IIA as an
authoritative body that is a widely recognized organization.
---------------------------------------------------------------------------

    \197\ See IIA's 2011 Annual Report, available at: https://na.theiia.org/about-us/Pages/Annual-Reports.aspx.
    \198\ See id.
---------------------------------------------------------------------------

    In addition, one of the publications identified in Table A is
issued by the Security Benchmarks division of the Center for Internet
Security (``CIS''). The CIS is a not-for-profit organization focused on
enhancing the cybersecurity readiness and response of public and
private sector entities. The CIS Security Benchmarks division
facilitates the development of industry best practices for security
configuration, tools for measuring information security status, and
resources to assist entities in making security investment
decisions.\199\ Its members include commercial organizations, academic
organizations, government agencies, and security service, consulting,
and software organizations.\200\ According to the CIS, its benchmarks
are regularly referred to by U.S. government agencies for compliance
with information security rules and regulations.\201\ The Commission
preliminarily believes these factors support a determination that CIS
is an authoritative body that is a widely recognized organization.
---------------------------------------------------------------------------

    \199\ See http://benchmarks.cisecurity.org/en-us/?route=default.about.
    \200\ See http://benchmarks.cisecurity.org/en-us/?route=membership.
    \201\ The CIS states that its benchmarks are widely accepted by
U.S. government agencies for compliance with the Federal Information
Security Management Act (FISMA), Gramm-Leach-Bliley Act, Sarbanes-
Oxley Act, The Health Insurance Portability and Accountability Act
of 1996 (HIPAA), and other the regulatory requirements for
information security. See http://benchmarks.cisecurity.org/en-us/?route=membership.
---------------------------------------------------------------------------

    Table A lists the publication(s) that the Commission has
preliminarily identified as SCI industry standard(s) in each domain
that an SCI entity, taking into account its nature, size, technology,
business model, and other aspects of its business, could, but is not
required to, use to establish, maintain, and enforce reasonably
designed policies and procedures that satisfy the requirements of
proposed Rule 1000(b)(1). Thus, the Commission is proposing that the
industry standards contained in the publications identified in Table A
be one example of ``current SCI industry standards'' for purposes of
proposed Rule 1000(b)(1), and requests commenters' views on the
appropriateness of each publication identified in Table A as a
``current SCI industry standard.'' Each listed publication is
identified with specificity, and includes the particular publication's
date, volume number, and/or publication number, as the case may be.
Thus, to the extent an SCI entity seeks to rely on SCI industry
standards for purposes of complying with proposed Rule 1000(b)(1)(ii),
the Commission intends SCI entities that establish policies and
procedures based on the SCI industry standards contained in the
publications set forth in Table A to enforce written policies and
procedures, taking into account their nature, size, technology,
business model, and other aspects of their business, consistent with
relevant standards, even if the issuing organization were to
subsequently update a given industry practice, until such time as the
list of SCI industry standards were to be updated, as discussed
below.\202\ Of course, SCI entities could elect to use standards
contained in the publications other than those identified on Table A to
satisfy the requirements of proposed Rule 1000(b)(1)\\.
---------------------------------------------------------------------------

    \202\ See discussion in this Section III.C.1.b following Table A
below.
    \203\ The Commission recently adopted a similar contingency
planning practice in Rule 17Ad-22(d)(4) that requires registered
clearing agencies to have policies and procedures designed to
identify sources of operational risk and minimize those risks
through the development of appropriate systems controls and
procedures. See Securities Exchange Act Release No. 68080 (October
22, 2012), 77 FR 66220 (November 2, 2012). See also supra note 95.

                        Table A--Publications Relating to Industry Standards in 9 Domains
----------------------------------------------------------------------------------------------------------------
                              Domain                                             Industry standards
----------------------------------------------------------------------------------------------------------------
Application Controls.............................................  NIST DRAFT Security and Privacy Controls for
                                                                    Federal Information Systems and
                                                                    Organizations (Special Publication 800-53
                                                                    Rev. 4) available at: http://csrc.nist.gov/publications/drafts/800-53-rev4/sp800-53-rev4-ipd.pdf.
Capacity Planning................................................  FFIEC, Operations IT Examination Handbook
                                                                    (July 2004), available at: http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Operations.pdf.
Computer Operations and Production Environment Controls..........  NIST DRAFT Security and Privacy Controls for
                                                                    Federal Information Systems and
                                                                    Organizations (Special Publication 800-53
                                                                    Rev. 4), available at: http://csrc.nist.gov/publications/drafts/800-53-rev4/sp800-53-rev4-ipd.pdf.
Contingency Planning (BCP) \203\.................................  NIST Contingency Planning Guide for Federal
                                                                    Information Systems (Special Publication 800-
                                                                    34 Rev. 1), available at: http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.
                                                                   2003 Interagency White Paper on Sound
                                                                    Practices to Strengthen the Resilience of
                                                                    the U.S. Financial System, Securities
                                                                    Exchange Act Release No. 47638 (April 8,
                                                                    2003), 68 FR 17809 (April 11, 2003),
                                                                    available at: http://www.sec.gov/news/studies/34-47638.htm.
                                                                   2003 Policy Statement on Business Continuity
                                                                    Planning for Trading Markets, Securities
                                                                    Exchange Act Release No. 48545 (September
                                                                    25, 2003), 68 FR 56656 (October 1, 2003),
                                                                    available at: http://www.sec.gov/rules/policy/34-48545.htm.
Information Security and Networking..............................  NIST DRAFT Security and Privacy Controls for
                                                                    Federal Information Systems and
                                                                    Organizations (Special Publication 800-53
                                                                    Rev. 4), available at: http://csrc.nist.gov/publications/drafts/800-53-rev4/sp800-53-rev4-ipd.pdf.
                                                                   NIST Guidelines on Security and Privacy in
                                                                    Public Cloud Computing (Special Publication
                                                                    800-144), available at: http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf.
                                                                   The Center for Internet Security
                                                                    Configuration Benchmarks, available at:
                                                                    http://benchmarks.cisecurity.org/en-us/?route=downloads.benchmarks.
Audit............................................................  FFIEC, Audit IT Examination Handbook (August
                                                                    2003), available at: http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf.
                                                                   IIA, The Role of Internal Auditing in
                                                                    Enterprise-wide Risk Management, available
                                                                    at: http://www.theiia.org/iia and http://www.theiaa.org/index.
Outsourcing......................................................  FFIEC, Outsourcing Technology Services IT
                                                                    Examination Handbook (June 2004), available
                                                                    at: http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_OutsourcingTechnologyServices.pdf.
Physical Security................................................  NIST DRAFT Security and Privacy Controls for
                                                                    Federal Information Systems and
                                                                    Organizations (Special Publication 800-53
                                                                    Rev. 4), available at: http://csrc.nist.gov/publications/drafts/800-53-rev4/sp800-53-rev4-ipd.pdf.
Systems Development Methodology..................................  NIST Security Considerations in the System
                                                                    Development Life Cycle (Special Publication
                                                                    800-64 Rev. 2), available at: http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf.
----------------------------------------------------------------------------------------------------------------

    As noted above, each of the publications listed in Table A is
intended to identify information technology practices that are widely
available for free to information technology professionals in the
financial sector and are issued by an authoritative body that is a U.S.
governmental entity or agency, association of U.S. governmental
entities or agencies, or widely recognized organization.
    Although the industry standards contained in the publications
identified in Table A above are intended as an appropriate initial set
of industry standards under proposed Regulation SCI, the Commission
does not seek to foreclose the development, whether by the Commission
or otherwise, of a set of industry standards that is more focused on
the specific businesses and systems of SCI entities.\204\ In such a
case, the Commission preliminarily believes that it would be
appropriate to use the industry standards contained in the publications
listed in Table A as a starting point for such development.
---------------------------------------------------------------------------

    \204\ Standards issued by the Commission itself would meet the
proposed criteria in that they would be: (i) Comprised of
information technology practices that are widely available for free
to information technology professionals in the financial sector; and
(ii) issued by an authoritative body that is a U.S. governmental
entity or agency, association of U.S. governmental entities or
agencies, or widely recognized organization.
---------------------------------------------------------------------------

    Further, the Commission recognizes that systems and technologies
are continually evolving. As such, the standards identified in this
proposal would likely be updated from time to time by the organizations
issuing them. However, the Commission also preliminarily believes that,
following its initial identification of one set of SCI industry
standards, it may be appropriate to update the identified set of
standards from time to time through the periodic issuance of Commission
staff guidance. Accordingly, the Commission preliminarily believes it
would be appropriate for Commission staff, from time to time, to issue
notices to update the list of previously identified set of SCI industry
standards after receiving appropriate input from interested
persons.\205\ The Commission preliminarily believes that this approach
would provide the public, including SCI entities and other market
participants, an opportunity to comment on newly proposed SCI industry
standards. However, until such time as Commission staff were to update
the identified set of SCI industry standards, the then-current set of
SCI industry standards would be the standards referred to in proposed
Rule 1000(b)(1)(ii) of Regulation SCI.
---------------------------------------------------------------------------

    \205\ As noted in the request for comment section below, the
Commission solicits comment on the ways in which appropriate input
from interested persons should be obtained for updating the SCI
industry standards.
---------------------------------------------------------------------------

    As noted above, proposed Rule 1000(b)(1)(ii) would require that any
SCI industry standards be: (i) Comprised of information technology
practices that are widely available for free to information technology
professionals in the financial sector; and (ii) issued by an
authoritative body that is a U.S. governmental entity or agency,
association of U.S. governmental entities or agencies, or a widely
recognized organization.

Request for Comment
    60. The Commission requests comment generally on proposed Rule
1000(b)(1). Do commenters believe the proposed scope of required
policies and procedures is appropriate? Why or why not? Please explain.
    61. Do commenters believe that it is appropriate to apply the
requirements of proposed Rule 1000(b)(1) to SCI systems and, for
purposes of security standards, to SCI security systems? Why or why
not? Please explain.
    62. Do commenters believe the enumeration of the items in proposed
Rule 1000(b)(1)(i)(A)-(F) that are to be addressed in the required
policies and procedures is appropriate? Why or why not? Specifically,
is the proposal to require that such policies and procedures include
the establishment of reasonable current and future capacity planning
estimates, as provided in proposed Rule 1000(b)(1)(i)(A), appropriate?
Why or why not?
    63. Should the Commission specify the interval (e.g., monthly or
quarterly) at which SCI entities would be required to conduct periodic
capacity stress tests of relevant systems, as provided in proposed Rule
1000(b)(1)(i)(B)? Should such periodic tests be limited to a subset of
systems? If so, for which systems should such tests be required and why
would that limitation be appropriate?
    64. Should the Commission require SCI entities to have a program to
review and keep current systems development and testing methodology, as
proposed to be required in proposed Rule 1000(b)(1)(i)(C)? Why or why
not?
    65. Should the Commission specify the interval at which SCI
entities would be required to conduct reviews and tests of SCI systems
and SCI security systems, including backup systems, to identify
vulnerabilities pertaining to internal and external threats, physical
hazards, and natural or manmade disasters, as provided in proposed Rule
1000(b)(1)(i)(D)? Why or why not? And, if so, what would be appropriate