Why are CLM Implementation Failing?

Aurora CEO Sean Vickers and iMeta CEO Ben Marsh address the elephant in the room, asking "Why are so many CLM implementation failing?", to help you avoid the pitfalls and realise your business case.

To get started, can you give us a sense of the general mood in the market around long-term challenges presented by RegTech implementations? Where do you stand on it?

Sean: I still think my view hasn’t changed. I’m like a broken record on this; I think that businesses across financial services really haven’t yet got their heads around the idea of why an operating model is so important to the delivery of technology. I don’t know why this is. There’s fractured thinking around how our business works and what technology will help you do. And I think in some ways people believe that technology not only has all this functionality out of the box, but also has the operating model somehow. After five years with Aurora and probably 15 years talking about this, I’m still completely blown away that it still hasn’t landed. I think it is changing, but I don’t think that’s changed.

Ben: I’ve never really cottoned onto it before we started speaking to people like you that everybody seems to look at the whole thing (their process) like a technology problem. They’re trying to hammer whatever they’re doing into a piece of technology rather than thinking, “Is what I’m asking, sensible?”

And the other thing, which people really struggle to do, is to ask, “If I could do it differently and I used the tools that could help me to do it differently, what would I do?”

Sean: A fantastic point, Ben. Currently, it lends itself to the siloed approach, which most financial services have built themselves upon. Often, the thinking about automation and KYC optimisation, which is its own thing, is slightly atomised because it doesn’t really look at the end-to-end problem. And again, it’s left to technology to unpick that and solve it and then generate the benefits and values of that. That’s a very tough ask for any technologist, because you’re basically saying, “Sort out my operating model through the back door.”

Now, where organisations really get it right is where they’ve been burned before, or they’ve learned the lesson that buying the technology doesn’t get you where you need to get to. They put the investment in up front, and they see the optimal benefits that you can get from the technology. There’s a symbiosis between the operating model and the technology. Getting that symbiosis right is vital, but it must be led by the construct of the organisation and what they’re trying to achieve. The technology overlaid onto that then puts the controls, the benefits, the scale, and the automation over it. And if you don’t do that, we’ll be having a conversation in five years’ time, where we’re still saying this is still happening, but the expectation on technology will have moved even further. It will have doubled down.

Ben: I agree, we do get engaged in so many conversations where people are looking to solve a particular point along the process rather than thinking about the whole thing holistically. If people don’t think about the product and being ready to trade, ready to settle, then that’s a fail, isn’t it? If you’re running for example a pizza delivery service, your metric is, “When does the hot pizza get into the customer’s mouth?” That’s the metric. Why is that not the metric in our world? Tasty pizza in my mouth. That’s what I want. That’s the customer experience. And the fact is that they too must ensure they’re doing it to a regulatory standard i.e., the Moped driver has got a license, the restaurant is clean, and it’s got its licenses. It still needs to be done. You then get the box and the ingredients ready – and the deliverable is hot, juicy pizza.

Sean: It’s a phenomenal parallel, Ben. I’ll tell you why. Because if you apply it to our industry, what we’d be saying to them is, “You can order that cheeseburger, but you have absolutely no idea how you make it. The way you order it is really slick and it’s completely tech-led.” In reality, how you make the cheeseburger and when you receive it is redundant, but you can order it in a really clever way. I think that’s what we need to shift it around from. To use that same example, people seem to be obsessed with measuring how long it takes to just do the KYC part.

Ben: Yes, it’s like we just measure time to get the pizza into the box but ignore the rest of the journey to the mouth. That’s not good because then it’s cold by the time it arrives.

Sean: Exactly. I can measure how long I think the KYC bit takes and price it, but I still can’t trade, and I haven’t factored in how much it costs the moped driver to get to me, or the cost of the box it goes into. I’m bemused by it all because they are data points that are atomised. They don’t mean anything. “Am I good to trade? Yes, or no?” It’s binary and it’s simple. You either can or you can’t, so you have to tie it together. It comes back to building the end-to-end story and how the technology enables it, and not the other way around.

Ben: That’s exactly right. What the customer cares about is eating the hot pizza, and what the corporate or institutional customer cares about is a transaction completing.

Sean: In my mind, it’s a brilliant example, because what if you still haven’t got your pizza, but you’ve had a fantastic customer experience through the technology platform. If you’re still not eating it, you don’t know when it’s going to arrive.

As noted above, the latter context particularly falls naturally within the compliance field, and the broader domain of Client Life Cycle Management (CLM).  While traditionally ESG checks and investigations have been catered for by “specialist” teams within a firm, it is not surprising that many heads of Compliance are now seriously considering including ESG as part of their existing suite of client due diligence and onboarding processes/checks.  Positive public perception is critical for FI’s, as is the avoidance of large fines and/or censure from the regulators.  It’s clear then that firms that onboard, service and make money from clients with poor ESG behaviour run the risk of significantly harming their businesses. Integrating ESG into the background checks firms undertake when onboarding clients is now a necessity.

Has there been a change in the way Financial Institutions are approaching implementations or are they still trying to fit a piece of technology on top of their existing operating model?

Ben: We tend to see people who are being tasked with doing a bit of the journey. “Who’s looking at it holistically?” is the question really, isn’t it?

Sean: I often talk about headwinds and tailwinds. The tailwinds are improving technology, APIs that mean we’re ‘super connected’, and embedded banking. These are moving the industry forward. The headwinds that we’re still fighting against are siloed businesses and transformation fiefdoms. Transformation happening in one group might be counterintuitive to transformation happening in another, but CLM runs all the way through it. They don’t help anyone, but they’re aligned to silos.

Another is the op model still isn’t sorted and it’s often seen as a bit of a headache. There’s this mix of headwinds and tailwinds, and technology is the tailwind. I think that’s why so much expectation is laden upon it because they haven’t fixed all the headwinds. There’s this view that technology is advancing so quickly that they’ll solve it, but technology can only go so far. There are still decisions that need to be made; there’s still an operating model that needs to be followed; there are still silos within banks where people make irrational decisions. Getting the operating model right can mitigate those headwinds.

Ben: I haven’t heard of an implementation, whether it’s an own build or a vendor implementation, other than ours, where things seem to have gone well. I might be blowing my own trumpet on that one, but if there are any, they’re pretty rare.

Sean: They occur within customer groups, where there is a more simplistic and robust customer journey that doesn’t have the complexity of cross-border onboarding, or onboarding to multiple balance sheets. Where I think the industry has moved on is they’ve stopped trying to say it’s simple. It’s not simple. The whole process is incredibly complicated. There was a narrative for a period, at the end of the last decade, where onboarding was perceived as simple. It’s not. It’s a complicated topic that touches many different groups in many different jurisdictions. That’s where I haven’t seen someone really crack it, where they can do a local onboard and a cross border onboard to a different balance sheet, and it’s effortless. We see glimpses of genius but it’s very, very hard. Onboarding and CLM is tough, and it requires the right thinking and the right technology to truly solve it.

So, what’s the reality for organisations that have built or bought CLM and it’s not worked? What’s the impact on the business case?

Sean: Well, the business case kicks in somewhere around the point of sale, because they’re saying this is what you get once the contract is signed. However, over time that business case becomes redundant because the expectations of the organisation and the outcomes change. The second you go over your defined implementation window, you’re spending more money than you expected. You end up with nothing in the tank, you’re spending more money, and the business case is reduced to the point where it ultimately becomes redundant and has to be re-baselined.

A lot of financial services are in the wide jaws of the graph above where they haven’t realised the business case and spent a load of money. Someone senior who got the business case signed off will have to go to someone more senior and tell them it’s become redundant. It erodes goodwill and trust. If you’re the seniors in that position, it puts you in a very vulnerable place.

From a consultancy perspective, where those lines part is where the project is suddenly tracking amber or red on a transformation PMO roadmap, because they’re saying, “Hold on, it’s supposed to be done,” and that is where the first bit of head scratching starts. Then there may be a point where someone has gone, “Hold on, we still don’t know what we’re building to.” The section between implementation and proposed completion is often where someone will go back and say, “We need to look at the operating model.”

Ben: Do FIs really think about and identify the key capabilities they need to see from the technology to solve their business problem? Even if they haven’t thought about the end-to-end. Using the example that you were talking about – the cross-border onboarding and being able to successfully onboard from one jurisdiction to another – what are the key capabilities that are actually needed to achieve what we’re trying to do? And how can I test that my vendor or internal developers can do this for me?

Sean: I would say there’s a sunshine path in my mind. For example, a client we’re working with has done it in what I would describe as the right order. They have looked at their processes, looked at their people, looked at their outreach, got everything in the right order, then looked at where they’re trying to get to and gapped it. So, they said, “OK, if we don’t look at technology, but we gap the current processes to what the ambition of the organisation is, it’s still lacking, therefore, we need an amplifier to get us to where we need to get to.” Because it’s been done in that order, they’ve written the business requirements for the RFP, so the solution will need to demonstrate X, Y and Z to allow the organisation to achieve its goals and outcomes. That is the right way, because the request that goes out isn’t about vendors showing off their wares, it’s about demonstrating that what the business has asked for can be achieved, which will allow them to achieve their goals and result in a better implementation. Often, the business requirements gapped to the outcomes of the business is lacking, so the business case is already on shaky ground. They don’t know why they are doing it or how to measure it.

When management changes, do those critical measurements carry or does new management say, “I want the technology to do something entirely different, so go and pivot.” The lack of consistency is often why projects go wrong because the stakeholders and actors change, and they basically have a different desire and outcome for what it should be doing. Their feet should be held to the fire, and someone should say, “We bought [or built] this solution because it addresses these requirements, which allows us to achieve certain outcomes or goals.” That conversation at a certain level, for some reason, is lacking.

Ben: Yeah, I agree with that. It filters down all the way, I think, right?

Sean: At that point where the project bisects and they switch the sponsor of the project over, that sponsor may have very different ideas about what it should look like.

If you asked the product development team why they are building the solution, they probably couldn’t tell you. If you said to them what’s on the business case, they probably couldn’t tell you. That’s damning because they are making decisions that impact the success and implementation of a project. So, they’re just going to carry on coding and building even though the direction has entirely changed. I think there’s a communication issue and there needs to be a fundamental question around ‘why’ and not necessarily ‘what’ and ‘how’. For some reason it’s not there. It’s evolving across our industry, but I don’t think it’s evolving at the right speed.

So, what does good look like? How do FIs give themselves the best chance of realising their business case?

Ben: The high-level view is about defining the outcome that you’re trying to achieve. The achievement of the outcome is not necessarily what you are doing, but it’s more about understanding where you are on your journey. As previously mentioned in the takeaway analogy, are you building the UI to ‘Pizza in Mouth’ journey or just sourcing the box to put it in?

To get it right, you need to understand where you are on your CLM journey and exactly what you are looking to achieve. Ask yourself the following questions:

• How can we really make this whole thing work?
• Have we clearly articulated the business benefits we’re hoping to achieve?
  
• Do we have alignment on that across the business?
  

If you ask these questions early on you increase your chances of realising your business case as you expect…

Sean: I agree. We believe at Aurora that there is an industry definition for what CLM is and how it should work in the most optimal way. Today, the CLM definition is in the eye of the beholder. It’s a myriad of functionality and data processes, and everyone seems to have a different definition of what it is. Generally, we believe there’s a right way to do this.

Ben: A big problem is there are projects not delivering because banks haven’t tested that the technology will enable them to do what it says. As soon as it doesn’t work, they end up trying to spend more money to fix it, and then it all unravels. Having said that, we’ve been in projects where they’ve not lined themselves up like that, but we’ve understood what needs building and we’ve been able to deliver it within the timescales.

There’s a fundamental mismatch in this space due to a problem of overselling and under delivering. The same language is often used to describe very different behaviours and outcomes.

At iMeta, we will not tell customers we can do something we can’t. We try to understand what it is we need to deliver on, the outcomes they’re trying to achieve, and the rationale behind what they’re doing. We ensure this is all documented from the very start. iMeta has a track record of getting it right.

Key Takeaways:

• Get clarity on where you are on your CLM journey before selecting your technology.
• Choose partners and technology that have got a track record of getting it right.
  
• Make sure you clearly understand the business benefits you’re looking to achieve.
  
• Get an understanding of what the capabilities are of the software that you’re buying.
  
• Get a proof of concept to test that the technology can help you realise the benefits in your business case.

Ben Marsh – CEO, iMeta Technologies. iMeta provides Client Lifecycle Management technology for Wholesale, Corporate, Institutional Banking & Capital Markets; delivering accelerated, compliant customer journeys, from onboarding to offboarding and everything in between.

Sean Vickers – CEO, Aurora. Aurora is a London-based consultancy with specialist knowledge in banking operations, middle office enablement, and Client Lifecycle Management technology. We help financial institutions and software companies deliver material change.