X-asset Front to Back solution, what a nightmare to implement!

I was asked to re-publish my article on implementation of a Cross-Asset Front-to-back solution for Capital Markets & Treasury in the wake of new technology advancements like micro-services and cloud. And to initiate a discussion if these large enterprise solutions will remain attractive in the future. Here it is :-). I will follow up in the next week's post with an opinion on these solutions.

What is the common denominator among the largest providers of Capital Market technology for a cross asset front-to-back solution?

The disastrous cost of an implementation

Who has not experienced, beside missing deadlines and going beyond budget, at least one of the following during such an implementation:

• Delayed promised developments

• Bad quality of software. Some clients feel they are doing the quality assurance on behalf of the vendor and paying for it!!

• Changing allocated Professional Service resources in the middle of the project

• Introducing last minute change controls with additional costs, the famous “that was not part of the deal”

But is all the blame on the vendor? The clients share part of the responsibility:

• Bad data quality from legacy systems

• Introducing other systems implementation in parallel

• Users stuck in their old ways of doing things

There are some success stories of course, and vendors will showcase them and convince the client that its implementation will be as successful. However, once you look into the so called success story, you find out that to succeed, the scope was dramatically reduced. Still the client would say it was a great success as jobs & reputations are on the line…

I am not talking about deploying solutions for complex products used by large banks, let us keep the large tier 1 and tier 2 banks aside. I am talking about the plain vanilla business in Capital Markets and Treasuries used by regional and local banks. Large software vendors have deployed solutions in this market for many years and claim that they have experience in boxing the cost and risk.

Yet, until proven otherwise, rare is the X-Asset FTB implementation that respects the timeline and budget.

Why is that?

Often enough, the implementation team:

• Starts the project with the disastrous question: “What do you want?”, opening the gates for all type of requests

• Tries to replicate what the institution used to do, without debating the necessity

• Does not understand the final Target Operating Model from the beginning

Implementation is not a “democratic” process. It needs a strong project manager that knows what to do and makes “autocratic smart” decisions.

So how can we avoid total frustration while deploying an enterprise X-Asset Front-to-Back solution?

Banks run similar operations and processes. Some differences arise because of volume, localization, integrations, and IP related functions (like analytics, pricing, risk…).

We can avoid the frustration and rough road of an implementation by approaching the subject with a Standard Operating Model.

How to make this happen?

The Standard Operating Model should be the core of the implementation.

The SOM is not just a configuration of the vendor’s product. It is:

• A description of how functions interact with each other [Trading, Risk, Collateral, Clearing, Funding, Operations, Treasury, Finance…]

• A description of how to use the solution [what type of reports to focus on, what type of exceptions to handle, how to pass information to other departments…]

• A complete documentation detailing the processes for auditors and regulators

• A complete lists of what to do and not to forget

• And finally, a complete vendor’s solution configured following the SOM

In fact, the SOM should be the starting and the ending point of an implementation and mostly independent from a vendor’s product.

A new approach to the implementation would involve:

• Walking the client through the SOM

• Adapting the initial scoping session in order to determine the differences between the client's operations and the SOM

• Understanding these differences:

- Have we missed mandatory processes in the SOM? => adapt the SOM (SOM is not set in stone; it evolves)

- Are these differences needed because of integration? => move it to customization (not part of SOM)

- Are they part of Market Localization? => adapt the SOM to this market

• Using the SOM immediately after the scoping to start educating all users about the solution

Implementation becomes an onboarding and integration exercise. And not a nightmare to go through.

The value added of the SOM goes beyond the implementation, it allows:

• Easier maintenance and upgrade (lower TCO)

• To satisfy the auditors (regulatory compliance)

• To deploy a business function faster (better time to market)

• To provide training for new users

• To move into the cloud and mutualize the cost (much lower TCO)

So who provides such a Standard Operating Model?

The answer is simply NO ONE as of today. Attempts have been made, but unfortunately it starts well and ends up more in good literature and marketing material. Why is that?

• No real belief in standardization. It is just used as hype to sell more

• No determination to take the standard till the end. It is just used as a starting point for configuration

Can it be done?

Of course it can. I am not claiming the SOM will standardize everything, but there is a lot that can be done and we should work on it, especially in post-trade operations.

I strongly believe it is time to do it and stop paying excessive fees to deploy & maintain a solution. It is time to start building this SOM.

Food for thought:

I asked myself this question lately:

"Is ONE X-Assets / FTB enterprise solution still good in the wake of new developments like micro-services on the cloud ,despite the cost in implementation, upgrade, support and long time to market."

I will tackle this in a new post soon, but welcome your opinion.