APIs for the investment industry: What does good look like?
In our last API blog post, we looked at how an API-first strategy reduces operational costs and enhances access to data. In this piece, we set out what a good quality API looks like and examine some of the ways in which the right API-first platform can transform how you access and manage your investment data.
APIs have long been touted as building blocks for the transformation of the investment industry. Yet despite their power to transform how investment data is managed and transferred throughout the fund industry, not all APIs are created equal. When looking at an API-first solution in investment management there are some features that are non-negotiable:
Any modern API will have robust authentication, encrypted transport and strong validation (at a bare minimum). Investment platforms will almost always hold sensitive customer data (names, addresses, portfolio holdings, national insurance numbers) and it’s critical this data is protected. There is zero margin for error when it comes to protecting your clients’ data.
Low barrier to entry
There should be a low barrier to entry for new users of any API. We find using a standard like OpenAPI (also known as Swagger) provides a familiar experience for developers. Access to Software Development Kits (SDKs) will also help shorten deployment cycles. A good SDK will handle the more routine tasks (e.g. authentication and translating API models into first-class objects) which lets users jump straight into solving their business problems (e.g. building a new asset allocation algorithm or integrating with a new custodian).
Any API you chose to work with should be well documented with lots of examples. The documentation should cover both technical features of the API and use-cases. Example: ‘What are the minimum field names and data types required to update a trade’ or ‘How do I do a valuation with a custom price source?’ or ‘How do I run a daily IBOR.
Split into logical building blocks which work together
You want API endpoints that represent logical and useful abstractions and resources. For example, almost all investment management platforms will have a separate Instruments and Holdings endpoint. These endpoints should work seamlessly together (we call this composability). You should be able to take the instruments details from the Holdings response and use these to call more details about the instruments from the Instruments endpoint.
Adopt industry recognised standards
A good quality API should adopt globally recognised standards. Using familiar standards improves the onboarding experience for new users (and applications). The REST architectural style – which uses the HTTP standard methods or verbs (GET, POST etc) – is an example of this. Developers intuitively understand that a “PUT holdings” request replaces (rather than adjusts) all the holdings in your portfolio without the need to study the system documentation in detail. Industry standards can also help the applications and machines processing API data. For example, we like JSON as all major programming languages have rich libraries for reading and writing JSON.
A quality API should use a consistent implementation of naming conventions and common features across all endpoints. For example, a Holdings endpoint and a Transactions endpoint might need to return an attribute which references a unique instrument. To deliver the best user experience, that attribute should have the same name (perhaps something like InstrumentId) in both endpoints. Common features across all APIs should also be consistent. Do your APIs have filtering functionality? If so, the syntax and operators used in those filtering statements should be the same across all endpoints.
After determining the ‘must have’ features in an API-first platform, let’s now look at some of the ways in which an API-first solution can give you better access to your investment data.
Integration with other systems
An API-first platform should enable seamless integration between different systems in your technology stack, by providing a “common language” for these systems to communicate with. For example, most investment managers will have a constant flow of data between an Order Management System (OMS) and a Portfolio Management System (PMS). Using an API-first platform as the backbone integration layer can ensure both systems are always up-to-date with correct data. You want orders raised from the PMS to hit the OMS instantly, and you want the PMS to be updated with allocations/transactions from the OMS in real-time so your portfolio managers are always making decisions from the best data.
Control over data access
A good API-first platform will have an easy to manage granular entitlements system meaning administrators have maximum control over what data specific users and groups can use. This will enable you to hit the sweet spot of data entitlements: where everyone has easy access to all the information they need but no one has access to data they shouldn’t see.
Rapid onboarding of new data
Do you need to onboard a new ESG data set for a client? Or have your data strategists sourced some new data which might be mined to generate alpha? An easy-to-use API with a flexible data model will help you set up a robust pipeline to pump this information into your ecosystem so your teams can get maximum value from new data immediately.
Involve end-users in the development process
The microservice approach of API-first platforms, where loosely coupled services are deployed and maintained independently, means API vendors can easily involve users in the development process. With segregated endpoints between “Production”, “Beta” and “Experimental” users can test new functionality early and participate in the feedback loop during early iterations of an API endpoint.
If you want to find out how an API-first platform can help you get the best possible insights from your investment data, get in touch with us.
Suite of SDKs
Subscribe to our newsletter
Get stories like this in your inboxSign up
An industry at an inflection point – part two
An industry at an inflection point – part one
Life as a Security Engineer at FINBOURNE