Liquidity Domain Design Overview

Introduction

Liquidity provides rates, quotes and pricing support. Manages and optimises access to wholesale liquidity markets (Broker deals).

  • Rates ensure the visibility of the current market situation between currencies.
  • Quotes to be able to book an actual price between currencies.
  • Broker Deals are accepted quotes through a liquidity broker.
  • Swaps are two broker deals for a forward contract with a liquidity broker.
  • Liquidity control ensures the best liquidity for each partner, currency pair, client, action, etc.
  • Spread management generates profit for each Quote booked.

Problem Description

Due to the FXSuite decommission plan the liquidity domain is being affected, and it needs to be migrated into a new version that fits into new standards of Ebury.

The Liquidity Service needs better control of the quote channel selected and new capabilities to be added based on the needs of Ebury and its clients.

This document describes an architecture that enables Ebury Services to have those capabilities and has well described and organised the connection with liquidity providers.

Also, we have information duplicated and disaggregated between applications for a domain. Almost all this information and processes are in FXSuite and as a decommission plan we need to migrate that processes and information.

BrokerDeals and Swaps information belongs to the liquidity domain, so that information should be in our internal services and BOS and other services needs to ask for them or replicate them.

In addition, rates are not being managed by a central solution so, a lot of services are reaching a rate provider, currently is Xignite, to get the rates between currency-pairs if this provider does not control a currency we will need to add a workaround in all the places to control that currency.

Background

The Liquidity domain is disaggregated between BOS and FXS and part of that domain is also in the new architecture.

Right now to do an RFQ (Request For Quote) or other operation that depends on rates/quotes we need to go to BOS, FXS and the FIX Connectors with the banks.

The information we store is different depending on the application, in FXS we store the Quotes, the same as in BOS but if the Quote is accepted then in BOS we create a BrokerDeal but not in FXS.

Spread is an additional fee we add to the rate of the bank, we have two kinds of Spreads the default spreads of FXSuite which are being filled by the Programme Managers script creation and the BOS Spreads which are being filled by Risk team using the Data Science information. We also have a third kind of spread in case Ebury acts as a bank (when we ask the quote to Xignite) this spread is being filled with data science information too, and it is on FXSuite.

Quote Request Flow: Quote Request Flow

Solution

The Liquidity Service contains and maintains all the necessary information to manage and optimises access to wholesale liquidity markets.

The Liquidity Service is going to be the service in charge to control the liquidity availability managing the open currencies to do trading, products and trading hours.

The Liquidity Service is going to have the ability to add spreads in the Quotes as percentages or pip, these spreads can be configured for Liquidity Providers and for Partners.

The Liquidity Service will manage the liquidity provider selection depending on the action we want to achieve (best quote, fast quote, priorities.), create and return the Quote independently of where the liquidity provider is coming from.

It is a fundamental requirement that there is an audit trail from all the changes in the Quote life.

The Rate Service will manage the rate providers connections and a different workflows in case we need to add rates by a different way, adding more rate providers or a manual interaction by users.

The capabilities of our services should be:

  • Provides rates for internal calculations and internal booking.
  • Easy and quick way to add new rates providers and add rates manually.
  • Provides for estimated quotes to liquidity providers.
  • Reject, Accept or expire the those quotes.
  • Controls the trading availability using the Bank Holidays and trading hours.
  • Returns the information for those Quotes to list them, or the details of one of them using an identifier, by API.
  • Configuration to choose one of the active liquidity providers based on brands, clients, currencies and other inputs.
  • Interface to easily change the previous mentioned configuration and activate/deactivate Liquidity Providers.
  • Adding extra spread if is needed to the accepted quotes, this information should be filled by other teams through an interface.
  • Expose the configuration information and spreads information and allow to users to modify it by API.
  • Store broker deals and Swaps information.
  • Returns the information of BrokerDeals and Swaps to list them, or the details of one of them using an identifier, by API.
  • Easy and quick way to add new liquidity providers.

Target Architecture

Liquidity Target Architecture

Gateways can be services outside the ownership of liquidity but will provide us with an interface for our internal capabilities or services inside the ownership of liquidity. Both need to provide an interface for our internal capabilities, and they will manage the connection with the third parties or to the connector.

Services

Rate Service is going to be in charge of provides rates for internal calculation for each currency-pairs Ebury has, the rate information is going to be is going to be stored in a database for historical rates and those rates will be exposed through an API and Kafka.

Liquidity services are going to provide the capabilities that Ebury needs in terms of Liquidity Domain, such us provides quotes, estimated quotes for a trade with the bank, order a trade with the bank, retrieve all the information.

Liquidity Service stores the Liquidity Providers configuration to choose the best channels for each request, depending on the client, brand, currencies, etc.

Liquidity Service saves Quote information and the status of the Quotes and the position aggregation information.

Liquidity Service transforms to Connectors the information given by Channels and consume the information from Connectors transforms it as Liquidity objects.

Connectors

This layer is going to contains the services that connects with the banks using FIX protocol or other protocols that can be used in future connectors.

Third Parties

Banks or other companies which we have a trading agreements.

Rates

Right now, Rates are being stored and calculated in many ways across Ebury.

Rates can be exposed directly to Kafka as currency-pair topics for other services and a global topic with all the rates.

For Liquidity Domain rates are going to be used to send to clients and applications for internal uses, like currency conversion for calculation of profit and lost in GBP, fee amounts, deposit amounts, etc.

There is going to be two kind of Rates, Live Rates and End of Day/Historical Rates. Live Rates are going to be populated each hour and the End of Day Rates are going to be populated at 17:00 GMT time.

Quotes

Quotes are being stored in FXS in different tables depending on the operation for swaps we use FIXQuotes, for Spots, we use the Quote table, and we also have MultiQuotes, in the new service these Quotes are going to be unified and accessible by other applications via API or Kafka.

As we said Quotes are an operation to do a deal with a third-party liquidity provider, the operation could be in 4 states:

  • Pending: We asked the liquidity provider for a price to be accepted/rejected in a time window.
  • Accepted: Accept a pending Quote from the liquidity provider.
  • Rejected: Reject a pending Quote from the liquidity provider.
  • Expired: Time limit reach to do an operation from a pending Quote.

An accepted Quote could also be known as a BrokerDeal in some areas of Ebury.

A Quote could be created directly as accepted if it comes from other applications where the dealers accept those deals in the liquidity provider, like VoiceTrading from SmartTrade.

Estimated Quote Flow

  1. Liquidity Service receives a request for an estimated Quote with the mandatory information via Rest API.
  2. Liquidity Service will decide if the trading is available by the currencies, the current time and the product the user wants.
  3. Liquidity will decide which provider is going to be used depending on the configuration.
  4. Liquidity Service will send the proper information to the Gateway of the provider/s to request a Quote/s depending on the action.
  5. Liquidity Service returns to the clients an 202 response.
  6. Gateway/s will consume the FIX Quote information, validate it and transform it as ExecutionReport Event.
  7. Liquidity Service will consume those ExecutionReport Events, update the Quote information and returns the quote information to BOS through a webhook .

Book Quote Flow

  1. Liquidity Service receives a request for Book Quote with the mandatory information via Rest API.
  2. Liquidity Service will decide if the trading is available by the currencies, the current time and the product the user wants.
  3. Liquidity will decide which provider is going to be used depending on the configuration.
  4. Liquidity Service publishes into Kafka the message/es to request a Quote using one or multiple providers depending on the action.
  5. Liquidity Service returns to the clients an 202 response.
  6. QFC service consumes the FIX messages and send to the providers the proper messages and publishes the Quote fix information coming from the providers into Kafka. (Only for particular providers)
  7. QFC service publishes the Quote fix information coming from the providers into Kafka. (Only for particular providers)
  8. Gateway/s will consume the Quote fix information, validate it and transform it as ExecutionReport Event.
  9. Liquidity Service will consume those ExecutionReport Events, it creates the Pending Quote and returns the quote information to the user through a webhook.

Accept Quote Flow

  1. Liquidity Service receives a request for Accept Quote with the mandatory information via Rest API.
  2. Liquidity Service will decide if the Quote can be accepted checking the time.
  3. Liquidity Service publishes into Kafka the message/es to accept a Quote.
  4. Liquidity Service returns to the clients an 202 response.
  5. The message/es will be consumed by the Gateway/s and be converted as FIX message/es for QFC services.
  6. QFC service consumes the FIX messages and send to the providers the proper messages and publishes the Quote fix information coming from the providers into Kafka. (Only for particular providers)
  7. Gateway/s will consume the Quote fix information, validate it and transform it as ExecutionReport Event.
  8. Liquidity Service will consume those ExecutionReport Events, it updates the Quote to Accepted Quote, it will create a broker deal(s) and Swaps (if needed) and returns the quote information to the user through a webhook.

Caveats

Due to Pricing is considered an FX Product is not going to be part from this blueprint/strategy.