A New Approach to Compliance: Find It, Fix It, Test It

With so many compliance and system maintenance demands, banks need to adopt a new strategy to free up resources for innovation.

Since the Enron scandal in 2001 and the recent period of economic austerity, the public has witnessed tremendous scrutiny of the financial services industry over the past decade. High profile banking outages, such as those reported at Santander, Barclays and HSBC in May this year – LIBOR rigging, PPI mis-selling and insider trading have caused major criticism of the financial industry. This negative reputation, combined with a new set of recent legislative changes, has resulted in a range of new global compliance measures, most notably Dodd Frank, ISO27002, Basel III, FACTA and SEPA.

In order to support compliance requirements, banks need to change and update their core business applications through software development and testing. Recent challenges such as missing code documentation, the growing coding skills gap and data privacy risks have led to a series of issues forcing banks to increase their spending merely to ‘keep the IT maintenance lights on’. JP Morgan recently announced that in order to support compliance demands it had grown its IT spending by 27 percent since 2011.
As IT budgets continually shrink, IT leaders need to revamp their compliance approach in order to drive efficiencies, reduce costs, and prepare their businesses for the future. This new strategy must include the use of automated application understanding, software development and data software testing to ensure that banks can find the right code as well as fix and test it quickly and efficiently. If done right, banks will get the results they need without exposing sensitive employee information.

Moving beyond simply ‘keeping the lights on’

The existing burden of day-to-day workload on IT organizations is now greater than ever. Maintenance and compliance alone account for tremendous amounts of resources and budget, however it hasn’t proved to substantially improve business in any way.

The need for core system replacement is also being driven by a number of market forces and external pressures. Today’s tech-savvy consumers are demanding cloud, mobile and new IT architecture. In addition, next generation consumers are forcing banks to look at their current IT strategy and find ways to reduce spending on maintenance and invest more in innovation.

However, reducing IT spending on compliance can be challenging and isn’t always an option. Financial institutions face legal imperatives and regulations often accompanied by unmovable deadlines and threats of punitive measures. HSBC, for example, was forced to a pay a $1.9 billion fine for money laundering last year. With deadlines usually locked and loaded, associated projects become high priority “must haves” and budget shoe-ins.
Not complying is not an option, yet updating core applications to ensure compliance presents an array of challenges. With billions of financial transactions passing through 30-year old code, there are bound to be issues.

Barriers to regulatory compliance

1. Application documentation is missing

Understanding where to make changes can be difficult, especially when application documentation is not up-to-date. This often affects how quickly developers are able to identify specific areas of code that are affected by the compliance change. In addition, in-house regulations including coding guidelines, standards adherence, quality metrics, and ”routine” change projects can become a challenging task and require an abundance of resources.

2. The coding skills gap

Developers must rely on the code itself to help them understand where to make their changes. However, many core-banking applications are written in COBOL, a language that many software developers are no longer well versed in. Most of today’s developers are skilled in languages such as C# and Java, therefore a tremendous coding skills gap exists. This becomes a huge issue for IT leaders when it comes to supporting these types of tasks.

3. Testing can risk divulging personal employee information

A key factor in eliminating risks in IT is to comply with new regulations and ensure that applications are released and updated without the introduction of errors. This is fairly well understood in the industry. However, many IT pros remain unaware of the risks involved in using production data for application testing. A 2009 survey of over 1,300 US and UK development professionals revealed that an overwhelming majority of respondents, including 80% of US respondents, use copies of production data for application testing purposes.

Test data can contain sensitive employee data, such as payroll information, if pulled from company personnel for testing needs. Personal data leaked through a testing process not only breaches employee codes but can cause a very high-profile regulatory compliance failure.

Yes, it is easy to say that a bank should do something this way, or revise its operations to do things that way. But budgets and reality sometimes get in the way. I agree the bottom-up approach works best, but it may not be as easy as it sounds.

The problem for banks and other FS organisations is that since 2008, they have been caught between the rock of burgeoning regulatory requirements and the necessity to adhere and the hard place of keeping costs to a minimum. Compliance initiatives are a cost centre, spending on which comes straight off the bottom line. It stands to reason that banks need help in - as David Taylor says, developing a new bottom up approach to compliance - but they also need to be coming at it from a cost efficiency perspective. They have shareholders to answer to. It is clear therefore that they must automate their quality and compliance routines - but only as long as it is done in a way that stands up to frequent change. Otherwise the cost of maintaining the automation cancels out the benefits it delivers.

It's refreshing that your recommendations have to do with "do it right the first time" and improving processes and governance -- compliance isn't just about investing in new reporting and analytics systems. It would be over-simplistic to blame compliance challenges simply on "systems glitches" but clearly a lot of this back-office, maintenance & skills stuff is an under-appreciated aspect of the compliance process.