The Lab

Expand all   Collapse all

Versions Compared

Old Version 20

changes.mady.by.user Sadat Tafader

Saved on

compared with

New Version 21

changes.mady.by.user Renghanath Natarajan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from this space and version 1.5.86

...

  • FWD, NDF, SWP, NDS requests with allocations (360T "Trade on Behalf", TOB) never include tenor codes, Whisperer will always pass such requests through as Broken-dated.
  • In the "Classic" applet, User IMM dates (March, June, September and December) are passed through as specific tenors. In the Bridge UI however, the same selections are delivered as broken dates.
  • Note also that in UAT at least, 360T Tenors via the Bridge are currently subject to change.

Block Pricing

When Whisperer receives a Block QuoteRequest from 360T, it needs to identify and net all allocations per value date leg, in order to determine and provide the overall LegSide in the Client QuoteRequest. All 360T Block requests are one-way.

The Client needs to take the following steps in order to price the Quote correctly:

  1. Net all legs to determine overall trade side.
  2. Use the trade side to determine the side (and thus value) of Spot to Quote. 
  3. Reference LegSide to determine the side (and thus value) of Forward Points to Quote for each leg.
  4. The sum of the above (spot +fwd pts) is the all-in price for Client to Quote for each leg.

...


FX Block Trading Overview

Whisperer Enterprise aggregates allocations into distinct legs grouped per LegSettlDate/ LegSettlType, as per standard market convention across most venues.

360T Block Trades are a simple list of individual allocations with no direct grouping by date.

Details of the Whisperer transformation of the Block trades are as follows:

Technical Workflow

When the Whisperer API receives a Block QuoteRequest from 360T, it performs a deterministic netting process to simplify the request for the client:

  1. Allocation Identification: Whisperer identifies all constituent allocations within the incoming request.
  2. Per-Leg Netting: Allocations are netted per value date (leg) to determine the net quantity for each specific date.
  3. Side Determination: Whisperer calculates the aggregate LegSide across all legs to define the global direction of the request. Note that all 360T Block requests are one-way (strictly Buy or strictly Sell).

Client Pricing Logic

To provide an accurate quote for a multi-leg block, clients must follow a specific pricing sequence:

  1. Determine Aggregate Trade Side: Net the leg quantity across all legs to identify the overall direction of the trade.
  2. Price the Spot Component: Use the aggregate trade side to determine the correct side (bid or offer) and value for the Spot rate.
  3. Calculate Leg-Specific Forward Points: For each individual leg, reference its specific LegSide to determine the appropriate side and value for forward points.
  4. Compute All-in Price: The final Quote for each leg is the sum of the global Spot rate and the leg-specific Forward Points (Spot + Forward Points = All-in Price).

Upon receiving the client's response, Whisperer uses the original allocation side to populate the correct price field in the 360T Quote message: either LegBidPx (Tag 681) or LegOfferPx (Tag 684).

MarketFactory Gateway Attribute Mapping

The following table details how the MarketFactory gateway maps and handles specific Block Trade attributes between Legs and Allocations:

AttributeMF Leg AttributesMF Allocation Attributes
Number of legs/ AllocationsNoLegs (Tag 555): Determined by the total number of unique LegSettlDate values.NoLegAllocs (Tag 670): Determined by the number of 360T allocations sharing the same LegSettlDate.
QuantityLegOrderQty (Tag 685): The aggregate netted quantity of all legs sharing a specific LegSettlDate.LegAllocQty (Tag 673): The individual quantity of the specific allocation, specified in terms of LegSide. Note: This value can be negative.
RegulatoryNoLegRegulatoryFields (Tag 20060): Group containing regulatory data mapped at the leg level.NoLegAllocRegulatoryFields (Tag 20080): Group containing regulatory data mapped at the individual allocation level.

For detailed field support, please refer to the Regulatory Fields section for the supported LegRegulatoryKey and AllocRegulatoryKey per FIX message.


Certification 

360T requires that the MTF certification is done with the specific algo-id that is to be used in production.

...