Note: This project was completed on April 15, 1998 prior to the issuance of SFAS 133.

Background and Introduction to Risk

The heart of this project is a relational database. The term project topic was suggested aids for using emerging technologies in measuring and evaluating investment risk. To that end, I created a relational database that is able to track the use of derivative instruments and assign a measure of risk to individual contracts. The creation of the database is an attempt at dissaggregated reporting. Theoretically, an investor could access the database through the Internet and compute custom reports and evaluate individual measures of risk associated with each derivative. The benefit of dissaggregated reporting lies in the investor’s ability to perform the aggregation of relevant data. In today’s environment, investors have to rely on annual financial statements of a company to acquire relevant information. The financial statements of a company do not always provide a complete picture of the financial condition of the company. Notably, off-balance sheet items such as derivative financial instruments do not appear in the body of the financial statements. The FASB and the SEC have made strides to overcome this reporting deficiency with pronouncements that require more informational disclosures in the financial statements.

FASB statement 119. the most recent standard regarding derivatives, requires disclosures about the amounts, nature, and terms of derivative financial instruments that are not subject to FASB statement 105. SFAS 119 also urges companies to report quantitative information about the risks associated with derivative financial instruments. It also requires more adequate disclosures of information of off-balance sheet risk, including dissaggregation of data. Under SFAS 119 the fair value of derivative financial instruments must also be presented. The SEC requires detailed disclosures for derivative instruments, including accounting policies and qualitative and quantitative information about the risks associated with derivatives. Most recently, FASB exposure draft 162-b. Accounting for Derivative and Similar Financial Instruments and for Hedging Activities, proposes mark-to-market accounting for all derivative instruments.

All of above statement and pronouncements are all attempting to give guidance to companies so they can provide adequate disclosure about the risks associated with derivative financial instruments. These risks can be classified into five main categories: general risk, credit risk. interest risk. legal risk and operational risk. General risk is the risk that a company will have a financial loss due to the use of derivative financial instruments. The loss might arise from an excessively high notional amount or a lack of research on the party entering the swap. Credit risk, or counterparty risk, is the exposure to the possibility of financial loss resulting from another party’s failure to meet its financial obligations (Bataglia 53). Interest risk, or market risk, is the risk that financial loss would occur due to fluctuations in interest rates. Legal risk is the risk that financial loss might result from the use of derivatives by action by a court. Operational risk is a system wide measure of risk and is associated with inadequate systems, human error, faulty controls, or human error. All of the above classifications of risk are both subjective and objective in nature, because of this, quantifying them presents a problem for companies.

As an attempt at a solution to the problems of using derivative instruments, I propose a relational database that not only keeps track of fluctuations in cash flows for each derivative contract, but also measures the risk associated with each contract.

My Project — Risk Management Database

The objectives in creating a relational database were as follows:

1. Create a database that could keep track of fluctuating cash flows resulting from changes in a variable interest.
2. Create a database that could support a sensitivity analysis. (i.e. demonstrate the cash flow ramifications if interest rate rise or fall).
3. Keep track and measure counterparty or credit risk associated with each contract.
4. Keep track and measure general risk associated with each contract.
5. Keep track and measure interest risk associated with each contract.
6. Keep track and measure legal risk associated with each contract.
7. Keep track and measure operational risk associated with each contract.
8. Summarize portfolio risk
9. Summarize portfolio cash flows
10. Provide a framework for dissaggregated reporting.

I used Microsoft Access as a development platform for the risk management database. For simplicity, I limited the different types of contracts to interest rate swaps. More specifically, I only included interest rate swaps receiving the fixed rate and interest rate swaps receiving the variable rate (based on LIBOR). The database is organized by tables, queries, forms, reports, and macros. Click here for a discussion of the organization of the database.

The table is the basic data store; general information about each type of derivative is stored in a table. For example the IRSwapRecFixed table holds information like, the fixed interest rate, the notional amount, the date entered into, etc. (IRFSwapRecFixed stands for Interest Rate Swap – Receive Fixed) Similarly, the IRSwapRecVariable table holds comparable information on all interest rate swaps receiving the variable rate. The distinction is made between the two types of swaps because the associated risks are different. For example, an interest rate swap – receive fixed, carries with it a greater degree of interest risk because the company is paying a variable rate. If the variable rate increases above the fixed rate, the company will lose money. More information stored in tables includes counterparty information, LIBOR history, and all measures of risk. Below is a picture of the database tables window and summary of all the table names along with a brief description of what each table includes.

1. Counterparty – Includes all relevant information about each counterparty that the Company engages in swaps with.
2. IRSwapRecFixed – Includes all relevant information about each receive-fixed contract
3. IRSwapRecVariable – Includes all relevant information about each receive-variable
4. Libor – Includes a history of the LIBOR rate
5. OperationalRisk – Includes all the relevant information about operational risk.
6. IRFCreditRisk and IRVCreditRisk – Both tables include information about credit risk
7. IRFGeneralRisk and IFVGeneralRisk – Both tables include information about general risk
8. IRFInterestRisk and IRVInterestRisk – Both include information about interest risk
9. IRFLegalRisk and IRVLEgalRisk – Both include information about legal risk
10. IRFJEHistory and IRVJEHistory – Both include a history of the last journal entry that was made for each type of swap

The database keeps track of each derivative contract and assign’s a weighted risk factor to each contract. The database will calculate the cash flows associated with each contract. This is useful as the number of contracts increases. As a company enters into more and more derivative contracts, simply keeping track of the cash flows can be daunting. The database also aggregates the total portfolio cash flow of all swaps. A company can see exactly how much money it is losing or making on a monthly and yearly basis. A sensitivity analysis is also incorporated to show similar cash flows if the LIBOR increases or decreases by .5%. The wonderful thing about this database is that nothing is permanent or built in to the system. If the company wanted to see a sensitivity analysis the had a 1% spread instead of a .5% spread, a simple change in the query would produce the result.

As stated earlier, risk is separated into five categories, general risk, credit risk, interest risk, legal risk and operational risk. The database measures risk based on the answers to various questions on a scale from 1 to 10, with 10 being the most risky. Except for operational risk, all the risk categories are evaluated on a per-contract basis. For example, the IR-12345 contract may have a 7 for interest risk while the IR-12346 contract may have a 5, depending on how the risk questions are answered in each subform. Operational risk is evaluated on a system wide basis. Operational risk is highly subjective and does not vary from contract to contract. Click here for a sample of risk factors per contract.

As the database opens, you will be prompted to enter a password. The database password is jfz . The next screen is the introduction page. You have two choices, go to the input forms section or to go to the reports section of the database. Once in the forms section, click on each button to view, change or add/delete data in that form. For example, if you go to the counterparty form. you can alter, add, or delete information about any counterparty. Use the command buttons to return to the main forms section. You will notice a data form for each of the two types of swaps, Interest Rate – Receive Fixed and Interest Rate – Receive Variable. After you have entered information for a swap, go to the risk assessment section by clicking the risk assessment button at the bottom of the form. The next screen will be a series of subforms all related to risk. For each question in each of the subforms, you are told to insert a 0 for a yes answer and a 1 for a no answer. Since the point of the database is to quantify risk, the more 1’s a risk category has, the more risky it is.

After all the subforms are complete, go to the operational risk form. Note that the operational risk form would normally not be filled out by the person entering swap information into the system. It is intended for third party use. Theoretically, an independent auditor would assess operational risk after substantial evaluation of the entity as a system. Operational risk is subjective in nature and hard to quantify, but it can be done. For each question in the operational risk assessment, the auditor is asked to provide a quantitative grade (from 1 to 10). For example, one question might be How capable are the risk managers at dealing with multiple types and numbers of derivative instruments? The auditor has to judge the managers on a scale from 1 to 10, thus assigning a quantitative evaluation for a subjective answer.

The uniqueness of the database is that it attempts to quantify the risks associated with derivatives. Normally, the risk associated with derivatives is both objective and subjective. For example, the higher the notional, the higher the general risk associated with the contract, that is an objective measure of risk. The purpose of the database is to quantify all risk whether subjective or objective.

Features of the database

1. Individual risk factors for each contract (general risk, credit risk…)– see Risk Factors — Receive Fixed/Variable reports
2. Individual weighted risk factors for each contract. The weighted factor represents a weighted factor of all the individual risks involved per contract – see Portfolio Risk report
3. Portfolio risk factor – see bottom of Portfolio Risk report
4. Individual cash flows by contract number based on a certain LIBOR that you must enter (MMYY) – see Interest Rate — Receive Fixed/Variable reports.
5. Individual sensitivity analysis that shows the cash flow effect of an increase or decrease in LIBOR – see Sensitivity Analysis reports for both fixed and variable contracts.
6. General summary report for each type of swap – see Interest Rate – Receive Fixed/Variable reports
7. Total portfolio summary that includes total yearly and monthly cash flows, aggregate sensitivity analysis, and an aggregate portfolio risk factor
8. The ability to rate the risk associated with a contract before you enter into it. For example, if a company is contemplating entering into a swap with another company and the calculated risk factor for that particular contract is above the acceptable level, the company could demand cash up-front in exchange for the added risk.
9. The ability to aggregate the data in many ways.

The database does have some limitations. Those limitations arise because of the time constraints involved with a term project. I am confident that given more development time, this database would prove to be a useful tool for any company using derivative financial instruments.