April 2010 – Coding Capital Markets

Covering a Short != Selling a Long

I spent most of the day yesterday listening to the Goldman Sachs testimony. Since I missed a few hours, I decided to revisit those parts I missed earlier today at the C-Span archives. I found it quite interesting how the Goldman Sachs traders spun their tales to deceive the Subcommittee. In particular, they often mentioned that their goal throughout 2006 and 2007 was to reduce risk. Yeah, fair enough. I’ve got to imagine with all the volatility in the market at the time, the middle and back office would have pushed pretty hard to reduce the risk.

One interesting thing I thought I’d dig into deeper is the difference between selling a long position and covering a short position. The witnesses often repeated the mantra that not only did they reduce their risk by selling their long position but they often also reduced their risk by covering their short position.

Well, yes. But not all risk is created equal, now, is it?

Between 2006 and 2008, to cover your short positions in the market basically meant you were “locking in” your profits. That’s because the mortgage backed security market was basically in freefall. By locking in your profits, you may indeed be reducing risk; risk that your counterparty (cough… Bear Stearns… cough) will not be around to pay you tomorrow. Either way, when you cover your shorts, you realize some amount of profit and reduce the company’s overall counterparty risk.

Selling your long positions between 2006 and 2008, however, was a whole different ballgame. In fact, I’d venture to guess that Goldman Sachs did very little of that because by the time they wanted to sell, there were probably no more buyers and therefore no market liquidity. They had no easy way to sell their longs since the buyer might have only been willing to pay pennies on the dollar. Instead, Goldman Sachs most probably offset these losses by taking opposite short positions. If they indeed made such spectacular profits in 2007, they must have indeed done the Big Short by several orders of magnitude more than their long positions. In any case, your aim in selling your longs is to minimize your market risk.

It’s interesting that the Goldman Sachs witnesses would combine market risk and counterparty risk and just call it risk in order to say their aim was to “minimize” risk and not go directional. Nice rhetoric guys.

ABX: A blast from the past

I’m listening to the Goldman Sachs testimony and as they float around words like CDO’s and ABX, I thought I’d check on what the ABX prices currently are as per Markit. If you recall, I actually wrote the code for CDS on ABX back when I was at Countrywide in 2006 and 2007.

Wow.

Factors Effective: 2010-04-26

27-Apr-10 Overview

Index Series Version Coupon RED ID Price High Low Factor

ABX.HE.PENAAA.07-2 7 2 76 0A08AWAD1 47.31 70.00 24.56 0.995918674

ABX.HE.AAA.07-2 7 2 76 0A08AHAD4 44.58 99.33 23.10 0.995918674

ABX.HE.AA.07-2 7 2 192 0A08AGAD6 5.32 97.00 3.75 0.842675865

ABX.HE.A.07-2 7 2 369 0A08AFAD8 4.63 81.94 2.97 0.383809843

ABX.HE.BBB.07-2 7 2 500 0A08AIAD2 3.58 56.61 2.89 0.15

ABX.HE.BBB-.07-2 7 2 500 0A08AOAD9 3.58 50.33 2.88 0.15

ABX.HE.PENAAA.07-1 7 1 9 0A08AWAC3 54.35 80.27 28.36 0.998941369

ABX.HE.AAA.07-1 7 1 9 0A08AHAC6 44.85 100.09 23.25 1

ABX.HE.AA.07-1 7 1 15 0A08AGAC8 5.13 100.09 2.86 0.827149338

ABX.HE.A.07-1 7 1 64 0A08AFAC0 3.77 100.01 2.33 0.432376793

ABX.HE.BBB.07-1 7 1 224 0A08AIAC4 3.68 98.35 2.19 0.15

ABX.HE.BBB-.07-1 7 1 389 0A08AOAC1 3.66 97.47 2.19 0.117129675

ABX.HE.PENAAA.06-2 6 2 11 0A08AWAB5 77.88 93.88 53.04 0.715876842

ABX.HE.AAA.06-2 6 2 11 0A08AHAB8 57.29 100.12 28.72 0.984457918

ABX.HE.AA.06-2 6 2 17 0A08AGAB0 14.83 100.12 6.94 0.92237709

ABX.HE.A.06-2 6 2 44 0A08AFAB2 5.20 100.12 3.42 0.431335167

ABX.HE.BBB.06-2 6 2 133 0A08AIAB6 6.78 100.59 2.29 0.111413346

ABX.HE.BBB-.06-2 6 2 242 0A08AOAB3 6.02 100.94 2.34 0.1

ABX.HE.PENAAA.06-1 6 1 18 0A08AWAA7 88.24 98.50 82.18 0.181987649

ABX.HE.AAA.06-1 6 1 18 0A08AHAA1 88.94 100.38 59.75 0.828696827

ABX.HE.AA.06-1 6 1 32 0A08AGAA9 45.83 100.73 15.90 0.972754188

ABX.HE.A.06-1 6 1 54 0A08AFAA7 14.79 100.51 7.50 0.826844803

ABX.HE.BBB.06-1 6 1 154 0A08AIAA4 4.98 101.20 3.95 0.424882857

ABX.HE.BBB-.06-1 6 1 267 0A08AOAA2 5.03 102.19 3.90 0.285366883

I realize this is somewhat cryptic, but take a look, say, at the price for ABX.HE.AAA.07-2. This was the AAA tranche of an ABS Index made up of Home Equity (HE) issued sometime around July of 2007. Do you see the price? 44.85. The price started at 100.0 at issue so for this particular Senior investment grade tranche, you’d have lost more than 50% of your money if you’d invested back in 2007.

Wow.

If you decided to take a little risk back then, you might have bought the Mezzanine branch, as the good ol’ boys at Goldman Sachs call it. If you’d bought $100 worth, guess how much you’d have right about now? $3.58.

If you think we’ve come even close to hitting housing bottom, I’ve got a bridge to sell you!

Adding custom Calypso packages by adding a new jar file

After my very interesting and enlightening attendance at The Server Side Java Symposium last month, I’ve decided to start exploring new technologies and how better do this than by creating some Open Source tools and libraries. Since I’ve been working almost exclusively with the Calypso API for the last decade, it’s somewhat logical that I would start there. I decided that my first project is to integrate Calypso with GridGain as Dispatcher to distribute Risk Analysis execution on the Grid. Calypso has its own Dispatcher implementation, but they themselves acknowledge it’s not ready for prime-time. They do sell an adapter to plug into DataSynapse as well, but I figured an Open-Source alternative would be a worthwhile tool for Calypso implementors. Besides, once I get it all up and running, I want to play with Scala as it seems to integrate very easily with GridGain.

So last week I launched Eclipse and created a new project. As I began creating a new package, com.steepi, I paused. In order to plug my package into Calypso, I would need to implement CustomGetPackages in the calypsox.tk.util package. But if I do that, how is a Calypso implementor going to use it? After all, they most certainly already have their own instance of CustomGetPackages! Now granted, they certainly could make the modification to their class to add my packages. Still. What if I truly wanted to provide a library that would attach my packages simply by adding a jar to the CLASSPATH? This problem merited further investigation…

After a few hours of research, I found a solution by locating an undocumented feature of Calypso. During startup, the AppStarter class will at some point try to instantiate calypsox.apps.main.UserStartup. If an instance of this class is found by InstantiateUtil, the method start() will be called via reflection. Just the hook I needed! I could place my custom code there to attach my custom packages.

Wait, though…

How would I go about doing so? Calypso’s API does not provide a method to add packages to InstantiateUtil. It’s all done within a static block when the class is loaded. Thankfully, I’ve encountered limitations with the Calypso API before and the way to circumvent this problem is to use Java reflection to render methods and fields accessible. Here, then, is the code that does exactly what I wanted! If you compile the following code and add it to your CLASSPATH, you’ll be able to attach custom packages to existing Calypso implementation projects that have their own CustomGetPackages implementation. It’s a nifty way to provide a third-party library on top of Calypso, don’t you think?

1:  package calypsox.apps.main;
2:
3:  import java.lang.reflect.Field;
4:  import java.util.Collections;
5:  import java.util.List;
6:
7:  import com.calypso.tk.core.Log;
8:  import com.calypso.tk.util.InstantiateUtil;
9:
10: public class UserStartup  {
11:     public void start() {
12:         // In order to attach our packages, we operate on
13:         // InstantiateUtil class using reflection so as to
14:         // reach through its encapsulation.
15:         Class clazz = InstantiateUtil.class;
16:         Field field;
17:         List packages = null;
18:         try {
19:             // Retrieve the _packages field in InstantiateUtil
20:             field = clazz.getDeclaredField("_packages");
21:             // Since this is a private field, we need to set it
22:             // to accessible so we can access it
23:             field.setAccessible(true);
24:             // Get the value of the field via reflection.
25:             // This is the actual List object
26:             packages = (List)field.get(clazz);
27:             // Add Steepi packages so they are available when
28:             // instantiating through reflection
29:             packages.add(0,"com.steepi");
30:         }
31:         catch (Throwable t) {
32:             Log.error("Error", "Unable to locate InstantiateUtil._packages via reflection.", t);
33:             return;
34:         }
35:         // TODO: Apply same logic to update _invertPackages field as well
36:     }
37: }

As noted inline, you’ll want to do the same to update the inverted packages field. I’ve omitted the code for brevity.

This solution should work with any version of Calypso prior to 11.1. Who knows whether or not they will eventually remove this logic since it is, after all, undocumented. Still, for the time being, it should be easier to deploy my packages in existing Calypso implementations without needing any code change. Sweet!