Mastering Complexity: The Key to Success in Capital Markets Onboarding

Aurora Chief Technology and Services Officer, Matthew Benham, sat down with iMeta CEO, Ben Marsh, to discuss why Capital Markets Onboarding is so complex, common pitfalls, and how to get it right when transforming the customer onboarding experience.

Key takeaways

• Customer types and associated products, legal documentation, and a multitude of downstream trading and settlement systems make capital markets incredibly complex environments.
• Most CLM vendors focus solely on customer onboarding and avoid product fulfilment due to its complexity, however iMeta’s solution enables every journey.
  
• Two of the biggest blockers to effective CLM implementations are the lack of policy alignment across jurisdictions and internal politics.
  
• The key to success lies in the creation of a roadmap to harmonise systems, processes, teams, and policies up-front, as waiting until implementation will cause delays and cost overruns.
  
• Data-driven, low-code technology provides the flexibility required to cope with operating model variation and extension to new jurisdictions.

Part 1: What makes capital markets onboarding so complex?

Products

The first distinction that makes capital markets so complex is the products, particularly those laden with additional risk, such as derivatives. They bring in a few specific complexities. The first of which is their own regulations, and a requirement that you must be of a certain size and type of business to be approved to transact those products under the regulations. You can’t just be a two-person fund trying to trade credit default swaps.

In addition to this is Structured Products, where the onboarding might be for a specific deal or transaction e.g. leasing an aircraft. In this instance special purpose vehicles are used, which in themselves are new to the bank, but in carrying out onboarding many related entities such as arrangers, sponsors and obligors who are not will need to be considered as part of the process.

Furthermore, a lot of capital markets products require a tied credit line, which means credit is on the critical path to completing the onboard. They’re often traded on different trading systems and there may be a jurisdictional split around where those products can be traded; for example, you might be able to trade metals on the London booking entity of a particular bank, but the French entity doesn’t trade in metals, and vice versa with derivatives. This process maybe about to become even more complicated for European entities under proposed CRD VI rules.

Trading Systems

As mentioned above, not all derivatives or jurisdictions use the same trading systems.

There’s usually a ‘few-to-many’ relationships between the products and the trading systems. Some systems can trade multiple products and some products can be traded on multiple systems, depending on the location of the system and what it’s been approved to do in a particular jurisdiction.

There are also corresponding settlement systems which aren’t always the same. The mapping from products to trading system, to settlement system isn’t always linear; it is often fragmented and varies between banks and jurisdictions.

iMeta has experience in helping large firms automate account and SSI flows, automating the mapping from product to system. In the industry overall however, with other vendor implementations this is often left out of the CLM scope, inhibiting the creation of a truly end-to-end flow.

Entity Types

The other aspect is complex entity types, such as funds and funds-of-funds. As people invest in a particular fund, behind the scenes, that fund could be reinvested into multiples of these products that are serviced in different locations, by different teams, that must adhere to different regulations.

Legal

Capital markets often has bespoke, documented contract formats, and nobody in the CLM world has really tackled this due to two main reasons:

1. Legal teams are often detached from the wider process and are resistant to technology, structure, support, or accountability around it.
2. The process tends to be arduous and lengthy, with the legal agreements often taking the longest, not the KYC as most people suspect.

iMeta's legal survey showed that KYC is 50% of the problem and legal/credit is the other 50%, with legal being the biggest culprit within that.

In a recent re-design of a process for managing the legal process within CLM, it was rejected by at least one legal team. The re-design provided a prompt for action with an on/off switch to show it’s with the legal team. The rejection highlighted a lack of desire for accountability.

Part 2: Where are the gaps in many of the tech solutions in the market?

The ambition of CLM has shrunk significantly from the vision of the market 12, 13 years ago, which was that, essentially, there is one overarching tool to rule them all. Well, that was the view at the time. The idea was that it would orchestrate everything that needed to be done, to not only get the client onboarded to the bank, but to get the client what they wanted at the end of their journey.

CLM has been shrunk down to pretty much just KYC and client onboarding, excluding credit, legal and ops, which are all functionally required to get the customer ready to trade.

As a result, they encounter this incredibly manual process where they’re engaging with 14 different teams still using forms and emails. Systems are very unsophisticated and getting the account set up is a long, arduous process. The bank can have an amazing SLA that says we get our customers onboarded in five days, but their clients don’t feel onboarded. They may have been be onboarded but their products haven’t. They’re still going through the machinations of getting an account and being able to trade.

What if the client wants to change a settlement structure, for example? How does the bank go about doing that? Do they use the same system they used to request a new account? If the client has asked for relatively vanilla products, such as equities or fixed income, the bank can get those products set up quicker than a credit default swap with a tied credit line.

This type of complexity has been avoided by most CLM vendors due to its challenging nature and the lack of flexibility and configurability of their technology. Often, changes take months and come with additional ongoing maintenance and development costs. What it means is they do the standard bit, customer fulfilment, and the more complicated product fulfilment is left within the structure of the bank’s existing operations.

iMeta’s approach is very different. The highly configurable technology enables changes that most banks would consider complex or difficult to be implemented in just a matter of days, and without additional maintenance or development costs to the bank. Where most CLM vendors are solely focused on the customer onboarding journey, iMeta enables every journey.

There’s often not a lot of automation in this space. In general, there’s now just a lot of very well organised operations teams who had their arms twisted to be more efficient at taking a product description and a set of client data, then mapping it to the right locations in the required systems. They’d use a market mapping matrix that defines the product and jurisdiction. If it’s in this booking entity for this product, this is the system that it goes to, and this is the system reference number.

If there’s four legs to the CLM table – KYC, Credit, Legal and Ops – it’s missing the last three of them. Even in KYC, we’re hearing that’s full of woodworm because it’s not doing the cross-jurisdictional piece very well. Most CLM stories stop, to an extent, once the major three or four jurisdictions are put into CLM. The smaller jurisdictions don’t get brought in and so some of them are exotic products that are only available in certain jurisdictions and never part of that CLM story that’s in place.

Each of the ‘table legs’ comes with their own complexity. With credit, for example, there are already credit approval systems in place in banks. CLM is very unlikely to replace those, apart from one or two players in the market who have been able to straddle the gap with credit approval flows. In an ideal world, CLM gives visibility into those credit approval flows, so you know exactly where it is in the process e.g. 90% complete. Realistically, however, no bank wants to rip out their existing credit approval process and system and replace it with something much lighter on credit functionality. So, the question becomes: how does the CLM tool orchestrate with an outside credit approval system?

The credit approval system connects to the limit monitoring systems, but CLM isn’t so interested in that limit approval system. It’s only interested in the approval flow and when that gets done.

If somebody at the front end of the process selects a derivative product with a tied credit line, the information they need for that credit line is the duration of the limit and the proposed pricing around the limit. They will then get credit reference ID that allows them to go and see the total credit profile for that parent company, if they’re an existing client.

Credit hierarchies were never put into CLM tools, so what’s left is an initiation request through the CLM system that transposes that information into their credit approval journey and Credit provides periodic updates to the CLM tool about progress on that credit limit. That is often a heavily manual process, but in the modern world of APIs, it shouldn’t be a huge problem to have credit approval flow updates on demand. A simple notification that says: “This credit limit is arriving at final approval,” which names the person approving, will provide visibility and allow it to be chased.

CLM won’t compete with existing credit tools. They should just plug in and listen.

The key objective is to get KYC/Compliance, Credit, Legal, and operations all focused on delivering a single goal for the customer. The reason this is failing today is because not everybody is working to the same process with the same goal.

Part 3: What are the common pitfalls and blockers to getting it right?

Policy

Financial institutions still get stuck with successfully implementing CLM in CIB. Why? Nobody’s really delivered on the original dream. The truth is that global policy alignment i.e., 90% harmonisation of policy across all jurisdictions, in addition to the obvious complexity of orchestrating across regions, is rarely achieved. It actually ends up being closer to 70% harmonised, with some regions acting entirely in their own interests with their own specificity. In our experience of global minimum standards, which is where you get to ideally 80% or 90% consistency, it has taken the banks that have done it more than three years.

If you don’t align on policy first, what you’ll see in CLM implementations is that you’ll get to two or three main locations and you’ll get into quicksand. You won’t be able to expand out beyond those core locations, which in the main, comes down to internal politics. So, you need to consider how to get the other countries to align and ask whether you’ve really thought about how much effort goes into policy alignment. Then, even if you can harmonise policy, you can’t always harmonise product. You certainly can’t always harmonise back-office systems.

The other option would be to manage multiple different risk models in your CLM, and ideally, you’d need the system to tell you how much of that risk model is shared data-wise. The system could probably make better sense of this than a human by identifying, for example, that 39 of 40 requirements are ticked for this location and 28 of 40 requirements are ticked for this one. This would take the pain away from trying to harmonise policy as the system determines what the gaps are instead. The challenge there, however, is that if you’ve got 10 risk models and a policy change comes in, that’s 10 places you need to change it. Broadly speaking, it’s a no brainer for banks to harmonise policy wherever they possibly can because it makes everything easier. It’s not just the tech build out, it’s policy drafting, it’s reduction in compliance effort, and you can centralise periodic reviews in one location, on behalf of all locations.

Internal Politics

Of course, centralisation itself is also hard. Even if you sort out the technology, that doesn’t necessarily mean you can centralise all your KYC teams, who are all currently working from different, localised procedures and policies. Ops leaders, however, are always looking to create synergies and flatten out variation. A Tier 1 bank might centralise the top five to eight locations, and the other locations are kept as tiny satellites with almost entirely bespoke procedures, because they’ve got bespoke policies, systems, and compliance needs. You also encounter resistance, where the regions reject the global KYC project and say, “We’re going to do our own thing.” People end up going cap in hand to every region, trying to get money to sponsor global projects that they don’t really want, so there’s often a political stall.

There are multiple actors on both the client side and the bank side, which adds to a need to plug in more areas in the CIB space than you do in pretty much any other area of the bank. How do you engage with all the functions, potentially in multiple locations? It’s a spider web of complex cross-border onboarding in CIB where there’s maybe three teams or personas involved on the client side and probably five people on the bank side in each location.

Legacy Systems and Processes

Another blocker is that disconnect between a client onboarding in CLM and a product onboard. Often, if the client gets onboarded, everyone pats themselves on the back. However, the client doesn’t feel onboarded because they don’t have what they’ve asked for. The process to that point has only been a cost for them. They’ve gathered all the required documents, answered questions, done a second wave of documents, and they still can’t trade because product set up isn’t complete. This is due to a disconnect between back-end systems and legacy product systems, which are stickier and much harder to change. It requires more creative workarounds that harmonises interactions between the two.

For example, iMeta built a unified account SSI view that created that harmonisation by building the variation for the products that are needed, so it all became one process. iMeta’s ability to wrap around legacy systems’ complexity with a translation layer enables the smooth passage of information from CLM through to product systems via a consistent entry point.

The whole design construct that people are thinking about from a very process-centric view of the world effectively ends up with you building or thinking about a specific set of journeys to solve a problem. Whether that’s specific to a jurisdiction or a product in a jurisdiction and you end up with layers upon layers of process-centric journeys built around a multitude of capital markets products, jurisdictions, and the associated variability they bring. This means you end up with tons of forms and journeys, all of which need disambiguating when you try and push any change through.

Part 4: What does good look like and has anyone got there yet?

Portions of CLM have been done well in different banks and some have had success. Where we’ve seen the most success is where organisations have taken a thinner slice of the pie. The big, multi-service or full-service banks are all thinking microservices, where CLM tools are assigned to orchestration of KYC activity and are seen as the glue that joins everything together. Specific systems are lined up to specific components, such as the risk rating engine, the BPM layer, or the Entity Reference Data solution, and it’s very ring-fenced. However, it is a very different story when you’re in smaller CIBs that don’t have other banking divisions. They want an out-of-the-box, end-to-end solution, as many of the big banks did five to eight years ago. Middle of the market fund managers, fund administrators, and some of the smaller players are more attracted to the idea that within one package you’ve got a solution to a whole bunch of problems.

Automation

Automation is essential because the customer expectations if you start a digital journey are that it’s going to be fast. If you don’t have the back end to do that, it falls out into a queue of people in operations that manually process the payment. The client thinks it’s real time, but the bank knows it isn’t, and it very quickly doesn’t feel like a digital process to the customer.

A couple of years ago someone from a Tier 1 bank at an onboarding event pitched this beautiful website they’d built as their front end for customers. It’s all online, looks dynamic and then someone asks: “How long does it take to get an account open?” and the response was, “Oh, it’s two weeks.” That’s because it’s going into an operational mess at the end, which sadly is remarkably common.

Unfortunately, full STP is still a nice to have. One of the challenges is that there’s still a desire from regulators and compliance people in banks to be able to say that a human has looked at something. There’s an arms race that’s going on. If you introduce a bunch of automated thresholds, people will find them out and someone in the bank will leak it to one of their slightly more corrupt mates. Suddenly, you’re getting requests for three accounts that all passed just under the threshold of being anomalies being picked up. People are constantly trying to game the system with synthetic identities.

A lot of the things that humans do in the process are a set of checks, which have often been driven by individual events or breaches. There’s often a procedure called a ‘make sense check’ that is an exact reaction to a particular instance of a breach, for example: “a 21-year-old with three million to invest”. They’ve got a note on this to check whether that seems rational that somebody of that age should be able to invest this much money. My question is always, if you’ve done the relevant checks and got proof of funds, does it change your decision? There’s plenty of 21-year-olds in the world now who have enough money to invest in businesses. You only need to look at the YouTube generation and the TikTokers. All these people are making enough money that half of them have set up food and drinks companies.

The flip side of not being able to say a human looked at this is that the system will always consistently perform all the checks, whereas humans won’t. Having sat with people while they were doing makes sense checks, there was no consistency of application.

Across the team of 20 people processing the applications, one person would look for 10 things and the next person would look at 10 other things. You trade off the ability to say a human has looked at it with the ability to say we’ve enforced a hundred percent of these checks 100% of the time through full automation.

Automation ultimately becomes a purely risk-based decision, and not subjective. You can also prove that you’ve done the process that a human may or may not do and it’s recorded in the system with an audit trail.

At the end of the day, if information from the client is wrong, a human is no more likely to pick that up. Some banks have got around this human touch point by just having ID&V verified by humans so that you can tick a box and say we’ve checked, even if they’re not actually doing the heavy checks.

However, automation can of course become problematic if it’s not used or implemented in the right way. Banks need to be willing to change their existing processes and procedures rather than overlaying automation onto already broken processes.

Harmonisation

Success or failure comes down to three main things: variation (in customer type, product type, jurisdictional policy, and systems), internal politics, and expectation management.

Trying to merge all that variation into one platform can undo everything because every point of every type of variation has its own complexity, its own set of stakeholders, its own set of politics, which creates that spider’s web mentioned earlier. Rather than replicating the spider’s web, organisations need to build a much simpler web of fewer points. Harmonising and flattening out that variation early makes sense because otherwise you end up with long lead times that keep getting extended due to poor expectation management.

If technology can provide the wrapper around product legacy systems, it means the bank’s operations people can focus on policy and process harmonisation, which they at least understand.

Aurora often finds that many organisations aren’t ready for technology. They haven’t worked out their desired end state, or even their current state. It’s a hiding to nothing for technology and how people perceive it if the vendor has six months to implement something that hasn’t already been mapped out. Conducting a rapid current state assessment up front helps identify potential pitfalls early and areas that need addressing first. Then, mapping out your target state sets a clear vision and set of requirements when talking to technology vendors. As well as saving time and money later, this will accelerate conversations with solution providers and ensure alignment to the most appropriate vendor.

Expectation Management

If you say to an operations person that it’s going to take three years to transition, that’s quite comforting to them. Tell them it’s a six-month transition and they’ll be terrified. Whereas, if you say to senior sponsors that it will take six months, they will very quickly start to ask what’s taking so long. They want to know whether the timeframes are still on and whether they can tell their boss that it’s all done and dusted.

In a bank, it’s common to have two to three months to re-engineer a single process. CLM comes in and tries to re-engineer five at once in every jurisdiction in the world. It’s not a reasonable expectation to be able to re-engineer at that pace and work out all the handoffs, interactions, new roles, and everything else that comes with that scale of change. So, expectation management and realistic timeframe setting are also key.

Part 5: iMeta's solution for complex business environments

iMeta’s approach has been to define a fully featured “out of the box” configuration which comes pre-loaded with all the things you would expect from your CLM system to cope with the complex nature of the wholesale/Capital Markets business environment:

• Onboarding workflows – including full CDD, EDD, regulatory & tax classification, screening, waivers, Q/A and business acceptance.
• Periodic review workflow
  
• Data maintenance workflow
  
• Offboarding workflow
  
• Management information & reporting
  
• “OOTB” Vendor data connections
  
• Ongoing regulatory update service

In addition to a number of functional capabilities that come from taking a data driven approach to CLM that is highly focused on delivering automation:

• 360 client view with full data re-use across balance sheet/jurisdiction and product
• Full STP of new/additional product onboarding
  
• Perpetual/trigger driven reviews (pKYC):
• Screening reviews
• Material changes
• STP of non-material changes

Delivering this fully featured and working product on day one allows iMeta to perform a gap analysis with their customers and quickly identify the changes that need to be made to make it fit their needs. iMeta can make these changes quickly and iteratively to have a live production deployment within 3-6 months. Furthermore, the unique data-driven, low-code architecture does not penalise iMeta’s ability to make the appropriate changes to cope with differences in operating model and business / regulatory rules; so the platform can be rapidly extended to accommodate new jurisdictions.

Part 6: In summary: don't boil the ocean

We’ve seen success where organisations have been somewhat realistic and pragmatic by focusing on getting it right for a specific customer segment in a few core jurisdictions and with a tight functional scope, before extending outwards. They then realise the benefits in the areas they’ve really homed in on rather than forcing change on people who haven’t yet bought in and where the analysis hasn’t been done.

If anyone was to get it right, an aspirational vision may include:

• Standardised policies with minimal regional uplifts
• Most KYC and due diligence tasks are automated, and it’s pKYC ready
  
• A single global orchestration tool to support activity in most locations
  
• Processes are optimised and / or automated
  
• Organisational structure focused on only those activities requiring human intervention
  
• Centralised teams operate on a ‘follow the sun’ model to maximise efficiency in customer support
  
• Centrally managed data and ‘trigger events’ are well handled
  
• Maximal use of data provision, aggregation, and reuse
  
• A fully integrated technology landscape, with CLM and RegTech solutions across all regions
  
• Best-in-class customer experience, with a fast and digital journey
  
• Minimal document and data requests
  
• Self-service portal in place
  
• All CLM journeys from onboarding to offboarding provide detailed status updates and communicate expectations

However, rather than trying to get there all at once, organisations need to recognise there are steps along the way. Milestones are not just an endpoint. The truth is that an organisation’s ability to roll out successfully in capital markets is going to be driven by their maturity in harmonising its complexities, selecting technology that enables that harmonisation, and collaboratively mapping their journey towards a future vision.

This article was written in collaboration with iMeta Technologies Ltd.