Can your system do this?

In July 2020 I joined a small Fintech to head the Asia region for the firm. I received many kind comments and good wishes from friends and ex-colleagues – a very humbling experience. But a common question that I was asked, bearing in mind my near 40 years in the industry, was: “What attracted you to this particular firm”?

So, I have been reflecting on this. Over my career, I have bought and/or implemented many investment management or financial services systems on behalf of my employers or customers; some have proven to be excellent choices for specific or narrow use-cases, while others have frankly been a disaster (and you know who you are). In the case of the ‘disasters’, it’s nearly always been a mismatch between client expectations set throughout the sales process, versus the functional reality of the system when it was being implemented. In my experience, the amount of effort put into constructing a ‘sharp and pointed’ RFP, together with a ‘Test and Verify’ approach, is an important predictor of the eventual outcome. Of course, there are always situations where a buying decision is made due to reciprocity or some other criteria unrelated to the functional performance of the proposed system, but those decisions almost never work out well for the people required to implement and operate that system!

By way of illustration, a few years ago I started an RFP search for an Investment Accounting platform with a specific emphasis on these core requirements, over and above the usual baseline functionality for such systems:

•     Cloud-native with zero local footprint and remote installation/training; cloud provider agnostic.

•     No ‘end of day’ processes that would impact/limit a client’s 24*7 transaction read/write access.

•     Crypto-capable including lot based records and interfaces supporting the maximum required decimal places for digital assets.

•     Unicode/multi-lingual throughout, especially for languages based on logogram characters (e.g. Kanji, Chinese).

•     Comprehensive and customizable data/reporting capability available through an online portal.

I sent an RFP around to a dozen firms in total – mostly well-known players, with the above specific passing criteria spelled out. Shortly afterwards I started to realize how difficult this specific ‘ask’ would be. By the end of the first round of response/reviews, five had pulled out mostly due to not being able to deliver on all or a combination of these three core requirements:

(i)            System was not ‘cloud-native’/did not have zero local footprint.

(ii)           System couldn’t handle the requirements for crypto and certain other alternative asset classes.

(iii)          System couldn’t handle Unicode/multi-lingual end-to-end from static data to reporting.

“I sent a very specific RFP to a dozen firms – a mix of vendors selling investment accounting platforms. Five immediately declined to respond due to ‘functional gaps’.”

On close inspection, three more firms couldn’t meet one or more of the core requirements fully, and several more struggled with providing a true multi-currency base; after all, not everyone wants US dollars as their base currency… The simple question: “Can your system do this?” became a follow-up of: “Can your system really do this? Please show me”. Let’s be clear: Holding Ethereum in a portfolio valuation as a ‘Held Elsewhere Asset’, clearly doesn’t tick the box, despite the best efforts of that sales team.

After the first round of eliminations, I was left with two firms on the short-list. Unfortunately, the Covid pandemic hit, and this specific project was postponed for business reasons, but one firm – who I joined 18 months later – impressed me with their modern technology as well as their integrity and commitment, together with their clarity when a particular function was not immediately available, or was in development.

While a comprehensive RFI/RFP is always a great place to start, it needs to be written with very specific pre-qualification hurdles, which frankly will save all of the participants a great deal of time. After that, a comprehensive ‘Test and Verify’ step is vital.  Having been on the receiving end of many, many RFPs of hundreds of pages, I can say that I had wished those requests were explicit in detailing the minimum acceptable requirements. RFPs that permit responses such as “Fully/Partially/Not Available” just prolong the agony for technology and service vendors that could otherwise be quickly eliminated. It seems to me that most good sales teams can manage to finagle a response of ‘Partially’ to just about anything…

Overall, the lesson I learned from this exercise – as well as many previous forays into the world of RFPs – was that while the attractive brochures and websites promise a lot, the reality is that there are still tremendous differences in the functionality and cost of ownership, even though each vendor seems to claim to provide everything that your business may need.

So thank you to everyone for your good wishes and I hope that explains what has attracted me to working with a small Fintech company. So pease remember to make your RFPs ‘Sharp and Pointed’ with clear pass/fail criteria for your ‘must haves’, followed by a comprehensive ‘Test and Verify’ process. The question: “Can your System do this?” needs to be based on a precise and comprehensive RFP survey with clear hurdle criteria. At the very least, it would save a lot of trees…