12.4  Functional Requirements

Once the purpose of a planned value-at-risk 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 ofvalue-at-risk 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 avalue-at-risk system. Defining and documenting a test plan for testing the completedvalue-at-risk 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.

12.4.2 Prototypes

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 thevalue-at-risk 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 thevalue-at-risk solution to be implemented.

However it is prepared, the requirements document should provide a comprehensive assessment of how the value-at-risk 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 thevalue-at-risk system.

Below, we discuss some issues to consider.

12.4.3 Instrument Coverage

What instruments should the value-at-risk 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 value-at-risk 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, value-at-risk 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 intovalue-at-risk 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 value-at-risk 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 thevalue-at-risk 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 runvalue-at-risk analyses.

Value-at-risk 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-dayvalue-at-risk 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-dayvalue-at-risk 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 value-at-risk 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 value-at-risk 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’svalue-at-risk as zero irrespective of the magnitude of the gamma.

Value-at-risk can be calculated rapidly for non-linear portfolios using a quadratic value-at-risk measure. To mitigate the significant error the quadratic remapping may introduce, it may be necessary to adopt a low quantile-off-loss value-at-risk metric with a short horizon—say 90% one-day value-at-risk. The most time consuming part of a quadraticvalue-at-risk 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 value-at-risk measure combined with a holdings remapping and variance reduction. Unlike a quadratic value-at-risk measure, this solution entails no compromise on accuracy, and it can be used with any value-at-risk metric. Run times will surely be longer than those of a quadratic value-at-risk measure if the variance reduction entails its own embedded quadratic value-at-risk measure. However, for some portfolios, especially those holding exclusively vanilla instruments, run times should be brief.

With discrete intraday monitoring, the individualvalue-at-risk 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.

12.4.5 Inputs

Production value-at-risk 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.

12.4.6 Outputs

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.

12.4.7 Interfaces

Manyvalue-at-risk 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.