The underlying infrastructure that drives the Retail Forex industry is evolving. Though the components available for brokers to build their wholesale offerings (front end platforms, order management infrastructure and liquidity pools) have remained structurally the same for the past five years, the number of available options has increased by an order of magnitude. The complexity of operating a Retail FX brokerage right now is highly correlated with the number of connected front ends, order routing solutions and LP’s. Implementing a new LP or client-facing platform forces the broker to deploy new interfaces which have to be created, tested and administered.

This paradigm is changing. The Retail FX space will soon start to see not only new players and offerings for the traditional set of software components but also an entirely new component class that will greatly simplify a broker’s technical and operational duties.

Join the iFX EXPO Asia and discover your gateway to the Asian Markets

Defining the Landscape

In order to describe how and why this evolution is occurring, we must first define the current state of the industry. Surprisingly, this is actually a difficult task due to a lack of common agreement among retail brokers about what role each component actually performs. While everyone agrees that there are “Bridges,” “Aggregators,” “ECNs,” “Pricing Engines” and “Platforms,” the defining characteristics of each of these vary widely based on whom you ask. Therefore, in the interest of accuracy and clarity, I humbly offer the following definitions:

Trading Platform – An access point by which the retail trader engages the broker. The core functionality of a trading platform is to display market pricing, initiate trades and monitor positions.
Synonyms: Front-end, GUI, Platform

Liquidity Pool – A venue through which a market participant can engage in FX transactions and trade with a counterparty. A liquidity pool can be provided by a single entity or be the combination of multiple entities. Some pools are public, whereas other pools are built/run specific to a participant or set of participants.
Synonyms: Liquidity Provider, LP

Bridge – A conduit between a Trading Platform and a liquidity pool. Despite popular interpretation, not all Bridges come as third-party components. Many Trading Platforms include Bridge modules as part of their core offering.
Synonyms: Gateway, Liquidity Adapter

Aggregator – A portal for combining multiple independent sources of liquidity in order to create a combined (but not necessarily independent, non-correlated) feed. Aggregators allow brokers, via a relatively robust FX Prime Brokerage model, to leverage multiple liquidity options and realize best pricing in real time.
Synonyms: BBO Engine, Price Blending

ECN – A specific network of Liquidity Providers accessible by both Takers and Makers offering a transparent view of available liquidity to participants. What differentiates an ECN from an aggregator is that (1) the liquidity output combines both Taker and Maker orders and prices, and (2) participants to the ECN pool are governed not by a specific clearing entity but by the venue itself.
Synonyms: Exchange, Order Book, Matching Engine

Pricing Engine – A Pricing Engine takes externally driven pricing inputs to generate a customized outgoing price that is unique to a particular broker based on additional factors. These factors can include, but are not limited to, the broker’s internal position, skewing logic, time based controls, volatility, etc. Unlike an aggregator or ECN, the Pricing Engine is specific to one clearing entity.
Synonyms: CEP Engine, Risk Management System

Looking Back

With these baseline terms defined, we now have a common language to describe what we’ve seen in the Retail FX space over the last five years. First, MetaQuotes’ MetaTrader 4 Trading Platform continues to dominate the market share of retail traders. Over the last two to three years, other Trading Platforms such as tradable, c-Trader, and ProTrader have begun to make a dent in the third-party Trading platform market. However, most brokers continue to either center their offering around MT4 or at the very least offer MT4 as an option to their clients. Though some of the new Trading Platform offerings include both trading and back-office capabilities, generally the broker who looks to offer more than one platform will either manage risk separately or implement a complex solution that provides an overview across multiple venues.

Second, on the back of MT4’s success there has been an explosion in the number of 3^rd party Bridge providers. The demand for bridging came from the fact that, though MT4 offered a robust set of APIs, it provided no off-the-shelf way to externalize risk. A related development is that some of the top-end Bridge providers have recently evolved into hybrid Bridges / Aggregators. These “Advanced Bridging” solutions combine aspects of more institutional components with the unavoidable demand for robust and stable connectivity into MT4.

Accompanying the growth in the Bridge market has been a dramatic increase in the number of off-the-shelf Aggregator products that cater solely to liquidity blending. Though this presented a challenge to the market dominance of early movers such as Currenex and Integral, many of these offerings have struggled to gain market share. This is especially true of those lacking native connectivity to the most popular retail front-ends. Consequently, many of these newcomers have been forced to evolve what was once an off-the-shelf aggregator into something closer to a shared ECN environment.

The picture has been more nuanced on the risk management side. Brokers offering a single front-end or running an agency model generally manage risk with an off-the shelf component or the risk management facility built into their front-end or Bridge, whereas brokers offering more than one venue tend to use custom Risk Management systems and Pricing Engines developed in-house. Though the FX space has attracted a few external parties offering quasi-commoditized functionality for operating as a 3^rd party Pricing Engine (e.g. CEP engines such as Apama) and we’ve seen a growing number of off-the-shelf Risk Management components, they have gained little traction in the market. Their appeal is often limited by minimal connectivity options, increased response latency due to integrating at the “tail end” of the trade pipeline, or being tied to a “Risk Management Service” that requires a broker to outsource both technology and the dealing expertise required to operate it.

Another trend that has come (and, hopefully, gone) in the last two to three years is the “all-in-one” solution where the front-end, aggregation, risk management and LP clearing / credit relationship is all tied into one solution. In these cases, the broker often finds themselves bound to a front-end, routing and liquidity relationship that is impossible to decouple. The broker gets very little flexibility in terms of picking and choosing the best components for their needs and becomes vulnerable to having their LP in control of their order management, risk management and client data.

Enter the Hub

Given all the entrants to the market and options available to brokers, what’s missing from this equation? The industry has plenty of solutions for client access, price discovery, execution and even customized price sharing available in a relatively mature marketplace of providers, users and cooperators. What more could a broker ask for?

To answer this we cannot simply ask which of these components each broker will need, but rather: (1) With how many components will the broker engage in its day-to-day business, (2) what is the cost-benefit analysis of adding more Trading Platforms or LP’s, and (3) is there an option to tie all of these components together? The answer to this question lies in a new type of component.

Hub – a centralized, broker specific, universal adapter for connecting Trading Platforms, Bridges, Aggregators, ECNs and Reporting.

The Hub may contain some aspects of each of these components, but its sole independent responsibility is to act as a central point of access for brokers to coordinate, integrate and manage the separate mechanisms that make up their ideal infrastructure.

Though this isn’t the first time the word “Hub” has been used in the FX & CFD industry, it traditionally has been touted as a brand, or a specific offering, rather than as a conceptual component. What I’m asserting here is that, five years from now, we will talk about “Hubs” as we do “Bridges” or “Aggregators” today.

Why a Hub?

Imagine your brokerage has multiple Trading Platforms. It sources CFD liquidity from an ECN, but it sources FX liquidity from an internal Aggregator customized for your brokerage. Up until now, adding each new piece to the topology created a lot of work for your Operations, Network, and Risk Management teams. In the future, these components will all seamlessly integrate together via a Hub.

• Hubs will standardize many aspects of the industry such as reporting, regulatory interaction and risk management across multiple bespoke sources.
• Hubs will allow brokers to interchange and add new components to their infrastructure without reinventing their risk management or reporting integrations each time they look to introduce a new offering.
• Hubs will provide a normalized, abstracted basis for broker-to-broker interactions.
• Hubs will provide API-based access to a standardized means of communicating trade, rate and reporting data. This allows 3^rd parties to address the needs of brokers without having to develop and maintain custom integrations to the disparate components of each broker’s unique infrastructure.

Looking Ahead

Similar to the evolution of the equities markets of the late 1990s and early 2000s, Hubs will form the fundamental basis for addressing the fragmented nature of Retail FX brokers by creating common, secure means of taking independent, custom-built solutions and tying them together. Unlike traditional Bridging or Aggregation components, Hubs operate less like a software product / solution and more like a software platform. By providing abstracted interfaces through which brokers can reliably combine multiple offerings into one custom solution, Hubs will also create a foundation for improved inter-broker liquidity sharing and disintermediation. The broker of the future will be able to custom-build a combined, multi-asset, multi-front-end, differentiated offering using a framework-based approach that provides the consistency and efficiency necessary to operate without substantial technical risks or overhead.