The Lab

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Bid|Offer vs Buy|Sell Perspective

The Whisperer Enterprise SBE Schema is Maker/Taker agnostic, meaning that Quote Requests, Quotes, Orders and Executions may flow either to or from the client - the direction obviously being dependent on the Venue that the client is connected to.

The perspective of transaction sides is always from the perspective of the originator of the transaction, with Takers Buying and Selling against Makers Bids and Offers as follows:


Takers will always Buy or Sell their specified Dealt Currency - which is either

  • Base - aka CCY1, LHS
  • Terms - aka CCY2, RHS


Conversely, Makers will publish quotes as Bids and Offers against the Base of the quoted Ccy pair:

  • The Bid price is the rate at which the Maker will buy the base currency.
  • The Offer price is the rate at which the Maker will sell the base currency.


This is set out in tabular form below:

Taker Tradesagainst Maker
Base CcyTerms Ccy
BUYSELLOFFER
SELLBUYBID



In short,  QuoteRequest, NewOrderMultileg and ExecutionReport all always express a transaction from the Taker perspective. Quotes always express prices from the Maker perspective.

Quote Construction

When publishing quotes as a Maker, it is important that the basic principles of price construction are understood, especially when considering multi-Legged product types.

Relevant details are provided in the QuoteRequest as follows:

  • Side - Side information is maintained on a per-Leg basis in the LegSide field, and on a per-alloction basis via the sign of the LegAllocQty.
  • Dealt Currency - Side is always stated with respect to the traded currency.
  • Date - Tenor and value date information is provided on a per-Leg basis in the LegSettLDate and LegSettlType fields.
  • Quantity - The relative quantities of individual legs must be understood when pricing multi-Legged requests.


Spot Side Determination

When pricing a multi-Legged request, the Maker needs to determine which side of Spot is to be used across all the individual Legs.

Business rules for Swap pricing are well known and summarised in the table below:

Far LegDealt CurrencyFar > NearSide of Spot

Near Leg

Fwd Pts & All-in

Far Leg

Fwd Pts & All-in

BuyBaseTRUEOfferBidOffer
SellTermsTRUEOfferBidOffer
BuyBaseFALSEBidBidOffer
SellTermsFALSEBidBidOffer
BuyTermsTRUEBidOfferBid
SellBaseTRUEBidOfferBid
BuyTermsFALSEOfferOfferBid
SellBaseFALSEOfferOfferBid



When considering Block requests, the simple "Far > Near" check is not sufficient to determine side of Spot. A naive approach is to simply extend the Swaps model above and arithmetically net all the Legs quantities to get an aggregated Buy or Sell. If the maker is more sophisticated, then the Net Present Value of each Leg can be determined, and those amounts aggregated.

Validation

Given the complexity of accounting for Venue-specific message and representational quirks, MarketFactory validates that each constructed quote adheres to some basic rules:

  • One-way requests must be quoted one-way (only). This means that the Maker cannot hedge their bets by, for example, providing both bid and offer spot rates. This ensures clarity and means that any pricing errors may easily be identified.
  • For vanilla outright and swap scenarios, MarketFactory will ensure that the correct side of spot is provided, as per the above table.
  • For Block scenarios, only one-way pricing is relevant.
  • For each leg, MarketFactory will verify that the Spot rate value derived from the quoted all-in rate and forward points matches the actual provided spot rate.
  • No labels