encryption is performed and the key management strategy (e.g., AES-
256, 3DES).
    [CAT Data stored in a public cloud must be encrypted at rest.
Non-PII CAT Data stored in a Plan Processor private environment is
not required to be encrypted at rest.]
    If public cloud managed services are used that would inherently
have access to the data (e.g., BigQuery, S3, Redshift), then the key
management surrounding the encryption of that data must be
documented (particularly whether the cloud provider manages the
keys, or if the Plan Processor maintains that control). Auditing and
real-time monitoring of the service for when cloud provider
personnel are able to access/decrypt CAT Data must be documented, as
well as a response plan to address instances where unauthorized
access to CAT Data is detected. Key management/rotation/revocation
strategies and key chain of custody must also be documented in
detail.

Data Storage and Environment

    Data centers housing CAT Systems (whether public or private)
must, at a minimum, be AICPA SOC 2 certified by [an independent
third party auditor] a qualified third-party auditor that is not an
affiliate of any of the Participants or the CAT Processor. The
frequency of the audit must be at least once per year.
    CAT compute infrastructure may not be commingled with other non-
regulatory systems (or tenets, in the case of public cloud
infrastructure). Systems hosting the CAT processing for any
applications must be segmented from other systems as far as is
feasible on a network level (firewalls, security groups, ACL's,
VLAN's, authentication proxies/bastion hosts and similar). In the
case of systems using inherently shared infrastructure/storage
(e.g., public cloud storage services), an encryption/key management/
access control strategy that effectively renders the data private
must be documented.
    The Plan Processor must include penetration testing and an
application security code audit by a reputable (and named) third
party prior to launch as well as periodically as defined in the
SLA(s). Reports of the audit will be provided to the Operating
Committee as well as remediation plan for identified issues. The
penetration test reviews of the Central Repository's network,
firewalls, and development, testing and production systems should
help the CAT evaluate the system's security and resiliency in the
face of attempted and successful systems intrusions.

Data Access

    The Plan Processor must provide an overview of how access to PII
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 user with access to different areas of the CAT System.
The CAT System must support an arbitrary number of roles 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 of the Participants and
the SEC will include only their respective list of users. The
Participants [and the SEC] 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.
    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 data must
follow non-PII password rules 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 [(including non-PII)] is required to be implemented by
the Plan Processor.

Breach Management

    The Plan Processor must develop policies and procedures
governing its responses to systems or data breaches. Such policies
and procedures will include a formal cyber incident response plan,
and documentation of all information relevant to breaches.
    The cyber incident response plan will provide guidance and
direction during security incidents. The plan will be subject to
approval by the Operating Committee. The plan may include items such
as:

Guidance on crisis communications;
Security and forensic procedures;
Customer notifications;
``Playbook'' or quick reference guides that allow responders quick
access to key information;
Insurance against security breaches;
Retention of legal counsel with data privacy and protection
expertise; and
Retention of a Public Relations firm to manage media coverage.

    Documentation of information relevant to breaches should
include:

A chronological timeline of events from the breach throughout the
duration of the investigation;
Relevant information related to the breach (e.g., date discovered,
who made the discovery, and details of the breach);
Response efforts, involvement of third parties, summary of meetings/
conference calls, and communication; and
The impact of the breach, including an assessment of data accessed
during the breach and impact on CAT Reporters.

PII Data Requirements

    PII data must not be included in the result set(s) from online
or direct query tools, reports or bulk data extraction. Instead,
results will display existing non-PII unique identifiers (e.g.,
Customer-ID or Firm Designated ID). The PII corresponding to these
identifiers can be gathered using the PII workflow described in
Appendix D, Data Security, PII Data Requirements. By default, users
entitled to query CAT Data are not authorized for PII access. The
process by which someone becomes entitled for PII access, and how
they then go about accessing PII data, must be documented by the
Plan Processor. The chief regulatory officer, or other such
designated officer or employee at each Participant [and the
Commission] must, at least annually, review and certify that people
with PII access have the appropriate level of access for their role.
    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.

Industry Standards

    The following industry standards [, at a minimum,]--which is not
intended to be an exclusive list--must be followed as such standards
and requirements may be replaced by successor publications, or
modified, amended, or supplemented and as approved by the Operating
Committee (in the event of a conflict between standards, the more
stringent standard shall apply, subject to the approval of the
Operating Committee):

National Institute of Standards and Technology:
    [cir] 800-23--Guidelines to Federal Organizations on Security
Assurance and Acquisition/Use of Test/Evaluated Products
    [cir] 800-53--Security and Privacy Controls for Federal
Information Systems and Organizations
    [cir] 800-115--Technical Guide to Information Security Testing
and Assessment
    [cir] 800-118--Guide to Enterprise Password Management
    [cir] 800-133--Recommendation for Cryptographic Key Generation
    [cir] 800-137--Information Security Continuous Monitoring for
Federal Information Systems and Organizations
    [cir] To the extent not specified above, all other provisions of
the NIST Cyber Security Framework
Federal Financial Institutions Examination Council:
    [cir] Authentication Best Practices
International Organization for Standardization:
    [cir] ISO/IEC 27001--Information Security Management

    The Company shall endeavor to join the FS-ISAC and comparable
bodies as the Operating Committee may determine. The FS-ISAC
provides real time security updates, industry best practices, threat
conference calls, xml data feeds and a member contact directory. The
FS-ISAC provides the Company with the ability to work with the
entire financial industry to collaborate for the purposes of staying
up to date with the latest information security activities.

BCP/DR Process

Overview

    The Plan Processor must develop and implement disaster recovery
(``DR'') and business continuity plans (``BCP'') that are tailored
to the specific requirements of the CAT environment, and which must
be approved and regularly reviewed by the Operating Committee. The
BCP must address the protection of data, service for the data
submissions, processing, data access, support functions and
operations. In the context of this document, BCP generally refers to
how the business activities will continue in the event of a
widespread disruption and the DR requirements refer to how the CAT
infrastructure will be designed to support a full data center
outage. In addition, the Plan Processor must have SLAs in place to
govern redundancy (i.e., no single point of failure) of critical
aspects of the CAT System (e.g., electrical feeds, network
connectivity, redundant processors, storage units, etc.) and

must have an architecture to support and meet the SLA requirements.
Any SLAs between the Plan Processor and third parties must be
approved by the Operating Committee.

Industry Standards

    The following National Institute of Standards and Technology
standards, at a minimum, must be followed in association with
Disaster Recovery, in each case as such standards and requirements
may be replaced by successor publications, or modified, amended, or
supplemented and as approved by the Operating Committee:

[ssquf] 800-34--Contingency Planning for Federal Information
Systems; and

    Specifically, the following sections as minimum requirements for
designing and implementing BCP and DR plans:

[cir] Chapter 3: Information System Contingency Planning Process,
which identifies seven steps to use when developing contingency
plans;
[cir] Chapter 4: Information System Contingency Plan Development,
which outlines the key elements of a contingency plan;
[cir] Chapter 5: Technical Contingency Planning Considerations
(using the specific sections applicable to the Plan Processor's
systems) which provides considerations specific to different types
of technology; and
[cir] Other sections and the appendices should be taken into
consideration as warranted.

    In addition, the Plan Processor will need to develop a process
to manage and report all breaches.

Business Continuity Planning

    The Plan Processor will design a BCP that supports a
continuation of the business activities required of the CAT in the
event of a widespread disruption.
    With respect to the team supporting CAT business operations, a
secondary site must be selected that is capable of housing the
critical staff necessary for CAT business operations. The site must
be fully equipped to allow for immediate use. The selection of the
site must take into account diversity in utility and
telecommunications infrastructure as well as the ability for CAT
staff to access the site in the event of transit shutdowns, closure
of major roadways and other significant disruptions that may affect
staff. Planning should consider operational disruption involving
significant unavailability of staff.
    A bi-annual test of CAT operations where CAT staff operates the
facility from the secondary site is required. This will ensure that
phone systems, operational tools and other help desk functions all
work as expected and the Plan Processor still functions as usual
even in the event of a disruption.
    CAT operations staff must maintain, and annually test, remote
access capabilities to ensure smooth operations during a site un-
availability event. Certain critical staff may be required to report
directly to the secondary office site. However, an effective
telecommuting solution must be in place for all critical CAT
operations staff. Furthermore, any telecommuting strategy must
require a remote desktop style solution where CAT operations and
data consoles remain at the primary data center and must further
ensure that CAT Data may not be downloaded to equipment that is not
CAT-owned and compliant with CAT security requirements.
    The BCP must identify critical third party dependencies. The
Plan Processor will coordinate with critical suppliers regarding
their arrangements and involve these parties in tests on an annual
basis. Critical third party firms may be required to provide
evidence of their BCP capabilities and testing.
    The Plan Processor must conduct third party risk assessments at
regular intervals to verify that security controls implemented are
in accordance with NIST SP 800-53. These risk assessments must
include assessment scheduling, questionnaire completion and
reporting. The Plan Processor should provide assessment reports to
the Operating Committee.
    The Plan Processor will develop and annually test a detailed
crisis management plan to be invoked following certain agreed
disruptive circumstances.
    The processing sites for business continuity must adhere to the
``Interagency Paper on Sound Practices to Strengthen the Resilience
of the U.S. Financial System.'' \3947\
---------------------------------------------------------------------------

    \3947\ See Interagency Paper on Sound Practices to Strengthen
the Resilience of the U.S. Financial System (Apr. 8, 2003),
available at http://www.sec.gov/news/studies/34-47638.htm.
---------------------------------------------------------------------------

    The Plan Processor will conduct an annual Business Continuity
Audit using an Independent Auditor approved by the Operating
Committee. The Independent Auditor will document all findings in a
detailed report provided to the Operating Committee.

Disaster Recovery Requirements

    The Plan Processor will implement a DR capability that will
ensure no loss of data and will support the data availability
requirements and anticipated volumes of the CAT.
    A secondary processing site must be capable of recovery and
restoration of services at the secondary site within a minimum of 48
hours, but with the goal of achieving next day recovery after a
disaster event. The selection of the secondary site must consider
sites with geographic diversity that do not rely on the same
utility, telecom and other critical infrastructure services. The
processing sites for disaster recovery and business continuity must
adhere to the ``Interagency Paper on Sound Practices to Strengthen
the Resilience of the U.S. Financial System.''
    The secondary site must have the same level of availability/
capacity/throughput and security (physical and logical) as the
primary site. The requirement implies and expects that fully
redundant connectivity between the primary and secondary processing
sites be established and fully available. Further, given this
recovery window, this connectivity must be used to replicate
repositories between the primary and secondary sites. Finally, CAT
Reporter and Data Submitter submissions must be replicated to the
secondary site for possible replay if recent replications are
incomplete. Replication must occur as deliveries complete to ensure
that a widespread communications failure will have minimal impact to
the state of the secondary site.
    On an annual basis, the Plan Processor must execute an industry
DR test, which must include Plan Participants and a critical mass of
non-Plan Participant CAT Reporters and Data Submitters. The tests
must be structured such that all CAT Reporters and other Data
Submitters can upload to the DR site and the data be ingested by the
CAT Data loaders. All DR tests are required to realistically reflect
the worst-case scenario.
    Failover processes must be transparent to CAT Reporters, as well
as failback. In the event of a site failover, CAT Reporters must be
able to deliver their daily files without changing configuration.
This avoids requiring all CAT Reporters to update configurations,
which is an error-prone effort.
    After a DR event, the primary processing site must be made
available as quickly as possible. For short duration DR events, the
primary site must be returned to primary within 48 hours after the
DR event. Longer duration outages will have differing SLAs. The DR
plan must include designs that allow the re-introduction of the
primary site or the introduction of a new primary site as the event
dictates and an indication of the time required for this re-
introduction.

Data Availability

Data Processing

    CAT order events must be processed within established timeframes
to ensure data can be made available to Participants' regulatory
staff 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 Participant regulatory staff and the SEC.

    Late submissions or re-submissions (after 8:00 a.m.) may be
considered to be processed that day if it falls within a given time
period after the cutoff. This threshold will be determined by the
Plan Processor and approved by the Operating Committee. In the event
that a significant portion of the data

has not been received as monitored by the Plan Processor, the Plan
Processor may decide to halt processing pending submission of that
data.
[GRAPHIC] [TIFF OMITTED] TN23NO16.000

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' regulatory staff 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'
regulatory staff and the SEC.
    The Plan Processor must provide reports and notifications to
Participant regulatory staff 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' regulatory
staff 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'
regulatory staff and the SEC.
[GRAPHIC] [TIFF OMITTED] TN23NO16.001

    CAT PII data must be processed within established timeframes to
ensure data can be made available to Participants' regulatory staff
and the SEC in a timely manner. Industry Members submitting new or
modified Customer information must provide it to the Central
Repository no later than 8:00 a.m. Eastern Time on T+1. The Central
Repository must validate the data and generate error reports no
later than 5:00 p.m. Eastern Time on T+[3]1. The 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 must be available to
regulators immediately upon receipt of initial data and corrected
data, pursuant to security policies for retrieving PII.

Receipt of Data from Reporters

Receipt of Data Transmission

    Following receipt of data files submitted by the CAT Reporter or
Data Submitter, the Plan Processor must send an acknowledgement of
data received to the CAT Reporter and Data Submitter, if applicable.
Such acknowledgment will enable CAT Reporters to create an audit
trail of their submissions and allow for tracing of data breakdowns
when data is not received. At a minimum, the receipt acknowledgement
will include:

SRO-Assigned Market Participant Identifier;
Date of Receipt;
Time of Receipt;
File Identifier; and
Value signifying the acknowledgement of receipt, but not processing,
of the file.

Data Validation

    The Plan Processor will implement data validations at the file
and individual record

level for data received by the Plan Processor including customer
data. If a record does not pass basic validations, such as syntax
rejections, then it must be rejected and sent back to the CAT
Reporter as soon as possible, so it can repair and resubmit.\3948\
The required data validations may be amended based on input from the
Operating Committee and the Advisory Committee. All identified
exceptions will be reported back to the CAT Reporter submitting the
data and/or the CAT Reporter on whose behalf the data was submitted.
---------------------------------------------------------------------------

    \3948\ If needed--data validation may be a process with an
initial validation phase for data errors and a subsequent validation
phase later in processing where more time is needed to assess the
context of the record in relation to data that may be submitted to
the CAT later in the submission window. The Plan Processor must have
an additional ``matching'' process for the purposes of linking
together order data passed between CAT Reporters.
---------------------------------------------------------------------------

    The data validations must include the following categories and
must be explained in the Technical Specifications document:

File Validations--Confirmation of file transmission and receipt are
in the correct formats. This includes validation of header and
trailers on the submitted report, confirmation of a valid SRO-
Assigned Market Participant Identifier, and verification of the
number of records in the file.
Validation of CAT Data--Syntax and context checks, including:
    [cir] Format checks:
    Check that the data is entered in the specified format
    [cir] Data Type checks:
    Check that the data type of each attribute is as per
specification
    [cir] Consistency checks:
    Check that all attributes for a record of a specified type are
consistent
    [cir] Range/logic checks:
    Range check--Validate that each attribute for every record has a
value within specified limits
    Logic check--Validate that the values provided against each
attribute are associated with the event type they represent
    [cir] Data validity checks:
    Validate that each attribute for every record has an acceptable
value
    [cir] Completeness checks:
    Verify that each mandatory attribute for every record is not
null
    [cir] Timeliness checks:
    Verify that records were submitted within the submission
timelines

Linkage Validation \3949\--Process by which related CAT Reportable
Events are in a linked daisy chain method
---------------------------------------------------------------------------

    \3949\ A linkage validation error should only populate for the
CAT Reporter that the Plan Processor determines to have broken the
link.

    CAT Reporters must have the ability to correct, replace or
delete records that have passed initial validations within the CAT.
    After the Central Repository has processed the data, the Plan
Processor must provide daily statistics, including at a minimum, the
following information:

SRO-Assigned Market Participant Identifier;
Date of Submission;
Number of files received;
Number of files accepted;
Number of files rejected;
Number of total order events received;
Number of order events accepted;
Number of order events rejected;
Number of each type of report received;
Number of each type of report accepted;
Number of each type of report rejected;
Number of customer records received;
Number of total customer records accepted;
Number of total customer records rejected;
Number of unknown accounts;
Number of late submissions;
Order-IDs rejected;
Reason(s) for rejection;
Number of records attempted to be matched;
Number of records matched; and
Percentage of records matched.

    Individual records contained in files that do not pass the file
validation process must not be included for further processing. Once
a file passes the initial validation, individual records contained
therein may then be processed for further validation. Individual
records that do not pass the data validation processes will not be
included in the final audit trail but must be retained.
Additionally, records not passing the validations will not be
included for matching processes.

Exception Management

    The Plan Processor must capture rejected records for each CAT
Reporter and make them available to the CAT Reporter. The
``rejects'' file must be accessible via an electronic file format
and the rejections and daily statistics must be available via a web
interface. The Plan Processor must provide functionality for CAT
Reporters to amend any exceptions.
    The Plan Processor must support bulk error correction. Rejected
records can be resubmitted as a new file with appropriate indicators
to identify the rejection record, which is being repaired. The Plan
Processor will then reprocess repaired records.
    A GUI must be available for CAT Reporters to make updates to
individual records or attributes and must include, at a minimum,
the:

Count of each type of rejection;
Reason for each rejection;
Ability to download the rejections;
Firm assigned order ID of each rejection;
Details of each rejection;
Type of report rejected; and
Repair status.

    The Plan Processor must support bulk replacement of records, and
reprocess such replaced records. The Plan Processor must provide CAT
Reporters with documentation that detail the process how to amend
and upload records that fail the validations that are outlined as
part of Section 7.4. The Plan Processor must maintain a detailed
audit trail capturing corrections to and replacements of records.
    The Plan Processor will provide CAT Reporters with their error
reports as they become available, and daily statistics will be
provided after data has been uploaded and validated by the Plan
Processor. The Plan Processor must support a continuous validation
and feedback model so that CAT Reporters can identify and correct
rejections on an ongoing basis. The rejected reports will include
descriptive details, or codes related to descriptive details, as to
why each data record was rejected by the Plan Processor.
    On a monthly basis, the Plan Processor must produce and publish
reports detailing performance and comparison statistics for CAT
Reporters,\3950\ similar to the Report Cards published for OATS
presently. This will enable CAT Reporters to assess their
performance in relation to their industry peers and help them assess
the risk related to their reporting of transmitted data.
---------------------------------------------------------------------------

    \3950\ See Appendix C, Error Communication, Correction, and
Processing.
---------------------------------------------------------------------------

    Breaks in intermittent lifecycle linkages must not cause the
entire lifecycle to break nor cause a reject to the CAT Reporter
that correctly reported.

Error Corrections

    Error corrections must be able to be submitted and processed at
any time, including timeframes after the standard repair window.
Additionally, in order to make corrections, CAT Reporters must have
access to the Central Repository over weekends.
    CAT Reporters must be able to submit error corrections for data
errors identified by CAT Reporters that passed format validations.
    Additionally, the Plan Processor must:

Provide feedback as to the reason(s) for errors;
Prevent a linkage break between reports from resulting in additional
events being rejected;
Allow broken linkages to be repaired without having to submit or
resubmit additional reports;
Allow error corrections to be submitted both via online and bulk
uploads or via file submission;
Support auto-correction of identified errors and notify reporters of
any auto-corrections;
Support group repairs (i.e., the wrong issue symbol affecting
multiple reports).

Data Ingestion

    Data submitted to the Central Repository, including rejections
and corrections, must be stored in repositories designed to hold
information based on the classification of the CAT Reporter (i.e.,
whether the CAT Reporter is a Participant, a broker-dealer, or a
third party Data Submitter). After ingestion by the Central
Repository, the Raw Data must be transformed into a format
appropriate for data querying and regulatory output.

Functionality of the CAT System

Regulator Access

    The Plan Processor must provide Participants' regulatory staff
and the SEC with access to all CAT Data for regulatory purposes
only. Participants' regulatory staff and the SEC will access CAT
Data to perform functions, including economic analyses, market
structure analyses, market surveillance, investigations, and
examinations.
    The CAT must be able to support, at a minimum, 3,000 regulatory
users within the

system. It is estimated that approximately 20% of all users will use
the system on a daily or weekly basis while approximately 10% of all
users will require advanced regulator-user access, as described
below. Furthermore, it is estimated that there may be approximately
600 concurrent users accessing the CAT at any given point in time.
These users must be able to access and use the system without an
unacceptable decline in system performance.\3951\
---------------------------------------------------------------------------

    \3951\ Specific performance requirements will be included in the
SLA.
---------------------------------------------------------------------------

    As stated in Appendix D, Data Security, the Plan Processor must
be able to support an arbitrary number of user roles. Defined roles
must include, at a minimum:

Basic regulator users--Individuals with approved access who plan to
use the Central Repository to run basic queries (e.g., pulling all
trades in a single stock by a specific party).
Advanced regulator users--Individuals with approved access who plan
to use the Central Repository to construct and run their own complex
queries.

    Regulators will have access to processed CAT Data through two
different methods, an online-targeted query tool and user-defined
direct queries and bulk extracts.

Online Targeted Query Tool

    The online targeted query tool will provide authorized users
with the ability to retrieve processed and/or validated (unlinked)
data via an online query screen that includes the ability to choose
from a variety of pre-defined selection criteria. Targeted queries
must include date(s) and/or time range(s), as well as one or more of
a variety of fields, including the following:

Instrument(s);
Related instruments (e.g., single stock and all options with for the
stock);
Data type (executions, orders, cancelations, quotes, etc.);
Product type (equity, option, etc.);
Processed data, unlinked data or both;
Listing market;
Exchange;
CAT-Reporter-ID(s)--CAT assigned and Participant assigned;
Customer-ID(s)--CAT assigned and CAT Reporter assigned;
CAT-Order-ID(s)--CAT assigned and CAT Reporter assigned;
ISO flag;
Put/call;
Strike price (include ability to select range);
Size;
Price;
Side;
Short-sale identifier;
Time-in-force (IOC, GTC, etc.);
Orders, quotes, BBOs or trades above or below a certain size;
Orders, quotes, BBOs or trades within a range of prices;
Canceled orders and/or trades;
CAT Reporters exceeding specified volume or percentage of volume
thresholds in a single instrument or market-wide during a specified
period of time;
CAT Reporter correction rate over time;
Audit trail of order linkages;
Corporate action events;
Instrument history; and
Others to be defined.

    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 data. Instead, it will display
existing non-PII unique identifiers (e.g., Customer-ID or Firm
Designated ID). The PII corresponding to these identifiers can be
gathered using the PII workflow described in Appendix D, Data
Security, PII 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. 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).
    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). Users that
select the multiple file option will be required to define the
maximum file size of the downloadable files. 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 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.

Online Targeted Query Tool Performance Requirements

    For targeted search criteria, the minimum acceptable response
times will be increments of less than one minute. For the complex
queries that either scan large volumes of data (e.g., multiple trade
dates) or return large result sets (>1M records), the response time
must generally be available within 24 hours of the submission of the
request. Regardless of the complexity of the criteria used within
the online query tool, any query request for data within one
business date of a 12-month period must return results within 3
hours.
    Performance requirements listed below apply to data:

 Online targeted query tool searches that include equities
and options trade data only in the search criteria must meet minimum
requirements, including:
    [cir] Returning results within 1 minute for all trades and
related lifecycle events for a specific Customer or CAT Reporter
with the ability to filter by security and time range for a
specified time window up to and including an entire day;
    [cir] Returning results within 30 minutes for all trades and
related lifecycle events for a specific Customer or CAT Reporter in
a specified date range (maximum 1 month);
    [cir] Returning results within 6 hours for all trades and
related lifecycle events for a specific Customer or CAT Reporter in
a specified date range (maximum 12-month duration from the most
recent 24 months); and
    [cir] Returning results for the full 6 years of data for all
trades and lifecycle events across daily, weekly, and multi-year
periods.
 Online targeted query tool searches that include equities
and options order and National Best Bid and National Best Offer data
in search criteria must meet minimum requirements, including:
    [cir] Returning results within 5 minutes for all orders and
their complete lifecycles for a single security from a specific
Participant across all markets (note: a Participant could have
multiple participant identifiers) in a specified time window not to
exceed 10 minutes for a single date;
    [cir] Returning results within 5 minutes for all orders,
cancelations, and the National Best Bid and National Best Offer (or
the protected best bid and offer) at the time the order is created
for a single security in a specified time window not to exceed 10
minutes for a single date;
    [cir] Returning results within 5 minutes for all equity and
options orders, cancelations, and executions from a specific market
participant in a single underlying instrument in a specified time
window not to exceed 10 minutes for a single date;
    [cir] Returning results within 5 minutes for all orders, quotes,
routes, cancelations and trades (complete life-cycle) for related
instruments (e.g., single stock and all options series for the same
stock) in a specified time window not to exceed 10 minutes for a
single date;
    [cir] Returning results within 5 minutes for all orders and
quotes entered during a specific time period by a list of specific
CAT Reporters, with the ability to drill down to show the complete
life-cycle must return results in a specified time window not to
exceed 10 minutes for a single date; and
    [cir] Returning results within 5 minutes for all orders and
quotes entered during a specific time period for a specified list of
instruments must return results in a specified time window not to
exceed 10 minutes for a single date.

    The online targeted query tool architecture must include an
automated application-level

resource management component. This feature must manage query
requests to balance the workload to ensure the response times for
targeted and complex queries meet the defined response times. The
resource management function will categorize and prioritize query
requests based on the input parameters, complexity of the query, and
the volume of data to be parsed in the query. Additionally, the
source of the query may also be used to prioritize the processing.
The Plan Processor must provide details on the prioritization plan
of the defined solution for online query requests.
    The online targeted query tool must support parallel processing
of queries. At a minimum, the online targeted query tool must be
able to process up to 300 simultaneous query requests with no
performance degradation.

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 data. A subset of the authorized regulators from the
Participants and the SEC will have permission to access and view PII
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 data must not be available via the online targeted query tool or
the user-defined direct query interface.

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 data. Instead,
they will return existing non-PII unique identifiers (e.g.,
Customer-ID or Firm Designated ID). The PII corresponding to these
identifiers can be gathered using the PII workflow described in
Appendix D, Data Security, PII Data Requirements.
    Participants and regulators must have the ability to create,
save, and schedule dynamic queries that will run directly against
processed and/or unlinked CAT Data. The examples below demonstrate
robust usage of the CAT Data to perform a variety of complex query,
surveillance, and market analysis use cases. User-defined direct
queries will be used to perform tasks such as market reconstruction,
behavioral analysis, and cross-market surveillance.
    The method(s) for providing this capability is dependent upon
the architecture of the CAT and will be defined by the final
solution. The CAT cannot be web-based due to the volumes of data
that could be extracted.
    The Participants are agnostic as to how user-defined direct
queries or bulk extracts are implemented as long as the solution
provides an open API that allows regulators to use analytic tools
(e.g., R, SAS, Python, Tableau) and can use ODBC/JDBC drivers to
access the CAT Data. Queries invoked through the open API must be
auditable. The CAT System must contain the same level of control,
monitoring, logging and reporting as the online targeted query tool.
The Plan Processor may define a limited set of basic required fields
(e.g., date and at least one other field such as symbol, CAT-
Reporter ID, or CAT-Customer-ID) that regulators must use in direct
dynamic queries.
    The Plan Processor must provide procedures and training to
regulators that will use the direct query feature. The Plan
Processor may choose to require that user-defined direct query users
participate in mandatory training sessions.
    The bulk extract feature will replace the current Intermarket
Surveillance Group (ISG) ECAT and COATS compliance data files that
are currently processed and provided to Participants for use in
surveillance applications. These files are used extensively across
all Participants in a variety of surveillance applications and are a
critical data input to many surveillance algorithms. With the
initial implementation of the CAT, opportunities exist to improve
the content and depth of information available in these data files.
The Plan Processor will need to work with ISG to define new layouts
that will include additional data elements that will be available in
the CAT Data.
    The Plan Processor is responsible for providing data models and
data dictionaries for all processed and unlinked CAT Data.

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'
regulatory staff and the SEC to conduct queries. The user-defined
direct query tool must:

Provide industry standard programmatic interface(s) that allows
Participants' regulatory staff and the SEC with the ability to
create, save, and run a query;
Provide query results that are extractable/downloadable and can be
used to refine subsequent queries;
Support complex, multistage queries;
Run at a minimum 3,000 queries on a daily basis. Of these, it is
anticipated that roughly 60% would be simple queries (e.g., pulling
of all trades in a given symbol traded during a certain time period)
and 40% would be complex (e.g., looking for quotes or orders more
than 5% away from the National Best Bid and National Best Offer);
Process and run approximately 1,800 queries concurrently;
Support SQL 92 as well as recursive queries with common table
expressions (recursive CTEs), bulk load utility, interface for
dimension management, windowing functions, JBDC and ODBC, or provide
another API with equal or greater query capabilities, so long as
ODBC and JDBC are supported. Support for stored procedures and user-
defined functions are optional;
Include data presentation tools/query tools that support query
results that produce data sets ranging from less than 1 gigabyte to
at least 10 terabytes or more of uncompressed data;
Provide query owners with the ability to schedule queries;
Provide query owners with the ability to cancel a query during
execution or prior to the scheduled running of a query;
Provide Participants with a means to view all saved queries owned by
the Participants as well as the scheduling of query executions (for
queries that have been scheduled);
Provide an automated delivery method of scheduled query results to
the appropriate Participant. Delivery methods must comply with all
information security guidelines (encryption, etc.);
Provide technical expertise to assist regulators with questions and/
or functionality about the content and structure of the CAT query
capability;
Include workload balancer to allow prioritization and processing of
queries and delivery of results; and
Support parallel processing of queries. At a minimum, the user-
defined direct query tool must be able to process up to 300
simultaneous query requests with no performance degradation.

Bulk Extract Performance Requirements

    For bulk extracts of an entire day of data, the minimum
acceptable transfer time of equity and options data is four hours.
This requirement assumes that there are no limitations within the
regulator's own network environment that will prevent the Plan
Processor from meeting this requirement.
    A consideration was made to require an online Report Center that
would include pre-canned reports that could be delivered to
regulators or pulled upon request. The reports would be predefined
based on requirements developed by Participants and the SEC. Due to
the added complexity and the lack of quantifiable use cases, the
Participants determined that this was something that may be useful
in the future but not at the initial implementation and launch of
the CAT. This will be reassessed when broker-dealers begin
submitting data to the CAT.
    It is envisioned that non-Participant CAT Reporters will be
unable to access their data submissions through bulk data exports
with the initial implementation of CAT. Only Participants and the
SEC will have access to full lifecycle corrected bulk data exports.
    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 data must be masked unless users have
permission to view the data that has been requested.
    The Plan Processor must have an automated mechanism in place to
monitor

user-defined direct query usage. This monitoring must include
automated alerts to notify the Plan Processor of potential issues
with bottlenecks or excessively long queues for queries or data
extractions. The Plan Processor must provide details as to how the
monitoring will be accomplished and the metrics that will be used to
trigger alerts.
    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.
    The bulk extract tool must support parallel processing of
queries. At a minimum, the bulk extract tool must be able to process
up to 300 simultaneous query requests with no performance
degradation.

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' regulatory staff 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.

Technical Operations

    The Plan Processor will develop policies, procedures, and tools
to monitor and manage the performance of the Central Repository, to
be approved by the Operating Committee. Such policies, procedures,
and tools will include, at a minimum:

Monitoring and management of system availability and performance, to
include both Online Targeted Query Tool and User-Defined Direct
Queries;
Monitoring and management of query tool usage (e.g., to identify
long-running or ``stuck'' queries); and
Segregation of query queues by regulator or Participant (i.e., one
regulator or Participant's queries should not prevent another
regulator or Participant's queries from running).

System SLAs

    Service Level Agreements for system and operational performance
will be established for areas, including the following:

Linkage and order event processing performance;
Query performance and response times;
System availability;
User support/help desk performance;
Application, network, and data security performance; and
Development, change management, and implementation processes and
timelines.

The actual terms of the SLAs will be negotiated between the Plan
Participants and the eventual Plan Processor.

CAT Customer and Customer Account Information

Customer and Customer Account Information Storage

    The CAT must capture and store Customer and Customer Account
Information 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 name;
Current address;
Previous name; and
Previous address.

For legal entities, the CAT must capture the following attributes:

 Legal Entity Identifier (LEI) (if available);
 Tax identifier;
 Full legal name; and
 Address.

    The Plan Processor must maintain valid Customer and Customer
Account Information for each trading day and provide a method for
Participants' regulatory staff and the SEC to easily obtain
historical changes to that information (e.g., name changes, address
changes, etc.).
    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 to assign a unique Customer-ID
for each Customer. The Customer-ID must be consistent across all
broker-dealers 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.
    Broker-Dealers will initially submit full account lists for all
active 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 to ensure the completeness and accuracy of the account
database. The Central Repository must support account structures
that have multiple account owners and associated Customer
information (joint accounts, managed accounts, etc.), and must be
able to link accounts that move from one CAT Reporter to another
(e.g., due to mergers and acquisitions, divestitures, etc.).

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.

Customer-ID Tracking

    The Plan Processor will assign a CAT-Customer-ID for each unique
Customer. The Plan Processor will determine a unique Customer using
information such as SSN and DOB for natural persons or entity
identifiers for Customers that are not natural persons and will
resolve discrepancies. 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 any Customer or group of Customers,
regardless of what brokerage account was used to enter the order.

Error Resolution for Customer Data

    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 must be communicated to the
submitting CAT Reporters and resolved within the established error
correction timeframe as detailed in Section 8.
    The Central Repository must have an audit trail showing the
resolution of all errors. The audit trail must, at a minimum,
include the:

CAT Reporter submitting the data;
Initial submission date and time;
Data in question or the ID of the record in question;
Reason identified as the source of the issue, such as:
    [cir] duplicate SSN, significantly different Name;
    [cir] duplicate SSN, different DOB;
    [cir] discrepancies in LTID; or
    [cir] others as determined by the Plan Processor;
Date and time the issue was transmitted to the CAT Reporter,
included 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.

User Support

CAT Reporter Support

    The Plan Processor will provide technical, operational and
business support to CAT Reporters for all aspects of reporting. 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 Information;
Monitor its compliance with CAT reporting requirements; and
Monitor system status.

    The Plan Processor will develop and maintain communication
protocols (including email messaging) and a secure website to keep
CAT Reporters informed as to their current reporting status, as well
as issues with the CAT that may impact CAT Reporters' ability to
submit or correct data. The website will use user authentication to
prevent users for seeing information about firms other than their
own, and will contain:

Daily reporting statistics for each CAT Reporter,\3952\ including
items such as:
---------------------------------------------------------------------------

    \3952\ Each CAT Reporter or Data Submitter must only be able to
view its own data and data it submits on behalf of others.
---------------------------------------------------------------------------

    [cir] SRO-Assigned Market Participant Identifier;
    [cir] Date of submission;
    [cir] Number of files received;
    [cir] Number of files accepted;
    [cir] Number of files rejected;
    [cir] Number of total order events received;
    [cir] Number of order events accepted;
    [cir] Number of order events rejected;
    [cir] Number of each type of report received;
    [cir] Number of each type of report accepted;
    [cir] Number of each type of report rejected;
    [cir] Number of total customer records accepted;
    [cir] Number of total customer records rejected;
    [cir] Order-IDs rejected;
    [cir] Reason for rejection;
    [cir] Number of records attempted to be matched;
    [cir] Number of records matched;
    [cir] Percentage of records matched;
    [cir] Number of customer records received;
    [cir] Number of unknown accounts;
    [cir] Latest view of statistics inclusive of re-submissions to
get a trade-date view of exceptions and correction statistics
available for CAT Reporters to know when everything for a given
trade date has been completed; and
    [cir] Most recent CAT Reporter Compliance Report Card, as
defined in section 12.4;
CAT System status, system notifications, system maintenance, and
system outages; and
A mechanism for submitting event data and correcting and
resubmitting rejections or inaccurate data.

    The Plan Processor will develop and maintain a public website
containing comprehensive CAT reporting information, including:

Technical Specifications;
Reporting guidance (e.g., FAQs);
Pending rule changes affecting CAT reporting;
CAT contact information;
Availability of test systems;
Testing plans;
Proposed changes to the CAT; and
Fee schedule.
    The Plan Processor will develop and maintain a mechanism for
assigning CAT Reporter-IDs. A mechanism will also be developed and
maintained to change CAT Reporter-IDs should this be necessary
(e.g., due to a merger), with the expectations that such changes
should be infrequent. Changes to CAT-Reporter-IDs must be reviewed
and approved by the Plan Processor.
    Initially, non-Participant CAT Reporters will not have access to
their data submissions through bulk data exports with the initial
implementation of the Central Repository. Only Participants and the
SEC will have access to full lifecycle corrected bulk data exports.
Non-Participant CAT Reporters will be able to view their submissions
online in a read-only, non-exportable format to facilitate error
identification and correction. Data Submitters will be able to
export bulk file rejections for repair and error correction
purposes.
    The Plan Processor will define methods by which it will consult
with and inform CAT Reporters and industry groups on updates and
changes to user support.
    The Plan Processor will define pre- and post-production support
programs to minimize the Error Rate and help CAT Reporters to meet
their compliance thresholds. Such pre-production support program
shall include, but are not limited to, the following activities:

Educational programs--Includes the following:
    [cir] Publication and industry-wide communication (including
FAQs) of the Technical Specifications, including:
    Appropriate definitions/expected usages for each value in field
format
    [cir] All available attribute values for each field
    [cir] Establishment of a dedicated help desk for Reporters to
contact;
    [cir] Industry participation in order linkage methodologies;
    Include information on new order/trade types;
    [cir] Hosting of industry educational calls; and
    [cir] Hosting of industry-wide training.
Registration--Requires all firms to:
    [cir] Register and be certified as CAT Reporters;
    [cir] Attend industry-wide training;
    [cir] Establish internal controls to capture potential
misreporting scenarios; and
    [cir] Work with the Plan Processor to understand scenario-based
reporting and expected outputs.
Communications Plan--A strong communications plan of the timeline to
reporting go-live shall:
    [cir] Include communication on how Error Rates and Compliance
Thresholds are calculated; and
    [cir] Describe how errors will be communicated back to CAT
Reporters.
Industry-wide testing--Industry-wide test results must be available
for all CAT Reporters.
    [cir] As mentioned in Appendix C, Objective Milestones to Assess
Progress, appropriate time must be provided between Technical
Specification publication and production go-live.
    [cir] Ample testing time must be provided.
    [cir] Appropriate scenario-based testing, including all three
validation processes, shall be established.
    [cir] A separate test environment for CAT Reporters that mirrors
the production environment shall be provided.

    Post-production support program activities shall include, but
are not limited to the following:

Issuing a monthly Report Card on reporting statistics, with
information on how reporters stand against similar entities;
Publishing daily reporting statistics;
Maintaining Technical Specifications with defined intervals for new
releases/updates;
Posting FAQs and other informational notices to be updated as
necessary;
Hosting of industry educational calls;
Hosting of industry-wide training;
Emailing outliers, meaning firms significantly reporting outside of
industry standards;
Conducting annual assessments of dedicated help desk to determine
appropriate staffing levels;
Using the test environment prior to releasing new code to
production; and
Imposing CAT Reporter requirements:
    [cir] Attendance/participation of industry testing sessions;
    [cir] Attendance in industry educational calls; and
    [cir] Attendance in industry-wide training.

CAT User Support

    The Plan Processor will develop a program to provide technical,
operational and business support to CAT users, including
Participants' regulatory staff 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' regulatory staff and the SEC's
ability to

access, extract, and use CAT Data. At a minimum, Participants'
regulatory staff 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.

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 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.

CAT Reporter Compliance

    The Plan Processor must include a comprehensive compliance
program to monitor CAT Reporters' adherence to SEC Rule 613. The
Chief Compliance Officer will oversee this compliance program, and
will have responsibility for reporting on compliance by CAT
Reporters to the Participants. The compliance program covers all CAT
Reporters, including broker-dealers and Participants.
    As a fundamental component of this program, the Plan Processor
will identify on a daily basis all CAT Reporters exceeding the
maximum allowable Error Rate established by the Participants. The
Error Rate will initially be set by the CAT NMS Plan, and will be
reviewed and adjusted on an ongoing basis by the Operating
Committee. Error Rates will be based on timeliness, correctness, and
linkages.
    The Plan Processor will, on an ongoing basis, analyze reporting
statistics and Error Rates and recommend to Participants proposed
changes to the maximum allowable Error Rates established by the
Participants. All CAT Reporters exceeding this threshold will be
notified that they have exceeded the maximum allowable Error Rate
and will be informed of the specific reporting requirements that
they did not fully meet (e.g., timeliness or rejections).
    The Plan Processor will develop and publish CAT Reporter
compliance report cards on a periodic basis to assist CAT Reporters
in monitoring overall compliance with CAT reporting requirements.
The Plan Processor will also recommend criteria and processes by
which CAT Reporters will be fined for inaccurate, incomplete, or
late submissions. The compliance report cards will include the
following information:

Number of inaccurate transactions submitted;
Number of incomplete transactions submitted; and
Number of transactions submitted later than reporting deadlines.

    The CAT Reporter compliance program will include reviews to
identify CAT Reporters that may have failed to submit order events
to the CAT, as well as to ensure CAT Reporters correct all
identified errors even if such errors do not exceed the maximum
allowable Compliance Threshold.
    The Plan Processor will, on a monthly basis, produce and provide
reports containing performance and comparison statistics as needed
to each Participant on its members' CAT reporting compliance
thresholds so that Participants can monitor their members'
compliance with CAT reporting requirements and initiate disciplinary
action when appropriate. The Plan Processor will also produce and
provide, upon request from the Participants and the SEC, reports
containing performance and comparison statistics as needed on each
CAT Reporter's compliance thresholds so that the Participants or the
SEC may take appropriate action if a Participant fails to comply
with its CAT reporting obligations.
    The Plan Processor will produce and make available on a monthly
basis reports for all CAT Reporters, benchmarking their performance
and comparison statistics against similar peers. The reports will be
anonymized such that it will not be possible to determine the
members of the peer group to which the CAT Reporter was compared.
    The Plan Processor will produce and make available to regulators
on a monthly basis a report detailing Error Rates, transaction
volumes, and other metrics as needed to allow regulators to oversee
the quality and integrity of CAT Reporter reporting to the Central
Repository.

Upgrade Process and Development of New Functionality

CAT Functional Changes

    The Plan Processor must propose a process governing the
determination to develop new functionality, which process must be
reviewed and approved by the Operating Committee. The process must,
at a minimum:

Contain a mechanism by which changes can be suggested to the
Operating Committee by Advisory Committee members, the Participants,
or the SEC;
Contain a defined process for developing impact assessments,
including implementation timelines, for proposed changes; and
Contain a mechanism by which functional changes which the Plan
Processor wishes to undertake can be reviewed and approved by the
Operating Committee.

    The Plan Processor shall not unreasonably withhold, condition,
or delay implementation of any changes or modifications reasonably
requested by the Operating Committee.

CAT Infrastructure Changes

    The Plan Processor must implement a process to govern changes to
CAT. This process must contain provisions for:

Business-as-usual changes (e.g., replacing failed hardware, adding
capacity to deal with expected increases in transaction volumes)
that would require the Plan Processor to provide the Operating
Committee with a summary report (e.g., infrastructure changes,
acquired costs, etc.); and
Isolated infrastructure changes (e.g., moving components of the
system from a self-hosted to an Infrastructure-as-a-Service
provider) that would require the Plan Processor to provide a request
to the Operating Committee for review and approval before commencing
any actions.

Testing of New Changes

    The Plan Processor must implement a process governing user
testing of changes to CAT functionality and infrastructure, which
process must be reviewed and approved by the Operating Committee.
The process must:

Define the process by which changes are to be tested by CAT
Reporters[ and regulators];
Define the criteria by which changes will be approved prior to their
deployment into the production environment(s); and
Define the environment(s) to be used for user testing.

EXHIBIT B

KEY TO COMMENT LETTERS CITED IN APPROVAL ORDER

Proposed National Market System Plan Governing the Consolidated Audit
Trail

(File No. 4-698)

1. Letter from Kathleen Weiss Hanley, Bolton-Perella Chair in
Finance, Lehigh University, and Jay. R. Ritter, Joseph B. Cordell
Eminent Scholar Chair, University of Florida, to Brent J. Fields,
Secretary, Commission, dated July 12, 2016 (``Hanley Letter'').
2. Letter from Courtney D. McGuinn, Operations Director, FIX Trading
Community, to Commission, dated July 14, 2016 (``FIX Trading
Letter'').
3. Letter from Kelvin To, Founder and President, Data Boiler
Technologies, LLC, to Brent J. Fields, Secretary, Commission, dated
July 15, 2016 (``Data Boiler Letter'').
4. Letter from Richard Foster, Senior Vice President and Senior
Counsel for Regulatory and Legal Affairs, Financial Services
Roundtable, to Brent J. Fields, Secretary, Commission, and Marcia E.
Asquith, Corporate Secretary, Financial Industry Regulatory
Authority, dated July 15, 2016 (``FSR Letter'').
5. Letter from David T. Bellaire, Esq., Executive Vice President and
General Counsel, Financial Services Institute, to Brent J. Fields,
Secretary, Commission, dated, July 18, 2016 (``FSI Letter'')
6. Letter from Stuart J. Kaswell, Executive Vice President and
Managing Director, General Counsel, Managed Funds Association, to
Brent J. Fields, Secretary, Commission, dated July 18, 2016 (``MFA
Letter'').
7. Letter from Bonnie K. Wachtel, Wachtel and Company, Inc., to
Commission, dated July 18, 2016. (``Wachtel Letter'').
8. Letter from David W. Blass, General Counsel, Investment Company
Institute, to Brent J. Fields, Secretary, Commission, dated July 18,
2016 (``ICI Letter'').
9. Letter from Larry E. Thompson, Vice Chairman and General Counsel,
Depository Trust and Clearing Corporation, to Brent J. Fields,
Secretary, Commission, dated July 18, 2016 (``DTCC Letter'').
10. Letter from Manisha Kimmel, Chief Regulatory Officer, Wealth
Management, Thomson Reuters, to Brent J. Fields, Secretary,
Commission, dated July 18, 2016 (``TR Letter'').
11. Letter from Theodore R. Lazo, Managing Director and Associate
General Counsel, and Ellen Greene, Managing Director, Financial
Services Operations, Securities Industry and Financial Markets
Association, to Brent J. Fields, Secretary, Commission, dated July
18, 2016 (``SIFMA Letter'').
12. Letter from Anonymous, to Commission, received July 18, 2016
(``Anonymous Letter I'').
13. Letter from Mary Lou Von Kaenel, Managing Director, Financial
Information Forum, to Brent J. Fields, Secretary, Commission, dated
July 18, 2016 (``FIF Letter'').
14. Letter from Marc R. Bryant, Senior Vice President, Deputy
General Counsel, Fidelity Investments, to Brent J. Fields,
Secretary, Commission, dated July 18, 2016 (``Fidelity Letter'').
15. Letter from Mark Husler, CEO, UniVista, and Jonathan Jachym,
Head of North America Regulatory Strategy and Government Relations,
London Stock Exchange Group, to Brent J. Fields, Secretary,
Commission, dated July 18, 2016 (``UnaVista Letter'').
16. Letter from Gary Stone, Chief Strategy Officer for Trading
Solutions and Global Regulatory and Policy Group, Bloomberg, L.P.,
to Brent J. Fields, Secretary, Commission, dated July 18, 2016
(``Bloomberg Letter'').
17. Letter from Dennis M. Kelleher, President and CEO, Stephen W.
Hall, Legal Director and Securities Specialist, and Lev Bagramian,
Senior Securities Policy Advisor, Better Markets, to Brent J.
Fields, Secretary, Commission, dated July 18, 2016 (``Better Markets
Letter'').
18. Letter from Industry Members of the Development Advisory Group
(``DAG'') (including Financial Information Forum, Securities
Industry and Financial Markets Association and Securities Traders
Association), to Brent J. Fields, Secretary, Commission, dated July
20, 2016 (``DAG Letter'').
19. Letter from John A. McCarthy, General Counsel, KCG Holdings,
Inc., to Brent J. Fields, Secretary, Commission, dated July 20, 2016
(``KCG Letter'').
20. Letter from Joanne Moffic-Silver, EVP, General Counsel and
Corporate Secretary, Chicago Board Options Exchange, Inc., to Brent
J. Fields, Secretary, Commission, dated July 21, 2016 (``CBOE
Letter'').
21. Letter from Elizabeth K. King, General Counsel and Corporate
Secretary, NYSE Group, Inc., to Brent J. Fields, Secretary,
Commission, dated July 21, 2016 (``NYSE Letter'').
22. Letter from John Russell, Chairman of the Board, and James Toes,
Securities President and CEO, Securities Traders Association, to
Brent J. Fields, Secretary, Commission, dated July 25, 2016 (``STA
Letter'').
23. Letter from Anonymous, to Commission, received August 12, 2016
(``Anonymous Letter II'').
24. Letter from Scott Garrett, Barry Loudermilk, French Hill, Lynn
Westmoreland, Randy Hultgren, Jody Hice, Lamar Smith, Tom Emmer,
Bill Huizenga, Sean Duffy, Robert Pittenger, Robert Hurt, and Ann
Wagner, Members of Congress, to Mary Jo White, Chair, Commission,
dated October 14, 2016 (``Garrett Letter'').
25. Letter from Participants to Brent J. Fields, Secretary,
Commission, dated September 2, 2016 (``Response Letter I'').
26. Letter from Participant to Brent J. Fields, Secretary,
Commission, dated September 23, 2016 (``Response Letter II'').
27. Letter from Participants to Brent J. Fields, Secretary,
Commission, dated October 7, 2016 (``Response Letter III'').
28. Letter from Participants to Brent J. Fields, Secretary,
Commission, dated November 2, 2016 (``Participants' Letter I'').
29. Letter from Participants to Brent J. Fields, Secretary,
Commission, dated November 14, 2016 (``Participants' Letter II'').

[FR Doc. 2016-27919 Filed 11-22-16; 8:45 am]
BILLING CODE 8011-01-P


[Federal Register Volume 87, Number 201 (Wednesday, October 19, 2022)]
[Notices]
[Pages 63506-63507]
[FR Doc No: 2022-22712]

=======================================================================
-----------------------------------------------------------------------

DEPARTMENT OF HOMELAND SECURITY

Coast Guard

[Docket No. USCG2022-0349]

Certificate of Alternative Compliance for the Hayden Grace, O.N.
1326783

AGENCY: Coast Guard, DHS.

ACTION: Notification of issuance of a certificate of alternative
compliance.

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

SUMMARY: The Coast Guard announces that the Chief of Prevention, Eighth
Coast Guard District has issued a certificate of alternative compliance
from the International Regulations for Preventing Collisions at Sea,
1972 (72 COLREGS), for the HAYDEN GRACE, O.N. 1326783. We are issuing
this notice because its publication is required by statute. Due to the
construction and placement of mast lights, stern light, and sidelights,
HAYDEN GRACE cannot fully comply with the light, shape, or sound signal
provisions of the 72 COLREGS without interfering with the vessel's
design and construction. This notification of issuance of a certificate
of alternative compliance promotes the Coast Guard's marine safety
mission.

DATES: The Certificate of Alternative Compliance was issued on October
4, 2022.

FOR FURTHER INFORMATION CONTACT: For information or questions about
this notice call or email Lieutenant Commander Jessica Flennoy,
District Eight, Prevention Division, U.S. Coast Guard, telephone 504-
671-2156, email [email protected].

SUPPLEMENTARY INFORMATION: The United States is signatory to the
International Maritime Organization's International Regulations for
Preventing Collisions at Sea, 1972 (72 COLREGS), as amended. The
special construction or purpose of some vessels makes them unable to
comply with the light, shape, or sound signal provisions of the 72
COLREGS. Under statutory law, however, specified 72 COLREGS provisions
are not applicable to a vessel of special construction or purpose if
the Coast Guard determines that the vessel cannot comply fully with
those requirements without interfering with the special function of the
vessel.\1\
---------------------------------------------------------------------------

    \1\ 33 U.S.C. 1605.
---------------------------------------------------------------------------

    The owner, builder, operator, or agent of a special construction or
purpose vessel may apply to the Coast Guard District Office in which
the vessel is being built or operated for a determination that
compliance with alternative requirements is justified,\2\ and the Chief
of the Prevention Division would then issue the applicant a certificate
of alternative compliance (COAC) if he or she determines that the
vessel cannot comply fully with 72 COLREGS light, shape, and sound
signal provisions without interference with the vessel's special
function.\3\ If the Coast Guard issues a COAC, it must publish notice
of this action in the Federal Register.\4\
---------------------------------------------------------------------------

    \2\ 33 CFR 81.5.
    \3\ 33 CFR 81.9.
    \4\ 33 U.S.C. 1605(c) and 33 CFR 81.18.
---------------------------------------------------------------------------

    The Chief of Prevention Division, Eighth District, U.S. Coast
Guard, certifies that the HAYDEN GRACE, O.N. 1326783 is a vessel of
special construction or purpose, and that, with respect to the position
of the mast lights, stern light, and sidelights, it is not possible to
comply fully with the requirements of the provisions enumerated in the
72 COLREGS, without interfering with the normal operation,
construction, or design of the vessel. The Chief of Prevention
Division, Eighth District, U.S. Coast Guard, further finds and
certifies that the mast lights, stern light, and sidelights are in the
closest possible compliance with the applicable provisions of the 72
COLREGS.\5\
---------------------------------------------------------------------------

    \5\ 33 U.S.C. 1605(a); 33 CFR 81.9.
---------------------------------------------------------------------------

    This notice is issued under authority of 33 U.S.C. 1605(c) and 33
CFR 81.18.

     Dated: October 13, 2022.
A.H. Moore, Jr.,
Captain, U.S. Coast Guard, Chief, Prevention Division, Eighth Coast
Guard District.
[FR Doc. 2022-22712 Filed 10-18-22; 8:45 am]
BILLING CODE 9110-04-P


[Federal Register Volume 76, Number 106 (Thursday, June 2, 2011)]
[Notices]
[Pages 31954-31955]
[FR Doc No: 2011-13681]

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

DEPARTMENT OF ENERGY

Federal Energy Regulatory Commission

[Docket No. DI11-7-000]

San Jose Water Company; Notice of Declaration of Intention and
Soliciting Comments, Protests, and/or Motions To Intervene

    Take notice that the following application has been filed with the
Commission and is available for public inspection:
    a. Application Type: Declaration of Intention.
    b. Docket No: DI11-7-000.
    c. Date Filed: May 16, 2011.
    d. Applicant: San Jose Water Company.
    e. Name of Project: Micro-Hydro-Turbine-Generator Project.
    f. Location: The Micro-Hydro-Turbine-Generator Project will be
located on a water delivery system pipe, replacing Pressure Reducing
Valves, in the town of San Jose, Santa Clara County, California.
    g. Filed Pursuant to: Section 23(b)(1) of the Federal Power Act, 16
U.S.C. 817(b).
    h. Applicant Contact: Thomas J. Victorine, Director of Operations,
San Jose Water Company, 110 W. Santa Clara Street, San Jose, CA 95196-
0001; Telephone:<PHONE_NUMBER>; FAX:<PHONE_NUMBER>; e-mail<EMAIL_ADDRESS>    i. FERC Contact: Any questions on this notice should be addressed
to Henry Ecton,<PHONE_NUMBER>, or E-mail address:
<EMAIL_ADDRESS>

    j. Deadline for filing comments, protests, and motions: June 30,
2011.
    All documents should be filed electronically via the Internet. See
18 CFR 385.2001(a)(1)(iii) and the instructions on the Commission's Web
site at http://www.ferc.gov/docs-filing/efiling.asp. If unable to be
filed electronically, documents may be paper-filed. To paper-file, an
original and seven copies should be filed with: Secretary, Federal
Energy Regulatory Commission, 888 First Street, NE., Washington, DC
20426.
    Commenters can submit brief comments up to 6,000 characters,
without prior registration, using the eComment system at http://www.ferc.gov/docs-filing/ecomment.asp. Please include the docket number
(DI11-7-000) on any comments, protests, and/or motions filed.
    k. Description of Project: The Micro-Hydro-Turbine-Generator
Project would consist of a municipal water delivery system in which two
Pressure Reducing Valves (PRV), used to control pressure in pipes,
would be retrofitted with hydro turbines, to generate 150-kW. The 16-
inch pipe, into which the PRVs are placed, carries water from the
city's water treatment plant and is part of the San Jose public
drinking water system. The water supplied to the water treatment plant
comes from three existing storage reservoirs. A transmission line will
connect the project to an interstate grid.
    When a Declaration of Intention is filed with the Federal Energy
Regulatory Commission, the Federal Power Act requires the Commission to
investigate and determine if the interests of interstate or foreign
commerce would be affected by the proposed project. The Commission also
determines whether or not the project: (1) Would be located on a
navigable waterway; (2) would occupy or affect public lands or
reservations of the United States; (3) would utilize surplus water or
water power from a government dam; or (4) if applicable, has involved
or would involve any construction subsequent to 1935 that may have
increased or would increase the project's head or generating capacity,
or have otherwise significantly modified the project's pre-1935 design
or operation.
    l. Locations of the Application: Copies of this filing are on file
with the Commission and are available for public inspection. This
filing may be viewed on the Web at http://www.ferc.gov using the
``eLibrary'' link. Enter the docket number excluding the last three
digits in the docket number field to access the document. You may also
register online at http://www.ferc.gov/docs-filing/esubscription.asp to
be notified via e-mail of new filings and issuances related to this or
other pending projects. For assistance, please contact FERC Online
Support at<EMAIL_ADDRESS>or toll-free at<PHONE_NUMBER>,
or TTY, contact<PHONE_NUMBER>. A copy is also available for inspection
and reproduction at the address in item (h) above.
    m. Individuals desiring to be included on the Commission's mailing
list should so indicate by writing to the Secretary of the Commission.
    n. Comments, Protests, and/or Motions to Intervene: Anyone may
submit comments, a protest, and a motion to intervene in accordance
with the requirements of Rules of Practice and Procedure, 18 CFR
385.210, .211, .214. In determining the appropriate action to take, the
Commission will consider all protests or other comments filed, but only
those who file a motion to intervene in accordance with the
Commission's Rules may become a party to the proceeding. Any comments,
protests, and/or motions to intervene must be received on or before the
specified comment date for the particular application.
    o. Filing and Service of Responsive Documents: Any filings must
bear in all capital letters the title ``COMMENTS'', ``PROTESTS'', AND/
OR ``MOTIONS TO INTERVENE'', as applicable, and the Docket Number of
the particular application to which the filing refers. A copy of any
motion to intervene must also be served upon each representative of the
Applicant specified in the particular application.
    p. Agency Comments: Federal, state, and local agencies are invited
to file comments on the described application. A copy of the
application may be obtained by agencies directly from the Applicant. If
an agency does not file comments within the time specified for filing
comments, it will be presumed to have no comments. One copy of an
agency's comments must also be sent to the Applicant's representatives.

    Dated: May 26, 2011.
Kimberly D. Bose,
Secretary.
[FR Doc. 2011-13681 Filed 6-1-11; 8:45 am]
BILLING CODE 6717-01-P