ATTACHMENT 3 - OEC E-Feeds DRAFT Statement of Objectives (SOO).pdf

DRAFT STATEMENT OF OBJECTIVES (SOO)

for the

OEC E-Feeds Program as of 01/18/2024

1. Background

The mission of the U.S. Securities and Exchange Commission (SEC) is to protect investors, maintain fair, orderly, and efficient markets, and facilitate capital formation.

The Office of the Ethics Counsel (OEC) is responsible for advising and counseling all Commission members and employees on such issues as personal and financial conflicts of interest, post-employment restrictions, securities holdings and transactions of Commission employees and their immediate families, gifts, seeking and negotiating other employment, outside activities, and financial disclosure. The Ethics staff also drafts, comments on, and implements regulations concerning ethical conduct issues.

The Ethics Office assists Presidential appointees with various aspects of financial disclosure to the Senate and the U.S. Office of Government Ethics in connection with the confirmation process.

This acquisition is to partner with an organization that can provide a software as a service (SaaS) solution that can support OEC’s compliance activities related to pre-trade requests, authorizations, confirmations, flagging trading violations, and matching real-time broker data to employee pre-trade authorization requests and confirmations, and certification of holdings.

2. Purpose

The objective of this contract is to enhance OEC’s ethics compliance efforts by automating two manual processes (submission of compliance data by employees and the compliance testing review performed by OEC staff) by implementing a compliance monitoring system that will deliver direct data feeds (E-Feeds) from financial institutions with securities accounts, holdings, and transactions attributable to SEC employees. The E-Feeds from the brokerages and other providers would provide real time, accurate data on holdings and transactions in a manner that is readily understandable, complete, and assists in testing employee compliance. The E-Feeds would interface with/replace the SEC’s current Personal Trading Compliance System (PTCS) in a manner that

ATTACHMENT 3 - DRAFT SOO

quickly and accurately identifies and flags potential violations. SEC is seeking a contractor with agile software development practices, experience with SaaS implementation, modern web application frameworks, experience with migrating legacy applications and databases to modern infrastructure, and user experience/visual design capabilities.

The SEC intends for this project to be completed by working in short iterations of several weeks, each of which will typically result in the delivery of functioning software that can be tested with internal and external users. The SEC is not looking to develop a custom application, but rather configure the SaaS software with minimum customizations to meet the functional and non-functional requirements provided to the vendor.

The success of these products will be based on ease of use, end user acceptance and adoption, the implementation of industry best practices, and rapid time to users for all configuration efforts. In contract to accomplish this, these services shall be provided via agile software development processes that achieve results through continuous capability enhancement, prompt response to emerging needs, demonstrated reliability, and optimized performance with resource utilization minimized.

Iterations should progressively develop non-proprietary, modern, well-designed web applications that will gradually replace SEC’s legacy applications, allowing SEC to decommission its existing systems as features and capabilities are replaced by this new application.

3. Scope

The vision of this project is to enhance SEC ethics compliance by automating the current manual processes to provide real time, accurate data on holdings and transactions in a manner that is readily understandable and complete.

These are the target groups for this project:

• All SEC Employees (approximately 4,500)

• Employee’s spouse

• Employee’s unemancipated minor child

• Individuals for whom an employee serves as legal guardian

• Trusts for which employee, spouse or unemancipated minor child serves as trustee

• Office of Ethics Counsel staff

The SEC needs to solve the following problems:

• Secure and timely access to the system

• Allow SEC employees to submit pre-trade authorization requests and transaction confirmations directly within the system

• Automatically generate pre-trade clearance determinations based on lists of prohibited and restricted holdings and/or transactions or send to manual review by OEC staff

• Ability to ingest a daily or more frequent confidential watch list

• Ability to manually adjudicate pre-trade requests that involve close and exact matches to the watch list

• Ability to receive manually uploaded statements and automatically transform data to database records for the annual Certification of Holdings (CoH)

• Ability to receive electronic data feeds from brokerage firms containing holdings and transactions

• Automatically monitor and flag individual employee trades for violations of rules in real time

• Allow OEC staff to add/delete and update rules that would result in flagged violations

• Provide visibility of Historical CoH information by employee

• Ability to view past years’ certified information

• Ability to access real time data reports

• The outcome for this project is as follows:

• SaaS (Software as a Service) solution maintained by third party

• Direct data feeds of financial statements from brokerage firms and other providers

• Built-in security that is FedRAMP authorized

• Customizable dashboards and reports

• Provide an integrated solution for employee pre-trade clearance, Certification of

Holdings and compliance review by OEC staff

• Ability to consume data from an external system

• Allow manual upload and direct data feeds of employee brokerage statements to enhance data visibility

• Automate monitoring and flagging of employee’s trades for violations of rules to improve compliance review completeness and accuracy

As is customary in agile development, priorities (as they relate to the modernization of OEC E-Feeds) may shift over time based on the natural evolution of the Government’s and contractor’s understanding of the problem space through continued discovery, user research, stakeholder engagement, and validated learning. These shifting priorities will be accounted for through collaboration between the Government (Product Owner, agency stakeholders, etc.) and the contractor to establish a shared understanding of the work, which will be planned for and communicated through standard agile practices such as product road mapping, backlog prioritization and sprint planning. For example, the SEC may decide during performance that additional functionalities for OEC E-Feeds may need to be added to the roadmap/backlog due to newly emerging real-time circumstances, at which time the Government would work with the contractor to plan for and prioritize that work. This process will be managed by the OEC E-Feeds product owner and achieved through a regularly updated product roadmap/backlog process in conjunction with the contractor team. The SEC is not looking to develop a custom application, but rather configure the SaaS software with minimum customizations to meet the functional and non-functional requirements provided to the vendor.

4. Anticipated Period and Place of Performance

The anticipated investment for this task order is a 12-month base period and four (4) 12-month option periods. The work will be done at the contractor’s location.

5. Performance Objectives

Discovery and Design

Working in conjunction with the federal Product Owner and the OEC agency team, the contractor will utilize modern human-centered design (HCD) principles to conduct user research and discovery around the needs of SEC system users, stakeholders, and other relevant user groups to define how OEC E-Feeds system should meet existing OEC use cases, as well as emerging user challenges. The contractor will utilize HCD techniques to design approaches to meeting these needs in the most impactful manner possible.

Tasks:

• Review any user research conducted prior to the beginning of this contract

• Conduct research into relevant organizations, processes, systems and policies to understand their needs and goals

• Work hand-in-hand with the federal Product Owner to iteratively develop and update (as relevant) the product vision, product roadmap(s), and product backlog(s) with associated user stories based on what is learned through user research and discovery

• Iteratively design solutions toward the end user experience so that products meet end user needs and goals

• When relevant, analyze opportunities for users to better leverage existing systems

• Initiate measurable feedback loops and establish metrics to measure effectiveness of products delivered

• Ensure new features are expandable and extensible to meet the ongoing needs of the relevant user groups and stakeholders

• Utilize modern methodologies when doing discovery/user research, including stakeholder interviews and usability tests

• Prototype and test design concepts with end users

• Incorporate UI/UX principles throughout the development process

• Create and track metrics to determine whether delivered solutions meets end user needs

• Formulate testable product hypotheses, measure outcomes, and share learnings

• Account for accessibility considerations and ensure that Section 508 requirements are considered, designed for, and met

• Work with the Product Owner in a continuous, iterative fashion throughout the development process to establish and prioritize features based on discovery/user research findings

• Build data analytics capability which allows SEC to easily measure business metrics related to its digital services across contracting and non-contracting programs, and instrument SEC’s digital services to ensure they capture the metrics required to access each product’s success.

• Execute a data migration from old databases into the new infrastructure. This migration must ensure data integrity and a seamless transition from the old systems to the new system.

• Maintain a tracking tool and metrics to monitor progress against the Agile Development Management Plan (ADMP).

• Cultivate a positive, trusting, and cooperative working relationship with the Government and other vendors that support SEC.

• Leverage technology capabilities to meet customer needs with timely and seamless access to the cloud-based infrastructure, business applications, and data. This includes staying abreast of new feature offerings and new and innovative ways to provide technology value to SEC customers, including, but not limited to, open sourcing the applications, or the development of APIs.

• Maintain a dialogue between the service provider and all project stakeholders, rather than trying to comprehensively specify requirements up-front. This focus will be assisted by working through short, tightly scoped product iterations in which working software is delivered to users regularly, and adjustments are made based on feedback gleaned from these iterations.

• Lead and collaborate with the COR, workgroups, and stakeholders in requirements sessions in contract to develop recommendations and approaches, to be approved by the Government to satisfy the objectives and purposes of this contract. Results of these sessions will generate the Product Road Map, Epics, and User Stories, business logic and rules, functionality, and system documentation.

• The Initial Product Backlog (See Appendix A) provides a detailed breakdown of the desired functionality as identified at this time. The initial product backlog is not a binding document, but rather a representative sample of the functionality that is anticipated will be required to be delivered under this contract. The specific user stories will be identified through the agile development process as proposed in the Performance Work Statement (PWS). The Initial Product Backlog provides some guidance on specific objectives that should be included in each project.

• The PWS should provide a detailed process for working with the Product Owner and End Users to capture, prioritize, and work-off the Product Backlog. The prioritization effort may include working backlog items across multiple projects concurrently based on the teams’ capacity and end user priorities.

6. Deliverables

The contractor is required to provide the following deliverables:

Deliverables under this contract are defined as the completion and acceptance according to the “Definition of Done” of the iterations completed, which are based on the contractor’s Agile Software Development methodology. This methodology defines the repeatable process of providing development and deployment services in small iterations lasting two to five weeks which results in the delivery of design, usable software, data, or product, which have little to no inherent defects. The Performance

Work Statement should document how planning, requirement analysis (user story building), design, coding, testing, quality assurance, and documentation will all meet the contractor’s “Definition of Done”.

Each deliverable shall incorporate SEC IT requirements as detailed in the Appendix of this document and the United States Digital Service Playbook standards (https://playbook.cio.gov) and be compliant with Section 508.

Deliverables

● Agile Development Plan

● Design Deliverables

● Metrics Dashboard

● Reports

Functional Requirements, translated into Epics and User Stories that will be used to populate the Product Backlog may include, but are not limited to:

● Initial application design and implementation

● System configuration to support business processes

● Integration for input and output methods

● Workflow design and implementation

● Overall collaboration of applications

● Enhancements, patches, and updates to applications, data, or cloud systems

● Data import of records collected from legacy systems

● Automated testing

● Training of end users on the systems https://playbook.cio.gov/

Deliverables table with Quality Assurance Surveillance Plan (QASP)

Deliverable Performance Standard(s)

FINAL Acceptable Quality Level

(AQL)

SEC Proposed

AQL Progression

Method of Assessment

Quality Assurance

A comprehensive testing plan must be created, integration and regression testing performed on the stated cadence.

100% feature coverage for manual testing, integration, and regression testing every release, and, if applicable, testing plan is refactored to incorporate previous features.

I. All new features have an accompanying test plan element. Code is not released until full test plan passes.

II. Relevant newly fixed issues have associated tests added and become part of the test suite.

III. Regression testing of the comprehensive test plan is performed every Sprint

IV. 100% feature coverage for manual testing, regression testing every Sprint, and, if applicable, testing plan is refactored to incorporate previous features.

Manual review of QA testing results.

Accessibilit y

Web Content Accessibility Guidelines 2.1 AA standards

0 errors reported in testing for custom-created interfaces;

all platform-related errors reported to the platform vendor.

I. All platform-related errors must be reported to vendor to address, monitored for progress, and accessibility issues are being managed in the backlog

II. Accessibility is included in the definition of done for a sprint (i.e., is completed for every sprint for all relevant work)

III. Accessibility is included in the definition of done at the user story level as applicable

IV. 0 errors reported in testing for custom-created interfaces

JAWS

Deployed Testing environment is isolated from development and production environments

Testing is performed in a separate environment and all issues are resolved before any production release.

I. Testing environment is isolated from development and production.

II. Testing is performed in a separate environment and all issues are resolved before any production release

Manual review of architecture and adherence to test plan & release cycle.

Documente d

All dependencies are listed, and the licenses are documented. Major functionality in the software/ source code is documented. A system diagram is provided. Individual methods are documented inline, and, if possible, using comments that permit the use of documentation-generation tools such as JSDoc. If possible, documented inline that permit the use of documentation-generation tool

Combination of manual review and automated testing, where applicable

I. Application and governance artifacts are provided and maintained for each release

II. Application and governance artifacts are maintained within each Sprint as applicable.

III. Application and governance artifacts are maintained within each User Story as applicable.

IV. Application and governance artifacts are maintained and auto generated where applicable.

Combination of manual review and automated testing, if available

User research

Usability testing and other user research methods must be conducted at regular intervals throughout the development process (not just at the beginning or end)

Artifacts from usability testing and/or other research methods with end users are available at the end of every applicable sprint, in accordance with the vendor’s research plan

I. Customers attend Sprint Demos, provide feedback, feedback is tracked, prioritize, and associated actions followed through

II. Customers are “touching,” using, trying the new functionality within the sprint it was delivered

Manual review

III. Customers and Delivery Teams are interacting continuously and Product adjustments/ enhancements are made within sprints/user stories.

IV. Artifacts from usability testing and/or other research methods with end users are available at the end of every applicable sprint, in accordance with the vendor’s research plan

Team Performanc e and Metrics

At a minimum, the following metrics must be monitored and visualized in a dashboard:

(1) Velocity chart,

(2) sprint burn-down/product burn-up chart,

(3) code coverage, and

(4) backlog traceability to product roadmap

Data available in real-time

I. Updated after every sprint

II. Real-time availability

Manual review of dashboard and Agile Lifecycle Management Tool

7. Operating Constraints

Ensure products are compliant with federal Section 508 requirements, FedRAMP authorization and SEC IT security requirements, as described in the Appendix B. For Section 508 compliance, the Contractor shall indicate for each line item in the schedule whether each product or service is compliant or noncompliant with the accessibility standards at 36 CFR § 1194. Further, the proposal must indicate where full details of compliance can be found (e.g., vendor’s website or other exact location Adherence to US Web Design Standards).

8. Stakeholders

Stakeholders for this project include, but are not limited to the following groups and individuals:

• Office of Information Technology – Solutions Delivery o Rupert Manley, Associate Director o Ning Tang, Assistant Director o Jonathan Karp, Branch Chief o Gary Yellin, Project Manager

• Office of Information Technology – OIT Security o Matthew Toscano, Assistant Director o Allante Allen, Branch Chief o Security Lead???

• Office of the Ethics Counsel o Danae Serrano, Director o Jay Bragga, Chief Compliance Officer and Business Owner o Frank Hemphill, Product Owner o John Pickett, Data Steward

• Office of Acquisitions o Victor Cairo, Contracting Officer o Connie Ginn, Contracting Officer & Specialist o Gary Yellin, Contracting Officer Representative

• Office of Human Resources o Hugh Flick

• Division of Enforcement o Mark Velsco

• Office of the General Counsel o Jeff Walker

9. Agile Development Management Plan (ADMP) and Vendor Personnel

Offerors shall propose an Agile Development Management Plan (ADMP) which demonstrates how the Offeror intends to manage, develop, implement, and maintain the requirements described in this SOO and the functional requirements document. The plan shall include, at a minimum:

● Contact information for all senior leaders and an organizational chart showing the Offeror’s organizational hierarchy and reporting structure, with specific designation of individuals as Vendor Personnel;

● Management resources;

● Technical resources and skill sets required to configure, implement, and maintain the proposed solution; and

● Details on the management of the Offeror’s team

The ADMP shall become part of the contract upon award.

The contractor must designate a Project Manager, Scrum Master and a Technical Lead for this project. The Project Manager/Scrum Master will be the direct liaison to the SEC’s Contracting Officer. The Project Manager/Scrum Master must be a senior staff member and will be responsible for the supervision and management of all of the Offeror’s personnel, technical assistance, and interface and compliance with instructions from the SEC’s COR(s). The Technical Lead must have a full understanding of the technical approach to be used by the Offeror’s delivery team and will be responsible for ensuring the Offeror’s delivery team follows that approach.

• Desired skills/experience for the Scrum Master include:

a. Experience in technical leadership.

b. Ability to rapidly prioritize competing requirements.

c. Ability to understand and simplify customer requirements.

d. Ability to communicate end user feedback to technical and design leads.

e. Product Delivery certification or equivalent work experience and proven knowledge of managing Agile Software Development efforts.

f. Strong communication and facilitation skills.

g. Proven knowledge of industry standards.

• Desired skills/experience for the Information System Security expert:

o Experienced in security architecture for web applications and infrastructure and shall have experience and working knowledge of Security Assessment and Authorization (SA&A) activities in accordance with standards from the National Institute of Standards and Technology

(NIST).

o Document and maintain knowledge of all relevant NIST 800-53 controls for each IT system o Maintain the following certifications:

Information Systems Security Professional (CISSP) Certified Information Security Manager (CISM) Information System Auditor (CISA)

• Desired skills/experience for the Technical Lead include:

o Experience with architecting and implementing secure cloud solutions for modern applications/systems.

o Working knowledge with the latest Amazon Web Service (AWS), Microsoft

Azure, and other cloud platforms including Software-as-a-Service (SaaS) to design, engineer and integrate software applications.

o Experience with data classification, transformation, integration, and security.

o Ability to provide technical guidance and support to the implementation team during the project as well as addressing operational issues.

10. Service Level Agreement (SLA)

• Availability o The system is 99% available and accessible.

• Incident Response and Resolution Time o P1 – Outage

In the event of a full system outage, the application shall be back online and accessible with 4 hours.

In the event of an outage, the vendor shall provide a root cause analysis (RCA) with an explanation for the outage and the steps being taken to mitigate the issue in the future.

o P2 – Partial Outage In the event of a partial system outage, the application shall be back online and usable within 8 hours.

In the event of a partial outage, the vendor shall provide a root cause analysis (RCA) with an explanation for the outage and the steps being taken to mitigate the issue in the future.

o P3 – Service Request

All service requests shall be responded to within 12 hours.

o P4 – General Inquiry

All general inquiries shall be responded to within 24 hours.

11. Kick-Off Meeting/Post-Award Conference

The Contracting Officer, Contract Specialist and Contracting Officer’s Representative shall hold a Kick-Off meeting/Post-Award Conference with the Contractor’s team and other relevant Government staff to review and clarify the project’s objectives, expectations from the Government, and to address any questions the Contractor may have.

The Contractor shall provide and collaborate with the Contracting Officer or the Contracting Officer’s Representative on an agenda for this meeting. Discussion topics shall include, but not be limited to: introduction of the Contractor and Government Staff;

understanding of the specific tasks and subtasks; project management expectations;

agreement on meeting schedules; and agreement on initial delivery dates.

The Kick-Off meeting/Post-Award Conference will take place within 10 days from award and will be scheduled by the Contracting Officer.

Appendix A

OEC E-Feeds Product Backlog

Req. # User Story-Requirement Description

RQ-001 Accessibility and Administration: As a logged-out User, I want to be able to access the Certification of Holdings system so that I can access my profile page and take actions in the system based on my permission level.

RQ-002 Accessibility and Administration: As an OEC Admin or Sys Admin user, I want the ability to add/remove a user’s ability to access the Certification of Holdings “Upload Statement” screen so that CoH uploads can only occur during the attestation period as defined by the OEC Admin (manual direct uploads only).

RQ-003 Accessibility and Administration: As an OEC Admin or Sys Admin user, I want to have the ability to define and/or update the start and end date of the Attestation period within the system by employee.

RQ-004 Accessibility and Administration: As an OEC Admin or Sys Admin user, I want to have the ability to give specific Users access to upload files to a new attestation period.

RQ-005 Data Visibility: As a User, I want to have Read-only access to my CoH Historical data throughout the year, so I can view what has been submitted for certification.

RQ-006 Data Visibility: As the Sys admin, I need the ability to purge data in accordance with the standard federal records management timeline of 6 years and have the ability to extend/stop that purge indefinitely, both system wide or for individual employees so that requests to hold data for investigation can be fulfilled.

RQ-007 Manual/direct upload of brokerage statements: As the User, I want to have the ability to directly upload, submit statements, certify and view holdings.

RQ-008 Manual /direct upload of brokerage statements: As the User, I want to have the ability to update or delete uploaded CoH Statements.

RQ-009 Manual /direct upload of brokerage statements: As a User, I want to have the ability to Declare no holdings within the system, so I can show that I have not had any holdings or transactional activity subject to the Certification of Holdings requirement

RQ-010 As a User, I want to have the ability to certify compliance with the SEC's Supplemental Ethics Rules on an annual or more frequent basis.

RQ-011 Electronic data feed of brokerage information: As a User, I want the vendor/system to manage and provide me with an automated brokerage data electronic feed authorization process.

RQ-0112 Electronic data feed of brokerage information: As an OEC Admin user, I want the vendor/system to provide me with a notification when employees change relevant personal information or financial institution.

RQ-013 Electronic data feed of brokerage information: As a User, I want the vendor/system to manage and host the automated financial data feed which will be sent directly from the employees' carrying financial institution to the vendor solution.

RQ-014 Electronic data feed of brokerage information: As an OEC Admin user, I want the vendor/system to provide a process for automatic notification and action to be taken on failed electronic brokerage data feeds.

RQ-015 Electronic data feed of brokerage information: As a User, I want to certify that I have signed up for an electronic brokerage feed within the system on a schedule determined by DAEO (Designated Agency Ethics Official).

RQ-016 Electronic data feed of brokerage information: As a User, I want a system that stores and compiles my electronic brokerage feed data, then securely submits the data security into the SEC network. (Data feed only service requirement)

RQ-017 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct real-time automated violation checks on the CoH data.

RQ-018 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct a violation check 1: Non-Compliance with the regulation-Missing information

RQ-019 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct a violation check 2: Prohibited and/or restricted financial interests and/or transactions

RQ-020 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct a violation check 3: Reported CoH transactions have not been precleared

RQ-021 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct a violation check 4: Purchasing a security in an IPO or direct listing for 7 days after the effective date.

RQ-022 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct a violation check 5: Purchasing or carrying securities on margin.

RQ-023 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct a violation check 6: Employee is selling securities short

RQ-024 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct a violation check 7: Employees has transactions involving securities derivatives (e.g., options or futures

RQ-025 Automated Violation/Trading Rules Monitoring: As a User, I want the ability to attest to the fact I am not engaging in transactions using material nonpublic information (MNPI).

This will be done by checking a checkbox.

RQ-026 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct a violation check 9: Minimum holding period not met.

RQ-027 Automated Violation/Trading Rules Monitoring: As an OEC Admin, I want the system to conduct a violation check 10: Trades in securities of issuers that are on the Watch List

RQ-028 Dashboard Functionality: As an OEC Admin, I want the system to provide me with the ability to view Dashboards to help visualize the data in the system.

RQ-029 Dashboard Functionality: As an OEC Admin, I want the system to provide me with the ability to view a Dashboard that shows System issues: any E-feed failures and any changes to an employees’ e-feed.

RQ-030 Dashboard Functionality: As an OEC Admin, I want the system to provide me with the ability to view a Dashboard that shows any violations that have occurred.

RQ-031 Dashboard Functionality: As an OEC Admin and/or Sys Admin users, I want the system to provide me with the ability to view and export data reports from within the system.

RQ-032 Technical Support: As an OEC Admin or System Admin user, I want data integration capability where I can export data via a tool and import it into another SEC system.

RQ-033 Technical Support: As a System user, I want the vendor to provide Technical and implementation setup support and training to the SEC and its employees.

RQ-034 Technical Support: As a System user, I want the vendor as a cloud service provider to have achieved FedRAMP compliance.

RQ-035 Pre-Trade Request: The software shall allow the user to perform the following transactions: Buy/Purchase, Sell/Redeem, Periodic Investment Plans, and Confirm of buy and sell transactions

RQ-036 Pre-Trade Request: The software shall have a list of securities that is updated daily. The list of securities shall include the following: Equities, Bonds, Mutual Funds, ETFs, UITs, money market funds, BDCs, 529 plan portfolios, REITs, insurance and annuity products containing securities, crypto assets, hedge funds, private funds, etc.

RQ-037 Pre-Trade Request: The software shall allow the Agency to have a restricted list of securities and an electronic real-time pre-clearance function with immediate notification to authorized users of possible violations.

a. The restricted list shall be protected from editing or updating by anyone other than authorized users at the Agency. The software shall allow for manual overrides at the Agency’s discretion.

RQ-038 Pre-Trade Request: The software shall allow the Agency to have a watch list of securities that requires manual review by Agency staff.

a. The watch list shall be protected from editing or updated by anyone other than authorized users at the Agency.

RQ-039 Pre-Trade Request: The software shall allow customizable trading rules.

a. No IPOs within 7-days of issuance

b. Hold Equities for 30-days

c. Hold Mutual Funds for 6-months

d. Allow for sell transactions if a 10% loss has occurred within the holding periods

e. The software shall allow for manual overrides at the Agency’s discretion.

RQ-040 Pre-Trade Request: The software shall have the capability to send email reminders to users for workflow items that need to be completed.

RQ-041 Pre-Trade Request: The system shall allow for the ability to manually review specific employees PTRs.

Appendix B

Security and Non-Functional Requirements

RQ-042 As a User, I want a system that is intuitive and easy to navigate.

RQ-043 As a user, I want a system that is accessible to all users including those with disabilities (Accessibility)

RQ-044 As a user, I want the system to prevent errors from being input through validation checks

RQ-045 As a user, I want a system that is availability 24/7 with built in redundancy, so I can conduct business when needed

RQ-046 As a user, I want a system that ensures the integrity of all data entered into the system, so that reliability do information is sound

RQ-047 As a system admin, I want a system that handles errors gracefully and provided details on those errors, so I can be aware of the issues occurring in the system

RQ-048 As a user, I need my system to be capable of handling large amounts of data without reduction in performance

RQ-049 As a system user, I want my system to maintain the proper Configuration control procedures as proposed by NIST SP 800-53 MA control requirements per Federal Information Processing Standard (FIPS) Publication 199, “Standards for Security Categorization of Federal Information and Information Systems” in order to ensure accountability and traceability

RQ-050 As a user, I want my system support to document and test all changes prior to implementation, so that the vendor can ensure the system is easy to maintain, update and enhance as needed.

RQ-051 As a user, I want the system to allow for the modularity and upgradability, so that the SEC has the ability to add additional features and functionalities

RQ-052 As a user, I want the system to have the ability to add additional employees and/or financial institution’s broker feed as requested by the SEC

RQ-053 As a user, I want the system to utilize the SEC’s Active Directory (AD) information via Active Directory Federation Services (ADFS) in order to authenticate users in their system, so that security and access management challenges can be avoided

RQ-054 As a user, I want the system to provide the audit logs to the SEC on a daily basis, so that the SEC’s Security team can ensure security for their employees.

RQ-055 As a user, I want the system to be Federal Risk and Authorization Management Program (FedRAMP) compliant, so that my data can be secure

RQ-056 As a user, I want my system to secure my data both in transit and at rest, so my data remains secure at all times

RQ-057 As a user, I want the system to use a single tenant architecture, so that the SEC can ensure control, reliability, security, and backup capability of their data.

RQ-058 As a user, I want the system to use the NIST Zero Trust Architecture (ZTA), NIST SP 800-207 framework, so that the SEC can ensure all threats are managed.