
Financial instruments and pricing engines 13
results. It consists in writing corresponding methods (here, firstLegBPS and secondLegBPS) which
ensure that the calculations are (lazily) performed before returning the stored results.
The implementation is now complete. Having been written on top of the Instrument class, the Swap
class will benefit from its code. Thus, it will automatically cache and recalculate results according
to notifications from its inputs—even though no related code was written in Swap except for the
registration calls.
2.1.4 Further developments
You might have noticed a shortcoming in my treatment of the previous example and of the
Instrument class in general. Albeit generic, the Swap class we implemented cannot manage interest-
rate swaps in which the two legs are paid in different currencies. A similar problem would arise if
you wanted to add the values of two instruments whose values are not in the same currency; you
would have to convert manually one of the values to the currency of the other before adding them
together.
Such problems stem from a single weakness of the implementation: we used the Real type (i.e., a
simple floating-point number) to represent the value of an instrument or a cash flow. Therefore,
such results miss the currency information which is attached to them in the real world.
The weakness might be removed if we were to express such results by means of the Money class.
Instances of such class contain currency information; moreover, depending on user settings, they
are able to automatically perform conversion to a common currency upon addition or subtraction.
However, this would be a major change, affecting a large part of the code base in a number of ways.
Therefore, it will need some serious thinking before we tackle it (if we do tackle it at all).
Another (and more subtle) shortcoming is that the Swap class fails to distinguish explicitly between
two components of the abstraction it represents. Namely, there is no clear separation between the
data specifying the contract (the cash-flow specification) and the market data used to price the
instrument (the current discount curve).
The solution is to store in the instrument only the first group of data (i.e., those that would be in its
term sheet) and keep the market data elsewhere.⁸ The means to do this are the subject of the next
section.
2.2 Pricing engines
We now turn to the second of the requirements I stated in the previous section. For any given
instrument, it is not always the case that a unique pricing method exists; moreover, one might want
to use multiple methods for different reasons. Let’s take the classic textbook example—the European
equity option. One might want to price it by means of the analytic Black-Scholes formula in order to
⁸Beside being conceptually clearer, this would prove useful to external functions implementing serialization and deserialization of the
instrument—for instance, to and from the FpML format.