Let’s step back and look at the client onboarding process itself. Imagine a bank wants to onboard a new client for a specific product—a bond transaction, for example.

Here’s where the problem starts: rather than tailoring the onboarding to the specific transaction, most banks treat onboarding as a standard process, considering the entity first, and then attaching products to it.

For this reason, banks end up asking for a huge amount of information and running checks that may have nothing to do with the transaction the client wants to carry out. From the client’s perspective, it’s time-consuming and frustrating.

In some cases, the entity to be onboarded isn’t even the main player in the transaction—they might be a related party playing a specific or contained role. Yet they’re still being asked for detailed, complex information in order to run exhaustive checks as if they were the main counterparty to the transaction.

This kind of over-complication doesn’t just frustrate clients; it also drains resources internally, as CLM teams spend time chasing down irrelevant details or updating exasperated clients (and salespeople) on progress - or lack of it.

A solution to this problem is to move from an entity-led process towards a targeted product-led onboarding model. Instead of starting with the client’s legal entity and working outward, you start with the transaction the client wants to perform.

This shift is already underway in many banks. The key is to focus on the specific risks connected to the product or transaction. The onboarding process should gather just the right amount of information—what you need to meet your baseline compliance standards, along with any additional details that are specific to that transaction or the role the parties are playing.

This brings us back to the original question: why don’t CLM platforms solve the onboarding problem?

The answer is that the real-world product scenarios are rarely communicated properly to the technical teams implementing the platform. In fact, it’s quite likely no-one in the bank has a full grasp of its product catalogue or the scenarios tied to each transaction.

Without that foundational understanding, the platform can’t possibly digitise onboarding in the right way. Whether you’re using a cutting-edge SaaS platform or an older on-premise system, the challenge remains the same: you can’t automate what you don’t understand. And more importantly, if you don’t understand it, the technology or vendor teams certainly won’t.

The first step in fixing this is for banks to get a grip on their own transaction scenarios. How many different variants of scenario do they have, and which products fit those scenarios?

These can be broken down at the asset class level—say, start with fixed income - and then by each subset of transactions. For each scenario, ask:
•    Who are the key parties involved?
•    What are the flows of information, instructions, and money between them?
•    Where do the risks lie?
•    What are the dependencies?

For a more detailed summary of the questions to ask, refer to our checklist via the link here:

Once you have a handle on these details, you can start mapping out the business scenarios that should be automated by your CLM platform. This in turn will allow the technical teams to design the right technical scenarios.

The risks in each scenario will vary depending on the transaction. For example, if you’re trading shares in a simple transaction with all parties regulated and in the same jurisdiction, the primary risk might be ensuring proper AML (Anti-Money Laundering) checks are in place, with only baseline level checks being conducted for sanctions and Anti-Bribery and Corruption (ABC).

But as the transaction becomes more complex—perhaps involving foreign entities or additional advisers—it would likely be advisable to consider more involved sanctions, ABC risks, and so on. The complexity of the onboarding process will reflect the complexity of the transaction.

If you’re a CLM Product Owner, and your organisation is about to embark on a platform implementation, this is the stage you can’t afford to skip. People often assume that someone else on the team will capture this information, or that it’s already documented somewhere in the bank. But in most cases, it hasn’t been.

In large, complex banks, it’s unrealistic to expect that you’ll be able to map out all of your transactions in one go. The best approach is to start small and work through the process in bite-sized chunks. Focus on one asset class or product line, and document the scenarios as thoroughly as possible.

And don’t assume this process will ever be truly finished. By the time you’ve completed one phase, regulations will have changed, products will have evolved, and new risks will have emerged. It’s an ongoing task, but that’s the reality of the business.

Ultimately, the key to a successful CLM platform implementation is to automate the right thing. That starts with understanding the processes and scenarios that apply to each transaction. By defining your business scenarios upfront, you can be sure of giving your technical teams the guidance they need to create the right automation.

And that’s how you’ll avoid the pitfalls that have tripped up so many other CLM platform implementations.