Thanks to regulation, legislation and the pandemic, the term ‘resilience’ has burst into the consciousness throughout the financial services industry. But why is it so important?
To answer this, we are going to delve deeper into the world of Operational Resilience by exploring how it has the potential to deliver a lot more than merely regulatory compliance. At the same time, we will look to give some clarity about how to use a buzzword you will hear a lot when discussing how to most effectively use data to drive business outcomes: fusion centre.
Ready? Then let’s go.
Trend 1: Operational Resilience will become a key driver of Customer Experience.
This trend is a big deal. When financial services organisations first started measuring customer experience - or customer satisfaction as it was then known - primary market research was the key data source for understanding how well customer interactions / journeys were performing. This was because interactions were typically conducted in ‘traditional’ channels: branch, telephone or ATM. Research was (at that time) a blunt instrument because the findings gave you a ‘rear view mirror’ view of something that had already happened, so it was typically too late to respond.
Move forward a couple of decades and the world is now digital. Customer Experience feedback is now real time, multi-sourced and event-triggered, which is much more helpful. But it is typically still shallow i.e it can lack context. To understand what causes positive and negative experiences, you need to understand exactly what happened during the interactions as well as how this made customers feel and behave.
Technology is now a critical driver of customer experience as most interactions are now digital. And in the digital world the complexity of technology can make it difficult to see and understand issues, which means that downtime is unavoidable. We have all experienced it. For example, the unavailability of a mobile banking app when trying to make a payment - mostly we just accept it as a way of modern life and choose to log in and make the payment later. Which is normally fine, even if it takes an hour for the app to become available…until it’s really not fine!
What if that payment is for a credit card bill and not paying it means that you will be charged interest, or for a mortgage and not paying it means that you have missed a payment? Then all of a sudden, that downtime is really important. And it negatively impacts the relationship with your provider.
So, what to actually do?
From a regulatory perspective, resilience means preventing long periods of service unavailability. In the UK, financial services organisations need to make regulators aware when critical service impact tolerances (the maximum acceptable downtime) have been breached. In the EU, meanwhile, DORA requires any ‘major incidents’ to be reported.
While this is a great starting point for delivering Operational Resilience, it only really deals with the most serious issues. Framing Operational Resilience using a Customer Experience lens requires a greater level of scrutiny and understanding i.e monitoring every single interaction between the customer and the brand. So, it’s much wider in scope. And the more disruptions that occur, the worse the customer experience.
Also as I alluded to earlier, not all journeys are equal. Missing a mortgage payment is clearly more important than not being able to transfer money to a mate after a night out - because the financial impact is greater. With this in mind, prioritisation is key. It is therefore important to prioritise the critical journeys first i.e those which have the greatest impact on customer experience and thereby financial performance.
To optimise the customer experience, it is necessary for financial services organisations to build a more resilient culture. And to do this requires additional work on top of the base regulatory requirements. A framework for delivering resilience maturity is shown in the diagram below. This highlights the importance of being able to proactively monitor business services to ‘get ahead of issues’ and ultimately ‘delight customers and build trust’.
Fig 1. Digital Resilience maturity model
Trend 2: Being proactive is the key to delivering optimised customer experiences in Operational Resilience
As the technology that supports business services becomes ever more complex, ephemeral and hybrid, employing an Observability approach is becoming increasingly important to improving resilience. Observability is key to knowing enough about each system, component or interaction to minimise the Mean Time to Resolve (MTTR) for all incidents. Employing this approach will help financial services organisations move towards being proactive and thereby deliver truly exceptional customer experiences.
In customer experience, being proactive, curious and to a certain extent relentless is the key to achieving service excellence. The same is true of Operational Resilience. As noted earlier, while it is important to align with the requirements of regulation and legislation, this should be perceived as the starting point from a maturity perspective. If everyone is doing the same thing i.e complying with regulatory requirements, it merely becomes table stakes.
So, what to actually do?
Well, the starting point is clearly regulation and legislation. The EU DORA guidelines are relatively prescriptive, whereas the UK FCA and PRA guidelines are much less so. But even if your organisation is located outside of the EU / UK, these regulations can be used as a starting point. In fact, regulators globally are already citing the EU and UK requirements as a starting point for their own guidelines.
It must be remembered that each set of regulations reflects the objectives of the bodies that have published them:
- EU - strengthen the financial sector’s resilience to ICT-related incidents
- FCA (UK) - protect consumers, keep the industry stable, and promote healthy competition between financial service providers
- PRA (UK) - promote the financial soundness of the firms it regulates
This means that all existing regulations need to be interpreted with the objectives of the bodies that made them in mind. It also means that these regulations will not cover every eventuality, i.e there may be gaps. To be truly resilient, therefore, financial services organisations must look beyond regulation and build their own target future state.
To do this effectively, they will need to firstly establish their ultimate goal i.e their desired end state. There are a number of Operational Resilience maturity models, which can be used to do this, including the one shown in Fig 1. This includes identifying the right KPIs to be monitored – which could be reduced downtime, an increased number of customer journeys completed, reduced security risk etc. Once the objectives have been set, there will need to be a process of implementation and refinement. During this process, it will be critical to learn and reflect on every step in the process.
If a resilience framework needs to be rolled out to multiple critical business services (which it typically does) then having a template that can be applied consistently is one of the key criteria for success. With consistency of approach in mind including a technology solution that can be applied to deliver the key resilience outcomes can be used - as is shown in Fig 2 below. This shows how transaction failures, latency and fraud can be monitored using a single holistic view of a business service, in this case card payments.
Fig 2 Indicative example, a single view of Operational Resilience for a card payment service
To develop the experience or ‘muscle growth’ required to deliver this type of observability consistently across all business services I would recommend for the approach to be applied successfully a minimum of 3 times. This is because it is not sufficient to implement once and assume that it will be fine to apply in the same way again: it needs to be proven across multiple disparate services.
Having a flexible approach is also important because of the fluid nature of the regulatory environment. With regulators globally reviewing operational resilience requirements, there is likely to be further harmonisation in the future. Whether or not there will ever be a single set of global requirements is not yet known, but it is clear that current Operational Resilience reporting will evolve over time - so all financial services organisations need to be ready. Future proofing will require flexibility to be built into all frameworks and processes.
Given this backdrop, it feels like financial services organisations are rapidly approaching a key decision point. Yes they must tick the ‘regulation box’ but they also need to choose whether to be a ‘leader’ or a ‘follower’ in Operational Resilience. Working with regulators to ensure that they are in a leadership position will have significant benefits, both for their organisation and the wider industry. The alternative will be to do the minimum required to comply, which will incur less cost but will deliver no incremental business value. Taking this path will also require organisations to be ready to respond when requirements change. Given this, Operational Resilience leadership is therefore something that I feel that every forward looking financial services organisation should be striving for.
The fusion centre is a great concept because it facilitates the effective use of data to deliver business outcomes. Something that I am passionate about.
But … the term fusion centre means different things do different people. When I think of Fusion Center, I think about the classic financial services definition: ‘A fusion centre gathers fraud analysts, cyber threat intelligence, and cyber analysts to address fraud together. These centres are supported by a continuous loop of information exchange within a single ecosystem of technology, processes, and documentation.’
However I’ve heard the term fusion centre used in many different contexts and scenarios. In reality any technology solution that required multiple different data sources to be correlated (i.e pretty much everything we do at Splunk) could be referred to as a fusion centre. So that’s a lot of potential for confusion!
So... what are we going to do about fusion centre?
A key characteristic of a fusion centre is the ability to align internal teams with the objective of achieving a common goal e.g improving operational resilience or fraud detection. With this in mind, I would like to see all references to fusion center be preceded by its purpose e.g a fraud fusion centre. In addition, I think the term ‘fusion centre’ should only be used when there are multiple teams being bought together to collaborate on a common goal.
This is just my point of view, but what do you think?