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:
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.
Click here to view a list of all queries
Click here top view a list of all forms
Click here to view a list of all reports
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
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.