FpML Trade Execution Messages - Proposal

Introduction

During the development of FpML 4.2, the A2A trade notification messages were deprecated in favor of the new contract notification messages. However, the contract notification messages do not cover reporting of a new block trade (trade execution). Issue #367 ( was reported to address this point.

To resolve this issue, I propose adding three new messages:

  • TradeExecuted - to report a new trade execution
  • TradeModified - to correct a previous execution report
  • TradeCancelled - to cancel a trade execution raised in error.

This document outlines the proposed messages and how they fit into the overall FpML business process flow.

Proposed message layouts

This section describes the trade execution messages.

TradeExecuted

This message is used to report the execution of a block-level trade. Content model is similar to the previous TradeCreated message. Similar to an NOE (Notice of Execution) in FIX.

It contains a trade and 2 or more parties.

TradeModified

TradeModified – use to report a modification to a previously-reported trade execution. Content model includes:

  • optionally, the original version of the trade, or just an identifier
  • the revised version of the trade
  • 2+ parties

TradeCancelled

This is used to cancel a previously reported trade execution, e.g. if the trade was raised in error. Content model includes either a trade identification section or a complete trade, plus one or more parties.

Sample workflows

Normal RFQ execution flow

The TradeExecution message could be the first message in a flow, or could happen as the result of a previous RFQ process.

In the case of an RFQ, the “QuoteAcceptanceConfirmed” message of FpML 4.x would be deprecated in 4.x once the change is approved, and removed in version 5.0, and the TradeExecuted message would be used in its place.

The TradeExecuted message would typically be followed by an allocation process, initiated by the RequestAllocation message.

The following diagram illustrates the overall flow of an RFQ, Trade Execution, and Allocation process:

Correction and cancellation flow

In the case of an error in the original TradeExecuted message, the TradeModified message is provided to correct the details.

The following diagram illustrates the scenario where a trading platform reports an execution, then corrects it twice (presumably due to an interaction out of scope of this diagram, such as GUI interactions), then finally decides that the trade was raised in error and cancels it.

Open Questions

It’s unclear whether these messages should go into the “fpml-tradexec.xsd” subschema or the “fpml-trade-notification.xsd” schema. If the first, the fpml-trade-notification.xsd subschema should probably be eliminated in version 5.0.