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 Trades | against Maker | |
|---|---|---|
| Base Ccy | Terms Ccy | |
| BUY | SELL | OFFER |
| SELL | BUY | BID |
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 Leg | Dealt Currency | Far > Near | Side of Spot | Near Leg Fwd Pts & All-in | Far Leg Fwd Pts & All-in |
|---|---|---|---|---|---|
| Buy | Base | TRUE | Offer | Bid | Offer |
| Sell | Terms | TRUE | Offer | Bid | Offer |
| Buy | Base | FALSE | Bid | Bid | Offer |
| Sell | Terms | FALSE | Bid | Bid | Offer |
| Buy | Terms | TRUE | Bid | Offer | Bid |
| Sell | Base | TRUE | Bid | Offer | Bid |
| Buy | Terms | FALSE | Offer | Offer | Bid |
| Sell | Base | FALSE | Offer | Offer | Bid |
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.