API’s and Systematic Trading. Are your OEMS and PMS platforms delivering?

Systematic trading has long been a feature of the financial markets. Even in the days before computers arrived on the scene, early systematic traders would use rule-based systems designed to remove human emotion from the trading process, generating trading signals and entry/exit points from a range of technical analysis methods.

Today, with the massive amount of data that can be used to drive trading models, and the computing power that is now widely available, systematic trading has become firmly established across the industry. Quantitative hedge funds have proliferated in recent years, and many traditional investment management firms now run a mix of discretionary trading and systematic trading funds.

In fact, a recent survey conducted by quantitative analysis platform SIGTech, found that 80 percent of hedge fund managers polled expect institutional investors to increase their allocations to quantitative strategies this year.[1]

Why APIs are imperative for systematic trading

In order to run quantitative strategies, firms need to be able to seamlessly integrate their systematic trading models with a range of sources and destinations, both internal and external. Sources that can provide the data needed to drive the models (such as market data, real-time positions, P&L and current exposures for example), and destinations such as brokers and exchanges, for the electronic execution of orders.

None of this can be achieved without the appropriate APIs (application programming interfaces). OEMS and PMS systems should therefore be designed to offer comprehensive, well-structured, two-way APIs, which can both provide the data that firms need in order to run their models, and ingest the output from those models so that trades can be automatically executed in the market.

From an OEMS perspective, when a systematic fund is generating orders, the API should be flexible enough to allow firms to either slice those orders via their own algos and route them directly into the market via DMA (direct market access), or to stage the orders and utilise their brokers’ execution algorithms. API-based trading needs to cater for both of these approaches.

Once orders are executed, the API needs to be able to receive fills from the broker or trading venue and not only feed those back into the systematic trading program itself, but also send those trades to other areas within the firm, such as risk, compliance and middle/back office systems, as well as Excel spreadsheets and other internal applications.

It is also essential for systematic traders to be able access their PMS via an API, in order to feed current, up-to-date positions back to the firm in real-time. This is necessary in order to facilitate intra-day risk and exposure management, as well as to potentially generate new trading signals.

Being able to interact with the full trade lifecycle in this way, at scale, across the PMS and OEMS components, is imperative for firms running systematic trading funds, but it can be a challenging proposition, particularly for firms that rely on solutions that lack the necessary API functionality.

How clients benefit from TORA’s APIs

TORA’s highly performant APIs benefit clients by providing their systematic applications with timely up to date data, so that they can make accurate decisions and rapidly respond to market events.

The ability to both ingest and extract data from any part of the system is a key benefit, as it allows clients to centralise everything in one place. The PMS API for example, enables firms to use their own custom pricing and risk models. If they are pricing derivatives products for example, they can feed those prices into the PMS, so they have accurate exposures and P&L within the system.

Another benefit of TORA’s API is the ability it gives clients to build custom reports and web pages based on up to the minute data. These can either be for internal use (e.g for risk reporting) or offered out to their own clients (as web pages showing current positions, P&Ls and balances, for example).

From an OEMS perspective, API users also benefit from the fact that TORA is designed from the ground up as a cross-asset, broker-neutral platform. This means that if traders see that a particular strategy works on one market, and want to use it with another broker, venue or asset class, they can just change some simple parameters, and the API will take care of the rest.

Real-world examples

There are countless ways that clients are using TORA’s OEMS and PMS APIs in the real world.

One typical example on the OEMS side, is where a fund might wish to automatically adjust its participation rates based upon real-time market volumes and pre-defined parameters around its own volume predictions. The API can ingest real-time market data and, based upon the parameters that have been set, automatically adjust the order slices it is sending into the markets to be more aggressive or passive, either using broker algos or DMA slices, for optimum execution.

Another example, which utilises the all-in-one capabilities of both the PMS and the OEMS, is where a beta-neutral fund may wish to automatically rebalance its position as its exposures change throughout the day, and execute rebalance slices at specific time intervals as baskets. Using TORA, the API can manage the individual orders within the baskets using algo parameter recommendations, and combine the client’s factor models with TORA’s own factor models to execute within the momentum of the market, for the most efficient beta hedging.

These are just two examples. The key point here is that both the PMS and OEMS components of the system are completely open for ingestion or extraction of data via APIs. This is unique amongst PMS and OEMS vendors, particularly those offering all-in-one platforms.

TORA’s interactive API implementation framework

The following diagram shows how TORA’s all-in-one PMS, OMS and EMS solution, designed from the outset with API interaction as a fundamental, core aspect of the platform, helps clients address the challenges of API trading.

To help clients work with our APIs, TORA provides an interactive implementation framework, which rivals those offered by ‘big tech’ companies across other industries. Rather than providing documentation in PDF format, TORA gives clients a sandbox, where they can simply search for keywords and go straight to a coding environment with built-in, web-based documentation, which allows them to experiment and see meaningful results.

Within the sandbox, TORA provides coding samples that clients can use as a starting point, so rather than having to copy/paste those samples into their own coding tool, they can run them and change them to suit their needs, thus testing out their code in relevant scenarios before going to production.

Additionally, clients can experiment with the different APIs that TORA provides. For example, if they need to access positions with real time and historical P&L, they may wish to compare our API offering very fast position data against our more complex API offering pre-computed data (which can also include the firm’s own formulas, which they can pre-define within the system). If a client is unsure as to which API is best suited to their needs, they can simply go to the interactive sandbox, try out alternative approaches, and compare results.

This is a really important feature for systematic traders using their own models and their own calculations, because they need to be able to see how something works within the TORA environment, in order to ascertain what is the best API to use to send and receive data in the most appropriate format to support their systematic trading needs.

Another key point is that TORA’s APIs are available in different languages, or ‘wire formats’. One common format is JSON, which has the benefit of being ‘human readable’, but is not as fast as a serialised framework such as ProtoBus, for example. Because TORA’s APIs are available in different wire formats, clients can use JSON when they’re building and prototyping their models, and then, once they’re comfortable with their queries and parameters, they can switch seamlessly to a more performant framework (e.g. ProtoBus) in their production environment.

TORA’s unique functionality – our handover mechanism

To enable the highest levels of automation and flexibility, TORA enables clients to control parameters within their trading models via both API and GUI access. In TORA, the UI is treated as one endpoint, and the API as another. That means that when clients use the API, they do not lose any UI functionality. For example, a trade intent can be generated through the API, but it can also come from a trader’s click, or from a trader taking an action in the UI that is then handed over to the API (or the other way around). This handover mechanism is unique, in that it allows traders to benefit from a dynamic, visual environment where they can even manage their algo engine using the TORA UI. If, for example, a trader wishes to annotate a tag on an order, the API will announce that and the engine will detect it, and act upon it.

Another aspect of API-based trading that can be particularly useful for firms, is where incoming and outgoing data is enriched, outside of their systematic trading models. Many brokers have their own FIX fields for example, so normalising the data, and having the API automatically map fields to match the internal taxonomy and nomenclature of both the firm and its brokers, allows the system to treat a trade intent as an object and hit the broker with the right fields. This not only allows for more rapid integration, but also reduces ongoing maintenance overhead.

Trading APIs should also be flexible enough to be enriched with additional useful data, such as TCA (transaction cost analysis) data, for example, which can provide recommendations around order routing based upon pre-defined parameters. Within TORA, these types of data can be customised to interact with the client’s own internal models, and flow back into the API.

Integration and customisation

TORA also provides full integration with Excel and other common end-user tools. We recognize that clients make extensive use of these tools as part of their workflow, and that many complex Excel spreadsheets have been built over time to support their trading operations.

TORA’s APIs can be used directly from within Excel (using Power Query), and with data visualization dashboards such as Power BI, so that if clients wish to process and use data from TORA, they can continue to use the third-party tools they’re familiar with. In fact, any application that supports REST & JSON can work with TORA’s APIs.

This feature is particularly useful where portfolio managers wish to use their own indicators, to augment the extensive range of indicators available within TORA’s PMS. Many clients already have logic sitting within Excel spreadsheets or other applications to compute these indicators. Using our APIs, they can seamlessly connect their existing spreadsheets to real-time data within TORA and have everything updated automatically.

TORA’s APIs are also customisable, so users can design their own tables and groupings for example. The system is designed to enable customers to augment the data that TORA provides with their own data, and expose it all through the TORA API, for use in their own models.

We also work in close co-operation with our clients to fully understand their use cases, guiding their API implementations and advising which API workflows are most suited to their individual systematic trading needs. We also help with integration tasks, to ensure that the TORA APIs are set up to accommodate their own internal systems and workflow.

How TORA’s technology makes our API offering unique

Many ‘all-in-one’ solutions are very limited in the API functionality they offer, particularly if they were originally built as a PMS, with OMS and EMS components added at a later stage. PMS platforms are generally more simplistic than OEMS platforms, and many PMS-based solutions do not offer anything like the extensive API functionality or the scalability that today’s systematic trading funds require.

TORA’s all-in-one solution is different. The system was built from the ground up around an open, scalable, EMS-based architecture. This means that all of the rich execution capabilities within our APIs are core to the system, and have been extended out to the PMS module, rather than the other way around, which is why we are able to rapidly adapt our APIs to meet the needs of our clients.

As an API-centric platform, unlike other PMS and OEMS systems, which often need to convert client calls into the internal language of those applications, the APIs that TORA exposes to clients are the same as those APIs we use internally within the system on an ongoing basis to connect the various services that are running. This is an important distinction.

For example, within TORA, the OEMS module pushes the data to the PMS module using the very same API that we make available to clients. The transactions API for example, used for pushing and pulling execution transactions within the application, can also be used by clients to handle their own transactions external to TORA.

This open systems approach is a fundamental design principle of the TORA platform, and allows for much greater flexibility from a client perspective, particularly around systematic trading. Systematic portfolio managers need to be able to seamlessly pull data into their own models from both the PMS and OEMS components, and to push trading instructions back into the market. This circular flow of data, from driving alpha generation models to managing the full execution lifecycle, can all be facilitated through TORA’s APIs.

Conclusion

With institutional investors set to continue to increase their allocations to systematic trading funds across asset classes, and with new quantitative hedge funds launching all the time, firms need to be sure that their platform providers can fully support their systematic trading needs. In this regard, the importance of APIs cannot be understated. Systematic traders need to know that their PMS and OEMS systems can fully integrate with their internal environments, and that those systems are flexible enough to cater for their ever-evolving needs across the trading workflow.

In this regard, TORA is unique. No other PMS, OEMS or all-in-one platform is able to offer the rich API functionality that TORA provides for feeding data into and out of any part of the system, from the PMS module right through to the OEMS. TORA’s scalable, cloud based, open platform is the only all-in-one solution that is designed from the ground up around an API-based architecture, providing the comprehensive API functionality needed to manage the entire trade and position lifecycle, across asset classes.

[1] https://www.sigtech.com/insights/quant-strategies-research-report-2021

Download the PDF