Twenty-five years ago this summer, I witnessed the first client trade executed from iFX Manager, an Internet-based FX trading platform for investment managers I created for one of my former employers, the Bank of New York. iFX Manager was built in concert with a U.K. FinTech firm named AVT Technologies, and connected to AVT’s initial pricing engine known as EchoFX. Designed in the late 1990s at the dawn of a transformational era for the foreign exchange market, EchoFX was an application that provided dealable or indicative spot, outright, and swap prices to a bank’s clients, enabling them to request a quote by a mere click of a mouse. The quote request was then transmitted to the bank electronically, where it was either auto-executed or intercepted by a bank FX salesperson or trader to update the price if necessary.
The added value of iFX Manager for clients, as a separate application from EchoFX, was providing them with significant automation and straight-through processing. Instead of entering one quote request at a time manually via EchoFX, Bank of New York’s investment manager clients could instead upload dozens and dozens of FX trade requirements, on behalf of various investment funds, and group them by currency pair and tenor before submitting them for quotes. To enable this means of high-volume trading, EchoFX was modified to allow iFX Manager, or any other application, to connect to it via API.
This modification of EchoFX, which later became the basis for Reuters Electronic Trading (RET), one of the FX industry’s most popular bank pricing engines, was prescient in allowing other trading applications to connect to it in a hub-and-spoke manner. Nearly two years later, in May 2001, I witnessed our first corporate client quote request from the newly launched multi-dealer platform FXall appear on the screen of EchoFX alongside quote requests from investment managers using iFX Manager. A few years after that, quote requests from some European-based clients using multi-dealer platform 360T also appeared on the same screen.
While the concept of providing a means for a bank’s clients to request prices and execute trades electronically – let alone over the Internet – was clearly revolutionary during this period, what was indeed remarkable for someone working in an FX trading room at that time was having the quote request information displayed on a computer screen – the client’s name, currency pair, the amount, the direction, and the value date. Previously, this information was relayed via phone, and not necessarily shared with everyone in the FX trading room.
During the 2000s, more and more of our clients were priced electronically as they gradually moved from the phone to the computer to trade, whether on a multi-dealer platform or our own single-bank platform. Even more impactful for our FX business, however, was the newfound ability to price and execute FX trades from indirect sources, such as those related to custody, brokerage, cross-border payments, and outsourced currency hedging. This ability to price all direct and indirect quote requests through a centralised pricing engine effectively created a view of much of our FX trading desk’s activity over the course of the day. Even more importantly, our evolving e-FX infrastructure enabled us to capture all of this FX risk from client trading activity at the moment of execution, and then feed it to a centralised book where the risk could either be offset with existing positions or else covered in the market.
The process of pricing relationship trading using an FX trading system while pricing competitive trading using an e-FX pricing engine is not ideal
The state of e-FX in 2024
Fast forward to today, the implementation and management of a robust e-FX infrastructure is now the way the top tier banks operate their FX business. They provide their clients with executable streaming prices across dozens of currency pairs, co-locate their low-latency pricing engines at industry data centers in New York, London, Tokyo, and Singapore, and manage sophisticated trading algorithms that can offload non-internalized risk with any number of liquidity providers in a matter of milliseconds.
However, many banks do not operate their FX business in this manner, namely the regional banks that were the subject of an article I wrote nearly four years ago for this magazine. These banks, which largely service retail, business, and commercial clients, and occasionally some corporate, investor, and/or wealth management clients, tend to have more transactional-related FX (e.g., foreign currency wire and ACH payments) than risk management-related FX (e.g., forwards, swaps, NDFs).
This transactional FX activity, which is part of what I call “relationship trading,” has historically been priced by regional banks using an indicative FX rate feed within an FX trading system from providers like Finastra, ION Group, CGI, Calypso, Broadridge, and Finzly. These FX trading systems are primarily designed to process, confirm, and settle trades, and provide P&L reporting to enterprise accounting systems. However, when a few of a bank’s clients desire to trade risk management-related FX on a competitive basis using an industry multi-dealer platform such as FXall, Bloomberg, 360T, or FX Connect, an FX trading system’s rudimentary pricing capabiity cannot support this. Instead, the bank is often driven to invest in an e-FX pricing engine and connect it to the multi-dealer platform to support these clients.
Balancing Relationship Trading with Competitive Trading – the Need for centralised e-FX Pricing
The resulting bifurcated process of pricing relationship trading – the bulk of a regional’s bank’s FX activity – using an FX trading system while pricing occasional competitive trading using an e-FX pricing engine is not ideal. For one, the e-FX pricing engine is often deployed on an exception basis by the trading desk and viewed as simply a means of providing prices in competition to a few clients on one or two multi-dealer platforms, with few resulting won trades. As a result, it may be operated on a standalone basis, and not used in tandem with other e-FX infrastructure components, such as risk management or liquidity aggregation from interbank sources, due to the additional costs involved. For another, this process creates a need to manage pricing and risk positions in two different places, not ideal for a bank that likely has limited FX trading personnel.
The solution, therefore, is if a bank is required to implement an e-FX pricing engine to support some clients trading via a multi-dealer platform, then the e-FX pricing engine should be the center of all client FX trading activity, such as quote requests originating from a bank’s single bank platform, its sales desk, or other internal FX activity that may be generated from the bank’s Treasury Management, Trade Finance, Custody, Brokerage, or Wealth Management businesses.
Doing so provides a bank with number of benefits:
With additional investment, an e-FX pricing engine can be integrated with other e-FX components, such as a liquidity aggregator to source the best prices available from liquidity providers, algorithmic tools for risk management to offload undesired positions systematically to liquidity providers, forwards and swap pricing data to support a bank’s own market-making in these products, and analytics to help traders optimize their price distribution while improving profitability with clients.
All client risk from both multi-dealer platforms and internal bank sources can be consolidated in a single trading risk book, giving the bank some opportunity to internalize client flows.
All completed FX trades can be fed through a single API designed for trade output, available from a provider like Refinitiv or OSTTRA, to the FX trading system for trade processing, confirmation, and settlement, providing a singular approach to straight-through processing.
While there has been some change in e-FX pricing engine providers since my initial article in 2020, the primary ones used by many regional banks these days include those from Refinitiv (Electronic Trading), 360T (Automated Dealing Services + Market Maker Cockpit), smartTrade (Liquidity FX), ION Group (Aphelion e-FX), oneZero (Liquidity Provider Hub), and Integral. These providers recognize the importance of a bank having a complete ecosystem of components to operate centralised e-FX pricing.
Utilising an e-FX pricing engine for multiple pricing methods
One misconception is that an e-FX pricing engine can only generate real-time FX prices that are constantly updating. While this is expected quoting behavior for the multi-dealer platforms, and perhaps for bank sources like a single bank platform, it may not be suitable for a bank’s other FX activity that may require static rates over the course of a few hours or an entire day, or may need to be priced using third-party rates such as those provided by the WM/Refinitiv fixing service.
In fact, many e-FX pricing engines, using a separate rate area or branch, can be configured to keep such static or fixing rates “live” for minutes or even hours so that they do not go stale and become ineligible for automated quoting. Employing multiple rate areas or branches within an e-FX pricing engine – such as one for real-time competitive trading pricing, one for real-time relationship trading pricing, and one for static pricing of FX transactions from internal businesses or systems – can provide a bank with ample flexibility to manage all electronic pricing in a centralised manner.
E-FX: The way forward for regional banks
In summary, regional banks that have not properly invested in an e-FX infrastructure and integrated in into all of their external and internal client FX trade sources need to realize that e-FX is not simply for the top end of the market, namely Tier 1 banks, large corporates, and large investment managers. Rather, implementing a proper e-FX infrastructure and using it to price all of a bank’s FX trading activity is the way to run a bank’s FX business in 2024, regardless of size.
