Legacy systems are a familiar conundrum for the buy-side industry. Firms have to weigh up the perils and potential costs associated with attempting to remove ageing architecture (with inherent operational risks, limited scalability and restricted interoperability) against the potential benefits of having a more modern, efficient application.
More often than not, the pain of replacing obsolete yet pervasive software is too much to bear. Any firm that wants to supplant a large legacy system will probably take three years doing so and spend an inordinate amount of money – with the ever-present danger that by the time it has been substituted, the new system will have become almost a legacy in itself, as business needs and market drivers evolve.
Furthermore, who defines what is a ‘legacy system’? Technologists will assert that you should be using the latest and greatest application on the market, with the most up-to-date language. Meanwhile systems administrators might imply that anything with 32-bit architecture is now redundant. Risk professionals might suggest that some old code that is not patched with the latest security updates should be replaced. There are also resource-restricted legacy systems: for example, where it is exceptionally difficult (or expensive) to find a programmer for dated languages such as COBOL. With little agreement on what even constitutes legacy software, what then is the way forward for buy-side firms? Could APIs provide an answer?
The primary purpose of effective APIs is getting software systems to talk to other systems. The process involves technology-agnostic messages that are written in an open standard (like XML) that most systems can readily consume or interrogate. A good example of the application of APIs in everyday life is the Citymapper app. When a user enters a target destination in say London, the app will call the Transport for London API as well as others such as Uber, aggregating data from multiple sources into one user interface. Money comparison sites operate in much the same way.
With Little Agreement On What Even Constitutes Legacy Software, What Then Is The Way Forward For Buy-Side Firms? Could Apis Provide An Answer?
Yet within asset management an API is a very loose term. Different perspectives on the same data mean that finding consistency in APIs is almost impossible. APIs can be technology-agnostic, but they can also be either proprietary or open source. The way firms communicate within the protocol can also vary according to different vendors. This lack of standardisation in APIs is certainly one issue that the software industry needs to overcome if APIs are to reach their potential.
For most asset management firms, data is king; the ability to acquire data in as close to real-time as possible is where the power lies. The method by which asset managers retrieve their data therefore has to be the easiest, quickest and most consistent way possible. For this reason they are increasingly turning to APIs at every opportunity, rather than continually building local interfaces between systems. The asset management industry is therefore moving ahead in its development and utilisation of APIs.
Within our own post-trade processing system (Salerio), we have used APIs to help our clients overcome legacy issues in order to present information regarding the meaningful events within the trade lifecycle. Asset managers want to capture when a trade transitions through its key states, allowing them to report to investors/clients or conduct further analytics as close to real-time as possible.
Furthermore, an outsourcer (securities services/investor services company) might just want to pull data out of a post-trade system to use within a client portal service, enabling its clients to view what is happening with their trades in near real-time. By utilising an API, the outsourcer can access the data in a consistent manner without being concerned about data extracts or interface delays.
Asset Managers Want To Capture When A Trade Transitions Through Its Key States, Allowing Them To Report To Investors/Clients Or Conduct Further Analytics As Close To Real-Time As Possible.
On the other hand, an asset manager may wish to analyse the data more closely, perhaps to automate processes using AI to minimise user interactions associated with trade exceptions. With a consistent API and data set, buy-side companies can concentrate resources on the ‘value add’ rather than the mechanics of accessing the data in the first place.
Will APIs provide the means for buy-side companies to finally ‘kill off’ their tired, old technology? I would argue that APIs enable them to ‘insulate’ legacy systems, rather than having the enormous cost and disruption by trying to replace them. If a buy-side firm can utilise APIs between legacy systems and the outside world, this will remove much of the pain and risk associated with dated technology. Through the effective deployment of APIs, companies can isolate systems while exposing the data. They can have easier access to the data without having to worry about the nature of the technology, because whatever is consuming or interacting with the data is technology-agnostic with respect to other systems.
Rather than sounding the death knell for legacy systems, APIs can extend their life-span. In uncertain days such as these, it may be the pragmatic way forward for many institutions with ageing architecture.
