As technology increasingly becomes the backbone of business, it is also becoming the single most expensive asset within any organization—bringing the topic straight to the boardroom. What most of us may not appreciate is that the custom software being built for enterprises has surpassed a threshold of complexity that would allow for any one person to understand an entire mission-critical system. And, unlike any other part of our critical infrastructure, there is no single manager who is responsible and accountable for the integrity of a company’s software backbone.
Having witnessed the increasing pace of notable outages in all industry sectors, including financial exchanges, the Securities and Exchange Commission (SEC) has proposed Regulation SCI (Systems Compliance and Integrity). This regulation applies to certain self-regulatory organizations (SRO), including registered clearing agencies, alternative trading systems (ATS), plan processors, and exempt clearing agencies subject to the Commission’s Automation Review Policy (ARP), which is voluntary in nature.
Overview of Regulation SCI
Regulation SCI is intended to enhance the Commission’s regulatory oversight to further ensure the capacity, integrity, resiliency, availability, and security of SCI entities, and enhance compliance with federal securities laws through the use of formalized standards and a well-defined regulatory framework.
One of the objectives of this proposed rule is to create the opportunity for more efficient and effective market operations with new data processing and communications techniques. The regulation also acknowledges that it is in the public interest and appropriate for the protection of investors and the maintenance of fair and orderly markets to assure the reliability and economically efficient execution of securities transactions.
Regulation SCI extends the existing ARP program and encodes it for compliance purposes. The main points the regulation addresses are:
- Adherence to best practices and standards in QA, BC, and governance
- Adherence to high levels of testing across the lifecycle
- Coordination of testing among market participants
- Improved backup and recovery, and specific SLAs for time to recovery
- Increased pre-trade and post-trade risk controls
- Real-time monitoring of systems
- Improved communication and reporting when system problems occur
A complete copy of the proposed rule can be found on the SEC website. Unfortunately, there is not any direct mention of managing the integrity and structural risk of the software itself. CAST has taken the opportunity offered by the SEC to provide feedback on the proposed regulation and brought this issue to the attention of the SEC personnel working on this rulemaking, and submitted formal comments.
A summary of CAST recommendations
At CAST, we see Regulation SCI as a welcome sign of industry effort to address fundamental problems in custom business software. While incremental to prior voluntary measures such as ARP, it is a laudable step in pulling the industry in the right direction and we are pleased to see the SEC take proactive steps in the area of system integrity.
A summary of our recommendations to the SEC follows:
- Leverage standard definitions of quality – Include language that leverages the work developed by CISQ, specifically the standard on the Characteristics of Good Software.
- “Identify system vulnerabilities and weaknesses that pertain to internal and external threats, structural integrity, physical hazards, system reliability, and natural or manmade disasters.”
- Build in reliability – The proposed language only addresses production issues. To be effective, the rule should include language and guidance that is relevant for development, such as the CISQ standards that specify requirements to control the stability, efficiency, security, and maintainability of business software.
- Define high-integrity software – The Commission should apply structural quality measurement standards, which will directly impact the core of software integrity issues and has been proven to reduce the number of live system incidents that lead to stability, performance, and security problems.
- Perform System Level Analysis – Structural quality can be measured at the individual component level, but it’s important for complex software to be considered as a whole system. Industry research suggests that over 90% of adverse events in production are caused by multi-component defects. Thus the analysis of structural quality, even within one organization, must take the entire system view into consideration as much as possible, to assess its integrity and target the risk of SCI events taking place. Testing alone is not sufficient.
You can review a copy of CAST recommendations as well as other industry responses from BATS, UBS, NYSE, ANSI, and FISMA here.
What can you do?
- Provide your comments – You can submit your own perspectives, especially regarding the importance of structural software quality, here.
- Partner with CISQ and ISO – Supporting these standards helps reduce ambiguity around what is considered good software.
Be proactive – Regardless of the final scope of Regulation SCI, this effort has been a rallying cry. Other groups including FISMA, NIST, IEEE, CISQ, ISO, and SIFMA have gotten involved. Each has their own perspective, but it’s in everyone’s best interest to get alignment. This is clearly in the timeline and will continue to gain momentum, as regulation and oversight continues in this area.