tl;dr By "give away" they mean allow their sophisticated clients access the tools to do business with Goldman. It's not open sourced or available publically in any manner.
If a customer uses a bank's database to do their pricing, they tend be much more likely to do their trading with that firm. This is why firms like to have their models become the market standard. (Example: "Lehman Live" was used to price Mortgage Backed Securities. Unfortunately that didn't end well)
It's used for pricing & risk management. Considered the best in class for large banks and has been attributed (at least partially) for GS scathing away from the financial crisis relatively unharmed because of being able to quickly price things, determine risk throughtout the firm, and make quick decisions.
Many other banks expose some of their pricing code as a web application to varying extents. For example https://live.barcap.com/ which was inherited from LehmanLive, considered state of the art for fixed income back in the day.
Also as the article states, anything that still has an actual competitive advantage won't be released.
I'm pretty sure they're referring to SecDB. There isn't much known about SecDB outside of Goldman, but I think the essence is that it:
1. Is a distributed data store for market positions, etc.
2. There's a dataflow/spreadsheet-like valuation engine on top of the data store
3. It's had long-term and senior level support among management, and most/all of GS's positions and businesses are available within SecDB.
4. There's a large pool of internal talent that's well acquainted with SecDB and how to use it.
So... it gives GS an easy way to see where they are, and then run models to figure out where they might be under different hypothetical scenarios.
What's noteworthy about this to me is that while they may be 'giving away' points 1 and 2 from my list, points 3 and 4 are the bigger competitive differentiators for Goldman. Even if another bank immediately adopts SecDB, while they may get the technology, it'll take them quite a while to integrate it as fully into their culture and business. SecDB implemented for a small bit of a big bank and run by a bunch of relative newcomers is a very different thing than SecDB as it might be implemented at Goldman.
It's been available outside Goldman for a long time. Cantab Capital had based their systems on it as long ago as 2006. The founders were ex Goldman and wangled some kind of deal where they could use the GS systems.
You can click "web" which will provide you a link to the article without the paywall.
But just for you: "Called Securities DataBase, or SecDB, the system remains Goldman’s prime tool for measuring risk and analyzing the prices of securities, and it calculates 23 billion prices across 2.8 million positions daily. It has played a crucial role in many of the seminal moments of the firm’s recent history, including its controversial trading just ahead of the financial crisis."
So, is it data, a database, or a risk-management tool?
Sounds like something that could have been hard with constraints of 1990s hardware, but these days any old person could rent a cloud to do this.
Also, I suspect people who aren't involved directly in the technology talk it up a lot more than would someone who was involved in building it. The execs have bet on it with budget money, and they get to open or close the gate, making it seem more important than it really is.
At the end of the day, every financial form has a bunch of code that lets them slice and dice their data. GS didn't survive the crisis because they had this system, they survived because they had a system and made some wise choices.
It's also a very slick integrated development environment for financial use cases.
The securities/price data are exposed as first-class entities in an ORM layer and you can manipulate them easily with scoping rules.
For example, if you want to get the current USD/JPY rate, it's just:
Rate(Security("USD/JPY"))
If you want to know what the price of an FX contract is under different rate regimes, you can actually set that price and then reevaluate the contract, e.g.
SetDiddlescope() {
Foreach(X, [90, 100, 110]) {
Rate(Security("JPY/USD")) = X // Only takes effect within this scope
Print(X + ": " + Price(MyFXSwap))
}
}
How this actually works is that most object's fields are dynamically recalculated using an early form of functional reactive programming (note that SecDB was mostly built in the 90s). Fields specify their dependencies, and when their dependencies change, the field's value gets invalidated. This is very similar to how ReactJS or Angular work.
Unlike React or Angular though, you can force intermediate calculations to take on certain values as well; for example, in the scope above, you can also force Price(MyFXSwap) to take on a particular value. This is useful, for example, you had a book of securities, MyFXSwap was one of them, and you wanted to see how the price of your book would change.
Even though all the securities are actually in a database somewhere, anything happening locally gets cached to an in-memory database so the performance is pretty decent. The security database itself, btw, was much closer to a pure distributed object store; there wasn't much in the way of querying ability.
To get the benefit, you need the securities models…and the data to feed the models…real-time prices…covariance matrices…volatility surfaces…at which point you're living in a very Goldman world. Not that that's a bad thing but it creates a lot of lock-in.
Also I'm not sure what the upside is to letting people run on-premises, vs. providing cloud APIs based on it (they make it sound like the former).
Just the software, without the models, data, strategists, is kind of like providing a proprietary environment of Microsoft SQL + R.
As I understand it, the closest thing would be something like writing your application for MSSQL. You have a cluster that is storing your data, and with a complex set of triggers, views, queries, etc, you're re-calculating things live.
Unfortunately you program SecDB mostly in proprietary internal languages (not SQL), which while I understand they are moderately capable, they lag behind the 'state of the art' in programming by quite a long way - I wouldn't image it's even on a par with Python, I think somewhere like Lua is probably more accurate.
Caveat - this is based on chatting to people from GS, I don't have experience working with any of this first-hand.
SecDB has been in a class of its own for years now. I've seen and heard of many other banks try to replicate it and failed. It's customizability and performance are very well respected in fintech circles.
That wasn't Dubno but Kirat Singh who worked for Mike at GS. I thin kit was the first of the SecDB offspring with other attempts at BAML and Morgan Stanley. I believe Deutsche bank are also doing something similar.
tl;dr The software is called SecDB. Giving it away is like giving a sports almanac to people that can't travel back in time. Somehow GS ended up using it at the right time, and even had fun speculating on how much to sell it for.
Readit News
It's so distant from the truth that you can't even find information about pricing, plans ,conditions, etc.
It's a nice way to get investors' attention though.
If a customer uses a bank's database to do their pricing, they tend be much more likely to do their trading with that firm. This is why firms like to have their models become the market standard. (Example: "Lehman Live" was used to price Mortgage Backed Securities. Unfortunately that didn't end well)
Also as the article states, anything that still has an actual competitive advantage won't be released.
1. Is a distributed data store for market positions, etc. 2. There's a dataflow/spreadsheet-like valuation engine on top of the data store 3. It's had long-term and senior level support among management, and most/all of GS's positions and businesses are available within SecDB. 4. There's a large pool of internal talent that's well acquainted with SecDB and how to use it.
So... it gives GS an easy way to see where they are, and then run models to figure out where they might be under different hypothetical scenarios.
What's noteworthy about this to me is that while they may be 'giving away' points 1 and 2 from my list, points 3 and 4 are the bigger competitive differentiators for Goldman. Even if another bank immediately adopts SecDB, while they may get the technology, it'll take them quite a while to integrate it as fully into their culture and business. SecDB implemented for a small bit of a big bank and run by a bunch of relative newcomers is a very different thing than SecDB as it might be implemented at Goldman.
Erm... https://github.com/saleyn/secdb
Written in Erlang with a C driver for low level stuff.
Author is Serge Aleynikov. Ex-GS employee sued in multiple courts over many years by GS.
But yeah, not "officially known" as in they released, but there is probably some association there. Just a guess ;-)
But just for you: "Called Securities DataBase, or SecDB, the system remains Goldman’s prime tool for measuring risk and analyzing the prices of securities, and it calculates 23 billion prices across 2.8 million positions daily. It has played a crucial role in many of the seminal moments of the firm’s recent history, including its controversial trading just ahead of the financial crisis."
"Many of those tools are being offered in the form of web-based applications that customers can customize and operate on their own."
Sounds like they are turning what used to be heavily guarded internal software into client-facing apps.
Sounds like something that could have been hard with constraints of 1990s hardware, but these days any old person could rent a cloud to do this.
Also, I suspect people who aren't involved directly in the technology talk it up a lot more than would someone who was involved in building it. The execs have bet on it with budget money, and they get to open or close the gate, making it seem more important than it really is.
At the end of the day, every financial form has a bunch of code that lets them slice and dice their data. GS didn't survive the crisis because they had this system, they survived because they had a system and made some wise choices.
The securities/price data are exposed as first-class entities in an ORM layer and you can manipulate them easily with scoping rules.
For example, if you want to get the current USD/JPY rate, it's just:
If you want to know what the price of an FX contract is under different rate regimes, you can actually set that price and then reevaluate the contract, e.g. How this actually works is that most object's fields are dynamically recalculated using an early form of functional reactive programming (note that SecDB was mostly built in the 90s). Fields specify their dependencies, and when their dependencies change, the field's value gets invalidated. This is very similar to how ReactJS or Angular work.Unlike React or Angular though, you can force intermediate calculations to take on certain values as well; for example, in the scope above, you can also force Price(MyFXSwap) to take on a particular value. This is useful, for example, you had a book of securities, MyFXSwap was one of them, and you wanted to see how the price of your book would change.
Even though all the securities are actually in a database somewhere, anything happening locally gets cached to an in-memory database so the performance is pretty decent. The security database itself, btw, was much closer to a pure distributed object store; there wasn't much in the way of querying ability.
Also I'm not sure what the upside is to letting people run on-premises, vs. providing cloud APIs based on it (they make it sound like the former).
Just the software, without the models, data, strategists, is kind of like providing a proprietary environment of Microsoft SQL + R.
I worked there for almost three years before I realized that we were playing around with FRP.
> in an ORM layer
... and I didn't realize that I was using an ORM for a good six months.
Life at Goldman was good as a developer. Retinal scarring from those damned blue windows aside, I kinda miss it sometimes.
Unfortunately you program SecDB mostly in proprietary internal languages (not SQL), which while I understand they are moderately capable, they lag behind the 'state of the art' in programming by quite a long way - I wouldn't image it's even on a par with Python, I think somewhere like Lua is probably more accurate.
Caveat - this is based on chatting to people from GS, I don't have experience working with any of this first-hand.
The secret sauce isn't the technology -- it's the decades of quant models that have been programmed using the stack.
(As in pushing for cheap software if you have exclusive hardware, and vice-versa.)
Deleted Comment
Deleted Comment