- The explosion in supply of Financial Technology has not correlated with an increase in success or ease of application implementations. Even the considerable acquisition and corporate activity across FinTechs does not simplify things; rather, it means a single vendor may be providing a suite of solutions without a common history that were not built to sit alongside one another.
- A strong partnership approach between vendors and suppliers is essential, with positive experiences typically sharing one common factor: upfront investment in time and resource to understand, in detail, the client’s processes and functional usage of the system and an appreciation of the vendor’s data and implementation requirements.
- Understanding one’s own USPs is critical in identifying the type of FinTech software, where many agreed that a premium or more resource-intensive solution (built or customised) can pay dividends versus relatively standardised parts of the business that simply need to work.
- The availability of well synergised software applications is limited and a demand for a “Capsule Wardrobe” of applications is high: a smaller range of interchangeable modules to allow multiple combinations for different firms and usages. Given that modular solutions and open APIs are becoming more prevalent, this may be a future trend.
Key challenges
- A significant challenge impacting a successful partnership with FinTechs was the commitment required to invest upfront in preparatory work. The FinTech vendor must understand the client’s requirements but equally, the client should appreciate the vendor’s requirements. This work should also include appraising the full capabilities of the software, functionality and data usage for the specific application and understanding how the application will sit within the current technology architecture.
- This may be a challenge for sponsors, with little progress visibly made but money and resource committed to the project. However, the criticality of these foundations resonated, with success stories coming from those who pragmatically managed stakeholders through this upfront investment period, achieved greater implementation results.
- A second challenge was the difficulty of actually selecting the right system for any given purpose. Many had seen isolated, compelling capabilities within systems only to find – perhaps too late – that the full application had critical gaps or was otherwise ill-suited for the client.
- One way of dealing with this was to, as above, spend longer detailing one’s requirements upfront and testing the relationship and commitment of the software partner / adviser to ensure they are a party who will work for the client. This creates a full understanding of the solution before embarking on implementation and generally is rewarded later on. The result is that clients either avoid unsuitable systems before it is too late, or knowingly compromise on certain functionality, allowing management of users’ expectations.
- The idea of ‘legacy’ challenges comes from two points of view. Outside of start-up clients, few if any firms are fortunate enough to avoid the complicating factors of a previous, sub-optimal technology footprint. These often result in arduous and inefficient manual processes which new technologies are frequently forced to recreate, even disabling the core, compelling components of new technology. This can only be fully avoided with a full front-to-back systems review and rationalisation which comes at a cost.
- Equally, FinTechs have their own history given the high number of acquisitions of software and FinTechs firms, meaning any single vendor may have a range of solutions that were never designed to work together: again, potentially compromising full functionality.
- Understanding the history of a vendor, their applications and historical target market becomes a core part of the selection process, particularly if we consider that the first buyers of an application usually have a larger imprint on development focus and configuration than subsequent buyers.
- The way to guarantee an edge and avoid compromise is to build the software oneself. However there are two important considerations:
First, the projects are not always successful and require significant investment from clients through money and (often expensive) FTE resource to share the nuances of the firm and its processes. Without these, the end result can be extremely lengthy projects to the misfortune of both FinTech and client, the former who has to recoup costs by packaging up the solution and distributing to a wider (potentially ill-suited) group of clients; the latter losing their competitive advantage as a result.
Second, the considerable expense of building technology means that it is only reasonable to do so in order to deliver one’s USPs, typically within the investment lifecycle or client engagement process. The remaining application architecture needs to be efficient but can be relatively commoditised and standardised. This model is widely used and many firms adopt core processing applications with specialised satellites around it to provide competitive differentiation.
Conclusions
- Identify your firm’s USPs and invest in differentiating technology in these areas. Elsewhere, try to buy off-the-shelf while aiming for operational efficiency.
- Try and identify a FinTech with whom you can genuinely partner with: understand their requirements (across data, testing, maintenance, functionality, etc.) in addition to your own and commit fully to preparatory work to maximise the chance of success.
- Manage stakeholders by setting users’ expectations around functionality and any compromises, and ensure sponsors understand the necessity of upfront work – with little demonstrable progress – to achieve the smoothest path to deployment and go-live.
Expert: Kevin Okell and Simon Bussy, Altus Consulting
Facilitator: Paddy Lewis, Sionic Global
