Skip to main content

Public and regulatory focus on Depositor Protection has increased following recent market events – how good is your SCV process?

In this post we set out some of the common issues that can arise for firms in being compliant with Depositor Protection rules and offer suggestions on how to combat these risks.

Why now?

With the global collapse of Silicon Valley Bank (and subsequent purchase in the UK by HSBC) and takeover of Credit Suisse by UBS in Switzerland, the banking sector has seen the largest bank failures since the dark days of the 2008 financial crisis. It has also brought back into public focus the global network of depositor protection or deposit insurance schemes set up in the wake of the financial crisis to maintain confidence in the banking sector and avoid scenes like those seen at Northern Rock and Bradford & Bingley back in 2008.

What does the UK do to protect depositors?

In the UK, licensed banks and building societies are part of the Financial Services Compensation Scheme (FSCS) which is designed to provide up to £85,000 compensation to depositors in the event of a bank insolvency. Despite this coverage being in place and despite prominent advertising, the scheme is often poorly understood by consumers and its regulatory reporting requirements are often poorly implemented by firms.

And it is not just individual depositors who are covered by the scheme – organisations of all sizes are covered as well. In cases where depositors are cash-rich, such as with many of Silicon Valley Bank’s customers, this leads to the situation where a significant portion of a bank’s deposit book may be unprotected. This can be potentially catastrophic for entire sectors, for example as seen by the heave reliance of technology start-up firms on Silicon Valley Bank.

Key to the scheme for banks and building societies is the requirement to provide upon request a Single Customer View (SCV) data file. This data file details the full customer and account population of the firm in a standardised format designed to be a ready-to-go record of the bank’s deposits should compensation to depositors be required in an insolvency scenario. The FSCS run regular testing of firms’ SCV files under the oversight of the PRA, the ultimate regulatory authority in this area.

What should firms be aware of?

Whilst most banks have had SCV reporting systems in place for many years, the banking landscape has changed dramatically since both the late 2000’s financial crisis and since the last major update to depositor protection regulations and reporting requirements in 2015. The growth of new technologies and different ways of banking have raised several interesting cases and scenarios for banks and building societies to consider – many firms will not have reviewed their SCV reporting capability in many years.

  • Beneficiaries of Financial Institutions – whilst deposits owned by financial institutions are out of scope of FSCS coverage, simply excluding all accounts managed by financial institutions is not the right approach as many of those accounts may in fact belong exclusively to that firm’s customers and should not be excluded as they are classed as Beneficiary accounts under the PRA rules. Whilst understanding where this is the case and applying that to the FSCS SCV process is a necessary step to being compliant, it is not always done correctly, with an over reliance on customers having explicitly flagged that an account contains client monies.
  • Metadata – most SCV reporting systems use existing metadata to drive eligibility and inclusion in the SCV files. However, this metadata is often used for other purposes in the bank and may be out of date or not adequately reflect the requirements of FSCS eligibility. For example, how the metadata for a state-owned airline is set up will dramatically affect its treatment in the SCV files – does it flow through as Eligible as an airline or Ineligible as a public authority?
  • Non-traditional currencies – whilst cryptocurrencies, precious metal and other non-traditional currencies are not generally covered by the FSCS, treatment of these on SCV files varies widely.
  • Deposit aggregators – a digital form of banking where an intermediary firm collects customer deposits and spreads them across several traditional banks with an aim of making use of multiple £85,000 FSCS protection limits whilst maximising returns. Depending on the legal structure of these firms the accounts may be considered as beneficiary accounts and require a specific treatment in the SCV files of the partner banks.
  • Monies in suspense – many firms will place deposit inflows into a suspense account in cases where they cannot immediately be processed into a customer’s account. Often these accounts are incorrectly excluded from the SCV files. These deposits also need to be allocated in the event of an insolvency and thus are in scope for evaluation by the FSCS during their reviews. Having procedures to demonstrate how such amounts are allocated efficiently and on a timely basis (before end of day ideally) is an important element of compliance.
  • Incorporating change – SCV reporting systems and governance are impacted by multiple sources of change, but they are typically governed from one location such as Finance, Operations, or Regulatory Reporting depending on firm structure. Changes that arise outside of the team that run the process are often not picked up and evaluated for relevance. For example, firms run the risk of not incorporating regulatory changes, new products, sales channels, or systems within their SCV reporting, giving the potential for under-reporting to the PRA.
  • Reconciliation – The most recent update to the SCV rules included a requirement to reconcile from source to reporting. Many institutions have relied upon IT data transfer integrity from source system to warehouse as evidence of a reconciliation. Whilst this mechanism does guarantee data delivery it does not assist with ensuring that all the correct data was extracted from the source systems in the first place. Anywhere that filters are used to obtain data is an area of reconciliation risk, irrespective of transmission integrity.
  • Data integrity and quality – a perennial issue for all regulatory reporting, data integrity and quality in SCV files has a unique dimension as much of the data is designed to be used for the fast and secure payment of compensation to depositors. Issue around duplication of customers, balance conversion and aggregation, flagging inconsistency, and incorrect application of the regulatory requirements remain common.

How should firms react?

As significant public focus turns to banking sector stability, increased attention is likely to be placed on FSCS coverage and depositor insurance schemes globally. In turn, this is likely to lead to a greater focus on the design and implementation of firms’ SCV reporting systems, both through stress testing of files by the FSCS and on ensuring that firms can handle any potential instability.

Firms should ensure that they are well positioned to respond to any testing requests or questions from the regulatory authorities on SCV build and reporting. Internal or external data testing of SCV files helps to provide confidence in a firm’s ability to meet the regulatory reporting requirements, and deeper dive audits and reviews can help to provide confidence in the wider build and governance around the SCV reporting systems including asking questions about each of the common pitfalls we have noted above.

Whilst SCV systems are ones which a firm will hope never to have to use for real, the importance of getting this right both for a firm and the wider banking sector cannot be underestimated. After all, you will never know if something is wrong in a SCV system until it’s too late.