Let's make all these concepts specific and talk about one firm in particular. It's, of course, people might know best. I worked there in two stints, between 1993 and 2019. I'll share my screen. I too think of Goldman Sachs as a platform for financial risk transfer. Goldman and its competitors are the hubs of an interconnected global network of market participants. They're corporation, hedge funds, consumers, governments, pensions, and many other kinds of actors. What do banks, such as Goldman Sachs, do and how did they do it? The broadest possible definition is to say that banks transform exposures that customers don't want, into exposures that they do want. The way they do that, and Goldman Sachs in particular, is by modeling comprehensively its entire business in software so that the business and the software are one and the same. We keep coming back to this theme, it's of such great importance. The only way you can introduce APIs and all the other wonderful things is if you've already made the hubs, the activities of your business, the activities that happen in software. Then, once you've done that, the way you manage risk is by asking counterfactual or "what if" questions in software rather than having to perform the experiments in reality. There's a diverse set of risks that banks intermediates, and this is just a small sample, really a tiny sample. The banks take risks onto its own balance sheet, and it also transfers risks as an agent between two other parties. Pinterest, as an example, this is an example of taking risks. Banks lead initial public offerings, IPOs, for corporations such as Pinterest, of course at the primary market activity. In underwritten IPOs, the bank own shares that the company fails to sell in the IPO to investors. In the middle case, as with the United Mexican States, matching risk, banks help sovereigns, such as Mexico, transfer the risk of a decline in oil prices to other clients such as airlines. They're looking to hedge against an increase in fuel costs, but of course, what the airlines need as a risk management tool or hedge is never what the oil producer needs, it's mismatched in cost and space and grade of oil. That's why banks stand in the middle using their own capital balance sheet software to facilitate that risk transfer and risk matching. Another example is sourcing risk. Banks help private client gain exposure to startup companies such as Stripe whose shares don't trade in the public market. How does Goldman Sachs manage risk on the SecDB platform? As I mentioned to you, I was the fourth person to join a team of engineers. We were crazy and certainly everybody thought we were. We had this ambition starting with foreign exchange, eventually to model all the risk of all of the businesses of the firm, putting all the tools, models, times series, market data, trades, position, deals in one place so that we could ask counterfactual questions about the software and the data stored in that one place, but you get a bunch of different things and a bunch of different verbs all happening in one factor artifact. We tend to call that artifact a platform. SecDB represents over 25 years of continuous innovation. To put that in context, it calculates about a 100 billion prices a day across tens of millions of trading position, about a million market scenarios that's about a 100 quintillion CPU instructions per day. To consider, how does that fit into something that we all might have a gut sense for? That amount of computation takes about 3,000 at the time that I'm producing this lecture, Amazon Web Services, top of the line instance, it's a 96-vCPU EC2 instance. It's called the c5.Metal Instance. I'm estimating because these numbers aren't published by Amazon, I'm estimating that's about 30 basis points of all of Amazon Web Services capacity. Goldman Sachs is doing a lot of calculation, but in the grand scheme of the whole planet, that's only 30-bits of AWS. Most banks have silos, Goldman Sachs has Platforms, and yet there is always, I think this is built into human nature, a centripetal tendency to create silos. It just comes with our tribalism, it's probably inscribed in our DNA. Even when you've got one platform, the temptation to create silos in that platform is often irresistible. That platforms of course, create scale and drive innovation. For the simple reason that when you invent something for one business, or one product, or one asset class, you don't have to reinvent the wheel when you move to another business, or product, or asset class. Some things is really self evidence that they need to be done consistently, uniformly across the firm and you only need one way to do it. The core of technology and infrastructure, hybrid public and private Clouds, for instance, cybersecurity. There's broad agreement that those need to be single platform across the firm. But it isn't quite as obvious that you need to then build everything across your bank on top of an enterprise platform. You need to have a consistent way of thinking about all of your clients across the businesses. This has been a drive that's gone on for decades at Goldman Sachs far from complete, still work in progress. Change is coming everywhere and of course, once the business becomes a software business, that change only accelerates and the winners in the banking business are going to need strong engineering and risk management as well as distribution capabilities, all three of those together. To give you a sense of all of the activities going on at Goldman Sachs, I've indicated some current and former portfolio companies. I have indicated some of the platforms that Goldman Sachs is building, some of that the new businesses, and some the technologies, which is Cloud Computing, Machine Intelligence, Machine Learning, Distributed Ledger, Open Source that firm is bringing together as it makes that plan real. Increasingly, we're seeing banks distribute their services on hybrid Clouds and Goldman Sachs recently had invested in January announced an ambition, really one that I'd been working on for the entirety of my career there to itself become a Cloud provider of financial Cloud provider operating at a higher level of abstraction on top of its own internal data centers, its own private Cloud, as well as on top of Amazon and Google Cloud. For the private Cloud, Goldman increasingly been using open standards, such as the Open Compute Project that Facebook launched and Goldman is also a huge consumer at scale of web services, Cloud services from Amazon and Google. Marco Argenti, the firm's Co-Chief Information Officer joined from Amazon web services. A lot of the read in the press was that, Marco was going to make the firm and even more audacious consumer of Cloud services, continuing a trend that I had started when I was Chief Information Officer back in 2013. But really the right read of Marco Argenti joining Goldman was to take his experience from having built AWS Lambda and help Goldman itself become a producer of Cloud services. Data Lakes have been a huge part of this transformation at Goldman Sachs. It's being last effort going on or about a decade now to create a single firm-wide data repository. Now with [inaudible] , we had done incredible job of creating a firm-wide repository of trading risks. But really here with the Data Lake, we're talking about everything, all the data of the firm, which is a much larger undertaking. For salespeople with clients, so they are trying to build it before year end. If you're trader, who can I sell my position to? If your research analysts, which clients will be interested in a report about some company and where do I get the data to do my analysis in the first place? All of this comes out of the Data Lake and it's crucial to have a uniform repository with tools for joining and distributing data and it's incredibly important to have customers, and permissions, and entitlements across the Data Lake. To give you a sense of the scale of this project, it's gone from five petabytes when I began as Chief Information Officer and as of the end of last year, it goes up to 24 petabytes. API usage, we all know has exploded across the web. It's really hard to keep track, but here's one data source going up to 2020 that shows the number of public APIs and that number is up to about 25,000 now and back in 2006, it was actually pretty hard to measure. Around the time of the financial crisis, maybe there were 1000 also public APIs. That number is ballooning. What's really exciting though is the call traffic, the number of API indications is just off the charts. We've got six trillion API indications in 2019 and that number's growing at least exponentially, perhaps super exponentially. Consistent with all that, Goldman Sachs is shifting to a services- oriented architecture, making all of its capabilities available as APIs. Just as people can consume the Google Maps API, there's Netflix and Goldman Sachs, and many, many other companies consumed, the Amazon Web Services APIs or Compute and Data markets. The Goldman's new consumer business is built to allow third-party applications, LendingTree is just one example to reach its World products, and of course, that expands the market reach, everything, all the services, all the verbs, all the products of the firm, made available as API and location. Increasingly clients are data-driven and they want this API based model that gives them rapid access to Goldman dataset, they give them dataset they can't get anywhere else, and of course, from Goldman's point of view, this creates stickiness with the client and inspires the client to keep coming back. As I mentioned earlier, when this works really well, clients will then turn to other providers and say, ''We're not going to rebuild our platform to consume your API, please produce exactly the same API as Goldman Sachs be 100 percent API compatible,'' hasn't happened yet. But when it does, and that'll be a profound measure of API uptake. I'll give you an example, how Goldman Sachs actually created an API portal. Here I'll say that Stripe was our inspiration. We set the documentation of Stripe as the gold standard for our own documentation in terms of its quality. We want our clients to be able to interact with all of our services, programmatically. We want them to be able to use any language that they want, and so we have 100s of API entry points with beautiful documentation, and to show how to call those APIs in a variety of programming languages. We're doing all of this on top of the SecDB Platform, an increasingly SecDB is disappearing under the hood, completely encapsulated in the APIs and SecDB is just part of the black box that makes Goldman Sachs do what it does. Be able to transform risk and do it at scale, and do it efficiently and at great prices, and with Epsilon Operations risks, and could do this in every product in every geography, all that complexity hidden under the hood by API. We're building on top of those APIs a number of applications. These are all distributed as pure HTML user experiences. There used to be a vigorous debate about whether you could create beautiful applications entirely in HTML, no one is having that debate anymore, and we insist that everything that these applications do is being done through the API, the exact same API that the clients use. In terms of capabilities, the applications don't deliver anything that isn't already deliverable by the API, but of course, they package it in a way that some of the individual users and many of our clients will want to consume. Studio platform is a particular example that allows the clients to construct baskets to measure the performance of those baskets over time, to measure the risk, to tailor the risk, and then to turn it into actual trade baskets executed with Goldman Sachs. Simon is an early example of marquee. The idea there is to provide the complete set of tools and services for structured investment. These are our nodes generally, initially at least issued by Goldman Sachs, with coupons that are linked to some other market variable, such as the level of the S&P. The levels can be tapped and flowed, they can be buffered, they can be enhanced, all kinds of customized payout. The idea was to create one of these platforms where customers instead of iterating painfully over the phone with Goldman Sachs as the third-party, at working through third-party distributors, could actually just go to a website and handle all of the workflow on their own. It was so successful with its multi-issuer capabilities that eventually in late 2018 it made more sense. The Goldman Sachs to create an independent company called Simon Markets LLC. Because we had built everything in Simon along the API boundary, separating Simon from the firm, so that it becomes a multi distributor and include some of Goldman's principle competitors, such as JP Morgan, Wells Fargo, Barclays, and Credit Suisse. What was already encapsulated by the API, that was really easy to separate from the firm, and that was the intent. When we began on the Simon journey, we didn't know whether it would always be an organic part of the firm, or whether it would make more sense to separate it, and building everything with height API encapsulation gave us that embedded option [inaudible] or extended off, and when it was clear that it was optimal for our clients to spin it up, that's what we did. I'm not going to go in detail here. If you look at the reading list, you can see all of these APIs, you could see all of the documentation, and you can see that increasingly we're putting a lot of time and energy into a new base with clients who are developers. We've never considered developers to be citizens, or clients of the firm directly. We always saw engineers as working with their own people at their own firms, but now the engineers that are client institutions are becoming direct client themselves of Goldman Sachs and so we need developer portals for them. We show on the developer portal how to register an application that they're creating, how to explore the dataset, how to actually request the dataset. We have all kinds of documentation, you can see on the right. How to make your first API call, and as I mentioned, developers are the new primary customer. We change our design to ensure that they perceive themselves to be satisfied. In other words, banks taking a page right out of the stripe playbook. You can see here, and we do believe it at Goldman Sachs. We believe developers will create the future of institutional finance. I'd encourage you to go check this on your own. Every bank has a GitHub repository. Most of them are pure marketing, three or four of them actually have some interesting code in them. With the kind of code that we're providing under the GS Quant and Marquee brand name, developers can color APIs and perform immensely complex computations, in this particular case, a risk calculation. Again, the combination of 25 years of time and energy and billions of dollars. Now, the developers and client organizations can write three or four lines of Python or their favorite language. We get several of them and they can get these calculations done. Once again, the power of an API, easy to call, very hard to produce. You might have seen this photo floating around on the web. One of my favorite stories about Kensho. One of the most successful, not the most successful today might be Machine Learning exit that has yet to happen. We encountered Kensho when I was on the board of Harvard, and at that time I think it was two people and a dog at Kensho and they were doing some interesting machine analytics. We thought, well, here's an opportunity to provide them some capital. Capital is a commodity. More important, we can actually drive revenues into their business by paying them revenues ourselves and by introducing them to our clients and then ultimately introducing them to our competitors as well. This flywheel turned out to be really powerful and the core of the interaction with APIs and so this was the photo at the end of a hackathon that actually happened in the corner of the Goldman Sachs trading forum. I didn't actually use those headphones but I wear them all the time. At the end of that hackathon we co-designed an API that we produced then they consumed and then another API that they produce, but we consume. That API enabled our clients to create in Kensho, a basket of stocks that would respond to complicated event such as an OPEC production cut. Kensho had Machine Learning that would tailor these baskets and then through the API, clients could actually drop that basket into the Marquee Studio, I showed you earlier. They could refine the basket and then press another button that would call an API and actually put that basket of stocks on as a trading basket. Some concluding thought. You can think of capital markets, which had been around for quite awhile as a canary in the coal mine. For all large, competitive, tech-enabled, two-sided, marketplaces and there are many of them emanating out of Silicon Valley. Consider Uber, Doordash, many other unicorn is bid-ask compression in the capital markets of harbinger you could ask of rate and spread erosion, or the unicorns. The capital market have an incredibly important role to play in a free society and software is a huge part of that, especially as these capital market and trading businesses become software businesses. But as I demonstrated, there are costs and there are risks, the flash crash is just one of them. The capital markets then you could say served as a test bed for the profitable convergence of software and business. There's many things that one can learn from that experiment about the nature of how human beings and machines interact. It is an open question. Have all of this made the financial system more or less fragile? I look forward to discussing all of those topics with you in our live sessions.
