Compliance and digital innovation needn’t be mutually exclusive
Justin Arbuckle is vice president EMEA and chief enterprise architect at Chef
Regulatory compliance might be a fact of life for every financial institution, but it can be very challenging when competitive pressures come in to play. This is no more true than in the software that an institution develops to use internally and deliver the best possible experience to its customers either through full-blown applications, mobile apps or its website.
Game-changing technologies appear all the time and customer expectations of the digital experience are very high. Software-based services are often now the primary means of contact between a company and its customers; IT is no longer a back-office support function, writes Justin Arbuckle.
At the same time, regulators are placing an increased focus on detailed compliance. The sheer number of compliance frameworks is daunting, as is the proliferation of detailed requirements within each regulatory framework. Since technology inevitably runs ahead of regulation, the new compliance frameworks anticipate the need to evolve and therefore often specify outcomes with many possible solutions. This creates ambiguity and uncertainty at audit time. However, enterprises have more motivation than ever to reconcile the conflict between complying with regulatory requirements and competing in the fast-moving digital marketplace.
It is a truism that the most regulated industries are most susceptible to disruption from newcomers. This is especially true in financial services where challenger banks and payment service provides have a lower regulation bar to overcome than traditional institutions. The compliance barrier to entry is lower. One of the primary reasons for this is technical debt. For financial institutions both compliance and technical debt need to be managed. Technical debt is the need to maintain systems and upgrade them over time – it is deferred maintenance, and starts accruing the day a system is launched. It includes both the ongoing costs of maintaining infrastructure by purchasing licenses and using suitable versions of software. Challengers and disruptors just don’t have the same burden of retrospectively forcing the compliance of a 20 year old code base.
It is important at this point to note that compliance is not just those rules imposed by external regulators, but also those internal rules, processes and technologies that larger companies gather as they grow. Of course, any snapshot of the current compliance landscape won’t match next year’s, or even next month’s. Regulations evolve. For example, the Dodd-Frank Act includes provisions that are still in the process of being defined. Any approach to compliance must be agile enough to accommodate new and changing requirements.
While a piece of software may be compliant at go live, the internal and external rules that govern the compliance over that software and hardware will change with time. Of course the biggest challenge of all is knowing when a change in compliance has affected existing systems – it is especially difficult when it also common that changes to software and hardware are seldom documented very thoroughly.
Digital innovation happens at high velocity, particularly in financial services where competition is intense. But this is hard to achieve with regulatory requirements becoming increasingly granular. The detailed requirements for handling personally identifiable information, and maintaining security over an ever more complex web perimeter are especially challenging in complex systems, where hundreds of types of data can have different regulatory requirements and different implications on different channels.
The conflict between compliance and velocity boils down to two questions. In essence, the question of compliance is “Can you prove it?” and for velocity it’s “Can you reduce drag?” Reducing drag increases velocity and translates into practical advantages, such as reducing time to market or increasing the number of services delivered within a certain time frame.
As the number of requirements increases, the process of checking them manually becomes overwhelming and error prone. This is where a new approach becomes necessary to reconcile compliance and velocity, by embedding compliance into the software production line in the same way we embed other qualities, such as frame stiffness in cars or round-trip response time in banking applications. Through automation, compliance can be achieved in the development process that is testable and can be updated in future against changes in applications, infrastructure or compliance. A critical component of this is the need to express the compliance requirements in a formal testable format. If you can’t get a machine to test for it, any compliance you think you might have is an illusion.
The bigger the organisation and the burden of technological and compliance debt, the harder it is to change and automate development, but it is critical to future success. Start by choosing a small unit of work that teams can experiment with, then take the lessons and scale the skills in the team to other teams. Steering clear of the challenge is not an option. Disruptive forces are already conspiring against you, your own ability to combine digital innovation and compliance at velocity is your only weapon.
Here is the key insight: only high velocity organisations can hope to be compliant. Creating high velocity development pipelines, embedding testable compliance in them and developing the capability to iterate at velocity is the only way to respond to both evolving compliance and new disruptive competition.
