In this series, I have defined the concept of a Product as a collection of obligations to make Payments (and rights to other Products). I was careful to delegate the task of stating the payment amount to another concept, that of an Index. I showed in Part 4 how the Index concept was far more general than the simple examples (underlyings) used to introduce it and in fact covers payoffs of arbitrary complexity. However, at no point in the above have we mentioned *modeling*.

I have alluded to it, in so far as we have focused on the information content within a contract that is pertinent to its financial worth, but I have stayed within the realm of the lawyer and not strayed into the mathematical domain of the quantitative analyst. This may seem surprising at first sight, because complex payoffs certainly do appear mathematical, and indeed they are, but they are strictly just expressing part of a legal obligation. They influence the value of the contract in the same way that the notional does; by determining the actual cash amount that is settled on a given date. On this date, no modeling assumptions are necessary, the value of each underlying is known, and a simple calculation will render the amount that one party owes another.

The task of the quantitative analyst (in the application of conventional risk-neutral pricing), is to form a suitable prediction of these payment amounts ahead of time. In other words, to make a well-chosen set of modeling assumptions for the relevant underlyings that allow the construction of a probability distribution of present value of the contract, whose mean is the arbitrage-free price.

This is now the world of sophisticated mathematical and computational techniques, and modeling judgment. Identifying these two realms as distinct, and defining our concepts accordingly, is a very deliberate choice, and a subtle one. Historically, due to the mathematical nature of both complex payoffs and modeling techniques, they were often blended together in the design (or evolution) of software systems.

If we instead keep what is valued (Product, Index) separate from how it is valued (Modeling), then there is far greater opportunity for reuse of subcomponents. Exotics and vanillas are valued in a consistent manner. The same modeling code can be used to value multiple contracts, and a given payoff calculation can be reused for a variety of modeling assumptions. Modeling effort is expended once, not on a per-trade basis customized for each payoff. And by being clear on where modeling ends and payoff expression takes over, each payoff component is written just once, for all models.

The separation also aids conceptual clarity. When comparing the value of a single contract under N different modeling assumptions, it is very useful to have a single object representing the contract and N objects for the models. Furthermore, within a given set of modeling assumptions for a group of underlyings, the task of pricing new structures does not need the expensive mathematical and computational sophistication of a quant; only an understanding of the simpler constructs found within financial payoffs and expressed by means of Indices. The ultimate goal of the providers of pricing libraries is to scan a term-sheet automatically (or to facilitate the representation of the legal agreement electronically in the first place). The conceptual separation of Product from modeling is an important step toward this goal.

So what is a model? What do model objects contain? What can you do with them? I'll answer these questions in my next post.