Even well meaning gatekeepers slow innovation, Jeff Bezos
Resilient banking technology is essential to maintain and enhance trust and confidence in the financial system alongside ensuring business continuity for banks. Financial regulators have low tolerance for customer impacting failures of banking technology. Their scrutiny of such failures usually results in financial penalties for banks who may also have to compensate customers for losses and inconvenience. Altogether, this creates distractions that banks can ill afford when trying to compete in a dynamic and disruptive business environment.
It is, therefore, no surprise that technology governance and change management are critical for banks. In most banks, these have grown into substantial processes with multi-layered manual approvals. There is now credible evidence that such processes are slowing down delivering business and customer value. At the same time, these processes are not also enhancing confidence in technology change.
Traditional governance processes are also an obstacle in cloud adoption by banks. The friction they introduce restricts banks in achieving the benefits they desire from public cloud, such as business agility, economy and faster time to market. Hence, lifting and shifting traditional change management to cloud leads to suboptimal results. The question this blog post attempts to answer is, how banks may achieve the technology governance outcomes of regulatory compliance and low risk with much lower friction so they can capitalise on the benefits of adopting public cloud.
This blog proposes a platform strategy for banks where the building blocks of banking and regulatory compliance functionality are implemented as loosely coupled services of a platform. Change management and governance here is automated in the form of functional , cross functional and compliance tests that are specified and approved by the governance functions in the banks. All this together should lead to much lower friction, greater flexibility and higher efficiency resulting in increased agility and economy on public cloud.
Impact of Change Advisory Boards (CAB) and Orthodox Approvals
Banking Frameworks and Coupling
Decoupling through Digital Platforms
Automating Change Management and Compliance
The Evolving Role of CAB and Governance
Impact of Change Advisory Boards (CAB) and Orthodox Approvals
UK’s Financial Conduct Authority (FCA) conducted a change implementation survey in 2019 to ascertain the causes of significant IT failures in the preceding 10 years. The survey found substantial change activity in banks. In 2019 alone, an average of 35,000 average changes were implemented per firm. Out of the 1000 material incidents, 17% of the incidents were change related. Practices contributing to change failures included manual review and approvals.
Most banks and financial institutions have Change Advisory Boards (CAB) to review and approve changes to production. CABs generally are formed of teams from technology, governance, risk and compliance. One major reason for constituting CABs is compliance with regulations around segregation of responsibilities, like Sarbanes Oxley (SOX). Banks consider that compliance with SOX requires people committing the change cannot approve and deploy it into production. There is a different interpretation of SOX that SOX does not mandate the manner in which approvals and change propagation should be implemented. All SOX requires is the person making the change is not the one reviewing it. By making changes small and self-contained, not only the complexity of the change is reduced, the reviews are far more comprehensive and effective.
As a result, CABs are far removed from the change itself. Change management and governance through CAB requires the teams to prepare lengthy and complicated change documentation, commonly referred to as compliance as prose. This introduces friction in change delivery without adding much confidence to change review and approvals. FCA found that CABs approved 90% of the changes they reviewed and in some firms CABs had not rejected a single change in 2019.
Hence, change management and oversight by CABs do not provide much confidence. At the same time they introduce friction in change delivery. These findings align with the findings revealed in the State of the DevOps Report (DORA) 2020 on change management in the wider industry. The report finds that firms with highly orthodox approvals are 9 times more inefficient than firms with low orthodox approvals.
Orthodox change management involves approvals by committees with multiple management layers and with rigid change schedules. Such governance and change management processes are orthogonal to cloud native operating models. Cloud native operating models benefit from end-to-end automation in delivery, including change management. These aim to progressively reduce friction while ensuring regulatory compliance and low risk.
Banking Frameworks and Coupling
Reduced friction from concept to cash automatically increases innovation opportunities. Banks are then able to implement ideas into production fast, measure the outcomes and adapt swiftly to maximise value to customers. At the same time, banks want to minimise risk of changes and ensure regulatory compliance. Traditionally, orthodox approvals have been used to ensure that risk remains low and regulations are complied with. As mentioned before, orthodox approvals generally fail to achieve these and at the same time restrict innovation opportunities by introducing more friction in the delivery process.
Banks have traditionally employed reuse to speed up delivery as well as ensure compliance. Key banking workflows are implemented as comprehensive frameworks which also provide functionality for regulatory compliance. The premise here is that application development teams using these frameworks get regulatory compliance functionality out of the box when they use these frameworks. Furthermore, with such frameworks, the change approval process was expected to simplify.
But reuse through large frameworks introduces coupling, not just between systems and the frameworks but also across different teams. Furthermore large, comprehensive frameworks are inherently complex which makes their own evolution slow and risky. All these factors add up to increase friction, not reduce it. Similarly, framework based banking systems require greater orthodox governance, not less.
Decoupling through Digital Platforms
Digital platforms are an alternative approach to frameworks. Platforms are composed of modular, decoupled and composable services that expose their capabilities via open and secure APIs. These services provide both business and regulatory capabilities. Business applications compose their workflows by orchestrating the relevant business and regulatory APIs as required.
Platforms introduce much less coupling than frameworks. Individual platform and application services can evolve independently. This allows breaking down changes into much smaller and less risky changes. Each of these granular changes require equally simpler yet more effective change management oversight as they are propagated to production.
The FCA survey mentioned above also revealed that major changes were twice as likely to result in an incident. While the firms appreciated the need to break changes down to reduce the risk, complexity of changes makes it difficult to decompose these changes. However big changes can be decomposed into smaller independent changes by decomposing the entire system into modular and decoupled services where each service can evolve independently. The overall system is then composed through the orchestration of these services.
Automating Change Management and Compliance
While digital platforms reduce friction by decoupling technology and teams, governance and compliance may be concerned whether the necessary regulatory services are being appropriately orchestrated. Orthodox change approvals with platforms can then tend to become more complicated, not less.
Traditional governance and compliance is achieved via prose, i.e., written instructions and checklists, that need to confirm compliance, are manually followed for each change. This makes governance and compliance laborious and error prone. Manual compliance checks are largely performed far to the right of the development cycle, usually before release to production. This makes changes to achieve compliance more disruptive and expensive. As mentioned above, the volume of change in financial institutions is considerably large. Mistakes are highly likely and, as the FCA survey suggests, they can lead to client impacting issues in production.
The alternative is to implement compliance as code. Here all the compliance and regulatory checks are implemented as automated tests. These tests are specified by governance functions like CAB and are implemented by developers. Once integrated with the CI/CD (Continuous Integration/Continuous Deployment) pipelines, every change is automatically tested for compliance as it is committed to the source control and progressed through the deployment pipelines. Compliance is tested to the left of the development cycle with fast feedback directly to the developers as results of failed tests.
CAB then no longer needs to manually confirm every change for compliance. This significantly reduces
- friction in delivering the change to production,
- risk of propagating non-compliant changes,
- effort in confirming compliance.
The DORA 2020 report suggests that involving engineering teams in governance and change management leads to 5 times more effectiveness through a shared understanding of the outcomes and process. As a result employees report higher involvement and are 13% more likely to understand and enjoy the process.
The Evolving Role of CAB and Governance
Some may argue the need for CAB and governance with compliance as code. Both CAB and governance are still needed but their roles evolve from prescriptive, output focused and activity based to outcome driven and principles aligned. Governance functions, including CAB, specify to engineering the outcomes they want achieved. Engineering and governance can then collaboratively convert those outcomes to automated tests which are integrated into development and delivery automation for early and frequent feedback on compliance. Any changes to the compliance tests need to be approved by governance. However, governance need not intervene in the delivery when all the specified tests are passing.
In many ways, the role of CAB and governance is elevated. They no longer need to ensure that compliance is achieved. They delegate this to the engineering teams and advise them on how compliance may be confirmed using automated tests. Beyond that, they focus on understanding the emerging regulatory requirements and their impact on business. They also assess how existing regulatory requirements can be ensured for new business capabilities.
Conclusions
Governance and compliance is essential to ensure confidence in technology used in regulated businesses like banking and finance. However, traditional governance processes with orthodox multilayered approvals introduce substantial friction in delivering technology to drive business value. And it has not shown any reduction in risk. Furthermore, lifting and shifting these processes to public cloud restricts the agility and economy public cloud can provide to businesses.
Automating compliance as code and changing the role of CABs from gatekeepers to advisors increases the involvement of teams in ensuring compliance early in the development process. This leads to faster feedback in case of non-compliance and at the same time reduces both friction and risk in delivering change. On public cloud, this translates to increased agility, greater economy and faster speed to market.
Banking on the Cloud 