Best regulatory reporting platform/service: Oracle Analytical Applications

Operational Risk Awards 2015: Oracle's enterprise risk management suite could help G-Sibs comply with Basel principles on risk data, which take effect in January 2016

Ambreesh Khanna, Oracle: Basel reporting solution

Part of the reason regulators are clamping down on global systemically important banks (G-Sibs) is to address a crucial weakness exposed in the financial crisis – the fact that many firms were unable to aggregate their risk exposures to Lehman Brothers and other stricken counterparties at group level and across business lines in a timely manner.

Oracle Financial Services, this year's winner of best regulatory reporting platform or service, is addressing this problem by automating the data management process – from data input to aggregation and reporting – at G-Sibs.

"The crux of the problem that we are trying to solve is that regulatory reporting has become excruciatingly expensive for banks," says Ambreesh Khanna, New York-based product manager for Oracle Financial Services Analytical Applications (OFSAA). "It is difficult for banks to identify all the necessary data requirements. Because the data exists in silos, they don't know who owns the data required to actually create the regulatory reports."

Banks must define a strategy for addressing data gaps identified in the self-assessments they had to undertake in 2013 to comply with the Basel Committee on Banking Supervision's Principles for effective data aggregation and risk reporting – also known as BCBS 239 – which will go into effect for G-Sibs in January 2016.

BCBS 239 arose from the fact that regulators were seeing variances in the risk statistics reported by individual banks, such as capital adequacy ratios, liquidity, large exposures, and other risk computations.

"They would see the same statistic being reported differently on different reports and began calling out banks and essentially asking, 'why are these numbers different? Which one is correct?'" says Bhargava Srinivasa, product manager for data management. "BCBS 239 has caused banks to realise they need a single version of the truth, so they can prove to the regulator how they arrive at these numbers."

The desired end-state for banks, says Khanna, is to be able to double-click on any element of a report that a regulator may ask them about and see the raw data and calculations that were used to create the element. This is necessary "because the regulators are asking for reconciliation between reports, which was not the case before", he says.

"Ideally, they'd like to create some sort of centralised repository from which all regulatory reporting can be done," Khanna says. "That's the business problem we are trying to solve."

OFSAA is essentially a set of applications for enterprise risk management – encompassing governance, risk and compliance, performance management and customer analytics. Most recently, Oracle collaborated with London-based risk and compliance vendor Lombard Risk to create OFSAA Regulatory Reporting, which combines OFSAA Data Foundation with Lombard Risk to automate the regulatory reporting process. "This is the final step to enable customers not only to be able to bring data into the foundation and perform the computations, but also to be able to do the reporting to regulators," says Khanna.

The Oracle-Lombard Risk collaboration began about a year ago when the two companies worked together to develop a regulatory reporting capability for a mutual customer, a large US bank. "We worked jointly to ensure that what we were building would satisfy the needs of [the customer's] regulator," says Khanna. "They are now successfully doing their reporting for the US Federal Reserve off our platform."

Oracle saw an uptick in customers seeking to invest in risk data aggregation technology as soon as the BCBS 239 regime was finalised in 2013. "[Customers wanted] to bring in data that is required for risk and financial reporting purposes into a single repository, and then put individual applications on top to perform the necessary computations,'" says Khanna.

BCBS 239 contains 14 principles covering four areas: governance and architecture, risk data aggregation, risk reporting, and supervisory review. Taken together, the principles push banks to clean up the fragmented data standards across their business lines and legal entities that prevent them from achieving a comprehensive view of their risk exposures.

A 2013 review of G-Sibs by the Basel Committee found many banks were struggling to establish strong data aggregation capabilities. Instead they were resorting to extensive manual workarounds, and 10 G-Sibs said they did not expect to fully comply with at least one of the BCBS 239 principles by the January 1, 2016 deadline.

"The key takeaway is that manual aggregation/reconciliation, even if it somehow results in acceptable risk reports, cannot substitute for strong aggregation capabilities, and overreliance on such manual workarounds impairs banks' risk data aggregation and reporting," the Basel Committee wrote in its report.

As the BCBS 239 compliance deadline for G-Sibs looms, banks are now scrambling to put their data houses in order. Unlike other regulations, BCBS 239 is more qualitative than quantitative in character, so it is hard to predict what yardsticks regulators will employ to test compliance.

"There are varying degrees of readiness," Khanna says. "Some of them are in decent shape, but most of them are still doing Excel-based compliance for BCBS 239, and they realise that they can only do this to get past the January 1, 2016 hump. Immediately after that they will have to automate the process."

Large banks other than the G-Sibs will also eventually come under the purview of BCBS 239. "At the moment, it's only applicable to the global Sibs, even though some of the domestic Sibs have decided to take it upon themselves to be compliant, because they know that as soon as the global Sibs are done, the local regulators are going to come upon them," says Khanna.