Treasury and Capital Market Solution: Which one?
During my 32+ years of designing, developing, selling, and now buying TCM solutions for banks and other financial institutions, I have often been asked this question: "What is the most efficient way to select a cross-assets front-to-back solution? a full treasury solution".
To justify the selection, banks will pay the big consulting firms outrageous fees to get an answer!
The answer is simple and does not need much spending to have it right.
In the world of Capital Market Cross-Assets Front-To-Back (XA-FTB) solutions, you have five players claiming to serve this front, the 'The Usual Suspects'.
Among these five major players, only two are truly built from the ground as XA-FTB. One vendor acquired multiple best of breeds solutions and created an umbrella to cover the plumbing behind the scene, and the rest kept their best of breeds acquisitions scattered all over the places.
And if you look at a Capital Market Cross-Assets Front-To-Confirmation (XA-FTC), the list gets a bit longer (maybe you can add three additional players).
Of course, you have a multitude of other players serving different niches but not a full XA-FTB or XA-FTC.
This article is about XA-FTB selection and negotiation tips to help institutions optimize their process and reduce their cost and time-to-market during the selection.
Honestly, 90% of the time, the following three vendors make the final list: Murex, Calypso, and Finastra (sometimes ION with Open-Link if the bank is small or commodity is the driver).
So, save your time, and start reaching out to these 3 with an RFP.
Before moving to the RFP and demos tips, you need to make sure when you are approaching 'The Usual Suspects' that you have an excellent budget, the skillset to run such a system, and patience to implement one.
Now, tips for the RFP:
The critical point is that this process is not a contest for who can fill in more pages and show off that he/she knows the latest jargon and functionalities to impress the management and justify hefty fees. Lengthy RFP is a waste of money and time for both the banks and vendors. Only the consulting firm gains from it.
The RFP should point out the problems and how you would like them to be solved. It should be a roadmap for the implementation (and developments, if any) team. FOCUS is the keyword. Now, I understand that management needs to cover their back, hence the lengthy RFP that lists every bits and piece where vendors have to prove they have it.
You have to trust that these big boys ('The Usual Suspects') know their business, and they cover 90% of your needs, if not more, or else they won't be in this game for so long.
So, the management has to be smart and FOCUS on the problem and solution. The big boys know how to deal with the rest.
Tips for demos:
One global demo per vendor that gives you an idea of the company, vision, system coverage, usability, describes the implementation process for all the management and future users (2 to 3 hours max).
Another demo for a smaller audience on how to tackle the problems you have in more detail.
Select the top two vendors with whom you feel understood, and you are at ease.
Moving to the workshops:
Avoid asking an unreasonable amount of data and configuration to be tested so that you or your management is comfortable (this is not the implementation, trust the vendor).
Keep the workshops short and straightforward (2 half days per vendor should be enough to convince you they have a solution).
Please do not use the workshop to test the whole system; the system works; trust the big boys.
Do not go beyond a couple of days; if it happens, it means something is wrong.
Select the preferred vendor and start the contract negotiation; keep the one in second place as a backup.
Tips for contract negotiations:
Do not:
Push for the lowest price by playing vendors against each other. You are not buying an app but a comprehensive enterprise solution. If the vendor is pushed too far and accepts, run away because, for sure, it will make you pay the difference in the future. Instead of pressuring too much on the price, check the 'Do' list below, you will gain more.
Impose the RFP as part of the contract (if the vendor accepts, run away).
Try to pay the subscription fee only at the 'go live' date (I am not yet using the solution, why should I pay?), make a reasonable scheduled payment.
Impose penalties if the vendor does not solve a bug on time. Bugs are inevitable, and no vendors like a 'Damocles Sword' hanging on its head to solve a bug. These are the big boys, remember, they have a track record in serving clients.
Send your contract to an external law firm. They will red line everything because they think they are making the smart approach. The vendor will reject your redlines, and you will end up spending too many back and forth and outrageous fees on getting at the end to a reasonable situation. Hire someone who knows these contracts and tell you what you can discuss and what you can reject from the start. You will reach a reasonable state much faster and much cheaper.
Do:
Have a C level contact from the vendor's side. Do not limit your negotiations with only the salespeople.
Get a good SLA process that gives you comfort. Vendors will start with a standard weak SLA, but all have a more advanced one hidden. Take this one.
Ask for roadmap sharing and being able to get your voice heard. The roadmap should be about vision, not just features/functions, and covers two years, at least.
Make sure they take care of your reasonable enhancement requests.
Get the right initial training for free for your support team.
Get a fair number of men days of Professional Services for free to be used at your request.
Include a yearly health check for free.
Set the upgrade period to 3 or 4 years, at least and not less. You do not want to start using the system and find out that you need to upgrade to the newer version by contract.
A contract should not take more than one to two weeks to negotiate; these are relatively standard. The vendor, in general, is quite open to changes, but keep them reasonable.
I do not recall a bank suing a vendor in this business or vice versa.
So do not worry.
Next time we will talk about implementation tips.
