Requirements for Fpml Trade Lifecycle Event Model

Requirements for FpML Trade Lifecycle Event Model

Definitions

·  An Event is a change in state to a trade. An event is typically caused either by a trading activity or a market condition, or is predefined by the terms of the contract.

·  A Trading Event is an event that changes the contractual terms of the resulting trade. It includes events such as option exercise, which terminate or replace the existing contract.

·  A Servicing Event is an event that does not change the contractual terms of the trade, but rather is already specified by the contractual terms.

Event Modeling Requirements

1.  The events should be modeled using a consistent, abstract type mechanism with subtypes for different events.

2.  Where an event changes the state of a trade, it should be possible to explicitly identify the before and/or after states of the trade. This implies developing some kind of trade version identification mechanism.

3.  It would be preferred, if possible, to reuse the existing FpML Event type or other components instead of creating new ones.

4.  It would be preferred to base event contents off existing messages or types where possible.

Relation of Events to Documents and Messages

5.  It should be possible to create document containing a collection of summaries of all of the events that occur during the trading, servicing, and evolution of a single trade.

6.  It should also be possible to collect these events in different ways, for example all settlement events that occur for a group of trades on a specific day.

7.  It should be possible to order the events within the document by the date on which they occur, and possibly by the time at which they are expected to occur (e.g. for rate fixings or option expirations).

8.  It should be possible to explicitly identify an event with an identifier that is meaningful outside of the document containing the event.

9.  It should be possible to link each event to the set of FpML messages that may have been used to communicate details of the event (e.g. a RequestTradeConfirmation message following by a ModifyTradeConfirmation message, etc.). The event itself will record the completion of the state change in the trade (e.g., that the trade was confirmed by the counterparty on a particular day), while the associated messages will contain complete details of the interaction that resulted in the state change.

Asset-Class Specific Requirements

10.  Events should be generalized across asset classes where possible. For example, rate observations of interest rates for IR swaps should be handled consistently with price observations of stocks for equity swaps and with FX rate fixings, to the extent practical.

11.  It should be possible to create an event diary for a collection of trades that cross asset classes.

Open questions

·  How do we handle periods of time, such as averaging periods or accrual periods? Do we model them as separate events for the beginning and end?

·  How much change to existing types/messages are we willing to entertain?

·  What is the impact of the distinction between trading and servicing events on event representation?

·  Should events that are foreseen by the contract and do not require confirmation, but yet change the terms of the contract (for example, equity resets in equity swaps that affect subsequent interest payments) be regarded as trading events or servicing events, or somewhere in-between? A similar situation may occur for a notional reset in an FX-linked IRS.