FpML Trade vs. Contractp. 1 of 5

Trade vs. Contract

Background

Until FpML version 4.2 TR#3, OTC derivative transactions had always been represented using the “Trade” structure. FpML 4.2 TR#3 introduced the idea of “Contract” for notification of derivative transactions. Since “Contract” and “Trade” cover similar concepts, it would be helpful if the standard clearly defined the relationship between these concepts.

Definitions

In the current version of the FpML schema, there is no annotation defining the term“Contract”, or explaining its relation to “Trade”. Nor, for that matter, is there a useful definition of “Trade”, as the current definition is circular:

  • From fpml-doc-4-2.xsd: Trade: A type definiting(sic) an FpML trade.

From the FpML 4.2 TR#3 Introduction, Trade is defined as follows:

  • A trade is an agreement between two parties to enter into a financial contract and the trade component in FpML contains the information necessary to execute and confirm that trade.

Also from the same Introduction, Contract is contrasted with Trade as follows.

Historically in FpML, there was no distinction between “trade” and “contract”.

However, the term "trade" should only be used to refer to the trading event and the resulting trade specifications. From there on all changes to the contracts should not be called trades, nor should the contract itself.

Trade is the transaction between a buyer and seller. Contract is the legal agreement that governs the transaction. In the contract, we can reuse the same information that details the transaction, but the contract is the legal agreement between the parties. Trade has been overloaded in FpML to cover the meaning of a contract, but that’s a mistake. Parties amend contracts, novate contracts, terminate contracts, increase contracts, not trades.

In order to allow for this distinction, a new definition of Contract has been introduced. The contract content is similar to the existing FpML trade content model but some elements have been omitted since they are not relevant for the contract definition.

I propose that we define the terms clearly in the schema, to clarify the difference between the two concepts, and their relation to similar concepts. The following proposed definitions are based on the descriptions above.

  • Trade is a business event in which two parties agree to enter into a contract or contracts. A trade occurs at a single point in time. A trade may result in a single contract, or if the trade is allocated, it could result in multiple contracts. The trade description may include the economic and possibly other terms that were agreed.
  • Contract is a legal agreement between two parties governing an OTC Derivative transaction. A contract lasts over an extended period of time (the life of the transaction), and defines the rights and obligations of each party, including economic and legal terms.
  • Position is the economic result of one or more financial transactions (such as trades, contracts, or securities transactions).

It is important to note that the proposed definition of “trade” is different from that currently implicitly used in FpML in many places. The current FpML implied definition overloads the concept of “Trade” with two meanings (the trading event, and the resulting contract). While I disagree that that this is necessarily wrong, it is certainly true that the second part overlaps with the meaning of “Contract”.

Issues

If we accept the distinction between “Trade” and “Contract” in the FpML 4.2 TR#3, there are a number of issues in the current version of the schema. These include the following:

  • The existing Confirmation messages refer to “Trades”, but with the new definitions above they should refer to contracts, since contracts rather than trades undergo the confirmation process.
  • With the deprecation of the A2A messages, it’s unclear how to report/notify of the execution of a trade (i.e. the original block trade). An example of where this would be required would be a message from a trade execution or entry platform to a system that performs trade allocations.
  • Exactly how a trade transitions to a contract is unclear. What message or message sequence is used? How is each construct identified? Is there any assumption about the relation of a trade ID to a contract ID? (e.g. are they allowed to be the same?)
  • The allocation messages should perhaps be adjusted to allow trades to be allocated to contracts. However, the existing allocation structures allow N-level allocation, and it’s unclear how to accommodate this if the allocations are to contracts. Alternatively, we could allow “allocation trades”; the bottom level allocation trades would correspond one-to-one to contracts, and somehow link these to contracts.
  • Should a “trade” be considered an event, similar to a post-trade event? (E.g. should it have an event ID?)
  • Should contract-specific fields such as “governing law” and “documentation” be removed from the “Trade” type?
  • Do we have the right dates for the “Contract” type? The current type structure has the field “contractDate” (with no definition in the schema), but this does not appear to be an ISDA defined term (see ISDA 2000 definitions). I assume that “contractDate” is intended to be the same as “Trade Date”, but the ISDA confirmation template examples show that a confirmation letter can have a date different from the trade date. Frequently in everyday business use, “contract date” implies the date the contract was issued or signed, which may be different from the date the original agreement was struck (especially if the contract is modified/amended subsequent to the original agreement). So we should clarify what this field means, and whether we might need any additional fields, such as perhaps, “contract issued date”, “contract agreed/confirmed date”, etc.
  • For the post-trade contract notification messages, how do we specifically identify the events (as opposed to the contracts)? They are not currently based on the FpML “Event” type, so they do not have an eventId, so there is no way to record a specific identifier for the event itself.
  • There are many post-trade events that refer to “Trade”, for example messages around amendment, termination, novation, etc. Presumably these should be modified to refer to contracts, as per the description above from the FpML 4.2 Introduction. Do we also want to have the ability to negotiate/execute post-trade events at the block trade level, not just the contract level? (I think not, but it’s worth asking the question for the sake of completeness).
  • Should “Position” be modified to allow it to reference Contracts? If it can include either trades or contracts, should there be any guideline on when to use one or the other?
  • The same question exists for the other valuation reporting messages – should they be allowed (required?) to reference contracts rather than trades?
  • Should other reporting and reconciliation (cash flow reconciliation, portfolio reconciliation) messages and types use the “contract” terminology rather than “Trade”?
  • For version 5.0, what is the relationship between Trade and Contract (and their corresponding product representations) and views? Should there be any difference between the degree of flexibility/rigidity in the product representation used for Trade vs. Contract? (E.g. should we be more flexible with “trade” than “contract”? Does it depend on the view?)
  • In the current working draft in progress of FpML 4.3 (which is nearly identical in content to 4.2 TR #3), there are approximately 64 complex types whose name contains the word “Trade”, and 84 types that contain at least one element or type named “trade” (or “Trade”). All of these should be reviewed to determine whether their use of the word “trade” is consistent with the definitions above. From a preliminary inspection, a significant proportion of these either should or could refer to “contract” rather than trade; many of these have not been discussed above. For example, consider “RequestTradeStatus”, “TradeNotFound”, “TradeMatched”, “BestFitTrade”, etc. Many of these represent messages or types that could apply equally to either concept, and so might require duplication or a choice group to support both concepts.

Possible solutions

There are a number of solutions that I can see to this situation:

Leave as-is

The easiest reaction to the above issues is to ignore them, assuming that users of the standard will be able to figure out how to deal with the issues. This is likely, however, lead to significant confusion about when to use “trade” and when to use “contract”, especially for buy-side institutions extending their use from the contract notification messages to other areas of the standard.

Leave as-is, but document more fully

A slightly better solution would be to leave the structure as it is, but more clearly document the terms and explain the overlap, historical reasoning, expected future evolution of the use of the two types, etc. This is likely to be challenging to do clearly, due to the number of issues, but has the advantage of requiring no technical changes. This could be done at any time, for example even in the “Recommendation” version of 4.2

Step Back – Eliminate “Contract”

The simplest way to resolve the above issues is probably to eliminate the use of “Contract” and revert to “Trade” throughout, documenting that the term “trade” can refer to both the original trading event and the resulting contract. To provide some additional clarity, the trade header could be tweaked to provide separate identifiers for the original trading event and the resulting transaction/contract.

However, this would in turn cause a number of problems, including:

  • This perpetuates the overloading of the term “Trade”, which many FpML participants agree is problematic.
  • This would be confusing and frustrating to users of the contract notification messages, who are firms that we would particularly like to encourage to use FpML right now.
  • There would be a timing issue to address in the transition of the notification messages to using “trade”, because it would be backward incompatible and therefore not allowed in a minor version (unless implemented in 4.2 prior to Recommendation status).

Unless we take the drastic step of implementing this by the FpML 4.2 Recommendation, this solution probably could not be fully implemented before 5.0, though the new messages may be able to be partly implemented in 4.3.

Switch from “Trade” to “Contract” where applicable

The cleanest solution to the above problem above would be to completely move to something like the definitions above, and modify the existing messages to respect the new definitions.

  • Change the confirmation messages to refer to contracts, since OTC transactions are generally confirmed at the allocation (contract) level, not the original trade level. This may include affirmation messages, or we may decide that we need the ability to affirm both trades and contracts.
  • Ensure that there is a way to notify of trade (not just contract) execution. This will involve either creating new messages or perhaps un-deprecating the A2A messages.
  • Ensure that there is an explicit way to link trades to contracts (e.g. through identification) where relevant. The ContractCreated message has a way to do this already, although it’s not clearly documented how to use this feature. We should determine if there are other cases where this might be required, e.g. for trade allocation, confirmation, etc.
  • Consider adjusting the allocation messages to allocate to contracts, or alternatively to link the allocation trades to contract IDs.
  • Modify post-trade messages to refer to contracts rather than trades.

This solution probably could not be fully implemented before 5.0, though parts of it may be able to be implemented in 4.3. This might include, for example, new ContractConfirmation messages and enhancements to the allocation messages to allow contracts to be referenced. The attached document, “Proposed Implementation of Trade vs Contract” shows one way this could be done.

Derive “Trade” and “Contract” from a common base type

In this solution, a variant of the previous one, both “Trade” and “Contract” would be derived (e.g. via extension) from a common base type, perhaps called “Transaction”. Existing messages that refer to “Trade” would in many cases be modified to refer to the base type, so that they could be used for either variant. The elements in Trade named “tradeHeader”, “tradeId”, etc. would be renamed to eliminate the “trade” prefix and be consistent between Trade and Contract. Type substitution or substitution groups (or perhaps just a choice structure) would be used to allow one variant or the other to be communicated.

This solution is likely to require at least as much effort as the previous one, but may result in a cleaner set of resulting types or messages. More analysis is required to determine the best way to implement this, if it is deemed to be an attractive option.

This solution could be implemented in version 5.0.