A New Approach to Compliance: Find It, Fix It, Test It
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.
Tweet This