12.4 Functional Requirements
Once the purpose of a planned VaR measure is known, functional requirements can be drafted. These are the user’s requirements. They relate to inputs, analytics, outputs, interfaces with other systems, and audit trails. These motivate technology requirements, which are the information technology professional’s requirements. They address architecture, open standards, security, redundancy, and regulatory requirements applicable to financial systems. Below, we focus on functional requirements.
Requirements don’t have to be written all at once. High-level requirements may be sufficient to launch a vendor software search to “find what’s out there.” That search will help the implementation team refine the requirements, which should be fairly specific before any vendor software is purchased. If the search for vendor software is unsuccessful, detailed requirements can be drafted for an internally implemented system.
12.4.1 Requirements Format
There are many approaches for capturing and documenting requirements. One approach employs use cases. A use case describes how a human or external system (known as actors in the use case terminology) interacts with the system in question. By definition, a use case defines a system feature that delivers business value.
Use cases are an excellent medium for describing the functional behavior of VaR systems because they are easy for both business users and IT developers to understand. Use cases can also provide a natural segmentation for phasing the software development. Once use cases are defined, the business team can prioritize them and work with the IT team to define software releases that consist of collections of use cases.
Another benefit of use cases is they provide a strong basis for subsequently testing a VaR system. Defining and documenting a test plan for testing the completed VaR solution can be a laborious process. Because use cases describe usage scenarios, they can be a starting point for test plans and enable the test team to quickly come up to speed on the expected behavior of the system.
As part of the requirements definition process, prototypes or proof-of-concept implementations can be useful. It is difficult to capture and communicate complex system requirements in the written word, so prototypes are valuable for ensuring that everyone understands the ultimate requirements for the VaR system.
Different approaches can be used for prototypes. The form of the prototype is less important than communicating the system requirements effectively. Some examples of effective prototyping strategies include:
- Developing Excel models that show concrete value-at-risk calculation examples
- Creating “wire frame” mockups using Visio or PowerPoint that show sequences of user actions and system results
- Describing output screens or reports using HTML or Microsoft Word documents
These prototypes, in conjunction with formal requirements, can provide a clear vision of the VaR solution to be implemented.
However it is prepared, the requirements document should provide a comprehensive assessment of how the VaR measure is to be used:
- on a day-to-day basis by primary end-users,
- by other users, perhaps less frequently, or
- by systems interfaced with the VaR system.
Below, we discuss some issues to consider.
12.4.3 Instrument Coverage
What instruments should the VaR measure cover? A firm that trades in fixed income, equities and foreign exchange may only want a system for its fixed income portfolio. If it wants to calculate value-at-risk for all portfolios, does it want to implement a single system to cover them all or separate systems for each? Politically, separate departments may want to each “own” their system, but implementing three systems will take more time and cost more money than implementing a unified system. Also, a unified system could calculate firm-wide value-at-risk, taking into account hedging or diversification effects across asset classes.
If a firm holds illiquid assets such as private equity, real estate or power generating facilities, a determination must be made as to the extent, if any, these will be included in the portfolio for value-at-risk analyses. Recall the distinction between market risk and business risk from Chapter 1. Market risk is risk due to uncertainty in instruments’ market values. If an asset or liability is so illiquid that it cannot regularly be marked to market, by definition, it entails no market risk. It may entail business risk, but value-at-risk does not apply. That being said, many firms whose portfolios largely comprise liquid instruments may ascribe mark-to-model values to illiquid instruments for the purpose of incorporating them into the overall VaR measure. Done on a very small scale this may be reasonable. However, if mark-to-model assets comprise more than 5% of a portfolio’s value, VaR measurements can become distorted. An example of this is energy merchants who, around the turn of the century, implemented value-at-risk for spot and forward energy contracts. Some also ascribed mark-to-model values to pipelines, power lines, natural gas wells and power plants, so they could be incorporated into VaR analyses. The economic value of those assets swamped the market value of the liquid instruments. The daily fluctuations in market value ascribed to them by the mark-to-model valuations were all but meaningless. The resulting VaR measurements were worse than useless. They were misleading and contributed to poor decision making.
12.4.4 Frequency of Calculation
Large financial institutions tend to calculate value-at-risk at the end of each trading day. In a typical arrangement, calculations are performed overnight, so the VaR results are available the next morning. Trading floors have many computers at their disposal, but that processing power supports trader analytics and pricing models during the day. At night, the computers tend to be idle, making that a good time to run VaR analyses.
VaR can be monitored on an intraday basis. Continuous monitoring has value-at-risk calculated at closely spaced intervals, say every ten seconds or every minute. Discrete monitoring is less frequent, say every hour. Query-based monitoring occurs, not at scheduled times, but on a user-initiated basis. For example, a trader might want to assess the impact on his portfolio’s value-at-risk of a proposed trade.
If a firm engages in day trading—speculatively trading liquid instruments during the day but closing out positions each evening—end-of-day value-at-risk won’t reflect the market risks the firm is taking. In that case, intra-day VaR analysis may be appropriate.
Intra-day monitoring can pose its own problems, especially if the complexity of a portfolio precludes continuous monitoring. Consider the situation of a derivatives dealer. Throughout the day, its traders put on large derivatives transactions for clients and then proceed to delta hedge with futures or otherwise offset the exposures. Between the time when a client trade is placed and a hedge is applied, the portfolio’s value-at-risk will briefly be elevated, likely exceeding applicable end-of-day VaR limits. Discrete intraday monitoring of such a portfolio would be frustrating. By chance some of the points at which value-at-risk is calculated will fall in the interval between a trader placing a client trade and hedging it, giving a false impression the trader is taking inappropriate risk.
Obviously, functional requirements need to be reasonable. Real time or continuous monitoring may be too computationally burdensome to be feasible. Some banks’ portfolios are so complicated that it takes hours to calculate their value-at-risk once in an overnight run, and that is with networked computers sharing the load.
Real-time continuous monitoring is easy if a portfolio holds exclusively linear instruments, say futures or forwards. A linear VaR measure will run in real time with no compromise on accuracy.
If a firm trades nonlinear instruments, say calls or swaptions, it cannot use a linear VaR measure. Formally, a linear remapping can be applied to a non-linear portfolio, followed by a linear transformation, but output won’t be “approximate” so much as “wrong.” Consider the case of a delta hedged, negative gamma portfolio. Its market risk could be extreme, if the gamma is negative enough. But a linear remapping would treat it as a delta hedged portfolio with zero gamma. Ignoring vega effects,1 it would calculate the portfolio’s VaR as zero irrespective of the magnitude of the gamma.
Value-at-risk can be calculated rapidly for non-linear portfolios using a quadratic VaR measure. To mitigate the significant error the quadratic remapping may introduce, it may be necessary to adopt a low quantile-off-loss VaR metric with a short horizon—say 90% one-day value-at-risk. The most time consuming part of a quadratic VaR computation is constructing a quadratic remapping. In practice, this requires multiple revaluations of the portfolio. Portfolios that hold only vanilla instruments, such as calls or caps, can be valued rapidly, perhaps in real time. Others, such as those holding numerous exotic derivatives or securitizations, can take much longer to value.
Another alternative for rapidly calculating value-at-risk for non-linear portfolios is to use a Monte Carlo VaR measure combined with a holdings remapping and variance reduction. Unlike a quadratic VaR measure, this solution entails no compromise on accuracy, and it can be used with any VaR metric. Run times will surely be longer than those of a quadratic VaR measure if the variance reduction entails its own embedded quadratic VaR measure. However, for some portfolios, especially those holding exclusively vanilla instruments, run times should be brief.
With discrete intraday monitoring, the individual VaR analyses do not have to be spaced far enough apart to allow one to be completed before commencing the next. Some or all of the analyses can be deferred and performed overnight, when computers are otherwise idle. A detailed graph of how the portfolio’s value-at-risk evolved during the day would be available the next morning.
Production VaR measures require as inputs
1. current and historical values for key factors, and
2. the portfolios composition.
The former may already be sourced by the firm for other purposes, or a source may need to be identified. The portfolio composition will be captured from the contract management system. That information may be usable as-is, or it may need to be supplemented. Depending on its source, assess the need for data to be filtered and cleaned. Indicate if inputs will be automated or manual.
The requirements document needn’t identify specific key factors to be used or describe what information is required on individual holdings. That is done in the design document.
In addition to reporting value-at-risk for the overall portfolio, the system may need to report value-at-risk for individual trading book, traders or other sub-portfolios.
How will outputs be disseminated? If they will be included in a daily risk report, will they be transferred into that report manually, or will this be automated?
Outputs should include data to be used in backtesting the system. See Chapter 14.
Many VaR systems need to interface with multiple other systems to obtain inputs and provide outputs. Inputs include historical market data, current market data and portfolio holdings. Different outputs may be required for front office, middle office, back office, accounting, compliance and audit functions. Outputs also must be archived for backtesting purposes.
Below are described several portfolios. Explain any particular challenges or considerations each might pose for implementing a VaR system.
- A pension plan has its assets invested 40% in equities, 30% in fixed income and 30% in commercial real estate.
- A limited partnership actively trades commodity futures during the day but mostly closes out positions at night.
- An investment bank holds a sizeable inventory of equities, including initial public offerings it has just bought to market.
- A wealthy individual collects fine paintings and wants to quantify the market risk in her collection.