Ever wondered why there are so many hurdles for platform integrations? Robin Bevan, CEO of Sprint Enterprise, explains why platform integration problems are so common.
The current state of play
The sharing of data between investment platforms and software systems is both essential and difficult. A typical intermediary with five advisers will operate 2-3 platforms and 3-4 software systems to manage their client’s investments – all these software systems (financial planning tools, reporting applications, portals, back-offices etc.) need data that is created on the platforms (valuations, transactions etc.) to function – without platform data they just don’t work. And without integration in place, it’s down to the intermediary to re-key data from platform to software system – but should intermediaries be doing this in the 21st century?
The problem is aggravated by two factors. First is the number of integrations required to connect all platforms with all software systems. With 30+ platforms and 100+ software systems, the number of point-to-point integrations required to bring about a fully integrated environment runs into the thousands. All these connections have to be put in place, maintained, and support provided – an enormous drain on an industry running on wafer-thin margins.
Second, the complexity of these integrations is getting so much greater. Gone are the days where valuations are the ‘currency’ for these integrations – software systems increasingly need transaction-level data to power their applications. Financial planning tools need inflows and outflows; reporting applications need transactions to calculate true investment performance and/or Mifid II fee reports, and portals need to show cash statements. The problem with transaction data is that it’s infinitely more complex as today’s valuation needs to reconcile with the sum of the transactions.
A simple fix?
But wait a minute. Surely all that’s required is for each platform to build a great API and allow software systems to access the data they need? Wouldn’t that fix the problem? The short answer is no, and for five good reasons.
First, while this may make sense for the platforms, it doesn’t help the software systems. Each software system would still need to build an interface to 30+ platform APIs all of which would make data available in a slightly different way. That places a significant burden on the 100+ software systems, both to build the integrations and to interpret data across multiple formats. Plus it creates a real barrier to entry for new software systems to enter the market.
Second, for many platforms, particularly those built 10+ years ago, their underlying technology didn’t anticipate the need to integrate with third-party software solutions. Some platforms struggle to generate the daily bulk data files that software solutions now require. Overlaying a new API on architecture that struggles to generate the core data isn’t going to work.
Third, making data available is only part of the solution. Making platform data readily usable for software solutions is equally important but more of a challenge. More often than not, platform data requires a lot of ‘heavy lifting’ before the data is ‘safe’ for software systems to use. The data often needs enriching (eg, adding additional ‘flags’ to identify inflows and outflows), interpreting, reconciling and checking for gaps and backdated changes (they do happen) before it can be relied upon. It may surprise many that raw data that doesn’t make sense without special processing is made available by platforms, but it’s true, and can leave everyone in the supply chain at risk.
Fourth, software systems have a wide range of requirements for data, depending on the nature of their application. Some software systems want daily bulk files; others prefer packets of data delivered ‘on demand’. Some need a full feed of all transactions; others only need inflows and outflows, and so forth. It’s highly unlikely that platforms could develop a consistent set of APIs that provide the level of data flexibility that all software solutions require.
Last, the larger software systems like Intelliflo and Xplan have their own APIs so new platforms will need to ‘deliver’ data in their format or commission them to write a bespoke integration. Like it or not, platforms are going to have to play to Intelliflo or Xplan’s tune on this.
A better way
So the approach of platforms building great APIs doesn’t look like the answer. Arguably, hub propositions [for disclosure, Sprint (Finio) has articulated one, as has Origo] look to be a much better route, whereby each platform and software system builds one connection to a hub, which in turn makes data available to software systems. However, the hubs DO need to take on the heavy lifting to ensure the data fully reconciles and is ready for the software systems to safely use. If not, it’s ‘unreconciled data in/unreconciled data out’ and the burden of the heavy lifting will fall to the software systems themselves.
Assuming the industry does crack this nut of integration between platforms and software systems, then where does it leave the industry and platforms? From an industry perspective, the answer is simple: in a much better place. Intermediaries will get better data, more quickly and with less effort into the software systems they use to manage their client’s investments. One of the barriers to entry for new software systems (access to data) will disappear allowing for a more competitive market for new and innovative software systems. And all the industry time spent on building and maintaining point-to-point connections can be redeployed to more productive uses.
From a platform viewpoint, the wider sharing of data with software systems should be welcomed. Going forward, intermediaries will increasingly demand that platforms share the same quality of data with all the software systems they use, and those that make this easier will do better than those that don’t. In turn, platforms will need to accept that in making data more available to software systems, they will get more competition for some areas of their offerings – particularly in the areas of client reporting and portals. Some may accept that intermediaries or end investors spend a little less time on their platforms; others may see this as an opportunity to enhance the client reporting and/or portal offerings. And some, like Transact, may choose to build more vertical offerings through the acquisition of software systems.