Blog

The only essential content of a Product is the list of payment obligations and rights to make choices which it assigns. Given how important payments are in this conceptual framework, it is worth spending examining their structure. To specify a single cash flow, we need to know how much is paid when, and to whom. It is useful to divide the information this conveys into some distinct components:

1. The payment date. Although an intra-day  time resolution is necessary for many aspects of handling derivatives, such as option expiry, market practice is to require settlement on a specific day, so a date suffices.
2. The notional.  Let's defer the juicy topic of specifying the exact amount of a payment until later posts and for now identify an overall scaling factor that multiplies a flow.
3. The accrual fraction. By calling out an accrual fraction, we are essentially saying that we expect the units of the amount (again, see later posts...) of the payment to be annualized. The accrual fraction can always be 1 if the payment is not of a rate-like quantity.
4. The direction. From the point of view of one party to a contract, payments (that contribute to the contract's value to that party) are either made or received. A sign convention must be chosen, with the natural one being that a positive sign indicates receipt. Some Product structures are highly complex, with many levels of nesting of Products, so expressing payment direction with a naked negative sign is highly error prone. It is safer for each Product to be associated with an explicit instruction to pay or receive, although during any valuation, the effect is to insert minus signs in appropriate places. In addition, pay/receive in some contexts becomes buy/sell, so an appropriate choice of name that accounts for both possibilities should be made.
5. The currency. Cash payments must be made in a currency. When the value of a Product is reported, it is natural to do so as a collection of values in each currency in which payments are made. Calculating the value of a multi-currency Product in a single currency is a separate step and part of the details of a particular valuation approach rather than being anything intrinsic to a Product. Indeed, the reporting currency for a given valuation need not be any of those in which payments are made.
6. Collateral. Every cash flow (indeed, every Product) may have an associated collateral agreement. This impacts any calculation of value that takes the risk of counterparty default into account, either by discounting at an appropriate rate or via an explicit calculation of exposure.
7. Auxiliary information. Given that this series considers the problem of developing a platform for the valuation of derivatives, it is natural to divide the total information content of a particular Product into two categories: that pertaining to its value and everything else. While not essential to valuation, it can be useful for a Flow to be labeled with auxiliary information, such as the counterparty, an ID indicating to which trading book the Flow belongs, or the ID of the Flow in some external system.

In 2 and 3 above, I alluded to the problem of specifying the amount of a payment. I'll cover that in my next few posts, before returning to other types of Product that go beyond a simple single flow and allow us to describe essentially any derivative contract.