Five questions to consider when implementing the LCR in the UAE

AxiomSL | Inside View - LCR

September 28, 2015 – By Wissam El Zeenni, Business Analyst, EMEA

LCRIn May, the Central Bank of the United Arab Emirates (UAE) announced that it will be phasing in its implementation of the Liquidity Coverage Ratio (LCR) from 1 January 2016. The LCR is a key component of the Basel lll liquidity regime, which presents technical and operational challenges for banks. The good news is that there are many lessons that banks in the UAE can learn from their counterparts in other countries that have already adopted the LCR.

Having worked on LCR projects for a number of banks in recent years, I believe there are five key questions that banks in the UAE need to address:

1) Do you have access to the necessary SME knowledge?

Interpreting the LCR requirements will be a significant challenge for banks in the UAE. The ratio must be reported on a group and entity basis, so banks need subject matter experts (SMEs) with familiarity of both the global and local versions of the requirements.

As well as the regulation, the SMEs must understand the technology the bank will use to manage the requirements and the bank’s operations more generally. For example, the SMEs will need a good understanding of the bank’s balance sheet and products.

The best way to overcome these challenges is by partnering with a vendor that provides both regulatory analysis and a technology solution that it has already implemented for clients around the world. A vendor that fits this profile will have built up knowledge of the requirements and their local variations.

The implementation of the LCR can also be made far easier by choosing a flexible, transparent regulatory platform. In particular, it is important that the platform gives users visibility of the input data.

2) How will you centralize the required data?

The LCR looks at a bank’s liquid assets across all of its operations. This means banks need a central hub that collects and manages data about all of their products from different business lines, including retail, commercial and investment banking. The hub should give users a single view of the assets of both its entire group and of the individual entities that make up the group.

Creating a centralized data hub like this is no mean feat, as all of the necessary data has historically been maintained in silos that employ different data definitions and data governance practices. For example, the way a bank defines a market value is likely to be different in each of its business lines and each of the jurisdictions in which it operates.

The simplest and most effective way for banks in the UAE to create a central data hub is by implementing a regulatory calculation and reporting platform that sits across all of the entities in its group and all of the systems it uses to manage its data. The platform should aggregate all of the data provided by these entities and systems, and harmonize it by subjecting it to the same controls and validations. As well as centralizing their data, banks will need the flexibility to be able to manage the local variations of the LCR requirements that apply to their entities in different countries.

3) What will you do when the reporting deadlines become more aggressive?

Since being implemented elsewhere, the reporting cycles for the LCR have been reduced dramatically. In Europe, the remittance period for LCR reporting was cut from 30 to 15 days earlier this year (click here for AxiomSL’s commentary on this topic), and domestic regulators in the  European Union (EU) have the option of requiring daily reporting. Banks in the UAE should therefore expect similar reductions in the future.

Cuts to the LCR reporting period test the ability of banks to aggregate all of the necessary data and run their calculations in a timely manner. A platform may be able to comfortably produce the LCR every 30 days, leaving enough time for users to make adjustments and rerun their calculations, if required. The question is whether the platform will still be able to do this if the reporting period is cut to 15 days or if daily monitoring of the LCR or daily reporting become mandatory during periods of crisis.

Banks in the UAE should prepare for aggressive reporting timelines from the start by ensuring their platform includes high-performance functionality that can aggregate and process large volumes of data not only on a monthly basis, but also on a daily basis.

4) What will you do when the calculations and report templates change?

The LCR calculations and report templates that banks in the UAE must use will inevitably change over time. This has certainly been the case in the EU, where banks were first required to implement the LCR as defined by the Basel Committee on Banking Supervision (BCBS) before migrating to a European-specific version. The European Banking Authority (EBA) continues to issue changes to the taxonomy banks must use to report the LCR in Europe.

Banks in the UAE will require a large number of resources if they attempt to monitor and implement changes to the LCR requirements themselves. They can greatly reduce the pressure on themselves by working with a vendor that will do this for them, providing updated versions of the calculations and templates when they change. This will ensure the bank always remains up to date and compliant.

5) Can you leverage your LCR solution for other requirements?

Complying with the LCR will be a significant project for banks in the UAE. They will therefore want to get the maximum return on their investment. They can do this by ensuring the regulatory platform they implement is flexible and can also be used to manage other calculation and reporting requirements, including the Net Stable Funding Ratio (NSFR),  Additional Liquidity Monitoring Metrics (ALMM) and Eligible Liquid Assets Ratio (ELAR).

Using a single regulatory platform to comply with multiple requirements allows banks to significantly reduce their infrastructure costs. It also eliminates duplicate work because banks do not need to process the same data multiple times for different regulations, and it ensures consistency between the data in individual regulatory returns because the data originates from the same system.