Principles of Quantitative Development

4.6 AGGREGATE VIEWS

When the trade reaches the market risk management group, there is a subtle change in the perspective from a trade-level view to a portfolio- or book-level view. We can think of portfolio or other groupings as aggregate views. Aggregation is a trivial process mathematically. After all, when you put a bunch of trades together, you get an aggregate view like a portfolio. How robust the portfolio hierarchy needs to be is a design consideration in the trading platform.

A weak portfolio structure can be implemented, for instance, by adding an attribute to the trade object. In this design, any modification to this attribute creates a portfolio implicitly. Such autogeneration of portfolios without any checks and approvals may not be compatible with the workflow and policies of the bank.

A more robust portfolio hierarchy would live in the database where the trades are booked, with specific access controlled user interfaces for creating and managing portfolios. Regardless of where the portfolio is defined, it is still necessary to decide how to lay it out in the memory when the trading platform is running. Do we make collection or container classes to hold trades in portfolios? Or do we keep it as a trade attribute? Does the hierarchy need to be nested with multiple levels and overlaps? We need to address all these considerations at the design stage in order to avoid incompatibilities and weaknesses after the implementation of the trading platform.

Figure 4.4 The queue ...