The banking and finance industries are going through a significant shift with the rapid growth of new payment players like Stripe, trading platforms like Robin Hood, and integration services like Plaid. In the rush to stay relevant, banks are exploring various approaches to accelerate digital transformation. Banks should keep their core competency around compliance top of mind in this process.
It is tempting to try and rip out the mainframes in a rush to support the latest cloud technologies. But banks and other financial organizations have quite a bit of knowledge already baked into their legacy apps. Banks that develop processes for infusing compliance into existing systems are much more likely to thrive in the turbulent times ahead.
We saw this in Europe as the banking industry prepared in mass for the shift to Open Banking. Leaders put as much attention on the processes for building apps in a compliant way as the technology for building them. DevSecOps recently grew in importance as enterprises struggle to address the security implications of new features earlier in the life cycle. An increased focus on compliance could give banks a leg up in the rush to monetize new services, products, and partnerships.
A focus on culture
In the run-up to Open Banking in Europe, technology executives started spending more time talking about organizational structure than technology. Bank technologists weigh the pros and cons of tribes, guilds, and other novel groupings.
Amidst this backdrop, Barclays, one of the world’s oldest banks, discussed the creation of “control tribes” that worked with other teams from the beginning of any new projects. These teams focused on identifying any potential problems in compliance or security issues when they were easier to fix.
In 2016, Jonathan Smart, then head of development services at Barclays, observed that in some cases, making a single code change required an average of 56 days to file all of the appropriate forms and wait for approvals. The control tribes found ways to streamline the compliance lifecycle by reusing the existing code and processes as much as possible. This approach allowed them to push out weekly updates and reduce code complexity.
Breaking through the logjam
Embedding compliance teams into the DevOps lifecycle helps address one of the biggest bottlenecks in the rollout of new financial products. The compliance department often has to veto a lot of ideas. But this faster failure also helps the organization rapidly innovate around the compliant pieces.
Banks, in particular, need to address massive reporting requirements: this grows in complexity with the constant pace of new financial and privacy regulations. Banks also need to include auditability and accountability as critical components of any software update.
At the same time, the core competency of bank culture compared to other industries is compliance. They have a long history of developing relationships with regulators, building products that comply, and the investing money in support of compliance. This is one of the most significant barriers preventing other organizations from penetrating the banking industry.
Many banks attempt to move to digital without realizing the amount of embedded knowledge in their current systems. One of the most effective strategies is to keep what they are doing today. The organizations create a simple interface layer to surface the legacy data and processes already baked into the system.
Automating smaller chunks
These existing systems are just the beginning of bringing more agility to the compliance process. The next phase lies in architecting the systems and methods for better compliance management. Carl Nygard, technical principal at ThoughtWorks, recently suggested that compliance teams consider emulating DevOps best practices around composability and automation.
Modern developers see some of the most significant productivity gains by reusing existing software libraries or customized components as part of new projects. They compose and configure the new application functionality rather than rewriting everything from scratch. One of the significant innovations of microservices is that enterprises found ways to break larger monoliths into smaller applications that could be reused rather than rewritten.
The most successful organizations move to microservices gradually, one service at a time. Similarly, compliance teams should think about how to expose the existing compliance process to facilitate reuse. Companies may want to start by exposing these processes through middleware rather than starting from scratch.
On the automation side, compliance teams could benefit by automating compliance testing. This reduces the expertise required to identify and rectify any issues. It also frees up compliance teams to identify edge cases and find further opportunities to test out new business services.
Banks that take advantage of their existing leadership in compliance have a head start over those that try to reinvent the wheel. It is tempting to start with a new technical architecture. But it is easier to innovate the current compliance process as a starting point for building out the technology that supports it rather than the other way around.
