To RFP or not to RFP

IBS has recently come out with its Sales League Tables for the year ended December 2011. The analysis has shown that IT vendors concentrating on the APAC market have moved up significantly.

Deal values in the region have made CIOs and others to sit up and take notice. The Asian banking and finance market has been remarkably hot and has surpassed Europe and Americas.

According to analyst reports, Asia-Pacific had the most activity among the Core Banking deals, covering 44% of the global score. The biggest growth was Central and South-East Asia, climbing from 45 deals to 58 in 2011.

Banks of all tiers and all segments (commercial, co-operative, and others) have been coming out with Request for Proposals (RFPs) and the trend is expected to continue.

RFPs come in myriad forms. I have seen RFPs with one liners such as ‘System should support Derivatives’, ‘System must support Mobile Banking’, and so on, and also ‘detailed RFPs’. The latter is quite less!

An RFP question such as ‘System must be IFRS compliant’ will typically find a response as ‘Yes. The system is IFRS compliant’. How many vendors actually respond as ‘Yes.

The system supports IAS39, IAS 12 and IAS 8 as published by xxx on dd/mm/yy’? Accounting rules and standards are always evolving and no vendor can truly support all. Similarly, for a requirement such as ‘System must support all regulatory requirements’, a vendor’s response of ‘Yes’, should be taken with a pinch of salt as there are zillions of regulations related to security, accounting, reporting, auditing, quality, and other parameters.

One line responses to one line questions, can often cause banks to shortlist a wrong vendor or product.

At the other extreme, there are detailed RFPs that run into hundreds of pages, data, test cases, and so on and then they give vendors two weeks to respond. Sometimes such copious data at an early stage can distract a vendor. Here too bankers and evaluation teams can get misled.

RFPs prepared by consultants are a different ballgame altogether. While they do contain a lot of panache, sometimes the consultants end up inserting so many best-of-breed features that are beyond the scope of the banks’ requirements.

There was a case when a vendor asked queries regarding requriements which the bank felt were not even part of its offering roadmap in mid-term, and as such, should be classified as only ‘nice to have’. The downside with consultant-prepared RFPs and demo scenarios is that sometimes the price quoted by the vendor becomes very high and much time is spent at later stages in dropping requirements and reducing scope.

All this makes me wonder if the RFP route is indeed the right way to select a ‘banking product’. If I were a banker, would I be better off listing out exactly what I am doing today and with what I plan to launch in the next 7 to 10 years?

Would I be better off evaluating products by calling the top three vendors for a demo and make them demonstrate live cases? Would banking product selection be better if it were POC/POV lead rather than RFP lead? Would there be lesser bitter arguments and negotiations during implementation on issues such as “Hey! You said Yes in the RFP”.

And the vendor explaining what he exactly meant by “Yes”. If I hire a consultant, would I rather advise him/her to forget global best practices and focus on my needs? Can banking product vendors not provide a trial version on some cumulonimbus cloud and bankers just evaluate the product there?

These thoughts remind me of those immortal lines in The Satan Bug by Alistair MacLean, “Mankind must abolish war or war will abolish Mankind”. On the same lines, should we say “Banks must abolish  RFPs or RFPs will abolish Banks”? 

Tapan Agarwa, Senior Vice President, Polaris Financial Technology Limited