API: a core component of securities services

API-sation

Do we have to change? If we want to keep up with our competition, traditional and disruptors, the answer is yes. Do we have to learn to love API? If we want to continue to satisfy customer needs and enhance the industry’s product offering, the answer is yes. Do we know what we must do? If we have been paying due attention to the changes taking place on an almost daily basis, the answer is also yes.

In-house and outsourced services

One issue that every provider will need to address is the question of just who does what in the changing landscape. Doing it yourself is one option. Enlisting the help of a partner is another. But APIs are changing the current landscape.

From messaging to API

Large custodians’ clients have been using SWIFT or SWIFT format to send settlement instruction orders for decades. But once instructions have been issued, clients have traditionally been wholly reliant upon bank staff to keep them apprised of the status of the settlement.

With the rise of the Internet, providers have started to offer Graphic User Interfaces (GUI) through the web for their transactional and reporting services. Simultaneously, some have also offered web services, a specific form of API that is only available via the World Wide Web. Internet users are now used to browsing websites that incorporate web services.

Typically, a website that is showing a weather report or forecast is presenting information retrieved from a specialised weather server through a web service. In effect, clients are using APIs via Internet without even knowing it.

API is more generic than a web service, as it can be accessed via various types of transport.

API security

The usual keywords associated with information security also apply to APIs. Authentication, integrity, and confidentiality are more related to its transport than to the API itself. The two main issues are  availability, as it creates a dependency on a third party and raises the issue of business continuity, especially for essential services, and scalability, whether the provider can respond within the client’s agreed timeframe.

Instructing & Reporting

In the brave new world of APIs, clients can send their instructions, track their status and retrieve various data for reporting, and they are able to do it directly from their own information system.

Functional extension

Being capable of integrating external functionalities or external data at the heart of an information system opens a broader field of opportunities, especially because most APIs are designed to provide a response upon request in real time or near real time. Client information systems can be extended with the functionalities offered by the API of their providers. To illustrate this concept, an arbitrage trading program is used to systematically buy and sell when the price difference between two correlated goods is changing. Such a program would rely on APIs to retrieve the price of the two goods, to send the purchase order to one market and the sale order to a second market, and to track their execution status.

Data enrichment

Inasmuch as APIs can be used to extend the scope of functions of the information system, they can be used to enrich data, adding detailed information, zooming out or classifying. With data, difficulties come from codification. Although the International Standards Organization (ISO) has set widely-adopted standards, there are many fields in which there are no widely-used standards. As an illustration, most securities can be identified by an International Securities Identification Number (ISIN), but there is no official codification for listed derivatives contracts, every exchange, quote vendor or clearer uses their own codification.

When there is no widely adopted standard, transcoding systems or correspondence tables must be maintained. These could also become services accessible through APIs.

Knock on effect

Clients will increasingly team up with their service providers to develop a strong API capability. These providers in turn will partner with their own suppliers, for instance local custodians, so that they can deliver more of the APIs that clients need.

Simple or Sophisticated

On a more practical level, an API can be designed either as an elementary service or as a broader service that enables selected data to be retrieved  from an extensive set, or as a high added-value service integrating various internal and external services. Most clients would want an added-value brick to simplify their operations, but larger clients or more secretive clients would require simpler bricks to assemble and enhance information by themselves, possibly with other suppliers. Smaller clients would prefer full business process outsourcing rather than having to manage an information system.

Common standards

Putting this firmly into a broader international context, APIs will enable providers to offer an end-to-end seamless service. Such a seamless service would increase the benefits for the clients, especially when service providers agree and use common standards and interoperability rather than proprietary “open standards”.