At my most recent job, I became familiar with the variable annuities market. Here's what I learned about the product.
Dynamic hedging and variable annuities
Variable annuities are investment products aimed to provide retirement cash-flow to the purchasers (policyholders). The idea is simple: put the retirement money on the stockmarket, charge a large fee (3%-4% a year plus a 6% upfront acquisition charge), and offer pension payments starting, say, 10 year from now, in the amount of 5% of principal a year until the death of the policyholder. The sweet part for the purchaser of the annuity is that the payments will continue even after the account goes empty. The typical rationale is that the stockmarket will provide sufficient returns to support the guarantee given the long horizon. History has proven that rationale wrong and there were cases of annuity writers losing substantial amounts of money.
As such, variable annuities contain complex investment guarantees which make liabilities for the direct writers of annuities. To manage that liability, the direct writers have three options.
1. Do nothing. The hope is that the markets always go up and the liabilities will never actualize. Face market risks.
2. Reinsure the risks. Face counterparty exposure.
3. Dynamically hedge the positions, using liquid exchange-traded instruments. Face model risk and market risk (if there is unexplained negative P&L, then we have a 'hedge breakage").
The risk factors in the variable annuity business can be largely listed as follows:
- regulatory requirements
- stock market
- policyholder mortality
- policyholder's surrender behaviour
- policyholder's portfolio allocation (in most products the policyholder can choose how to invest the money)
- basis risk
- interest rate market (some investment guarantees are attached to the rates of interest)
- model risk
Regulatory risk: the FAS rules require that the variable annuity liabilities are given the fair value and that the institution holds sufficient capital against the deterioration in the fair value. Although the liabilities are very long-dated, the movements in the model-produced fair value can be sharp and can cause the regulator to move in and take action against the direct writer.
Stock market risk: will the stockmarket provide enough returns to pay the policyholders?
Mortality risk: mortality triggers either a lump-sum payment, or annuitization of the guarantee. If the portfolio is large enough, the law of large numbers will guarantee at least some stability in the mortality distribution and so the mortality risk is considered "diversifiable".
Surrender risk: some policyholders will choose to withdraw the funds from the stockmarket account. They will forgo any guarantees of future cash flows, but also deny the writer any future fees and will leave any hedge position naked. Adjustments in the hedge will be required.
Portfolio allocations risk: when putting the money on the stockmarket, the policyholder can choose from a basket of mutual funds. The portfolio chosen may be more or less risky and this affects the value of the liabilities.
Basis risk: the instruments used to hedge the position may have different returns from the mutual funds where the pension money is invested. This can cause the hedge to be inaccurate. Smart annuity writers will restrict the choice of investments for the policyholders.
Interest rates risk: firstly, some variable annuities have returns tied to market interest rates. Secondly, the valuation of the liabilities typically uses the discounted cash flow approach and uses the "risk-free rate curve" to calculate the present value. Thus the interest rate movements affect the model fair value.
Model risk: no model is perfect and the model that most market participants are using have
deficiencies. Lapsation behaviour is one big unknown with most market parcitipants using very simple historical lapsation distribution. Calibration of the market scenario parameters is another tricky area as the products can have life of over 30 years and the choice of time period to calibrate the model is very idiosynchratic. Most of the models use Monte-Carlo to perform the valuation which introduces additional errors. My own view is that a simple model is better and that back-testing is extremely important to identify the weaknesses in the model.
Who are the participants in this market? One of the main players in the variable annuities space is the regulator which is responsible for making sure that the insurer holds significant capital against the investment guarantees made. As the most recent events (2008) show, the taxpayer will eventually foot the insurers' bill if they run out of money so it is in the taxpayers' interest that the likelihood of that event is minimised. With the maturity of the guarantees above 20 years, it's a very challenging task.
Who buys variable annuities, anyway? Turns out they are not bought but sold. The brokers who sell them receive high commission upfront, up to 6% of the principal amount invested. To account for this commission, an accounting technique (read: trick) called DAC=Deferred Acquisition Charge unlocking has been developed - the amount of acquisition charge expensed each year is determined by the stockmarket situation, the worst the performance, the higher the unlocking. Of course, the intent is to compensate through the commissions.
Many authors do not recommend the use of variable annuities as an investment, for example Larry Swedroe in ``The only guide to alterntive investments you`ll ever need``. The very high commissions involved, both ongoing fees and the sales commission, create a conflict of interest for the financial advisors and the insurance companies alike causing them to ignore the best interest of the investors.
Monday, July 6, 2009
Sharing information in a large bank
Challenge: "What's our exposure to GMAC?"
In every large bank with multiple lines of business, such a question is not an easy one to answer.
There are 10 - 20 different computer systems used for booking trades and a similar number of market data feeds. In addition, each trading / sales desk keeps part of the trade information in the desks' own spreadsheets.
While it's easy to tell which trades each desk has on the book, it's harder to know what is the total position with each counterparty if it has relationships with multiple desks, or if a position and its hedge or its collateral are booked by different departments or trading groups.
To find the bank's exposure to a specific counterparty, for example GMAC, it will take days of work. GMAC may be counterparty to different types of deals. GMAC bonds may be held in some of the bank's books and also act as reference asset for CDS and CDO.
A proactive solution is needed to know the bank's positions and risk exposures across all lines of business.
Solution: Build a repository which will receive positions and trades information from all lines of business, in real-time or at the end of each day. It can take the form of an SQL database that will store positions, trades, instruments, market prices, risk measures in its tables. Information will arrive when it's created, it will be time-stamped so that it's easy to produce reports for a previous date, such as the month-end.
Maintain counterparty mapping between different systems. For example, GMAC can be called "General Motors Acceptance Corporation" in one book, "85444" (for example) in another. An effort should be made to make this kind of matching. The advantage of doing it in a systematic way is that once done, it doesn't need to be done again for existing counterparties.
Build processes to collect the required information, automatically wherever possible, manually when required. Create reports using the most convenient presentation tool, Excel.
Brief Plan
In the first phase, which may take 3-6 months, deliver the repository for a book of deals that's most important for the bank at the moment. Firstly, list the data feeds required and the risk analytics needed. Develop the data feeds and the risk analytics code. Develop the reports and present to senior management. Promote the prototype to all interested parties.
In the second phase, expand the project step-by-step to include other bank's positions, in order of priority. Gradually cover most or all of the books.
Detailed plan
1. In the first phase, we need to develop the Integrated Risk Platform for a high-priority, high-visibility deal book. At Scotia, it was the book of structured credit instruments. The report already existed, however each time it took a week to produce. The report was therefore produced only monthly. An introduction of an automated process was very helpful in speeding up the reporting and was a great deliverable to justify a larger project.
2. We need to create a list of people, departments, systems and processes involved in the management of the book. Normally the individuals involved are marketers who sell the products, bookrunners who take care of booking, back office staff involved in day-to-day operations, risk management staff producing the analytics, and middle office responsible for daily monitoring. Since the book is already covered by a number of reports, it's very important to ensure that the changes do not disrupt the existing operation but only make it faster and easier. That is the key selling point of the project.
3. Next we need to select a database and an application engine to store the data and perform the analytical calculations. At Scotia, we decided to use MySQL because it was available at no cost, and the SQL scripting language to perform the calculations. If the organization's staff has substantial experience with a specific type of database engine, then that specific engine can be used. The choice of the platform depends mostly on the developers' experience and cost considerations.
4. We need to design the database schema. A robust visual design application (UML-based) is great for simultaneously producing the schema and the documentation for the schema. It's important to set naming conventions at this point because the multiple systems involved will all have different naming conventions. Data mapping has to be performed and documented. At this point a source control system, such as Subversion, can be used to store multiple revisions of the project code and documentation.
The database schema design will be a continuous process and changes will be needed when new issues come to light.
5. In parallel with the schema design, we should request the data feeds from the staff responsible for the booking systems, and organize the manual data feeds where they are completely unavoidable. There will be a lot of going back-and-forth between the systems staff and the project staff. The most typical format for a data feed is a CSV file, however a more robust result can be obtained by using the XML format. Although it takes more space, it also allows for a more rigorous data definition.
6. Start running the data feeds on the system at the production frequency. Each data feed should be equipped with quality checking code that will inform the operational staff about errors or delays in delivering the data.
7. Start designing the risk analytics code for the book. The code can be developed using either C# or perl, or C++, or even VBA, or SQL stored procedures. We always balance between readability, performance and developer preferences. 8. When the risk analytics code is designed, it's time to document what has been done to the current point and move to developing the reports for the book We have already planned for the information we need to deliver and we have developed the risk analytics code, so producing a report is now a matter of producing appropriate SQL queries and making a high-quality presentation on their basis.
9. Implement the reports using Excel. The objections may be that it's hard to ``lock up`` Excel spreadsheets, however the point here is to produce reports in the most familiar form for the customers. The database and the analytic code can be locked up, however the end-product itself should be as flexible as possible.
10. Schedule and perform a presentation for the senior management to emphasize the advantages of the project: data accuracy, automation, speed of delivery and ease of use. If successful, the presentation will provide the necessary buy-in for the continuation of the project.
In every large bank with multiple lines of business, such a question is not an easy one to answer.
There are 10 - 20 different computer systems used for booking trades and a similar number of market data feeds. In addition, each trading / sales desk keeps part of the trade information in the desks' own spreadsheets.
While it's easy to tell which trades each desk has on the book, it's harder to know what is the total position with each counterparty if it has relationships with multiple desks, or if a position and its hedge or its collateral are booked by different departments or trading groups.
To find the bank's exposure to a specific counterparty, for example GMAC, it will take days of work. GMAC may be counterparty to different types of deals. GMAC bonds may be held in some of the bank's books and also act as reference asset for CDS and CDO.
A proactive solution is needed to know the bank's positions and risk exposures across all lines of business.
Solution: Build a repository which will receive positions and trades information from all lines of business, in real-time or at the end of each day. It can take the form of an SQL database that will store positions, trades, instruments, market prices, risk measures in its tables. Information will arrive when it's created, it will be time-stamped so that it's easy to produce reports for a previous date, such as the month-end.
Maintain counterparty mapping between different systems. For example, GMAC can be called "General Motors Acceptance Corporation" in one book, "85444" (for example) in another. An effort should be made to make this kind of matching. The advantage of doing it in a systematic way is that once done, it doesn't need to be done again for existing counterparties.
Build processes to collect the required information, automatically wherever possible, manually when required. Create reports using the most convenient presentation tool, Excel.
Brief Plan
In the first phase, which may take 3-6 months, deliver the repository for a book of deals that's most important for the bank at the moment. Firstly, list the data feeds required and the risk analytics needed. Develop the data feeds and the risk analytics code. Develop the reports and present to senior management. Promote the prototype to all interested parties.
In the second phase, expand the project step-by-step to include other bank's positions, in order of priority. Gradually cover most or all of the books.
Detailed plan
1. In the first phase, we need to develop the Integrated Risk Platform for a high-priority, high-visibility deal book. At Scotia, it was the book of structured credit instruments. The report already existed, however each time it took a week to produce. The report was therefore produced only monthly. An introduction of an automated process was very helpful in speeding up the reporting and was a great deliverable to justify a larger project.
2. We need to create a list of people, departments, systems and processes involved in the management of the book. Normally the individuals involved are marketers who sell the products, bookrunners who take care of booking, back office staff involved in day-to-day operations, risk management staff producing the analytics, and middle office responsible for daily monitoring. Since the book is already covered by a number of reports, it's very important to ensure that the changes do not disrupt the existing operation but only make it faster and easier. That is the key selling point of the project.
3. Next we need to select a database and an application engine to store the data and perform the analytical calculations. At Scotia, we decided to use MySQL because it was available at no cost, and the SQL scripting language to perform the calculations. If the organization's staff has substantial experience with a specific type of database engine, then that specific engine can be used. The choice of the platform depends mostly on the developers' experience and cost considerations.
4. We need to design the database schema. A robust visual design application (UML-based) is great for simultaneously producing the schema and the documentation for the schema. It's important to set naming conventions at this point because the multiple systems involved will all have different naming conventions. Data mapping has to be performed and documented. At this point a source control system, such as Subversion, can be used to store multiple revisions of the project code and documentation.
The database schema design will be a continuous process and changes will be needed when new issues come to light.
5. In parallel with the schema design, we should request the data feeds from the staff responsible for the booking systems, and organize the manual data feeds where they are completely unavoidable. There will be a lot of going back-and-forth between the systems staff and the project staff. The most typical format for a data feed is a CSV file, however a more robust result can be obtained by using the XML format. Although it takes more space, it also allows for a more rigorous data definition.
6. Start running the data feeds on the system at the production frequency. Each data feed should be equipped with quality checking code that will inform the operational staff about errors or delays in delivering the data.
7. Start designing the risk analytics code for the book. The code can be developed using either C# or perl, or C++, or even VBA, or SQL stored procedures. We always balance between readability, performance and developer preferences. 8. When the risk analytics code is designed, it's time to document what has been done to the current point and move to developing the reports for the book We have already planned for the information we need to deliver and we have developed the risk analytics code, so producing a report is now a matter of producing appropriate SQL queries and making a high-quality presentation on their basis.
9. Implement the reports using Excel. The objections may be that it's hard to ``lock up`` Excel spreadsheets, however the point here is to produce reports in the most familiar form for the customers. The database and the analytic code can be locked up, however the end-product itself should be as flexible as possible.
10. Schedule and perform a presentation for the senior management to emphasize the advantages of the project: data accuracy, automation, speed of delivery and ease of use. If successful, the presentation will provide the necessary buy-in for the continuation of the project.
Friday, November 21, 2008
The baby wants candy
When will the governments learn?
As more and more firms are asking for help from governments, they mostly get what they want. All three US automakers have asked the Ontario government for cash help. Chrysler was particularly straightforward and named the amount, USD 1bn, saying that the situation at the company may hurt the Ontario workforce.
The baby cries and the parent gives the baby a candy. Then the baby is happy for a week or so, but soon it finishes the candy and cries louder, and gets even more candy. Having repeated the trick three or four times, the baby learns the pattern and terrorizes the parent each time it feels like it. In the meanwhile, the baby’s health gets worse and worse from over-eating. That’s how the markets seem to be these days. It’s a death by thousand candies.
Counterparties and customers running away from Bear Stearns, shares tanking to $2? Make a good, reputable bank buy it for $10. The US quasi-government mortgage SIVs, Fannie Mae and Freddie Mac, messed up? Give them loads of money and take then over! Financial stocks tanking? Prohibit short sales. Then it’s AIG, and possibly Citigroup. Now, it’s the turn of emerging markets – China is going to spend about USD 1 BN on public works. When is this going to end?
But wait, here’s a bright sign: the US automakers’ CEOs asked for a piece of bailout in the Senate, but went home empty-handed. After all, why should everybody in the country pay for the arrogant management and bloated, unionized workforce?
Maybe the governments have learned, after all.
As more and more firms are asking for help from governments, they mostly get what they want. All three US automakers have asked the Ontario government for cash help. Chrysler was particularly straightforward and named the amount, USD 1bn, saying that the situation at the company may hurt the Ontario workforce.
The baby cries and the parent gives the baby a candy. Then the baby is happy for a week or so, but soon it finishes the candy and cries louder, and gets even more candy. Having repeated the trick three or four times, the baby learns the pattern and terrorizes the parent each time it feels like it. In the meanwhile, the baby’s health gets worse and worse from over-eating. That’s how the markets seem to be these days. It’s a death by thousand candies.
Counterparties and customers running away from Bear Stearns, shares tanking to $2? Make a good, reputable bank buy it for $10. The US quasi-government mortgage SIVs, Fannie Mae and Freddie Mac, messed up? Give them loads of money and take then over! Financial stocks tanking? Prohibit short sales. Then it’s AIG, and possibly Citigroup. Now, it’s the turn of emerging markets – China is going to spend about USD 1 BN on public works. When is this going to end?
But wait, here’s a bright sign: the US automakers’ CEOs asked for a piece of bailout in the Senate, but went home empty-handed. After all, why should everybody in the country pay for the arrogant management and bloated, unionized workforce?
Maybe the governments have learned, after all.
Subscribe to:
Posts (Atom)
