a substantial number of small entities? If not, please describe the
nature of any impact on small entities and provide empirical data to
illustrate the extent of the impact.

VI. Statutory Authority and Text of the Proposed Amendments to the CAT
NMS Plan

    Pursuant to the Exchange Act and, particularly, Sections 2, 3(b),
5, 6, 11A(a)(3)(B), 15, 15A, 17(a) and (b), 19 and 23(a) thereof, 15
U.S.C. 78b, 78c(b), 78e, 78f, 78k-1, 78o, 78o-3, 78q(a) and (b), 78s,
78w(a), and pursuant to Rule 608(a)(2) and (b)(2),\802\ the Commission
proposes to amend the CAT NMS Plan in the manner set forth below.
---------------------------------------------------------------------------

    \802\ 17 CFR 242.608(a)(2) and (b)(2). These provisions enable
the Commission to propose amendments to any effective NMS Plan by
``publishing the text thereof, together with a statement of the
purpose of such amendment,'' and providing ``interested persons an
opportunity to submit written comments.''
---------------------------------------------------------------------------

    Additions are italicized; deletions are [bracketed].
* * * * *

Section 1.1. Definitions

    As used throughout this Agreement (including, for the avoidance
of doubt, the Exhibits, Appendices, Attachments, Recitals and
Schedules identified in this Agreement):
* * * * *
    ``[Customer]Account [Information]Attributes'' shall include, but
not be limited to, [account number,] account type, customer type,
date account opened, and large trader identifier (if applicable);
except, however, that (a) in those circumstances in which an
Industry Member has established a trading relationship with an
institution but has not established an account with that
institution, the Industry Member will (i) provide the Account
Effective Date in lieu of the ``date account opened''[; (ii) provide
the relationship identifier in lieu of the ``account number'';] and
([i]ii) identify the ``account type'' as a ``relationship''; (b) in
those circumstances in which the relevant account was established
prior to the implementation date of the CAT NMS Plan applicable to
the relevant CAT Reporter (as set forth in Rule 613(a)(3)(v) and
(vi)), and no ``date account opened'' is available for the account,
the Industry Member will provide the Account Effective Date in the
following circumstances: (i) Where an Industry Member changes back
office providers or clearing firms and the date account opened is
changed to the date the account was opened on the new back office/
clearing firm system; (ii) where an Industry Member acquires another
Industry Member and the date account opened is changed to the date
the account was opened on the post-merger back office/clearing firm
system; (iii) where there are multiple dates associated with an
account in an Industry Member's system, and the parameters of each
date are determined by the individual Industry Member; and (iv)
where the relevant account is an Industry Member proprietary
account.
* * * * *
    ``CAIS'' refers to the Customer and Account Information System
within the CAT System that collects and links Customer-ID(s) to
Customer and Account Attributes and other identifiers for queries by
Regulatory Staff.
    ``CAIS/CCID Subsystem Regulator Portal'' refers to the online
tool enabling Manual CAIS access and Manual CCID Subsystem access.
* * * * *
    ``CCID Subsystem'' refers to the subsystem within the CAT System
which will create the Customer-ID from a Transformed Value(s), as
set forth in Section 6.1(v) and Appendix D, Section 9.1.
    ``CCID Transformation Logic'' refers to the mathematical logic
identified by the Plan Processor that accurately transforms an
individual tax payer identification number(s)(ITIN(s))/social
security number(s)(SSN(s))/Employer Identification Number (EIN(s))
into a Transformed Value(s) for submission into the CCID Subsystem,
as set forth in Appendix D, Section 9.1.
* * * * *
    ``Comprehensive Information Security Program'' includes the
organization-wide and system-specific controls and related policies
and procedures required by NIST SP 800-53 that address information
security for the information and information systems that support
the operations of the Plan Processor and the CAT System, including
those provided or managed by an external organization, contractor,
or source, inclusive of Secure Analytical Workspaces.
* * * * *
    ``Customer and Account Attributes'' shall mean the data elements
in Account Attributes and Customer Attributes.
* * * * *
    ``Customer [Identifying Information] Attributes'' means
information of sufficient detail to identify a Customer, including,
but not limited to, (a) with respect to individuals: Name, address,
[date] year of birth, [individual tax payer identification number
(``ITIN'')/social security number (``SSN'')], individual's role in
the account (e.g., primary holder, joint holder, guardian, trustee,
person with the power of attorney); and (b) with respect to legal
entities: Name, address, Employer Identification Number (``EIN''),
and [/]Legal Entity Identifier (``LEI'') or other comparable common
entity identifier, if applicable; provided, however, that an
Industry Member that has an LEI for a Customer must submit the
Customer's LEI in addition to other information of sufficient detail
to identify a Customer.
* * * * *
    ``Customer Identifying Systems'' means CAIS and the CCID
Subsystem.
* * * * *
    ``Customer Identifying Systems Workflow'' describes the
requirements and process for accessing Customer Identifying Systems
as set forth in Appendix D, Data Security.
* * * * *
    ``Manual CAIS Access'' when used in connection with the Customer
Identifying Systems Workflow, as defined in Appendix D, shall mean
the Plan Processor functionality to manually query CAIS, in
accordance with Appendix D, Data Security, and the Participants'
policies as set forth in Section 6.5(g).
* * * * *
    ``Manual CCID Subsystem Access'' when used in connection with
the Customer Identifying Systems Workflow, as defined in Appendix D,
shall mean the Plan Processor functionality to manually query the
CCID Subsystem, in accordance with Appendix D, Data Security, and
the Participants' policies as set forth in Section 6.5(g).
* * * * *
    [``PII'' means personally identifiable information, including a
social security number or tax identifier number or similar
information; Customer Identifying Information and Customer Account
Information.]
* * * * *
    ``Programmatic CAIS Access'' when used in connection with the
Customer Identifying Systems Workflow, as defined in Appendix D,
shall mean the Plan Processor functionality to programmatically
query, and return results that include, data from the CAIS and
transactional CAT Data, in support of the regulatory purpose of an
inquiry or set of inquiries, in accordance with Appendix D, Data
Security, and the Participants' policies as set forth in Section
6.5(g).

    ``Programmatic CCID Subsystem Access'' when used in connection
with the Customer Identifying Systems Workflow, as defined in
Appendix D, shall mean the Plan Processor functionality to
programmatically query the CCID Subsystem to obtain Customer-ID(s)
from Transformed Value(s), in support of the regulatory purpose of
an inquiry or set of inquiries, in accordance with Appendix D, Data
Security, and the Participants' policies as set forth in Section
6.5(g).
* * * * *
    ``Regulatory Staff'' means the Participant's Chief Regulatory
Officer (or similarly designated head(s) of regulation) and staff
within the Chief Regulatory Officer's (or similarly designated
head(s) of regulation's) reporting line. In addition, Regulatory
Staff must be specifically identified and approved in writing by the
Chief Regulatory Officer (or similarly designated head(s) of
regulation).
* * * * *
    ``Secure Analytical Workspace'' or ``SAW'' means an analytic
environment account that is part of the CAT System, and subject to
the Comprehensive Information Security Program, where CAT Data is
accessed and analyzed by Participants pursuant to Section 6.13. The
Plan Processor shall provide a SAW account for each Participant that
implements all common technical security controls required by the
Comprehensive Information Security Program.
* * * * *
    ``Secure File Sharing'' means a capability that allows files to
be extracted and shared outside of the SAW in a manner consistent
with the provisions of Section 6.13(a)(i)(D).
* * * * *
    ``Transformed Value'' refers to the value generated by the CCID
Transformation Logic, as set forth in Section 6.1(v) and Appendix D,
Section 9.1.
* * * * *

Section 4.12. Subcommittees and Working Groups

* * * * *
    (c) The Operating Committee shall establish and maintain a
security working group composed of the Chief Information Security
Officer, and the chief information security officer or deputy chief
information security officer of each Participant (the ``Security
Working Group''). Commission observers shall be permitted to attend
all meetings of the Security Working Group, and the CISO and the
Operating Committee may invite other parties to attend specific
meetings. The Security Working Group's purpose shall be to advise
the Chief Information Security Officer (who shall directly report to
the Operating Committee in accordance with Section 6.2(b)(iii)) and
the Operating Committee, including with respect to issues involving:
    (i) Information technology matters that pertain to the
development of the CAT System;
    (ii) the development, maintenance, and application of the
Comprehensive Information Security Program;
    (iii) the review and application of the confidentiality policies
and procedures required by Section 6.5(g);
    (iv) the review and analysis of third party risk assessments
conducted pursuant to Section 5.3 of Appendix D, including the
review and analysis of results and corrective actions arising from
such assessments; and
    (v) emerging cybersecurity topics.
    The Chief Information Security Officer shall apprise the
Security Working Group of relevant developments and provide it with
all information and materials necessary to fulfill its purpose.
* * * * *

Section 6.1. Plan Processor

* * * * *
    (d) The Plan Processor shall:
* * * * *
    (v) provide Secure Analytical Workspaces in accordance with
Section 6.13.
* * * * *
    (v) The Plan Processor shall develop, with the prior approval of
the Operating Committee, the functionality to implement the process
for creating a Customer-ID(s), consistent with this Section and
Appendix D, Section 9.1. With respect to the CCID Subsystem, the
Plan Processor shall develop functionality to:
    (i) Ingest Transformed Value(s) and any other required
information and convert the Transformed Value(s) into an accurate
and reliable Customer-ID(s);
    (ii) Validate that the conversion from the Transformed Value(s)
to the Customer-ID(s) is accurate; and
    (iii) Transmit the Customer-ID(s), consistent with Appendix D,
Section 9.1, to CAIS or a Participant's SAW.
* * * * *

Section 6.2. Chief Compliance Officer and Chief Information
Security Officer

    (a) Chief Compliance Officer.
* * * * *
    (v) The Chief Compliance Officer shall:
* * * * *
    (H) regularly review the Comprehensive I[i]nformation
S[s]ecurity P[p]rogram developed and maintained by the Plan
Processor pursuant to Section 6.12 and determine the frequency of
such reviews;
* * * * *
    (Q) oversee the Plan Processor's compliance with applicable
laws, rules and regulations related to the CAT system, in its
capacity as Plan Processor[.];
    (R) in collaboration with the Chief Information Security
Officer, review the Participants' policies developed pursuant to
Section 6.5(g)(i), and, if the Chief Compliance Officer, in
consultation with the Chief Information Security Officer, finds that
such policies are inconsistent with the requirements of the Plan,
notify the Operating Committee of such deficiencies;
    (S) in collaboration with the Chief Information Security
Officer, determine, pursuant to Section 6.13(d), whether a
Participant should be granted an exception from Section
6.13(a)(i)(B) and, if applicable, whether such exception should be
continued; and
    (T) as required by Section 6.6(b)(ii)(B)(3), in collaboration
with the Chief Information Security Officer, review CAT Data that
has been extracted from the CAT System to assess the security risk
of allowing such CAT Data to be extracted.
    (b) Chief Information Security Officer.
* * * * *
    (v) Consistent with Appendices C and D, the Chief Information
Security Officer shall be responsible for creating and enforcing
appropriate policies, procedures, and control structures to monitor
and address data security issues for the Plan Processor and the
Central Repository including:
* * * * *
    (F) [PII] Customer and Account Attributes data requirements,
including the standards set forth in Appendix D, [PII Data
Requirements] Customer Identifying Systems Requirements and Customer
Identifying Systems Workflow;
* * * * *
    (viii) In collaboration with the Chief Compliance Officer, the
Chief Information Security Officer shall review the Participants'
policies developed pursuant to Section 6.5(g)(i). If the Chief
Information Security Officer, in consultation with the Chief
Compliance Officer, finds that such policies are inconsistent with
the requirements of the Plan, they will be required to notify the
Operating Committee of such deficiencies.
    (ix) In collaboration with the Chief Compliance Officer, the
Chief Information Security Officer shall determine, pursuant to
Section 6.13(d), whether a Participant should be granted an
exception from Section 6.13(a)(i)(B) and, if applicable, whether
such exception should be continued.
    (x) As required by Section 6.6(b)(ii)(B)(3), in collaboration
with the Chief Compliance Officer, review CAT Data that has been
extracted from the CAT System to assess the security risk of
allowing such CAT Data to be extracted.
* * * * *

Section 6.4. Data Reporting and Recording by Industry Members

* * * * *
    (d) Required Industry Member Data.
* * * * *
    (ii) Subject to Section 6.4(c) and Section 6.4(d)(iii) with
respect to Options Market Makers, and consistent with Appendix D,
Reporting and Linkage Requirements, and the Technical
Specifications, each Participant shall, through its Compliance Rule,
require its Industry Members to record and report to the Central
Repository the following, as applicable (``Received Industry Member
Data'' and collectively with the information referred to in Section
6.4(d)(i) ``Industry Member Data''):
* * * * *
    (C) for original receipt or origination of an order and
Allocation Reports, the Firm Designated ID for the relevant
Customer, and in accordance with Section 6.4(d)(iv), Customer and
Account Attributes [Information and Customer Identifying
Information] for the relevant Customer[.]; and
    (D) for all Customers with an ITIN/SSN/EIN, the Transformed
Value.
* * * * *

Section 6.5. Central Repository

* * * * *
    (b) Retention of Data
* * * * *
    (i) Consistent with Appendix D, Data Retention Requirements, the
Central Repository shall retain the information collected pursuant
to paragraphs (c)(7) and (e)(7) of SEC Rule 613 in a convenient and
usable standard electronic data format that is directly available
and searchable electronically without any manual intervention by the
Plan Processor for a period of not less than six (6) years. Such
data when available to the Participant's R[r]egulatory S[s]taff and
the SEC shall be linked.
* * * * *
    (f) Data Confidentiality
    (i) The Plan Processor shall, without limiting the obligations
imposed on Participants by this Agreement and in accordance with the
framework set forth in, Appendix D, Data Security, and Functionality
of the CAT System, be responsible for the security and
confidentiality of all CAT Data received and reported to the Central
Repository. Without limiting the foregoing, the Plan Processor
shall:
* * * * *
    (C) develop and maintain a C[c]omprehensive I[i]nformation
S[s]ecurity P[p]rogram with a dedicated staff for the [Central
Repository, consistent with Appendix D, Data Security] CAT System,
that employs state of the art technology, which program will be
regularly reviewed by the Chief Compliance Officer and Chief
Information Security Officer;
* * * * *
    (ii) [Each Participant shall adopt and enforce policies and
procedures that:
    (A) implement effective information barriers between such
Participant's regulatory and non-regulatory staff with regard to
access and use of CAT Data stored in the Central Repository;
    (B) permit only persons designated by Participants to have
access to the CAT Data stored in the Central Repository; and
    (C) impose penalties for staff non-compliance with any of its or
the Plan Processor's policies or procedures with respect to
information security.
    (iii) Each Participant shall as promptly as reasonably
practicable, and in any event within 24 hours, report to the Chief
Compliance Officer, in accordance with the guidance provided by the
Operating Committee, any instance of which such Participant becomes
aware of: (A) noncompliance with the policies and procedures adopted
by such Participant pursuant to Section 6.5(e)(ii); or (B) a breach
of the security of the CAT.
    (iv)] The Plan Processor shall:
* * * * *
    (B) require the establishment of secure controls for data
retrieval and query reports by Participants' R[r]egulatory S[s]taff;
and
* * * * *
    ([v]iii) The Company shall endeavor to join the FS-ISAC and
comparable bodies as the Operating Committee may determine.
    (g) Participants' Confidentiality Policies and Procedures.
    (i) The Participants shall establish, maintain and enforce
identical written policies [and procedures] that apply to each
Participant. Each Participant shall establish, maintain and enforce
procedures and usage restriction controls in accordance with these
policies. The policies must:
    (A) be reasonably designed to (1) ensure the confidentiality of
[the ]CAT Data[ obtained from the Central Repository]; and (2) limit
the use of CAT Data to [obtained from the Central Repository] solely
[for ]surveillance and regulatory purposes[.]; [Each Participant
shall periodically review the effectiveness of the policies and
procedures required by this paragraph, and take prompt action to
remedy deficiencies in such policies and procedures.]
    (B) limit extraction of CAT Data to the minimum amount of data
necessary to achieve a specific surveillance or regulatory purpose;
    (C) limit access to CAT Data to persons designated by
Participants, who must be (1) Regulatory Staff or (2) technology and
operations staff that require access solely to facilitate access to
and usage of the CAT Data by Regulatory Staff;
    (D) implement effective information barriers between such
Participants' Regulatory Staff and non-Regulatory Staff with regard
to access and use of CAT Data;
    (E) limit access to CAT Data by non-Regulatory Staff, by
allowing such access only where there is a specific regulatory need
for such access and requiring that a Participant's Chief Regulatory
Officer (or similarly designated head(s) of regulation), or his or
her designee, document his or her written approval of each instance
of access by non-Regulatory Staff;
    (F) require all Participant staff who are provided access to CAT
Data to: (1) sign a ``Safeguard of Information'' affidavit as
approved by the Operating Committee pursuant to Section
6.5(f)(i)(B); and (2) participate in the training program developed
by the Plan Processor that addresses the security and
confidentiality of information accessible in the CAT pursuant to
Section 6.1(m), provided that Participant staff may be provided
access to CAT Data prior to meeting these requirements in exigent
circumstances;
    (G) define the individual roles and regulatory activities of
specific users;
    (H) impose penalties for staff non-compliance with the
Participant's or the Plan Processor's policies, procedures, or usage
restriction controls with respect to information security,
including, the policies required by Section 6.5(g)(i);
    (I) be reasonably designed to implement and satisfy the Customer
and Account Attributes data requirements of Section 4.1.6 of
Appendix D such that Participants must be able to demonstrate that a
Participant's ongoing use of Programmatic CAIS and/or CCID Subsystem
access is in accordance with the Customer Identifying Systems
Workflow; and
    (J) document monitoring and testing protocols that will be used
to assess Participant compliance with the policies.
    (ii) The Participants shall periodically review the
effectiveness of the policies and procedures and usage restriction
controls required by Section 6.5(g)(i), including by using the
monitoring and testing protocols documented within the policies
pursuant to Section 6.5(g)(i)(J), and take prompt action to remedy
deficiencies in such policies, procedures and usage restriction
controls.
    (iii) Each Participant shall as promptly as reasonably
practicable, and in any event within 24 hours of becoming aware,
report to the Chief Compliance Officer, in accordance with the
guidance provided by the Operating Committee: (A) any instance of
noncompliance with the policies, procedures, and usage restriction
controls adopted by such Participant pursuant to Section 6.5(g)(i);
or (B) a breach of the security of the CAT.
    (iv) The Participants shall make the policies required by
Section 6.5(g)(i) publicly available on each of the Participant
websites, or collectively on the CAT NMS Plan website, redacted of
sensitive proprietary information.
    (v) On an annual basis, each Participant shall engage an
independent accountant to perform an examination of compliance with
the policies required by Section 6.5(g)(i) in accordance with
attestation standards of the AICPA (referred to as U.S. Generally
Accepted Auditing Standards or GAAS) or the PCAOB, and with
Commission independence standards based on SEC Rule 2-01 of
Regulation S-X. The independent accountant's examination report
shall be submitted to the Commission upon completion, in a text-
searchable format (e.g. a text-searchable PDF). The examination
report provided for in this paragraph shall be considered submitted
with the Commission when electronically received by an email address
provided by Commission staff.
    (vi) The policies required by Section 6.5(g)(i) are subject to
review and approval by the Operating Committee, after such policies
are reviewed by the Chief Compliance Officer and Chief Information
Security Officer pursuant to Sections 6.2(a)(v)(R) and 6.2(b)(viii).
* * * * *

Section 6.6 [Regular] Written Assessments, Audits and Reports.

* * * * *
    (b) Regular Written Assessment of the Plan Processor's
Performance.
* * * * *
    (ii) Contents of Written Assessment. The annual written
assessment required by this Section 6.6 shall include:
* * * * *
    (B) a detailed plan, based on the evaluation conducted pursuant
to Section 6.6(b)(i), for any potential improvements to the
performance of the CAT with respect to the items specified in SEC
Rule 613(b)(6)(ii), as well as:
* * * * *
    (3) an evaluation of the Comprehensive I[i[nformation
S[s]ecurity P[p]rogram to ensure that the program is consistent with
the highest industry standards for the protection of data[;], as
part of which, the CCO, in collaboration with the CISO, shall review
the quantity and type of CAT Data

extracted from the CAT System to assess the security risk of
permitting such CAT Data to be extracted and identify any
appropriate corrective measures;
* * * * *

Section 6.10 Surveillance

* * * * *
    (c) Use of CAT Data by Regulators.
* * * * *
    (ii) Extraction of CAT Data shall be consistent with all
permission rights granted by the Plan Processor. All CAT Data
returned shall be encrypted, and [PII] Customer and Account
Attributes data shall be [masked]unavailable unless users have
permission to view the CAT Data that has been requested.
* * * * *

Section 6.12. Comprehensive Information Security Program

    The Plan Processor shall develop and maintain the
C[c]omprehensive I[i]nformation S[s]ecurity P[p]rogram [for the
Central Repository], to be approved and reviewed at least annually
by the Operating Committee, and which contains at a minimum the
specific requirements detailed in Appendix D, Data Security and
Section 6.13.
* * * * *

Section 6.13. Secure Analytical Environments

    (a) SAW Environments. The Comprehensive Information Security
Program shall apply to every Participant's SAW and must, at a
minimum:
    (i) Establish data access and extraction policies and procedures
that include the following requirements:
    (A) Participants shall use SAWs as the only means of accessing
and analyzing Customer and Account Attributes.
    (B) Participants shall use SAWs when accessing and analyzing CAT
Data through the user-defined direct query and bulk extract tools
described in Section 6.10(c)(i)(B) and Appendix D, Section 8.2,
unless receiving an exception as set forth in Section 6.13(d).
    (C) Participants shall only extract from SAWs the minimum amount
of CAT Data necessary to achieve a specific surveillance or
regulatory purpose.
    (D) Secure file sharing capability provided by the Plan
Processor shall be the only mechanism for extracting CAT Data from
SAWs.
    (ii) Establish security controls, policies, and procedures for
SAWs that require all NIST SP 800-53 security controls and
associated policies and procedures required by the Comprehensive
Information Security Program to apply to the SAWs, provided that:
    (A) For the following NIST SP 800-53 control families, at a
minimum, security controls, policies, and procedures, shall be
applied by the Plan Processor and shall be common to both the SAWs
and the Central Repository in accordance with Section 2.4 of NIST SP
800-53, unless technologically or organizationally not possible:
audit and accountability, security assessment and authorization,
configuration management, incident response, system and
communications protection, and system and information integrity; and
    (B) SAW-specific security controls, policies, and procedures
shall be implemented to cover any remaining NIST SP 800-53 security
controls for which common security controls, policies, and
procedures are not possible.
    (b) Detailed Design Specifications.
    (i) The Plan Processor shall develop, maintain, and make
available to the Participants detailed design specifications for the
technical implementation of the access, monitoring, and other
controls required for SAWs by the Comprehensive Information Security
Program controls.
    (ii) The Plan Processor shall notify the Operating Committee
that each Participant's SAW has achieved compliance with the
detailed design specifications before that SAW may connect to the
Central Repository.
    (c) SAW Operations.
    (i) In accordance with the detailed design specifications
developed pursuant to Section 6.13(b)(i), the Plan Processor shall
monitor each Participant's SAW, for compliance with the
Comprehensive Information Security Program and the detailed design
specifications developed pursuant to Section 6.13(b)(i) only, and
notify the Participant of any identified non-compliance with the
Comprehensive Information Security Program or with the detailed
design specifications developed pursuant to Section 6.13(b)(i).
    (ii) Participants shall comply with the Comprehensive
Information Security Program, comply with the detailed design
specifications developed pursuant to Section 6.13(b)(i), and
promptly remediate any identified non-compliance.
    (iii) Each Participant may provide and use its choice of
software, hardware configurations, and additional data within its
SAW, so long as such activities comply with the Comprehensive
Information Security Program.
    (d) Non-SAW Environments.
    (i) A Participant may seek an exception from the requirements of
Section 6.13(a)(i)(B). If such exception is granted, the Participant
may employ the user-defined direct query or bulk extract tools
described in Section 6.10(c)(i)(B) and Appendix D, Section 8.2 in a
non-SAW environment.
    (A) To seek an exception from Section 6.13(a)(i)(B), the
requesting Participant shall provide the Chief Information Security
Officer, the Chief Compliance Officer, the members of the Security
Working Group (and their designees), and Commission observers of the
Security Working Group with:
    (1) A security assessment of the non-SAW environment, conducted
within the last twelve (12) months by a named, independent third
party security assessor, that: (a) demonstrates the extent to which
the non-SAW environment complies with the NIST SP 800-53 security
controls and associated policies and procedures required by the
Comprehensive Information Security Program pursuant to Section
6.13(a)(ii), (b) explains whether and how the Participant's security
and privacy controls mitigate the risks associated with extracting
CAT Data to the non-SAW environment through user-defined direct
query or bulk extract tools described in Section 6.10(c)(i)(B) and
Appendix D, Section 8.2, and (c) includes a Plan of Action and
Milestones document detailing the status and schedule of any
corrective actions recommended by the assessment; and
    (2) Detailed design specifications for the non-SAW environment
demonstrating: (a) the extent to which the non-SAW environment's
design specifications adhere to the design specifications developed
by the Plan Processor for SAWs pursuant to Section 6.13(b)(i), and
(b) that the design specifications will enable the operational
requirements set forth for non-SAW environments in Section
6.13(d)(iii).
    (B) Within 60 days of receipt of the materials described in
Section 6.13(d)(i)(A), the Chief Information Security Officer and
the Chief Compliance Officer must simultaneously notify the
Operating Committee and the requesting Participant of their
determination.
    (1) The Chief Information Security Officer and the Chief
Compliance Officer may jointly grant an exception if they determine,
in accordance with policies and procedures developed by the Plan
Processor, that the residual risks identified in the security
assessment or detailed design specifications provided pursuant to
Section 6.13(d)(i)(A) do not exceed the risk tolerance levels set
forth in the risk management strategy developed by the Plan
Processor for the CAT System pursuant to NIST SP 800-53. If an
exception is granted, the Chief Information Security Officer and the
Chief Compliance Officer shall provide the requesting Participant
with a detailed written explanation setting forth the reasons for
that determination.
    (2) If the Chief Information Security Officer and the Chief
Compliance Officer decide not to grant an exception to the
requesting Participant, they must provide the Participant with a
detailed written explanation setting forth the reasons for that
determination and specifically identifying the deficiencies that
must be remedied before an exception could be granted.
    (C) If a request for an exception from Section 6.13(a)(i)(B) is
denied, the requesting Participant may attempt to re-apply, after
remedying the deficiencies identified by the Chief Information
Security Officer and the Chief Compliance Officer, by submitting a
new security assessment that complies with the requirements of
Section 6.13(d)(i)(A)(1) and up-to-date versions of the materials
specified in Section 6.13(d)(i)(A)(2).
    (ii) Continuance of any exception granted pursuant to Section
6.13(d)(i) is dependent upon an annual review process.
    (A) To continue an exception, the requesting Participant shall
provide a new security assessment that complies with the
requirements of Section 6.13(d)(i)(A)(1) and up-to-date versions of
the materials required by Section 6.13(d)(i)(A)(2) to the Chief
Information Security Officer, the Chief Compliance Officer, the
members of the Security Working Group (and their designees), and
Commission observers of the Security Working Group at least once a
year, as measured from the date that the initial

application materials were submitted. If these materials are not
provided by the specified date, the Chief Information Security
Officer and the Chief Compliance Officer must revoke the exception
in accordance with remediation timelines developed by the Plan
Processor.
    (B) Within 60 days of receipt of the updated application
materials, the Chief Information Security Officer and the Chief
Compliance Officer must simultaneously notify the Operating
Committee and the requesting Participant of their determination.
    (1) The Chief Information Security Officer and the Chief
Compliance Officer may jointly continue an exception if they
determine, in accordance with policies and procedures developed by
the Plan Processor, that the residual risks identified in the
security assessment or detailed design specifications provided
pursuant to Section 6.13(d)(ii)(A) do not exceed the risk tolerance
levels set forth in the risk management strategy developed by the
Plan Processor for the CAT System pursuant to NIST SP 800-53. If the
exception is continued, the Chief Information Security Officer and
the Chief Compliance Officer shall provide the requesting
Participant with a detailed written explanation setting forth the
reasons for that determination.
    (2) If the Chief Information Security Officer and the Chief
Compliance Officer decide not to continue an exception, they must
provide the requesting Participant with a detailed written
explanation setting forth the reasons for that determination and
specifically identifying the deficiencies that must be remedied
before an exception could be granted anew.
    (C) If a request for a renewed exception from Section
6.13(a)(i)(B) is denied, or if an exception is revoked pursuant to
Section 6.13(d)(ii)(A), the CISO and the CCO must require the
requesting Participant to cease employing the user-defined direct
query or bulk extract tools described in Section 6.10(c)(i)(B) and
Appendix D, Section 8.2 in its non-SAW environment in accordance
with the remediation timeframes developed by the Plan Processor. The
requesting Participant may attempt to re-apply for an exception,
after remedying the deficiencies identified by the Chief Information
Security Officer and the Chief Compliance Officer, by submitting a
new security assessment that complies with the requirements of
Section 6.13(d)(i)(A)(1) and up-to-date versions of the materials
specified in Section 6.13(d)(i)(A)(2).
    (iii) Non-SAW Operations. During the term of any exception
granted by the Chief Information Security Officer and the Chief
Compliance Officer:
    (A) The Participant shall not employ the non-SAW environment to
access CAT Data through the user-defined direct query or bulk
extract tools described in Section 6.10(c)(i)(B) and Appendix D,
Section 8.2 until the Plan Processor notifies the Operating
Committee that the non-SAW environment has achieved compliance with
the detailed design specifications provided by the Participant
pursuant to Section 6.13(d)(i) or (ii).
    (B) The Plan Processor shall monitor the non-SAW environment in
accordance with the detailed design specifications provided by the
Participant pursuant to Section 6.13(d)(i) or (ii), for compliance
with those detailed design specifications only, and shall notify the
Participant of any identified non-compliance with these detailed
design specifications. The Participant shall comply with such
detailed design specifications and promptly remediate any identified
non-compliance.
    (C) The Participant shall simultaneously notify the Plan
Processor, the members of the Security Working Group (and their
designees), and Commission observers of the Security Working Group
of any material changes to its security controls for the non-SAW
environment.
    (D) The Participant may provide and use its choice of software,
hardware, and additional data within the non-SAW environment, so
long as such activities comply with the detailed design
specifications provided by the Participant pursuant to Section
6.13(d)(i) or (ii).
* * * * *

Appendix C

    Appendix C was filed with the CAT NMS Plan that was published
for comment on May 17, 2016.\803\ As required by Rule 613, Appendix
C includes discussion of various considerations related to how the
Participants propose to implement the requirements of the CAT NMS
Plan, cost estimates for the proposed solution, and the costs and
benefits of alternate solutions considered but not proposed. Because
these discussions were intended to ensure that the Commission and
the Participants had sufficiently detailed information to carefully
consider all aspects of the national market system plan that would
ultimately be submitted by the Participants, these discussions have
not been updated to reflect the subsequent amendments to the CAT NMS
Plan and Appendix D.
---------------------------------------------------------------------------

    \803\ See Securities Exchange Act Release No. 77724 (April 27,
2016), 81 FR 30613.
---------------------------------------------------------------------------

Discussion of Considerations

SEC Rule 613(a)(1) Considerations

* * * * *

Appendix D

* * * * *

4.1 Overview

* * * * *
    The Plan Processor must provide to the Operating Committee a
C[c]omprehensive Information S[s]ecurity P[p]lan that covers all
components of the CAT System, including physical assets and
personnel, and the training of all persons who have access to the
Central Repository consistent with Article VI, Section 6.1(m). The
Comprehensive Information S[s]ecurity P[p]lan must be updated
annually. The Comprehensive Information S[s]ecurity P[p]lan must
include an overview of the Plan Processor's network security
controls, processes and procedures pertaining to the CAT Systems.
Details of the Comprehensive Information S[s]ecurity P[p]lan must
document how the Plan Processor will protect, monitor and patch the
environment; assess it for vulnerabilities as part of a managed
process, as well as the process for response to security incidents
and reporting of such incidents. The Comprehensive Information
S[s]ecurity P[p]lan must address physical security controls for
corporate, data center, and leased facilities where Central
Repository data is transmitted or stored. The Plan Processor must
have documented ``hardening baselines'' for systems that will store,
process, or transmit CAT Data or [PII] Customer and Account
Attributes data.

4.1.1 Connectivity and Data Transfer

    [The CAT System(s) must have encrypted internet connectivity.
CAT Reporters] Industry members must connect to the CAT
infrastructure using secure methods such as private lines for
machine-to machine interfaces or [(for smaller broker-dealers)]
encrypted Virtual Private Network connections over public lines for
manual web-based submissions. Participants must connect to the CAT
infrastructure using private lines. For all connections to CAT
infrastructure, the Plan Processor must implement capabilities to
allow access (i.e., ``allow list'') only to those countries where
CAT reporting or regulatory use is both necessary and expected.
Where possible, more granular ``allow listing'' should be
implemented (e.g., by IP address). The Plan Processor must establish
policies and procedures to allow access if the location cannot be
determined technologically.
* * * * *

4.1.2 Data Encryption

    All CAT Data must be encrypted at rest and in flight using
industry standard best practices (e.g., SSL/TLS) including archival
data storage methods such as tape backup. Symmetric key encryption
must use a minimum key size of 128 bits or greater (e.g., AES-128),
larger keys are preferable. Asymmetric key encryption (e.g., PGP)
for exchanging data between Data Submitters and the Central
Repository is desirable.
    Storage of unencrypted [PII] Customer and Account Attributes
data is not permissible. [PII] Customer and Account Attributes
encryption methodology must include a secure documented key
management strategy such as the use of HSM(s). The Plan Processor
must describe how [PII] Customer and Account Attributes encryption
is performed and the key management strategy (e.g., AES-256, 3DES).
* * * * *

4.1.3 Data Storage and Environment

    Data centers housing CAT Systems (whether public or private)
must, at a minimum, be AICPA SOC 2 certified by a qualified third-
party auditor that is not an affiliate of any of the Participants or
the CAT Processor, and be physically located in the United States.
The frequency of the audit must be at least once per year.
* * * * *

4.1.4 Data Access

    The Plan Processor must provide an overview of how access to
[PII] Customer and Account Attributes and other CAT Data by

Plan Processor employees and administrators is restricted. This
overview must include items such as, but not limited to, how the
Plan Processor will manage access to the systems, internal
segmentation, multi-factor authentication, separation of duties,
entitlement management, background checks, etc.
    The Plan Processor must develop and maintain policies and
procedures reasonably designed to prevent, detect, and mitigate the
impact of unauthorized access or usage of data in the Central
Repository. Such policies and procedures must be approved by the
Operating Committee, and should include, at a minimum:
     Information barriers governing access to and usage of
data in the Central Repository;
     Monitoring processes to detect unauthorized access to
or usage of data in the Central Repository; and
     Escalation procedures in the event that unauthorized
access to or usage of data is detected.
    A Role Based Access Control (``RBAC'') model must be used to
permission users with access to different areas of the CAT System.
The CAT System must support [an arbitrary number of]as many roles as
required by Participants and the Commission to permit [with ]access
to different types of CAT Data, down to the attribute level. The
administration and management of roles must be documented. Periodic
reports detailing the current list of authorized users and the date
of their most recent access must be provided to Participants, the
SEC and the Operating Committee. The reports provided to[of] the
Participants and the SEC will include only their respective list of
users. The Participants must provide a response to the report
confirming that the list of users is accurate. The required
frequency of this report will be defined by the Operating Committee.
The Plan Processor must log every instance of access to Central
Repository data by users.
    Following ``least privileged'' practices, separation of duties,
and the RBAC model for permissioning users with access to the CAT
System, all Plan Processor employees and contractors that develop
and test Customer Identifying Systems shall only develop and test
with non-production data and shall not be entitled to access
production data (i.e., Industry Member Data, Participant Data, and
CAT Data) in CAIS or the CCID Subsystem. All Plan Processor
employees and contractors that develop and test CAT Systems
containing transactional CAT Data shall use non-production data for
development and testing purposes; if it is not possible to use non-
production data, such Plan Processor employees and contractors shall
use the oldest available production data that will support the
desired development and testing, subject to the approval of the
Chief Information Security Officer.
    Passwords stored in the CAT System must be stored according to
industry best practices. Reasonable password complexity rules should
be documented and enforced, such as, but not limited to, mandatory
periodic password changes and prohibitions on the reuse of the
recently used passwords.
    Password recovery mechanisms must provide a secure channel for
password reset, such as emailing a one-time, time-limited login
token to a pre-determined email address associated with that user.
Password recovery mechanisms that allow in-place changes or email
the actual forgotten password are not permitted.
    Any login to the system that is able to access [PII] Customer
and Account Attributes data must follow [non-PII password] rules
that do not allow personally identifiable information to be used as
part of a password and must be further secured via multi-factor
authentication (``MFA''). The implementation of MFA must be
documented by the Plan Processor. MFA authentication capability for
all logins is required to be implemented by the Plan Processor.
* * * * *

4.1.5 Breach Management

    The Plan Processor must develop written policies and procedures
governing its responses to systems or data breaches. Such policies
and procedures will include a formal cyber incident response plan
(which must include taking appropriate corrective action that
includes, at a minimum, mitigating potential harm to investors and
market integrity, and devoting adequate resources to remedy the
systems or data breach as soon as reasonably practicable), and
documentation of all information relevant to breaches. The Plan
Processor must provide breach notifications of systems or data
breaches to CAT Reporters that it reasonably estimates may have been
affected, as well as to the Participants and the Commission,
promptly after any responsible Plan Processor personnel have a
reasonable basis to conclude that a systems or data breach has
occurred. Such breach notifications, which must include a summary
description of the systems or data breach, including a description
of the corrective action taken and when the systems or data breach
has been or is expected to be resolved: (a) may be delayed if the
Plan Processor determines that dissemination of such information
would likely compromise the security of the CAT System or an
investigation of the systems or data breach, and documents the
reasons for such determination; and (b) do not apply to systems or
data breaches that the Plan Processor reasonably estimates would
have no or a de minimis impact on the Plan Processor's operations or
on market participants.
    The cyber incident response plan will provide guidance and
direction during security incidents and must provide for breach
notifications. The plan will be subject to approval by the Operating
Committee. The plan may include items such as:
* * * * *

4.1.6 [PII Data Requirements] Customer Identifying Systems
Requirements and Customer Identifying Systems Workflow

    Customer and Account Attributes data must be stored separately
from other CAT Data within the CAIS. It cannot be stored with the
transactional CAT Data in the Central Repository, and it must not be
accessible from public internet connectivity.
    [PII data] Customer and Account Attributes must not be included
in the result set(s) from online or direct query tools, reports or
bulk data extraction tools used to query transactional CAT Data.
Instead, query results of transactional CAT Data will display
[existing non-PII] unique identifiers (e.g., Customer-ID or Firm
Designated ID). The [PII] Customer and Account Attributes
corresponding to these identifiers can be gathered [using the PII]
by accessing CAIS in accordance with the Customer Identifying
Systems [w]Workflow described below [in Appendix D, Data Security,
PII Data Requirements]. By default, users entitled to query CAT Data
are not authorized to access [for PII] Customer Identifying Systems
access. The process by which someone becomes entitled [for PII] to
Customer Identifying Systems[ access], and how [they]an authorized
person then [go about accessing PII data] can access Customer
Identifying Systems, must be documented by the Plan Processor. The
chief regulatory officer (or similarly designated head(s) of
regulation), or his or her designee, [or other such designated
officer or employee] at each Participant must, at least annually,
review and certify that people with [PII] Customer Identifying
Systems access have the appropriate level of access for their role,
in accordance with the Customer Identifying Systems Workflow, as
described below.
    [Using the RBAC model described above, access to PII data shall
be configured at the PII attribute level, following the ``least
privileged'' practice of limiting access as much as possible.
    PII data must be stored separately from other CAT Data. It
cannot be stored with the transactional CAT Data, and it must not be
accessible from public internet connectivity. A full audit trail of
PII access (who accessed what data, and when) must be maintained.
The Chief Compliance Officer and the Chief Information Security
Officer shall have access to daily PII reports that list all users
who are entitled for PII access, as well as the audit trail of all
PII access that has occurred for the day being reported on.]
    A full audit trail of access to Customer Identifying Systems by
each Participant and the Commission (who accessed what data and
when) must be maintained by the Plan Processor, and the Plan
Processor must provide to each Participant and the Commission the
audit trail for their respective users on a monthly basis. The Chief
Compliance Officer and the Chief Information Security Officer shall
have access to daily reports that list all users who are entitled to
Customer Identifying Systems access, such reports to be provided to
the Operating Committee on a monthly basis.

Customer Identifying Systems Workflow

Access to Customer Identifying Systems

    Access to Customer Identifying Systems are subject to the
following restrictions:
     Only Regulatory Staff may access Customer Identifying
Systems and such access must follow the ``least privileged''
practice of limiting access to Customer Identifying Systems as much
as possible.
     Using the RBAC model described above, access to
Customer and Account Attributes shall be configured at the Customer
and Account Attributes level.

     All queries of Customer Identifying Systems must be
based on a ``need to know'' data in the Customer Identifying
Systems, and queries must be designed such that query results
contain only the Customer and Account Attributes that Regulatory
Staff reasonably believes will achieve the regulatory purpose of the
inquiry or set of inquiries, consistent with Article VI, Section
6.5(g) of the CAT NMS Plan.
     Customer Information Systems must be accessed through a
Participant's SAW.
     Access to Customer Identifying Systems will be limited
to two types of access: manual access (which shall include Manual
CAIS Access and Manual CCID Subsystem Access) and programmatic
access (which shall include Programmatic CAIS Access and
Programmatic CCID Subsystem Access).
     Authorization to use Programmatic CAIS Access or
Programmatic CCID Subsystem Access must be requested and approved by
the Commission, pursuant to the provisions below.
     Manual CAIS Access
    If Regulatory Staff have identified a Customer(s) of regulatory
interest through regulatory efforts and now require additional
information from CAT regarding such Customer(s), Manual CAIS Access
will be used. Additional information about Customer(s) may be
accessed through Manual CAIS Access by (1) using identifiers
available in the transaction database (e.g., Customer-ID(s) or
industry member Firm Designated ID(s)) to identify Customer and
Account Attributes associated with the Customer-ID(s) or industry
member Firm Designated ID(s), as applicable; or (2) using Customer
Attributes in CAIS to identify a Customer-ID(s) or industry member
Firm Designated ID(s), as applicable, associated with the Customer
Attributes, in order to search the transaction database. Open-ended
searching of parameters not specific to a Customer(s) is not
permitted.
    Manual CAIS Access will provide Regulatory Staff with the
ability to retrieve data in CAIS via the CAIS/CCID Subsystem
Regulator Portal with query parameters based on data elements
including Customer and Account Attributes and other identifiers
available in the transaction database (e.g., Customer-ID(s) or Firm
Designated ID(s)).
    Performance Requirements for Manual CAIS Access shall be
consistent with the criteria set out in Appendix D, Functionality of
the CAT System, Online Targeted Query Tool Performance Requirements.
     Manual CCID Subsystem Access
    Manual CCID Subsystem Access will be used when Regulatory Staff
have the ITIN(s)/SSN(s)/EIN(s) of a Customer(s) of regulatory
interest obtained through regulatory efforts outside of CAT and now
require additional information from CAT regarding such Customer(s).
Manual CCID Subsystem Access must allow Regulatory staff to convert
ITIN(s)/SSN(s)/EIN(s) into Customer-ID(s) using the CCID Subsystem.
Manual CCID Subsystem Access will be limited to 50 ITIN(s)/SSN(s)/
EIN(s) per query.
    Manual CCID Subsystem Access must provide Regulatory Staff with
the ability to retrieve data from the CCID Subsystem via the CAIS/
CCID Subsystem Regulator Portal based on ITIN(s)/SSN(s)/EIN(s) where
the CCID Transformation Logic is embedded in the client-side code of
the CAIS/CCID Subsystem Regulator Portal.
    Performance Requirements for the conversion of ITIN(s)/SSN(s)/
EIN(s) to Customer-ID(s) shall be consistent with the criteria set
out in Appendix D, Functionality of the CAT System, Online Targeted
Query Tool Performance Requirements.

Programmatic Access--Authorization for Programmatic CAIS Access and
Programmatic CCID Subsystem

    A Participant must submit an application, approved by the
Participant's Chief Regulatory Officer (or similarly designated
head(s) of regulation) to the Commission for authorization to use
Programmatic CAIS Access or Programmatic CCID Subsystem Access if a
Participant requires programmatic access. The application must
explain:
     Which programmatic access is being requested:
Programmatic CAIS Access and/or Programmatic CCID Subsystem Access;
     Why Programmatic CAIS Access or Programmatic CCID
Subsystem is required, and why Manual CAIS Access or Manual CCID
Subsystem Access cannot achieve the regulatory purpose of an inquiry
or set of inquiries;
     The Participant's rules that require Programmatic
Access for surveillance and regulatory purposes;
     The regulatory purpose of the inquiry or set of
inquires requiring programmatic access;
     A detailed description of the functionality of the
Participant's system(s) that will use data from CAIS or the CCID
Subsystem;
     A system diagram and description indicating
architecture and access controls to the Participant's system that
will use data from CAIS or the CCID Subsystem; and
     The expected number of users of the Participant's
system that will use data from CAIS or the CCID Subsystem.
    SEC staff shall review the application and may request
supplemental information to complete the review prior to Commission
action.
    The Commission shall approve Programmatic CAIS Access or
Programmatic CCID Subsystem Access if it finds that such access is
generally consistent with one or more of the following standards:
that such access is designed to prevent fraudulent and manipulative
acts and practices, to promote just and equitable principles of
trade, to foster cooperation and coordination with persons engaged
in regulating, clearing, settling, processing information with
respect to, and facilitating transactions in securities, to remove
impediments to and perfect the mechanism of a free and open market
and a national market system, and, in general, to protect investors
and the public interest.
    The Commission shall issue an order approving or disapproving a
Participant's application for Programmatic CAIS Access or
Programmatic CCID Subsystem Access within 45 days, which can be
extended for an additional 45 days if the Commission determines that
such longer period of time is appropriate and provides the
Participant with the reasons for such determination.
     Programmatic CAIS Access
    The Plan Processor will provide Programmatic CAIS Access by
developing and supporting an API that allows Regulatory Staff to use
analytical tools and ODBC/JDBC drivers to access the data in CAIS.
    Programmatic CAIS Access may be used when the regulatory purpose
of the inquiry or set of inquiries by Regulatory Staff requires the
use of Customer and Account Attributes and other identifiers (e.g.,
Customer-ID(s) or Firm Designated ID(s)) to query the Customer and
Account Attributes and transactional CAT Data.
    Performance Requirements for Programmatic CAIS Access shall be
consistent with the criteria set out in Appendix D, Functionality of
the CAT System, User-Defined Direct Query Performance Requirements.
     Programmatic CCID Subsystem Access
    The Plan Processor will provide Programmatic CCID Subsystem
Access by developing and supporting the CCID Transformation Logic
and an API to facilitate the submission of Transformed Values to the
CCID Subsystem for the generation of Customer-ID(s).
    Programmatic CCID Subsystem Access allows Regulatory Staff to
submit multiple ITIN(s)/SSN(s)/EIN(s) of a Customer(s) of regulatory
interest identified through regulatory efforts outside of CAT to
obtain Customer-ID(s) in order to query CAT Data regarding such
Customer(s).
    Performance Requirements for the conversion of ITIN(s)/SSN(s)/
EIN(s) to Customer-ID(s) shall be consistent with the criteria set
out in Appendix D, Functionality of the CAT System, User-Defined
Direct Query Performance Requirements.
* * * * *

6.1 Data Processing

    CAT order events must be processed within established timeframes
to ensure data can be made available to Participants' R[r]egulatory
S[s]taff and the SEC in a timely manner. The processing timelines
start on the day the order event is received by the Central
Repository for processing. Most events must be reported to the CAT
by 8:00 a.m. Eastern Time the Trading Day after the order event
occurred (referred to as transaction date). The processing
timeframes below are presented in this context. All events submitted
after T+1 (either reported late or submitted later because not all
of the information was available) must be processed within these
timeframes based on the date they were received.
    The Participants require the following timeframes (Figure A) for
the identification, communication and correction of errors from the
time an order event is received by the processor:

Noon Eastern Time T+1 (transaction date + one day)--Initial data
validation, lifecycle linkages and communication of errors to CAT
Reporters;
8:00 a.m. Eastern Time T+3 (transaction date + three days)--
Resubmission of corrected data; and
8:00 a.m. Eastern Time T+5 (transaction date

+ five days)--Corrected data available to Participants'
R[r]egulatory S[s]taff and the SEC.
* * * * *

6.2 Data Availability Requirements

    Prior to 12:00 p.m. Eastern Time on T+1, raw unprocessed data
that has been ingested by the Plan Processor must be available to
Participants' R[r]egulatory S[s]taff and the SEC.
    Between 12:00 p.m. Eastern Time on T+1 and T+5, access to all
iterations of processed data must be available to Participants'
R[r]egulatory S[s]taff and the SEC.
    The Plan Processor must provide reports and notifications to
Participants' R[r]egulatory S[s]taff and the SEC regularly during
the five-day process, indicating the completeness of the data and
errors. Notice of major errors or missing data must be reported as
early in the process as possible. If any data remains un-linked
after T+5, it must be available and included with all linked data
with an indication that the data was not linked.
    If corrections are received after T+5, Participants'
R[r]egulatory S[s]taff and the SEC must be notified and informed as
to how re-processing will be completed. The Operating Committee will
be involved with decisions on how to re-process the data; however,
this does not relieve the Plan Processor of notifying the
Participants' R[r]egulatory S[s]taff and the SEC.
    Figure B: Customer and Account Attributes [Information
(Including PII)]
* * * * *
    CAT [PII] Customer and Account Attributes data must be processed
within established timeframes to ensure data can be made available
to Participants' R[r]egulatory S[s]taff and the SEC in a timely
manner. Industry Members submitting [new or modified] Transformed
Values and Customer and Account Attributes [information] must
provide [it] them to the CCID Subsystem and Central Repository
respectively no later than 8:00 a.m. Eastern Time on T+1. The CCID
Subsystem and Central Repository must validate the data and generate
error reports no later than 5:00 p.m. Eastern Time on T+1. The CCID
Subsystem and Central Repository must process the resubmitted data
no later than 5:00 p.m. Eastern Time on T+4. Corrected data must be
resubmitted no later than 5:00 p.m. Eastern Time on T+3. The Central
Repository must process the resubmitted data no later than 5:00 p.m.
Eastern Time on T+4. Corrected data must be available to regulators
no later than 8:00 a.m. Eastern Time on T+5.
    Customer information that includes [PII data] Customer and
Account Attributes and Customer-ID(s) must be available to
regulators immediately upon receipt of initial data and corrected
data, pursuant to security policies for retrieving [PII] Customer
and Account Attributes and Customer-IDs.
* * * * *

8.1 Regulator Access

    The Plan Processor must provide Participants' [r]Regulatory
[s]Staff and the SEC with access to [all ]CAT Data based on a roles-
based access control model that follows ``least privileged''
practices and only for surveillance and regulatory purposes[ only]
consistent with Participants Confidentiality Policies and Procedure
as set forth in Article VI, Section 6.5(g). Participants'
[r]Regulatory [s]Staff and the SEC [will access CAT Data to]must be
performing regulatory functions when using CAT Data, including for
economic analyses, market structure analyses, market surveillance,
investigations, and examinations, and may not use CAT Data in such
cases where use of CAT Data may serve both a surveillance or
regulatory purpose, and a commercial purpose. In any case where use
of CAT Data may serve both a surveillance or regulatory purpose, and
a commercial purpose (e.g., economic analyses or market structure
analyses in support of rule filings submitted to the Commission
pursuant to Section 19(b) of the Exchange Act), use of CAT Data is
not permitted.
* * * * *

8.1.1 Online Targeted Query Tool

* * * * *
    The tool must provide a record count of the result set, the date
and time the query request is submitted, and the date and time the
result set is provided to the users. In addition, the tool must
indicate in the search results whether the retrieved data was linked
or unlinked (e.g., using a flag). In addition, the online targeted
query tool must not display any [PII] Customer and Account
Attributes data. Instead, it will display existing [non-PII] unique
identifiers (e.g., Customer-ID or Firm Designated ID). The [PII]
Customer and Account Attributes corresponding to these identifiers
can be gathered using the [PII] Customer Identifying Systems
[w]Workflow described in Appendix D, Data Security, [PII] Customer
and Account Attributes Data Requirements. The Plan Processor must
define the maximum number of records that can be viewed in the
online tool as well as the maximum number of records that can be
downloaded (which may not exceed 200,000 records per query request).
Users must have the ability to download the results to .csv, .txt,
and other formats, as applicable. These files will also need to be
available in a compressed format (e.g., .zip, .gz). Result sets that
exceed the maximum viewable or download limits must return to users
a message informing them of the size of the result set and the
option to choose to have the result set returned via an alternate
method.
    The Plan Processor must define a maximum number of records that
the online targeted query tool is able to process. The minimum
number of records that the online targeted query tool is able to
process is 5,000 (if viewed within the online query tool) or 10,000
(if viewed via a downloadable file). The maximum number of records
that can be viewed via downloadable file is 200,000.
    Once query results are available for download, users are to be
given the total file size of the result set and an option to
download the results in a single or multiple file(s), if the
download does not exceed 200,000 records. Users that select the
multiple file option will be required to define the maximum file
size of the downloadable files subject to the download restriction
of 200,000 records per query result. The application will then
provide users with the ability to download the files. This
functionality is provided to address limitations of end-user network
environment that may occur when downloading large files.
    The tool must log submitted queries and parameters used in the
query, the user ID of the submitter, the date and time of the
submission, as well as the delivery of results (the number of
records in the result(s) and the time it took for the query to be
performed). The tool must log the same information for data accessed
and extracted, when applicable. The Plan Processor will use this
logged information to provide monthly reports to each Participant
and the SEC of its respective metrics on query performance and data
usage of the online query tool. The Operating Committee must receive
all monthly reports in order to review items, including user usage
and system processing performance.
* * * * *

8.1.3 Online Targeted Query Tool Access and Administration

    Access to CAT Data is limited to authorized regulatory users
from the Participants and the SEC. Authorized regulators from the
Participants and the SEC may access all CAT Data, with the exception
of [PII] Customer and Account Attributes data. A subset of the
authorized regulators from the Participants and the SEC will have
permission to access and view [PII] Customer and Account Attributes
data. The Plan Processor must work with the Participants and SEC to
implement an administrative and authorization process to provide
regulator access. The Plan Processor must have procedures and a
process in place to verify the list of active users on a regular
basis.
    A two-factor authentication is required for access to CAT Data.
[PII] Customer and Account Attributes data must not be available via
the online targeted query tool or the user-defined direct query
interface.
* * * * *

8.2 User-Defined Direct Queries and Bulk Extraction of Data

    The Central Repository must provide for direct queries, bulk
extraction, and download of data for all regulatory users. Both the
user-defined direct queries and bulk extracts will be used by
regulators to deliver large sets of data that can then be used in
internal surveillance or market analysis applications. The data
extracts must use common industry formats.
    Direct queries must not return or display [PII] Customer and
Account Attributes data. Instead, they will return existing [non-
PII] unique identifiers (e.g., Customer-ID or Firm Designated ID).
The [PII] Customer and Account Attributes corresponding to these
identifiers can be gathered using the [PII] Customer Identifying
Systems [w]Workflow described in Appendix D, Data Security, [PII]
Customer and Account Attributes Data Requirements.
* * * * *

8.2.1 User-Defined Direct Query Performance Requirements

    The user-defined direct query tool is a controlled component of
the production environment made available to allow the Participants'
R[r]egulatory S[s]taff and the SEC to conduct queries. The user-
defined direct query tool must:

Provide industry standard programmatic interface(s) that allows
Participants' R[r]egulatory S[s]taff and the SEC with the ability to
create, save, and run a query;
* * * * *

8.2.2 Bulk Extract Performance Requirements

* * * * *
    Extraction of data must be consistently in line with all
permissioning rights granted by the Plan Processor. Data returned
must be encrypted, password protected, and sent via secure methods
of transmission. In addition, [PII] Customer and Account Attributes
data will be unavailable [must be masked] unless users have
permission to view the data that has been requested.
* * * * *
    The user-defined direct query and bulk extraction tool must log
submitted queries and parameters used in the query, the user ID of
the submitter, the date and time of the submission, and the date and
time of the delivery of results. The Plan Processor will use this
logged information to provide monthly reports to the Operating
Committee, Participants and the SEC of their respective usage of the
[online query tool]user-defined direct query and bulk extraction
tool.
* * * * *

8.3 Identifying Latency and Communicating Latency Warnings to CAT
Reporters

    The Plan Processor will measure and monitor Latency within the
CAT network. Thresholds for acceptable levels of Latency will be
identified and presented to the Operating Committee for approval.
The Plan Processor will also define policies and procedures for
handling and the communication of data feed delays to CAT Reporters,
the SEC, and Participants' R[r]egulatory S[s]taff that occur in the
CAT. Any delays will be posted for public consumption, so that CAT
Reporters may choose to adjust the submission of their data
appropriately, and the Plan Processor will provide approximate
timelines for when system processing will be restored to normal
operations.
* * * * *

9. [CAT Customer and Customer Account Information] CAIS, the CCID
Subsystem and the Process for Creating Customer-IDs

9.1 The CCID Subsystem

    The Plan Processor will generate a Customer-ID using a two-phase
transformation process that does not require ITIN(s)/SSN(s)/EIN(s)
to be reported to the CAT. In the first phase, Industry Members or
Regulatory Staff will transform the ITIN(s)/SSN(s)/EIN(s) of a
Customer using the CCID Transformation Logic, as further outlined
below, into a Transformed Value which will be submitted to the CCID
Subsystem with any other information and additional elements
required by the Plan Processor to establish a linkage between the
Customer-ID and Customer and Account Attributes. The CCID Subsystem
will perform a second transformation to create the globally unique
Customer-ID for each Customer. From the CCID Subsystem, the
Customer-ID will be sent to CAIS separately from any other CAT Data
(e.g., Customer and Account Attributes) required by the Plan
Processor to identify a Customer. The Customer-ID will be linked to
the associated Customer and Account Attributes and made available to
Regulatory Staff for queries in accordance with Appendix D, 4.1.6
(Customer Identifying Systems Workflow) and Appendix D, Section 6
(Data Availability). The Customer-ID may not be shared with the
Industry Member.
    The CCID Transformation Logic will be provided to Industry
Members and Participants (pursuant to the provisions of Appendix D,
Section 4.1.6 (Customer Identifying Systems Workflow), as described
below.
    Industry Members: The CCID Transformation Logic will be embedded
in the CAT Reporter Portal or used by Industry Member in machine-to-
machine processing.
    Regulatory Staff: Regulatory Staff may receive ITIN(s)/SSN(s)/
EIN(s) of Customers from outside sources (e.g., via regulatory data,
a tip, complaint, or referral) and require the conversion of
ITIN(s)/SSN(s)/EIN(s) to Customer-ID(s). Consistent with the
provisions of Appendix D, Section 4.1.6 (Customer Identifying
Systems Workflow), for conversion of fifty or fewer ITIN(s)/SSN(s)/
EIN(s), the Plan Processor will embed the CCID Transformation Logic
in the client-side code of the CAIS/CCID Subsystem Regulator Portal.
For Programmatic CCID Access, Participants and the SEC will use the
CCID Transformation Logic pursuant to the provisions of Appendix D,
Section 4.1.6 (Customer Identifying Systems Workflow).
    The CCID Subsystem must be implemented using network
segmentation principles to ensure traffic can be controlled between
the CCID Subsystem and other components of the CAT System, with
strong separation of duties between the CCID Subsystem and all other
components of the CAT System. The design of the CCID Subsystem will
maximize automation of all operations of the CCID Subsystem to
prevent, if possible, or otherwise minimize human intervention with
the CCID Subsystem and any data in the CCID Subsystem.
    The Participants must ensure the timeliness, accuracy,
completeness, and integrity of a Transformed Value(s), and must
ensure the accuracy and overall performance of the CCID Subsystem to
support the creation of a Customer-ID that uniquely identifies each
Customer. The Participants also must assess the overall performance
and design of the CCID Subsystem and the process for creating
Customer-ID(s) as part of each annual Regular Written Assessment of
the Plan Processor, as required by Article VI, Section 6.6(b)(i)(A).
Because the CCID Subsystem is part of the CAT System, all provisions
of the CAT NMS Plan that apply to the CAT System apply to the CCID
Subsystem.

9.[1]2 Customer and [Customer] Account Attributes in CAIS and
Transformed Values [Information Storage]

    The CAT must [capture] collect and store Customer and [Customer
Account Information] Account Attributes in a secure database
physically separated from the transactional database. The Plan
Processor will maintain information of sufficient detail to uniquely
and consistently identify each Customer across all CAT Reporters,
and associated accounts from each CAT Reporter. The following
attributes, at a minimum, must be captured:
     [Social security number (SSN) or Individual Taxpayer
Identification Number (ITIN);
     Date of birth;
     Current n]Name (including first, middle and last name);
     [Current a]Address (including street number, street
name, street suffix and/or abbreviation (e.g., road, lane, court,
etc.), city, state, zip code, and country;
     [Previous name] Year of Birth; and
     [Previous address] Role in the Account.
    For legal entities, the CAT must [capture] collect the following
attributes:
     [Legal Entity Identifier (LEI) (if available);
     Tax identifier;
     [Full legal name; [and]
     Address[.] (including street number, street name,
street suffix and/or abbreviation (e.g., road, lane, court, etc.),
city, state, zip code, and country;
     Employer Identification Number (EIN); and
     Legal Entity Identifier (LEI), or other comparable
common entity identifier (if available), provided that if an
Industry Member has an LEI for a Customer, the Industry Member must
submit the Customer's LEI.
    For the account of a Customer, the Plan Processor must collect,
at a minimum, the following data:
     Account Owner Name
     Account Owner Mailing Address
     Account type;
     Customer type;
     Date Account Opened, or Account Effective Date, as
applicable;
     Large Trader Identifier (if applicable);
     Prime Broker ID;
     Bank Depository ID; and
     Clearing Broker.
    The Plan Processor must maintain valid Customer and [Customer]
Account Attributes [Information] for each trading day and provide a
method for Participants' [r]Regulatory [s]Staff and [the ]SEC staff
to easily obtain historical changes to [that information (e.g., name
changes, address changes, etc.)] Customer-IDs, Firm Designated IDs,
and all other Customer and Account Attributes.
    [The Plan Processor will design and implement a robust data
validation process for submitted Firm Designated ID, Customer
Account Information and Customer Identifying Information, and must
continue to process orders while investigating Customer information
mismatches. Validations should:
     Confirm the number of digits on a SSN,

     Confirm date of birth, and
     Accommodate the situation where a single SSN is used by
more than one individual.]
    The Plan Processor will use the [Customer information submitted
by all broker-dealer CAT Reporters] Transformed Value to assign a
unique Customer-ID for each Customer. The Customer-ID must be
consistent across all [broker-dealers] Industry Members that have an
account associated with that Customer. This unique [CAT-]Customer-ID
will not be returned to [CAT Reporters and will only be used
internally by the CAT] Industry Members.
    [Broker-Dealers] Industry Members will initially submit full
[account] lists of Customer and Account Attributes, Firm Designated
IDs, and Transformed Values for all [a]Active [a]Accounts to the
Plan Processor and subsequently submit updates and changes on a
daily basis. In addition, the Plan Processor must have a process to
periodically receive [full account lists] updates, including a full
refresh of all Customer and Account Attributes, Firm Designated IDs,
and Transformed Values to ensure the completeness and accuracy of
the [account database] data in CAIS. The Central Repository must
support account structures that have multiple account owners and
associated Customer and Account Attributes [information] (joint
accounts, managed accounts, etc.), and must be able to link accounts
that move from one [CAT Reporter] Industry Member to another (e.g.,
due to mergers and acquisitions, divestitures, etc.).

[ 9.2 Required Data Attributes for Customer Information Data
Submitted by Industry Members

    At a minimum, the following Customer information data attributes
must be accepted by the Central Repository:

 Account Owner Name;
 Account Owner Mailing Address;
 Account Tax Identifier (SSN, TIN, ITIN);
 Market Identifiers (Larger Trader ID, LEI);
 Type of Account;
 Firm Identifier Number;
    [cir] The number that the CAT Reporter will supply on all orders
generated for the Account;
 Prime Broker ID;
 Bank Depository ID; and
 Clearing Broker.]

9.3. Customer-ID Tracking

    The Plan Processor will assign a [CAT-]Customer-ID for each
unique Customer. The Plan Processor will [determine] create a unique
Customer-ID using [information such as SSN and DOB] the Transformed
Value for natural persons Customers or an EIN for legal entity
[identifiers for]-Customers [that are not natural persons] and will
resolve discrepancies in Transformed Values). Once a [CAT-]Customer-
ID is assigned, it will be added to each linked (or unlinked) order
record for that Customer.
    Participants and the SEC must be able to use the unique [CAT-
]Customer-ID to track orders from, and allocations to, any Customer
or group of Customers over time, regardless of what brokerage
account was used to enter the order.

9.4 Error Resolution for [Customer Data] the CCID Subsystem and
CAIS

    The CCID Subsystem and CAIS shall support error resolution
functionality which includes the following components: validation of
submitted data, notification of errors in submitted data,
resubmission of corrected data, validation of corrected data, and an
audit trail of actions taken to support error resolution.
    Consistent with Section 7.2, the Plan Processor will design and
implement a robust data validation process for all ingested values
and functionality including, at a minimum:
     The ingestion of Transformed Values and the creation of
Customer-IDs through the CCID Subsystem;
     The transmission of Customer-IDs from the CCID
Subsystem to CAIS or a Participant's SAW; and
     The transmission and linking of all Customer and
Account Attributes and any other identifiers (e.g., Industry Member
Firm Designated ID) required by the Plan Processor to be reported to
CAIS.
    For example, the validation process should at a minimum identify
and resolve errors with an Industry Member's submission of
Transformed Values, Customer and Account Attributes, and Firm
Designated IDs including where there are identical Customer-IDs
associated with significantly different names, and identical
Customer-IDs associated with different years of birth, or other
differences in Customer and Account Attributes for identical
Customer-IDs.
    These validations must result in notifications to the Industry
Member to allow for corrections, resubmission of corrected data and
revalidation of corrected data. As a result of this error resolution
process there will be accurate reporting within a single Industry
Member as it relates to the submission of Transformed Values and the
linking of associated Customer and Account Attributes reported.
    The Plan Processor must design and implement procedures and
mechanisms to handle both minor and material inconsistencies in
Customer information. The Central Repository needs to be able to
accommodate minor data discrepancies such as variations in road name
abbreviations in searches. Material inconsistencies such as two
different people with the same [SSN] Customer-ID must be
communicated to the submitting [CAT Reporters] Industry Members and
resolved within the established error correction timeframe as
detailed in Appendix D, Section [8]6.2.
    The Central Repository must have an audit trail showing the
resolution of all errors including material inconsistencies,
occurring in the CCID Subsystem and CAIS. The audit trail must, at a
minimum, include the:

 [CAT Reporter] Industry Members and Participants (pursuant
to the provisions of Appendix D, Section 4.1.6 (Customer Identifying
Systems Workflow) submitting the [data] Transformed Value or
Customer and Account Attributes and other identifiers, as
applicable;
 Initial submission date and time;
 Data in question or the ID of the record in question;
 Reason identified as the source of the [issue]error, such
as:
    [cir] Transformed Value outside the expected range of values;
    [cir] duplicate [SSN]Customer-ID, significantly different Name;
    [cir] duplicate [SSN]Customer-ID, different [DOB]year of birth;
    [cir] discrepancies in LTID; or
    [cir] others as determined by the Plan Processor;
 Date and time notification of the [issue] error was
transmitted to the [CAT Reporter]Industry Member or Participant
(pursuant to the provisions of Appendix D, Section 4.1.6 (Customer
Identifying Systems Workflow), include[ed]ing each time the issue
was re-transmitted, if more than once;
 Corrected submission date and time, including each
corrected submission if more than one, or the record ID(s) of the
corrected data or a flag indicating that the issue was resolved and
corrected data was not required; and
 Corrected data, the record ID, or a link to the corrected
data.

10. User Support

10.1 CAT Reporter Support

    The Plan Processor will provide technical, operational and
business support to CAT Reporters for all aspects of reporting
including, but not limited to, issues related to the CCID
Transformation Logic and reporting required by the CCID Subsystem.
Such support will include, at a minimum:
     Self-help through a web portal;
     Direct support through email and phone;
     Support contact information available through the
internet; and
     Direct interface with Industry Members and Data
Submitters via industry events and calls, industry group meetings
and informational and training sessions.
    The Plan Processor must develop tools to allow each CAT Reporter
to:
     Monitor its submissions;
     View submitted transactions in a non-bulk format (i.e.,
non-downloadable) to facilitate error corrections;
     Identify and correct errors;
     Manage Customer and [Customer ]Account
Attributes[Information];
     Monitor its compliance with CAT reporting
requirements;[and]
     Monitor system status[.]; and
     Monitor the use of the CCID Transformation Logic
including the submission of Transformed Values to the CCID
Subsystem.
* * * * *

10.2 CAT User Support

    The Plan Processor will develop a program to provide technical,
operational and business support to CAT users, including
Participants' R[r]egulatory S[s]taff and the SEC. The CAT help desk
will provide technical expertise to assist regulators with questions
and/or functionality about the content and structure of the CAT
query capability.
    The Plan Processor will develop tools, including an interface,
to allow users to monitor the status of their queries and/or

reports. Such website will show all in-progress queries/reports, as
well as the current status and estimated completion time of each
query/report.
    The Plan Processor will develop communication protocols to
notify regulators of CAT System status, outages and other issues
that would affect Participants' R[r]egulatory S[s]taff and the SEC's
ability to access, extract, and use CAT Data. At a minimum,
Participants' R[r]egulatory S[s]taff and the SEC must each have
access to a secure website where they can monitor CAT System status,
receive and track system notifications, and submit and monitor data
requests.
    The Plan Processor will develop and maintain documentation and
other materials as necessary to train regulators in the use of the
Central Repository, including documentation on how to build and run
reporting queries.

10.3 CAT Help Desk

    The Plan Processor will implement and maintain a help desk to
support broker-dealers, third party CAT Reporters, and Participant
CAT Reporters (the ``CAT Help Desk''). The CAT Help Desk will
address business questions and issues, as well as technical and
operational questions and issues. The CAT Help Desk will also assist
Participants' regulatory staff and the SEC with questions and issues
regarding obtaining and using CAT Data for regulatory purposes.
    The CAT Help Desk must go live within a mutually agreed upon
reasonable timeframe after the Plan Processor is selected, and must
be available on a 24x7 basis, support both email and phone
communication, and be staffed to handle at minimum 2,500 calls per
month. Additionally, the CAT Help Desk must be prepared to support
an increased call volume at least for the first few years. The Plan
Processor must create and maintain a robust electronic tracking
system for the CAT Help Desk that must include call logs, incident
tracking, issue resolution escalation.
    CAT Help Desk support functions must include:
     Setting up new CAT Reporters, including the assignment
of CAT-Reporter-IDs and support prior to submitting data to CAT;
     Managing CAT Reporter authentication and entitlements;
     Managing CAT Reporter and third party Data Submitters
testing and certification;
     Managing Participants and SEC authentication and
entitlements;
     Supporting CAT Reporters with data submissions and data
corrections, including submission of Customer and [Customer] Account
Attributes [Information];
     Coordinating and supporting system testing for CAT
Reporters;
     Responding to questions from CAT Reporters about all
aspects of CAT reporting, including reporting requirements,
technical data transmission questions, potential changes to SEC Rule
613 that may affect the CAT, software/hardware updates and upgrades,
entitlements, reporting relationships, and questions about the
secure and public websites;
     Responding to questions from Participants' regulatory
staff and the SEC about obtaining and using CAT Data for regulatory
purposes, including the building and running of queries; [and]
     Responding to administrative issues from CAT Reporters,
such as billing; and
     Responding to questions from and providing support to
CAT Reporters regarding all aspects of the CCID Transformation Logic
and CCID Subsystem.

    By the Commission.

    Dated: August 21, 2020.
Vanessa A. Countryman,
Secretary.
[FR Doc. 2020-18801 Filed 10-15-20; 8:45 am]
BILLING CODE 8011-01-P


[Federal Register Volume 88, Number 205 (Wednesday, October 25, 2023)]
[Notices]
[Page 73329]
[FR Doc No: 2023-23588]

-----------------------------------------------------------------------

DEPARTMENT OF ENERGY

Federal Energy Regulatory Commission

[Docket Nos. ER02-2001-020; ER20-2726-001; ER20-2694-000]

Electric Quarterly Reports, Grand Energy, LLC, Icon Energy LLC;
Notice of Revocation of Market-Based Rate Authority and Termination of
Electric Market-Based Rate Tariff

    On August 24, 2023, the Commission issued an order announcing its
intent to revoke the market-based rate authority of several public
utilities that had failed to file their required Electric Quarterly
Reports.\1\ The Commission directed those public utilities to file the
required Electric Quarterly Reports within 15 days of the date of
issuance of the order or face revocation of their authority to sell
power at market-based rates and termination of their electric market-
based rate tariffs.\2\
---------------------------------------------------------------------------

    \1\ Electric Quarterly Reports, 184 FERC ] 61,117 (2023) (August
24 Order).
    \2\ Id. at Ordering Paragraph A.
---------------------------------------------------------------------------

    The time period for compliance with the August 24 Order has
elapsed. The above-captioned companies failed to file their delinquent
Electric Quarterly Reports. The Commission hereby revokes, effective as
of the date of issuance of this notice, the market-based rate authority
and terminates the electric market-based rate tariff of each of the
companies who are named in the caption of this order.

    Dated: October 19, 2023.
Kimberly D. Bose,
Secretary.
[FR Doc. 2023-23588 Filed 10-24-23; 8:45 am]
BILLING CODE 6717-01-P


provisions but did not object to a delay of the compliance dates (see
Document ID 2118, pp. 1-2; 2123, p. 3).
    In finalizing the compliance delay, the agency is also being
consistent with its 2018 delay of the compliance dates for many of the
ancillary provisions in the beryllium standard for general industry
(see 83 FR 25536 (June 1, 2018) (NPRM); 83 FR 39351 (Aug. 9, 2018)
(final rule)). There, OSHA planned to propose modifications to those
ancillary provisions; the agency reasoned that it would not make sense
for either the

agency or the regulated community for OSHA to begin enforcement of
requirements that would be affected by changes made in the upcoming
rulemaking. Employers would likely have to take unnecessary measures to
comply with provisions that could subsequently be modified, resulting
in wasted resources. Furthermore, the compliance date extension for the
beryllium general industry standard gave OSHA time to prepare and
publish the planned substantive NPRM to amend the standard before
employers were required to comply with the affected provisions of the
rule (see 83 FR 25536). The reasons OSHA gave in 2018 for delaying
compliance with the general industry provisions are applicable to the
agency's current final action in delaying the compliance dates for the
ancillary provisions of the construction and shipyards standards.
Indeed, the rationale has particular force here. Unlike in general
industry, where OSHA planned merely to revise existing requirements in
the standard, OSHA here previously proposed to revoke the ancillary
provisions of the construction and shipyards standards entirely. As
such, employers in these industries likely have not prepared to comply
with any portion of these provisions.
    In general industry, OSHA proposed to delay the compliance date for
certain ancillary provisions to allow the agency time to issue a new
proposal and expressed its intention to rely on its de minimis
enforcement policy while the rulemaking was pending so that employers
could comply with the proposed provisions without risk of a citation
(83 FR at 25537). Such an approach was appropriate in the general
industry context, where the agency planned to propose discrete changes
to provisions that employers otherwise expected to go into full effect.
Here, however, OSHA does not believe reliance on its de minimis policy
is appropriate. If finalized as proposed, the 2017 NPRM would have
eliminated any requirement for employers to comply with the ancillary
provisions of the shipyard and construction standards. Given OSHA's
decision not to revoke these provisions in this rulemaking and instead
to propose revisions to the ancillary provisions in a forthcoming
rulemaking action, OSHA believes that it is appropriate to apply a one-
year compliance extension to allow employers to prepare to comply. The
proposed delay was supported by several commenters (Document ID 2125,
p. 23; 2141, p. 11; 2142, p. 4). OSHA also notes that this is
consistent with the agency's approach in the 2017 final rule, where the
agency similarly gave all industries one year before any compliance
obligations began.
    OSHA recognizes the comments highlighting the urgent need for these
standards and the effect on workers' health that could occur in the
period before compliance is achieved (e.g., Document ID 2136, p. 4;
2130, p. 2). However, OSHA notes that the comments highlighting the
high levels of exposure that workers would continue to experience
during a compliance delay (e.g. Document ID 2140, p. 9; 2131, p. 2)
were submitted in 2017, before OSHA began to enforce any aspects of the
standards. Since May 2018, the agency has been enforcing the new, lower
exposure limits, providing important protection for workers who were
previously exposed above these limits (see Memorandum for Regional
Administrators, Delay of Enforcement of the Beryllium Standards under
29 CFR 1910.1024, 29 CFR 1915.1024, and 29 CFR 1926.1124, Mar. 2, 2018,
available at: https://www.osha.gov/laws-regs/standardinterpretations/2018-03-02). OSHA reiterates that employers must continue to comply
with paragraph (c) (the PEL and STEL) as subsequent rulemaking efforts
proceeds (see 29 CFR 1915.1024(o)(2)(i) and 29 CFR 1926.1124(o)(2)(i),
as amended).
    Similarly, OSHA acknowledges the comment, from NABTU, that OSHA has
not determined compliance with the 2017 final rule to be infeasible for
construction and shipyard employers, and the comment from Public
Citizen that compliance with the proposed rule (rescinding all
ancillary provisions but retaining the PELs) would have been much
easier to achieve than compliance with the 2017 final rule (see
Document ID 2129, p. 11; 2134, p. 4). OSHA still considers compliance
with the 2017 final rule to be feasible; the agency has not stated
otherwise. Regardless of feasibility, however, it would not make sense
for OSHA to require employers to comply with, or prepare to comply
with, ancillary provisions that are in a state of flux, especially
given that OSHA is enforcing the lower PELs. As for Public Citizen's
comment that compliance with a final rule revoking all ancillary
provisions would have been simpler for employers to comply with (see
Document ID, Attachment 2134, p. 4), OSHA agrees but, as discussed
above, the agency is not finalizing that portion of the NPRM.
    Finally, OSHA recognizes the comments, from the American Thoracic
Society and a private citizen, noting that the current regulatory
uncertainty is of OSHA's own making (Document ID 2081; see also
Document ID 2130, p. 2). However, as explained herein, OSHA has
determined that it is more important to proceed apace with a new
proposal than to require compliance with a standard that is subject to
change in the near future. The new proposal will account for regulatory
overlap, where it exists, be consistent with the general industry
beryllium standard, where appropriate, and maintain crucial worker
protections.

List of Subjects in 29 CFR Parts 1915 and 1926

    Beryllium, Cancer, Chemicals, Hazardous substances, Health,
Occupational safety and health.

Authority and Signature

    This document was prepared under the direction of Loren Sweatt,
Principal Deputy Assistant Secretary of Labor for Occupational Safety
and Health, U.S. Department of Labor. The agency issues the sections
under the following authorities: 29 U.S.C. 653, 655, 657; 40 U.S.C.
3704; 33 U.S.C. 941; Secretary of Labor's Order 1-2012 (77 FR 3912 (1/
25/2012)); and 29 CFR part 1911.

    Signed at Washington, DC, on September 24, 2019.
Loren Sweatt,
Principal Deputy Assistant Secretary of Labor for Occupational Safety
and Health.

Amendments to Standards

    For the reasons set forth in the preamble, chapter XVII of title
29, parts 1915 and 1926, of the Code of Federal Regulations is amended
as follows:

PART 1915--OCCUPATIONAL SAFETY AND HEALTH STANDARDS FOR SHIPYARD
EMPLOYMENT

0
1. The authority citation for part 1915 continues to read as follows:

    Authority: 33 U.S.C. 941; 29 U.S.C. 653, 655, 657; Secretary of
Labor's Order No. 12-71 (36 FR 8754); 8-76 (41 FR 25059), 9-83 (48
FR 35736), 1-90 (55 FR 9033), 6-96 (62 FR 111), 3-2000 (65 FR
50017), 5-2002 (67 FR 65008), 5-2007 (72 FR 31160), 4-2010 (75 FR
55355), or 1-2012 (77 FR 3912); 29 CFR part 1911; and 5 U.S.C. 553,
as applicable.

0
2. Amend Sec.  1915.1024 by revising paragraph (o)(2) to read as
follows:

Sec.  1915.1024   Beryllium.

* * * * *
    (o) * * *
    (2) Compliance dates. (i) All obligations contained in paragraph
(c) of this standard commence and become enforceable on March 12, 2018;
and
    (ii) All other obligations of this standard commence and become
enforceable on September 30, 2020.

PART 1926--SAFETY AND HEALTH REGULATIONS FOR CONSTRUCTION

Subpart Z--Toxic and Hazardous Substances

0
3. The authority citation for subpart Z of part 1926 continues to read
as follows:

    Authority: 40 U.S.C. 3704; 29 U.S.C. 653, 655, 657; and
Secretary of Labor's Order No. 12-71 (36 FR 8754), 8-76 (41 FR
25059), 9-83 (48 FR 35736), 1-90 (55 FR 9033), 6-96 (62 FR 111), 3-
2000 (65 FR 50017), 5-2002 (67 FR 65008), 5-2007 (72 FR 31160), 4-
2010 (75 FR 55355), or 1-2012 (77 FR 3912) as applicable; and 29 CFR
part 1911.
    Section 1926.1102 not issued under 29 U.S.C. 655 or 29 CFR part
1911; also issued under 5 U.S.C. 553.

0
2. Amend Sec.  1926.1124 by revising paragraph (o)(2) to read as
follows:

Sec.  1926.1124  Beryllium.

* * * * *
    (o) * * *
    (2) Compliance dates. (i) All obligations contained in paragraph
(c) of this standard commence and become enforceable on March 12, 2018;
and
    (ii) All other obligations of this standard commence and become
enforceable on September 30, 2020.

[FR Doc. 2019-21037 Filed 9-27-19; 8:45 am]
 BILLING CODE 4510-26-P