Written by Bruce Davidson on Wednesday 6 November 2013
Over the last six months there have been quite a few announcements of platforms selecting new back-office technology: Ascentric, Fidelity, Skandia and SJP have all made the news with stories of significant investments in new systems, and I suspect there are more to come.
Given all the noise we’ve made at Altus about the need for improved operational efficiency, it’s gratifying to see that platforms are taking this seriously and spending their hard-earned cash on industrialising the engine-room. But in one important respect the challenge is only just beginning.
Anyone who’s worked on system migration in the Financial Services industry will tell you it’s always a Cinderella cousin to the glamorous new technology project; scrubbing data and patching holes while new system features and proposition possibilities grab all the headlines. Despite its low profile, migration rarely goes smoothly and there’s no reason to believe this will change in the case of platforms. Many platforms looking to migrate are moving from bespoke systems developed over years, or were originally re-purposed from other functions. Understanding how they’ve been used and changed over the years is important if the migration is to avoid years of “adjusting” transactions suddenly appearing in clients’ online transaction histories, or failing at the final hurdle to reconcile with the market.
The industry doesn’t have a great success rate with migrations, even where the systems are primarily internal and the challenges largely technical. For platforms, which are always operating “in public” to the market and their customers, the challenge extends well beyond the realm of technology. So before platform IT Heads reach for a Gartner report on ETL tools, here are a few business issues to consider.
Platforms are designed to aggregate assets for multiple clients; the quest for more efficient operations has led to assets and cash being held in fewer accounts, spanning business streams and products. That’s great for daily operation but not so good for a typical phased migration approach. Splitting a pool of assets and reconciling them across both old and new systems is possible but brave. One of the first steps in a platform migration therefore has to be to get a good picture of the current nominee and bank account structures and compare this to any desired phasing by different business lines. Depending on the results, the next step may well be to accept that migration will need to occur in the outside world as well as the database, or to accept that Big Bang is the only option!
Another issue for platforms is timing the migration; finding a window of downtime to do the cutover – and potentially back it out if required. Platform terms and conditions typically allow clients to trade whenever the markets are open and CASS effectively requires a platform of any scale to run cash reconciliations daily. Couple that with the ability of clients to view their holdings online whenever they choose and it’s clear that this presents quite a bigger challenge than might be expected.
And what about in-flight transactions? Daily priced funds are one thing but what about monthly priced property funds, corporate action elections, or partially settled equity trades? The final migration must cope with an unknowable set of in flight transactions, placing heavy emphasis on a thorough understanding of market processes and dynamics when designing the migration tests, long before the actual migration date.
In short, there’s plenty to think about long before you look at the mechanics of how to move the data.