The Lab

Expand all   Collapse all

Versions Compared

Old Version 2

changes.mady.by.user Hymavathi Velagapudi

Saved on

compared with

New Version Current

changes.mady.by.user Matthew Whitaker

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.77

Table of Contents

Change Summary

Red/Amber/Green box depending on severity.

Whisperer Client Impact

No changes required from the Clients.

Note
Tip
titleNormalisation Changes

Background

To provide a normalised view of the ExecutionReport received by Clients, there changes are corrections being made to the quantity fields to be listed below. Currently these values are taken directly from the Venue messages.  

For the venues where these values are not as per Whisperer standard, improvements are being made to bring them inline with the schema . Details of changes to each field are listed below:

  • LegAllocCalculatedCcyQty - As per the schema, ABS (SUM (LegAllocCalculatedCcyQty))=LegCalculatedCcyLastQty. For the affected venues listed below the calculation does not match.

    • definition.

    LegAllocQty - As per the schema, 

    Field

    		Schema definitionNormalisation IssueAffected VenuesRelease Version
    LegCumQtyTotal quantity filled so far on this Leg of the Order.

    LegCumQty is populated inconsistently by some venues across different OrderStatuses.

    		autobahnfx_rapid, baml, barx, citi_colo, rbc_trading, standardchartered_s2bx, statestreet_efx, t360_tex.

    2025.11.19.WE.RHEL9 - bnpparibas_efx_algo, fxspotstream_algo, precision_algo, ubs_algo, autobahnfx_rapid, baml, bgc_midfx, broadridge_orders, bnpparibas_efx_streaming 

    2025.12.03.WE.RHEL9 - All venues except lseg_ftg, refinitiv_mapi, barx, jpmorgan_fx_algo 

    2025.12.04.WE.RHEL9 - All venues

    LegLeavesQtyQuantity remaining to execute on this Leg of the Order.LegLeavesQty is populated inconsistently by all venues across different OrderStatuses.All taker APIs

    2025.11.19.WE.RHEL9 - bnpparibas_efx_algo, fxspotstream_algo, precision_algo, ubs_algo, autobahnfx_rapid, baml, bgc_midfx, broadridge_orders, bnpparibas_efx_streaming 

    2025.12.03.WE.RHEL9 - All venues except lseg_ftg, refinitiv_mapi, barx, jpmorgan_fx_algo 

    2025.12.04.WE.RHEL9 - All venues

    LegAllocQty

    If ExecType=Calculated/Trade then ABS (SUM (LegAllocQty))=LegLastQty, otherwise ABS (SUM (LegAllocQty))=LegOrderQty

    . There are inconsistencies across the venues where the value

    LegAllocQty is is populated inconsistently across different ExecTypes.

    LegAllocQty issent as 0 for

    cancelled/rejected orders.

    Cancelled ExecutionReports.

    		All taker APIs2025.08.29.WE.RHEL9 - All venues
    LegAllocCalculatedCcyQty

    If LegCurrency is LHS then=-LegAllocQty*LegLastPx;

    if LegCurrency is RHS then=-LegAllocQty/LegLastPx (rounded to the precision of LegAllocQty, half-up)

    		Allocation side is not taken into account for some venues and thus LegAllocCalculatedCcyQty is always sent as positive.autobahnfx_algo, baml, exchange24
  • LegCumQty - This is a mandatory field to be populated in the ExecutionReport and currently it is based on what venue sends and is not in line with the schema which is "Total quantity filled so far on this Leg of the Order".

    • Changes

    1) LegAllocCalculatedCcyQty - ExecutionReport now reflects the signed value and the calculation is inline with the schema.

    Affected Venues: autobahnfx_algo, baml
    , fxspotstream_algo, precision_algo, xtx_euthenia

    2) LegAllocQty - ExecutionReport now reflects the signed value and the calculation is inline with the schema.

    AffectedVenues: All taker APIs

    3) LegCumQty - This is now the cumulative qty of all the fills of the order if OrdStatus is PartiallyFilled/Filled/PendingCancel/Cancelled/PendingReplace/Expired and 0 otherwise.

    AffectedVenues: autobahnfx_rapid, baml, barx, citi_colo, rbc_trading, standardchartered_s2bx, statestreet_efx, t360_tex.

    Timeline

    At the client's discretion.

    Clients are advised to contact the MarketFactory Delivery Team to enable this feature in UAT for testing and subsequently deploy the changes in production.

    Warning
    titleContext

    TODO - Actions required of the Client in order to accommodate the change.

    Change Details

    Additional technical content

    Documentation

     2025.09.04.WE.RHEL9 - autobahnfx_algo, baml, exchange24, fxspotstream_algo, precision_algo, xtx_euthenia

    Change

    This change will ensure that the above quantity fields are normalised consistently across all venues OrdStatus/ExecType combinations. These fields will never be null in the ExecutionReport.

    Timeline

    • Phased rollout starting August 2025.

    Whisperer Client Impact

    Note

    Clients should consider the impact if they are reliant on these fields of the ExecutionReport. These fields will never be populated as null.

    Change Details

    • LegCumQty and LegLeavesQty: 

    Quantity received from the Venue will be evaluated/corrected to match the expected behaviour below:

    OrdStatusCumQtyLeavesQty
    New0LegOrderQty
    PendingNew0LegOrderQty
    Rejected00
    Partially FilledTotal quantity filled so far on this Leg of the Order.LegOrderQty-LegCumQty
    FilledLegOrderQty.0
    Pending Cancel

    Total quantity filled so far on this Leg of the Order.
    0 if there are no PartialFills.

    Total quantity filled 

    		LegOrderQty-LegCumQty
    CanceledTotal quantity filled so far on this Leg of the Order.
    0 if there are no PartialFills.    		0
    Pending ReplaceTotal quantity filled so far on this Leg of the Order.LegOrderQty-LegCumQty
    ExpiredTotal quantity filled so far on this Leg of the Order.
    0 if there are no PartialFills.    		0
    • LegAllocQty:

    Thiswill be populated with LegOrderQty except for the ExecType Trade and Calculated, where this will be LegLastQty.

    • LegAllocCalculatedCcyQty:

    This will be populated as a negative value if LegSide matches with the allocation Side, and a positive if LegSide does not match with the allocation Side. 

    ...