Tag: LinkedIn

Back in San Francisco!

I’m baaaack! This is an aerial view of the Carquinez bridge, near our home.

Actually we’ve been back for a few weeks now, but it’s been so crazy busy I haven’t had time to blog about it until now. My wife and I had talked about moving back up here for a few months but the idea became concrete when I received an offer from Calypso, my former employer. So here I am now, development manager for the FX and Treasury group. Simply put, I’m totally psyched!

As far as timing is concerned, it truly was impeccable. Within a month of my giving notice at Countrywide, the bad news started rolling in. I’m not too concerned for the team I worked with there, though, since they’re pretty well insulated from the layoffs. It’s a very small and solid team of IT professionals that are supporting the Calypso implementation for the whole organization. Countrywide Securities is actually one of the few subsidiaries that’s making serious money, and as they’re moving more and more financial products onto Calypso, I can’t imagine them getting rid of the IT team that keeps this all going!

We’re back in our house… You have no idea how happy we are!

And the housing bubble goes KABOOM!!!!!

Why is everyone apparently so surprised with the current housing crisis in the United States, and what brought it about? The short answer is collective stupidity, but I suppose that’s not nearly as entertaining as understanding the pieces of the puzzle.

One important catalyst is securitization. Securitization, as defined in wikipedia, is the process of homogenizing and packaging financial instruments into a new fungible one. Acquisition, classification, collateralization, composition, pooling and distribution are functions within this process. Simply put, some financial alchemists found a way to sell stuff on Wall Street that couldn’t easily be sold there before.

The way mortgages used to work was Joe Blow would walk into his local bank and talk with his banker, with whom he’d had a relationship since he first opened his savings account at age 12. Joe would explain to Mr. Banker that he needed a loan for his house. Mr. Banker could borrow the money at 6% so, taking in his cut (the spread), he loaned the money to Joe Blow at 7%. Everybody happy. The problem was that traders couldn’t really get in on the action. The overhead to handle such petty loans made it unmanageable. BSDs don’t care about Joe Blow’s pathetic $125,000 30-year 7% loan. In order to make their fat bonuses to buy a new yacht, they need to handle lots and lots of loans but they don’t want to deal with individual accounts. They trade stuff. That’s what they do. So how can they get in on the action?

Well, in the US we have the perfect tool for this job… the FICO score! This magic number tells you all about a person’s credit worthiness. So you can bucket mortgages by FICO score, mortgage type and maturity… 750+ 30-year fixed maturing August 2035 all go into one bucket. That’s a whole bunch of assets right there… Now the mortgage lender creates a subsidiary, probably offshore, that becomes the rightful “owner” of all these assets. This subsidiary issues some bonds based on expected cashflows coming in every month from all the people in that bucket. Let’s say, for simplicity, that there’s 10,000 mortgages in that bucket bringing in an expected $2.5 million a month in payments. Now, statistically, you’re dealing with 750+ FICO scores, so these people are extremely creditworthy… Still, assume that $100K won’t get paid every month… that leaves $2.4M. Of course, there’s operational costs, vacations, hookers,… so that leaves maybe $1.5 million per month. Now whatever bonds you issued pays $1.5 million per month over 30 years… Voila! Bonds is the kind of thing traders understand.

So that’s the first piece of the puzzle. The geeks on Wall Street found a way to let traders in on the game of mortgage. So far, so good.

Let’s go back to FICO scores… It’s easy enough to bucket 750+, 700-750, 650-700 mortgages. Those are some pretty solid credit scores. The odds are pretty good that those homeowners will make sure to pay their mortgage every month. But what about some poor shmuck with no income and a credit score of 525? How can you get him to play the housing bubble game? The geeks on Wall Street thought long and hard and decided that maybe you could slice the buckets horizontally.

They call it tranching in structured finance. The idea in so doing is to provide more reward for more risk taken. So the lower tranches will still get securitized and make their way onto the Street… but those are serious junk bonds. They may bring in 18% annually but they’re backed by a bunch of mortgages that were handed out to homeless trolls living in shopping carts in Berkeley. Let’s say that the risk of default is high… Aha! But not quite… because a shopping cart in Berkeley will cost you $500,000 and you can probably sell it tomorrow for $600,000, so at that point in time you’ll have built up some equity and you can refinance… No no…you don’t need any income. In fact, you don’t even need to give us any money at all. We’ll just tack on the interest at the end of your loan. Actually I diverge… we’ll discuss mortgages further below. For now, back to tranching. So basically, the top tranche is given a grade of AAA because, despite the fact that it only pays 5% annually, it is the first tranche to get paid. So the top tranche of the 500-550 bucket (read: serious subprime) still manages to get a AAA rating… As long as it’s BBB+ or above, it’s investment grade so the traders can happily tap into it… Ok, look let me get graphic for a minute… Yo, Einstein…If you fill a bucket with shit, does the cream rise to the top? Investment grade? Sheesssh

So now you have the big mortgage lenders who have a way to offload their mortgages onto Wall Street…. Sah-weet! The way to make a lot of money is to take in as many loans as you can, grab your cut, “securitize” them, and send them off to Wall Street. Thus, the creative mortgages were born: No points. No fees. 3/1 ARM. Negative Amortization. Hybrid Interest Only. HELOCs… “Come one, come all!!! Get your loan right here!!! Get ‘em now while they’re hot!”

So now we have it… Wall Street and large mortgage lenders have created a very large need for lots and lots of loans, which means we need lots and lots of new houses for people to buy. No income? No problem… Come and get your house and you can ‘flip it’ in a year or two and make $200K. See? Now you got income!

In places like Vegas, build houses they did like there was no tomorrow. Here in California, they pushed well into the central valley and, of course, prices in large metropolitan areas skyrocketed. “Build it, and they will come?” Damn straight they did!!!! Everybody was buying and demand was far outpacing supply.

Interest rates were low, too, making it much easier to borrow money for cheap. Traders, too, borrowed money to trade these bonds… They borrowed Yen at 0% and traded them into dollars so they could buy these bonds. They even have a name for this, the Carry Trade.

Well, we’re now in the days of reckoning… Ultimately the people who are paying today are those greedy bastards on Wall Street and those who bought a house without following the fundamentals. I’m fairly certain that those of us who bought in the last 3 or 4 years at 3 times annual income, like the rule-of-thumb suggests, aren’t really sweating it right now. Those with a $75,000 household income who bought a place in SF for $850,000? Well, good luck to you. I hope you make it out of this mess unscathed, but I wouldn’t hold your breath.

Traders, Guns, and Money

I’m wrapping up a truly enjoyable read, Traders, Guns, & Money. The book talks about the going abouts in the world of financial derivatives and it’s a fun read. I’ve even managed to actually learn a thing or two about what all the greek symbols in Financial engineering actually mean. In other words, it’s pretty accessible as well.

In light of that book, I chuckled when reading this quote today by Richard Marin, Chief Executive of Bear Stearns Asset Management:

“We have brought in additional resources with expertise in these asset classes to facilitate the orderly deleveraging process,” said he, speaking of an ailing fund with $1.2 billion in debt.

Orderly deleveraging?!? It’s way up there with collateral damage and corporate restructuring as far as rhetoric is concerned, ain’t it?

Startups are hard

I’ve had 2 real experiences with startups, but I’ve written 3 or 4 business plans. All these experiences were failures. Which is totally ok, because you pick yourself up, dust yourself off, and start again. Still, after all these failures I understand why serial entrepreneurs typically succeed more and get funding easier. If you’ve succeeded once, you’ve already proved to an investor that you can handle all the stress and even if you’re just a geek, if you’ve founded a startup and you’ve succeeded, then you probably have way better people skills than 99% of the other geeks out there.

I’m just thinking about that after reading Marc Andreesen’s latest post: The Pmarca Guide to Startups, part 1: Why not to do a startup. Marc has been lucky enough to succeed repeatedly. I haven’t. Nevertheless let me tell you that a lot of the things he mentions ring absolutely true: Startups are a Bitch with a capital ‘B’!

Frankly, although I still very much have the entrepreneurial bug, I don’t know if I’ll ever launch another startup again. It’s brutal, and it’s hard, and it’s painful. The day after we closed the doors on didgets, the startup I helped cofound back in 2000, I found myself in the ER with an anxiety attack. Thanks, but no thanks.

If I were to do it again in the future, I’ll be doing it by myself, organically, in my home office. I would definitely stay within the realm of what I’m familiar with. What inefficiencies have I seen over and over, and how can I facilitate the processes?

Do I regret having given blood, sweat, and tears to my dead startups? No, not really… I’ll take the Pepsi Challenge on a Stanford or Berkeley MBA any day of the week.

Programming Fashion Faux-Pas

We’re releasing a new version of our code today so the last week’s basically been a free-for-all as far as fixing bugs and implementing enhancements. I had to push some additional Swaption data onto TIBCO for Blackrock to consume. So I had the pleasure of modifying an interface I’ve never worked on before. So I come across this:

if (product instanceof Swap) {
    ...
} else if (product instanceof TotalReturnSwap) {
    ...
} else if (product instanceof CDSABSIndex) {
    ...
}

Dude, are you kidding me? You ever heard of an interface? I think that right there tells me whether or not the person who wrote this code is a seasoned developer with good refactoring skills. I should remember to use that as an interview question. Frankly I wouldn’t hire a guy who codes like that…. It shows a complete lack of programming fashion sense.

Work’s been keeping me quite busy lately, actually. We are finally going live with CDS on ABX next week and I’m pretty pleased since I did pretty much 95% of the development for that. I got to get very intimate with the various credit events that can occur and how they should be handled. Actually Calypso’s not quite up to par in how it models CDS on ABX, at least as far as accounting is concerned. For accounting to get what it wants, a separate transfer needs to be created for each individual credit event. So if MarkIT says on a given month that ABX.HE.BBB-.06-1 has got an interest shortfall of 59.2, an interest reimbursement of 12.5, and a fixed correction of 15.1, Calypso needs to generate 3 individual transfers. As of 8.0.3, Calypso doesn’t even handle corrections at all. (Maybe they fixed that in 9.0?) Of course, the individual transfers can and should be netted together, but each one should generate its own transfer type and, further downstream, its own posting.

Anyway, it was interesting making this enhancement and seeing it trickle all the way down to Peoplesoft.

On the Cutting Edge of Finance

So by now everybody’s read about the subprime mortgage meltdown, right? Well thankfully Countrywide doesn’t seem to be so affected, but I’ve been reading some interesting analysis by Gretchen Morgenson over at the New York Times. She’s way sharp and although I frankly don’t know enough about all this, I tend to agree with her prognosis. Let’s just say it’s going to be a bumpy ride for the next 3 or 4 years when it comes to Real Estate in the U.S.

The thing is, you had all these mortgage lenders pretty much lending trillions of dollars to just about anyone who’d walk into their office, qualified or not. This of course drove housing prices way up since you had flippers gobbling up houses like crazy. Demand went through the roof but supply remained a constant. So now these lenders all have tons of expected payments but they want to liquify their assets, so they securitize these loans into asset backed securities. Subprime loans magically become BBB and BBB- asset tranches. Investors start buying these up since they offer a pretty good return on investment. Hell, you’ve even got investors borrowing Yen, converting into dollars just so they can gobble up all these asset backed securities.

Fast forward to the present. The Fed’s had to raise its lending rate quite a bit to curb inflation. Inflation is a risk thanks to instability in the Middle East and the growing demand for oil, especially in China. Americans are consuming as much as ever, not saving anything. All of a sudden, however, a lot of these ARMs are resetting so homeowners who were 2 years ago paying 4.5% are all of a sudden paying 8%. In subprime land, it’s more like 7% to 12% or some such nonsense. All of a sudden, the mortgage payment goes from $2,000 a month, which was a stretch, to $3,500 or more. So all these homeowners start defaulting on their loans. The lenders in turn pass the bad news to investors who start seeing interest shortfalls on their BBBs and BBB-s. So these guys are pissed and selling the assets. In the meantime, Japan’s raising rates and there’s a lot of Americans owing a lot of Yen.

What a mess…

Anyway, I’ve totally rambled on, but what’s cool about all this as far as I’m concerned is that I’m currently implementing Credit Derivatives on Asset Backed Securities (CDS on ABS, for short) and my employer plans to go live on indices within a month. All this is so very a propos especially with the subprime mortgage meltdown. Basically lenders use credit derivatives to minimize their credit risk. If you’re a lender, you buy protection by paying a monthly premium to a third party in exchange for them to cover you if there’s a default on the loan.

Right now our focus is to finish the implementation of ABX indices as we’re going live with that early April. I’ve been spearheading the effort, making enhancements and especially interfacing with MarkIT data feeds. It’s cool because it’s still so new everyone is trying to figure out how these creatures work. I’m pulling XML data from MarkIT before it’s even completely ripe… I’m on the cutting edge of finance and lovin’ it!

Dreaming in Code

I’ve just recently purchased a new book, Dreaming in Code, by Scott Rosenberg.

It’s a good read, so far, but I’m only on page 100 or so, so I got a ways to go. Still, I’ve got to chime in right now because I’ve heard and/or read this before and I think it’s bullshit:

Here, once more, was the archetypal dilemma of software reuse. Build or borrow? Virtually every software project sooner or later arrives at this fork in the road. (The full phrase traditionally is “Build, buy, or borrow?” From a technical perspective, though, “buy” and “borrow” are similar, the commercial and open source sides of the same coin.)

Look, I don’t give a damn if you’re the most productive developer or architect in the universe, if you have a solution that fits your needs but perhaps only to 80% and you ain’t buying or borrowing, then you really shouldn’t be in charge of the project. Do yourself and your employer (or client, as the case may be) and focus on technology and let somebody do project management because you suck at it.

Bottom line is: write an interface. Then have the implementation of this interface be a simple adapter to some borrowed or purchased code. If you have time to make it better in the future, then plug in a new implementation. If you rewrite because you ain’t getting that last 20%, then you’re a fool. If you’re at this fork in the road, realize that you currently have 0%, and that you can probably crank out an adapter within a couple of days. 80% of the desired functionality within a few man/days. You have to be smoking something if you don’t follow that path!

Yes, I’m fairly extreme in my views on this, but I’ve found that I’m always right when it comes to this issue, too.

Note to Self: Use session token as argument across all your APIs.

If you’re gonna be running code on any kind of multithreaded environment, a service layer of any kind, whatever… In other words, unless you’re actually running on the GUI and you’re actually dealing with event-driven development… please please please add a session token as an argument to every method call in your API.

You probably will think: “Why? I don’t need it.” But if and when you do, it might be too late… because you might be live at several clients, and you may not be able to change the API at that point in time, or you have to be backward compatible, right? Well, if you ever plan on having two-phase commit, or horizontal access permissions, whatever… you better have some kind of session token that allows you to retrieve your “context.” If you don’t have that, you’ll hack it…. oooohhhh, you’ll hack it real good, because you won’t have a choice. But you know what? If you ever want a clean fix: you’re shit out of luck!

Think Outside the Box

I came upon an interesting problem late last week.

I’ve recently implemented an OTR Bond interface to Calypso so that, when new TIBCO messages alerts us of a new “On-the-run” Bond issue, we can insert the appropriate data into Calypso. Of course, if it’s a new Bond, there’s also a good chance that we don’t yet have the Bond definition in Calypso and, for that, we use the Bloomberg Connect API to retrieve the Bond and link it to the Calypso BondBenchmark… Sorry. That was just an overview but I can already see that most of y’all have your eyes all glazed over. Didn’t mean to bore you to death.

Anyway, I’m rather familiar with Calypso’s Bloomberg Connect API and how it works. Puh-lease… give me a hard one!!! After all, I pretty much wrote the whole thing single-handedly a couple of years ago. Let’s just say that a request file is generated, then FTP’ed over to Bloomberg. Then, it’s your responsibility to poll the remote directory for the equivalent response file. Once it is available, you download it and parse it locally with the data you requested. Pretty straightforward, right?

Well, when I implemented the Bloomberg interface, I thought of the “requested” scenario and never bothered (foolish me!) to think outside the box. Let’s say you request a Bond with CUSIP 123456, then I’d simply generate a request file called cy_123456.req (cy being short for Calypso. Y’see? To top it all off Bloomberg states that there’s a maximum number of characters in the file name. Some puny amount like 12 or 15, I think.) So anyway, cy_123456.req would get processed and FTP’ed to the remote directory. Then, I’d poll every once in a while for a file called cy_123456.out. When the file would be present, I’d FTP it back to my local directory and remove the file remotely, thus cleaning up after myself.

This ain’t rocket science, right? That should work just fine, no?

If you’ve got one instance of Bloomberg Connect running, it runs fine and dandy, yes… but here at Countrywide, we got a bunch of environments all running in parallel. We’ve got a couple of development boxes, UAT, and of course, the production environment. The configuration for these boxes are identical and the OTR Bond adapter task kicks off from 4 AM until 5:30 AM. So now you have these 5 or 6 processes all running on different boxes each listening to TIBCO. Let’s say at 4:05 TIBCO broadcasts: The 3 month OTR Bond has CUSIP 2223123. Well what’s been happening is this: these processes would check Calypso and determine it that Gosh-darn-it… we ain’t got that Bond definition. Let’s go fetch it!

5 processes on 5 different machines each generating a request file, cy_2223123.req. Some time passes and the Bloomberg Engine running on each box processes the file and uploads it to the remote (COMMON!) Bloomberg directory. Some time later, these 5 processes would each look for some file, cy_2223123.out, download it back locally and proceed to delete the remote file.

Hmmm…. can I get semaphores implemented on top of FTP? On second thought, don’t answer that…

I’m surprised that the process failed so infrequently, but occasionally, you’d have some poor process who’d never get its .out file. No wonder, some selfish sibling would have wiped it out before he got a chance to retrieve it. The funny thing is that, had I even pondered the question back at Calypso, it would have easily been apparent. I just never bothered to think: “Hey, wait… what if they run this process 5 times instead of just once, which seems logical.”

The quick fix? We’ve decided, until Calypso issues an official fix, to stagger the execution time for OTR Processing. Typically TIBCO will broadcast OTR information sometime between 3 and 4 AM and, of course, that information remains cached for new subscribers. So as long as we don’t connect before 4 AM and we have each box start processing OTR Bond messages on TIBCO at 10 minute interval, each instance of Bloomberg Engine should, hopefully, get to do its thing by itself. It’s not the most elegant solution, but hopefully it’ll do the trick!

On-the-run Bonds

For the last few weeks, I’ve worked on implementing OTR Bonds in Calypso. An OTR Treasury security is the most recently auctioned Treasury bill, note or bond of a stated maturity, with OTR an abbreviation for “On-the-Run.” Today, 09/29/2006, for instance, the 3 Month OTR Bond has CUSIP 912795YL9 and was issued yesterday with a maturity of 12/28/2006. In 15 days, however, it will roll to a different Bond issued sometime in mid-October. So, in essence, the 3 month OTR Bond is a reference to an actual bond. Calypso’s modeled this quite nicely, in fact, with the concept of a Bond Benchmark which, itself, is an instrument that can be priced or traded, but actually references a “benchmark” Bond. Simply put, OTR securities provide a convenient way to model market data curves for Fixed Income Trading.

The thing that’s been rather tricky, actually, is to interface Calypso with a Treasury TIBCO feed that supplies us with the latest OTR Bond aliases. Obviously enough, the first step is to retrieve the Bond Benchmark to make sure that OTR Bond and the actual benchmark match the data provided by TIBCO. If they don’t match, then the Bond Benchmark needs to be updated as well. Then, however, we also need to update Calypso’s feed config so it knows how to retrieve the latest quote from TIBCO in the future.

It’s actually not all that complicated, except that the persistence layer for Calypo’s Bond Benchmark keeps barfing up NullPointerExceptions. Apparently it tries to do some caching, but it’s really not all that good at it, and considering that you’re dealing with… hell, let’s say one thousand bond benchmarks, Calypso’d be better off just fetching the data from the DB instead of spewing exceptions at me. That’s simply not polite.

Unfortunately, Calypso doesn’t give you the ability to trade a Bond Benchmark. You can trade the underlying Bond, but apparently trading a reference was too hairy to design. It’s true that it adds a level of complexity since you would need to take a “snapshot” of the benchmark at the point in time when the trade is created. If that trade settles a month down the line, the 3 month OTR Bond will have changed, but obviously the Bond which was traded will not! Then again, seeing it from that perspective, it might be just a little too confusing to keep track of. A nifty feature, though, would be to at least be able to enter a trade with the 3 month OTR Bond and having Calypso automatically fetch and populate the trade entry screen with the appropriate bond.

I’m kind of curious why not create a generic ProductPointer that can be traded and have the BondBenchmark either extend the base class or implement the interface. My gut says I’d go with an abstract base class since you’d want to bring down as much functionality as possible into the superclass and just give hooks to customize the behavior.

Have a good weekend,