Roger Lee, Head of EMEA Sales, BidFX
To set the scene of this hidden world that some are not familiar with… and answer the ‘What’ part to this equation – API is an acronym for Application Programming Interface and, for the benefit of the uninitiated, all you need to think of it as being is a software ‘pipe’ that allows two or more applications to talk to each other. There are various (coding) languages that can be used for APIs, the most common being REST (Representational State Transfer), Python, FIX, C++, Java, and .Net, and there are many ways in which APIs can be used, but for electronic and automated trading strategies one thing is sure, APIs are nothing but essential.
Where: APIs can connect to any datacentre, such as the 4 global setups with BidFX, (London, New York, Tokyo, Singapore), which are co-located next to all major LPs data centres. Why is this useful? This gives a client immediate access to a high speed worldwide network, that can be tapped 24/6, in a follow-the-sun modus operandi. BidFX’s buyside clients enjoy leveraging a network team, liquidity sharing, data centres all through one trading technology partner.
Now, digging a little more into the dynamics of the FX marketplace: we have 2 main forms of trading (excluding traditional forms by voice/telephone of course) by the institutional buyside community:
- Discretionary – often known as ‘clickers’, those who click on currency tiles on web-based interfaces and
- Systematic – typically model driven or quantitative. With the former, workflow wise, clients can and do use APIs, for transferring large numbers of orders (e.g., perhaps FX hedges for equity trades) from an Order Management System (OMS) or Portfolio Management System (PMS) to an Execution Management System (EMS), an example of an EMS being BidFX.
The process of transferring these orders is known as staging. Meanwhile, the process of getting these ‘staging APIs’ live involves a one-time certification process of coding, testing, and pushing to a live environment – between the EMS and the OMS/PMS provider, which is typically completed by qualified technical personnel at each firm. Once tested and released into a production environment, this allows a limitless number of clients to leverage that same connectivity pipe / API, transferring orders and executions back and forth seamlessly between OMS/PMS and EMS. The typical use case for a staging API will be that of a long only asset manager, or perhaps for a Treasury Division of a bank, large corporate or global macro hedge fund.
From the buyside perspective, when we’re looking at the second main use case of trading – clearly the systematic style of API trading is quantitative, and model driven. Now, as a client, you can decide to go direct to a liquidity source or provider, but this does have practical drawbacks, e.g. the client has to be able to support different methodologies from each provider, there are ongoing changes or additional components brought into the mix with an individual API specification, so this involves constant work for the buyside client, and time and technical resources are at a premium, what with the constant juggling of buyside priorities.
So, it can be argued very easily that time and effort could be better spent on optimising model driven strategies instead. To be clear, when you trade with an EMS, it’s a de facto part of their business model to normalise the client experience, as soon as you are set up with that EMS, their team deals with all the sources of liquidity around the clock, since they have dedicated ‘Integration’ teams around the globe whose expertise are wholly focused on API connectivity, maintenance and upgrades.
Now we have another factor that lies around the world of APIs and systematic trading that drives activity, and that is data. This is indeed also very API-driven as well as cloud based, although queries can also be done on screen to visualise your data set. The API trading services of systems like BidFX, also include data, which is crucial for back testing one’s models and putting them live. Under the data ‘bonnet’ lies two main fields, one’s own data (known as tick data) as well as a potentially wider set of data, not necessarily one’s own data, which is typically called composite data.
As the buyside community becomes progressively sophisticated in their interaction with technology, the world of APIs provides one more benefit, and that is time saved. How does this happen? Through rules-based automation and/or algorithmic trading functionality, via bank algo suites or algo wheels. This reduces manual intervention and is integral to what an EMS provides the marketplace, efficiently accelerating the trading workflow for a client.
Finally, if an order does require manual intervention (e.g., over a set notional size) and the trader wants to avoid signal generation, that might adversely impact his fill, it can be resolved through Risk limits. For both discretionary and systematic API trading, Risk limits on APIs exist to help clients manage:
- what goes out the door without hindrance,
- what requires one step before the order leaves the room or
- what allows the door to be slammed shut, as a hard ‘no’ limit.
All in all, you may now be piecing the puzzle together, realising that there is a great deal of moving parts, that are both interoperable and that apply to API and screen-based trading. The benefits increase the more feature-rich the EMS is that the API is connected to, allowing buyside developers to concentrate on new models without having to examine an already established and well tested suite of products (which BidFX is proud to offer).
The sophistication of electronic FX trading is advancing at an incredible speed within the buyside community. BidFX is at the cutting edge of the eFX community, an EMS with a class-leading Data & Analytics product suite that offers buyside clients a full trading solution.
If you are keen to find out more, please do not hesitate to reach out.
This article was written by Roger Lee, Head of EMEA Sales, BidFX.
Roger.Lee@bidfx.com
