BCBS239 for DSIBs and 5 things We have Learned from their Global Counterparts

BCBS239 for DSIBs and 5 things We have Learned from their Global Counterparts

With the compliance date for BCBS239 designated GSIBs (Global Systemically Important Banks) just about to arrive in January 2016; many DSIBs (Domestic Systematically Important Banks) are looking carefully at their global counterparts to see what worked well; and what didn’t.

The first challenge is that not every Bank knows whether it will be designated a DSIB or not, which doesn’t help with planning. Then we’ve got signals that if a Bank is designated as a DSIB, then the likely timeframes for compliance could be three years out. To compound this issue further, the messages coming from the GSIB community is suggesting that achieving a roadmap to compliance is not only very challenging but that attitudes to compliance may need to change.

One area of benefit from BCBS239, and similar regulations, has been the emergence of the Chief Data Officer (CDO) role. This role has, and is, doing much to enable organisations to take data from all parts of the organisation to drive much more benefit from it by looking at as a whole, rather than a set of parts.

BCBS239 Compliance as an Opportunity

I wrote a blog recently about Compliance as an Opportunity. In short, this refers to the fact that the effort of getting compliant can have significant benefits in the way the process of getting compliant exposes insights on an organisations customers, businesses or markets. These insights can be used to support Customer Centricity activities, marketing planning or even simple things like understanding the quality of data used for decision making across an organisation.

I think that there has also been a second but possibly more fundamental opportunity arisen – that is the benefits associated with a Bank treating its data as a corporate asset. Now many Banks say that they already do this. The qualifying response question I always ask is “that’s great – do you treat data as a corporate asset across all the businesses of the bank and in a consistent, holistic way?” The response is often that these points are aspirations given the size and complexity of most Banks.

I agree most Banks are large and complex but isn’t that even more reason to treat data as a corporate asset?

5 things we’ve learned

So DSIBs have the benefit of watching and looking at what the GSIBs have had to go through with the net result of attempting to achieve compliance better, faster and cheaper.

GSIBs that get through the process well will become magnets for what they did and how they did it. Those that don’t do well will be rapidly looking to understand what they could have been done better to avoid the same mistakes on the next compliance requirement.

Below are 5 key things we’ve observed, as provider of data technology services to some of the GSIBS, which should be of benefit to any DSIB:

  1. Programme not Project
    Banks can either treat being BCBS239 as either a necessary requirement where they will spend the minimal amount of time and effort to achieve compliance or they can recognise it as a journey and work hard on how to best utilise the experience. Banks in the former category tend to approach being compliant to a specific regulation as a Project. The challenge with a project is that it has a defined end point and often the requirements drive a delivery approach that only considers the needs of the specific project. I would argue that getting compliant is one challenge but staying compliant on an on-going basis is a bigger one. Those Banks that look at compliance more like a Programme tend to take a longer term view of what they’re trying to achieve and are looking at what other associated benefits can be achieved as part of the exercise. Programme not project seems to underlie the idea of a journey not just a destination.
  2. Top down not Bottom Up
    One question about data projects is whether to start with the data a Bank has or to start with the requirements the Bank needs. For many Banks, the data aggregation requirements for BCBS239 require them to deliver new datasets and new generated insights. These datasets and insights are probably created from data across business lines so the question becomes; which originating sets of data are the right ones to be using for compliance? The only really effective way of understanding this is to start with a top down definition of the key data entities the Bank needs to report its compliance on and then go looking for the physical data to populate these entities. If the physical data doesn’t exist then a Bank can go look at ways to find it. Starting with the data a Bank has restricts their view on the opportunity for the wider potential use of data.
  3. Good Data Governance is critical
    Good data governance is a key underpinning requirement for any successful BCBS239 compliance programme. Many Banks do provide good data governance either within a business line or within an operational silo – achieving this across the organisation has been hard. Many Banks have successfully deployed data governance technologies in support of BCBS239 requirements but achieving this across an organisation puts the spotlight on the processes adopted and methodologies deployed. The requirement is now on how to deliver and maintain good data governance across an organisation and do it in a systematic manner – technology is useful here but a wider set of capabilities are required to tackle this.
  4. It requires a range of skills and disciplines
    The range of skills and disciplines required to support any BCBS239 programme seems to have increased. It is now much more common to see roles such as business modelling, data modelling, data architecture, technical architecture, enterprise architecture, data quality plus business and technical delivery. On top of this we’re seeing real engagement between business and IT functions trying to tackle some of the more challenging problem areas. Given that BCBS239 is now a Board level conversation in most Banks, the awareness of the importance of data has increased significantly. Prior to BCBS239 how often did the Board of a Bank discuss ‘data aggregation’? Not often probably but they do now. With it comes more awareness of the importance of getting it right as well as getting the right balance of skills and disciplines in place at the right time.
  5. End-to-end visibility of data processing is key
    The portion of BCBS239 relating to business data lineage has challenged many organisations given the siloed nature of many businesses, the plethora of technologies utilised to solve many data processing problems, the continued reliance on spreadsheets for data manipulation plus the lack of a common set of business terms being used across the business. Achieving business data lineage requires a much more holistic view on how data is managed plus the removal of many bespoke or shadow systems employed by many business lines. This consolidation approach requires organisations to really understand where their compliance data comes from and build strategies for how to document, deploy and manage both the data and its associated metadata. Technology and tools can help here around discovering data, improving its quality and making it available in the right format at the right place and at the right time. What technology can’t do is see when a business line is using bespoke tools (for example) built for their own use that mask the real source and manipulation of data – compliance data needs to be managed transparently from source to destination otherwise it creates a risk-point in the data processing flow which somebody is going to have to fully understand and take account of.

So what next?

I get the sense that the first half of 2016 will see many DSIBs looking for best practice and ideas from the GSIBs around BCBS239 delivery from those that appear to have done well. DSIBs will be looking at what methods worked well to see if they can be applied to their own organisation as well as associated technologies and technical capabilities.

Of the GSIBs that do well, I also get the sense that some have embarked on a new journey with their data and are looking at this requirement as a way of addressing a number of other business challenges.

Maybe the old expression needs changing. Are we moving away from ‘People, Process and Technology’ towards ‘People, Process, Technology and Data’?