6 ms·
That's quite interesting: " At the risk of getting sued, let me throw you geeks a bone and part the Goldman veil a bit. The Goldman Sachs risk system is called
by d_c 16y ago
That's quite interesting:
"
At the risk of getting sued, let me throw you geeks a bone and part the Goldman veil a bit. The Goldman Sachs risk system is called SecDB (securities database), and everything at Goldman that matters is run out of it. The GUI itself looks like a settings screen from DOS 3.0, but no one cares about UI cosmetics on the Street. The language itself was called SLANG (securities language) and was a Python/Perl like thing, with OOP and the ORM layer baked in. Database replication was near-instant, and pushing to production was two keystrokes. You pushed, and London and Tokyo saw the change as fast as your neighbor on the desk did (and yes, if you fucked things up, you got 4AM phone calls from some British dude telling you to fix it). Regtests ran nightly, and no one could trade a model without thorough testing (that might sound like standard practice, but you have no idea how primitive the development culture is on the Street). The whole thing was so good, I didn’t even know what an ORM really was until I started using Rails and had to wrestle with ActiveRecord. The codebase was roughly 15MM lines when I left, and growing. I suspect my retinas are still scarred by the weird color blue SecDB was by default.
"
- etm117 16y agoI think that is one of the more thorough accounts of that system I have seen published. All in one paragraph no less.
- antongm 16y agoThanks. I haven't seen many published accounts by SecDB. When I joined, there was literally zero. I now note there are some descriptions on Wilmott and the like. Seems like word is seeping out. All of my description is on the Web in bits and pieces.
- yummyfajitas 16y agoI've had a number of people tell me this system is why GS won the financial crisis. During the financial crisis, GS knew their positions and their risks. They could also calculate the side effects of proposed trades as quickly as their computers could calculate it. This meant the people at the top could actively plan what to do next during the day. In contrast, MS and JPM can only get information like this a few hours after the end of the day, and supposedly Citi just can't calculate such things without massive effort.
- jbooth 16y agoIf you know and can speak about enough to do a blog post on this, could you consider it? I'd love to hear more about the different systems capabilities and how that affected the different big houses' ability to trade effectively in a storm.
- yummyfajitas 16y agoI don't know much more than what I put into my post, which is more or less standard industry knowledge. One more thing I should mention - this isn't a purely IT-driven story. Goldman doesn't simply have better IT than Citi or the Morgans. Citi has had many mergers and acquisitions (e.g., Vikram Pandit came onboard when Citi bought his hedge fund), whereas Goldman is mostly homegrown. Even if Goldman's geniuses ran Citi, they would still never be able to do what Goldman did.
- noname123 16y agoThe issue with real-time P/L and risk calculation is not necessarily IT but your math models valuing your positions in very hard to value securities. For instance, a liquid stock such as MSFT is easy to value; just look at the last traded price. Chances are, if you are liquidate your entire holding of MSFT (even if you are a big fund or bank), it'll fall roughly in the range of couple of cents of last traded price. A fairly illiquid stock such as a penny stock or a stock with relative low shares float; if you were to close your position as a bank, you are probably unloading/covering so many shares that it'll affect the price of that stock significantly. So you need to model that into your P/L model. Things get even messier with a derivative, because let's say you are trying to sell an option position. Whoever your counterparty you sold your option contracts too, probably has some counter-strategy in which they might hedge their option transaction with an underlying equity or with another option spread at a different price whose counterparty might choose to hedge with an underlying equity position. All of which would in term affect the underlying equity pricing and how the options call/put parity is re-adjusted and then in terms, the pricing of the option contracts you just traded. So you need to model that. So in your derivative pricing model, you might have to consider underlying pricing/volatility/liquidity, options pricing/time-decay/liquidity, futures pricing, currency exchange rates (for an ADR security) and how all of them all interact and influence one another. And even with the math aside, constructing and consolidating all exchange/quote systems that trade all of these products is a system integration nightmare.