image alt text

Steven Lofchie, the co-chair of Cadwalader’s financial services department, has a great way of thinking about the interaction of regulation and risk. He recently highlighted a FINRA fine against Merrill Lynch which arose from a programming error in one of Merrill Lynch’s electronic execution platforms. For a specific group of securities (non-convertible preferreds), Merrill Lynch was not properly incorporating the market-wide “best bid and offer” for the security when providing executions to clients. Rather, they only used data from the securities’ primary exchanges. In turn, this caused Merrill to fail to meet its best-execution duty to clients.

Mr. Lofchie argues that firms haven’t caught up to the reality that “a thorough review of the way in which each item of technology in a firm works is an essential part of the compliance process.” He goes on to advocate that compliance should maintain an inventory of the firm’s technology and the regulatory requirements the technology is required to fulfill. While we think that is a great first step, in System Logic’s view, such a review presents challenges to compliance departments for several reasons.

First, failures like the one Merrill Lynch experienced arise from the complexity inherent in the business of electronic trading. There are actually many services under the umbrella of electronic trading, each with their own detailed specifications and historical idiosyncrasies. Separate but tightly-linked components, like programs that provide market data, risk checks, an interface to an exchange, and algorithmic order generations, have to work together to deliver seamless electronic execution. As a result, logic exists in separate places that must interface properly. There are numerous component boundaries–places where discrete components have to interact–which can lead to unexpected behavior and errors.

In addition to the complexity inherent to the business of electronic trading, organizational complexity makes a top-down compliance review of technology daunting. One form of organizational complexity is decentralized development, where many programmers work in small teams and provide support directly to business units. ( In many ways, decentralized development is hugely beneficial, as developers tend to work faster and more effectively in smaller teams and are exposed directly to the needs of the business.) Such a setup fragments knowledge between teams, and leads to a rate of change that surpasses the the ability for a centralized group to track. This is not a problem of scale that can be solved by a centralized database with more people tracking changes. It is a problem inherent in the technical and organizational structure of the business.

Finally, even if compliance had an inventory of every system and could keep up with every change, these problems are buried in the tiny technical details of implementation. The problems are subtle; if they were obvious, they would have been easier to catch and correct. In this case, conducting the required post-trade surveillance could have detected this particular problem earlier. However, the fact that a required surveillance was not performed correctly bolsters the case that the inherent systemic complexity is what drove the mistake. If a resourced and well-regarded trading firm like Merrill makes such a mistake in their electronic execution software, that represents a failure is in the status quo approach to capture and control these risks.

The Integrated Approach

We at System Logic advocate an integrated cultural approach to compliance and risk management that goes beyond an inventory of important systems and regulatory requirements. This integrated approach emphasizes communication, skepticism, and a preoccupation with failure. Communication is used to fight fragmentation of knowledge. By having groups work together and learn from each others’ best practices and mistakes, the firm as a whole is less likely to commit errors. This can include targeting the specific risks of component errors (for example, training in the market-data Application Programmers Interface) and pairing compliance with programmers to discuss regulatory obligations like best execution.

Skepticism is an organizational mindset that fight common biases - those facts that confirm our worldview and assume that everything is operating well. Firms should formalize processes that require independent code review from multiple programmers, which will further encourage communication between groups. In addition, for particular projects, designate a project skeptic: someone whose functional role is to question the details of a particular implementation and try to think about the ways that things can or have gone wrong. Testing is also a critical part of the software development process. Firms should develop a test suite that allows them to simulate or replay market conditions and see that the expected execution behavior is actually happening.

Finally, firms should cultivate a positive and healthy preoccupation with failure. Discuss and record errors and near misses: errors that occurred and those that were caught before systems entered production. This record of near misses is an invaluable learning tool. For example, the particular mistake of only considering market data from the primary exchange has likely been made, and caught, in another context with the organization ( Obviously, this has to be done with a view to protecting proprietary information and work product. ).

The System Logic stance of advocating an integrated cultural approach over a centralized, formulaic process can be viewed as naive. On the contrary, we think an integrated approach is the only way to manage the risks that arise from complex systems. It breaks down a complex system into component parts, and empowers those with the requisite technical skills to integrate those parts. Good communication and organizational design promote learning from mistakes and enable collaboration between different groups–in this case, compliance and software developers. It is the approach found in many robust and successful enterprises, from how Google tests infrastructure to how pilots avoid making life-threatening mistakes.

Mr. Lofchie is spot on: compliance does has a very important role. It is their job to understand the rules and how developers’ choices affect compliance with the rules and the stability and fidelity of any trading system. But in order to support such complexity, fluidity, and technical intricacies, the answer is beyond a centralized inventory. Rather, a culture of compliance, communication, skepticism, and preoccupation with errors must be aligned within the organization to manage the regulatory, reputational, and technical risks that arise from the inherently complex system of electronic execution.

Clients should call System Logic ([email protected], (646) 543-4250) if they want help thinking through the practical steps that can be taken to implement such an integrated solution.

Thanks to Mr. Lofchie for bringing this enforcement action to our attention. He and his team distribute a free daily newsletter, which covers a broad scope of financial services news in the legal-regulatory space. If you’re interested in receiving this free newsletter, sign-up here. To learn more about his regulatory website, see the Cadwalader Cabinet, here.

Image © 2008 Maureen Flynn-Burhoe