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.