Hello, and welcome to Stanford GSB Gen 544. How software eight finance. I'm R Martin Chavez, maybe someday I'll tell you what the R stands for. Nobody calls me that everybody calls me Marty. So please call me Marty. I would say if you asked me who I am, first of all, father, and second, I'm a computer scientist. Many other things too, I'm a dad, investor, entrepreneur, risk manager, leader coach, and now I'm the professor. And I'd like in this class to share with you a few things I've learned from working for 26 years at the intersection of software and finance. You probably will find it hard to get me to say fin tech, in my view, software and finance have been converging for a long time. And so I'll just say, in a much more wordy way, the intersection or the Venn diagram of software and finance. So I'll tell you a little bit about myself. I'm from Albuquerque, New Mexico. My very first job turned out to be a harbinger of things to come. I was 16. I got a job working at the Air Force weapons laboratory writing Fortran programs. Now what was going on in the world is that the government was not wanting to detonate hydrogen bombs in Nevada and other places to see how they worked. And had begun a project considers really an extreme and almost crazy project at the time. And this is the 70s I'm dating myself to simulate the explosion have a hydrogen bomb. And it would obviously be if you could construct a high fidelity model, a much better thing to detonate in silico or in software rather than real life. And so I found myself writing what we call particle pushing calculation. Stochastic partial differential equation solutions where we would simulate the scattering of constant electrons, one electron at a time. And we were having troubles with the dynamic precision of the floating point on the computers in those days using MKS units. And so my job was to turn the whole program into electron rest math units, and I learned a lot in that. Another inflection point in my career happened in 1981. I was a freshman at Harvard. And I encountered the legendary Professor Stephen Harrison in biochemistry and molecular biology and he told me, Marty, the future of molecular biology is computational. A present statement, not at all obvious at the time, very obvious today. And he and I together constructed a concentration where I took a little bit of wet science in the biochem labs and an awful lot of chemistry and physics and software architecture and engineering. And my most passionate academic discipline, which was theoretical computer science and computational complexity theory. After that, I went to the MBP PhD program at Stanford, PhD in Medical Information Sciences, working with a group of colleagues and faculty on Bayesian inference in machine learning and medical diagnosis. There, we had the dream of making tools that doctors would use to come to the right diagnosis, using the firm foundations of probability theory. And we might have even had a dream of computers just doing the diagnosis themselves. Now, as it happens, there were great limits to what we could do with the computational power that was available in those days and data that was available in those days. And so, I certainly was open to other possibilities. I was despondent. I didn't even say the word AI back then because it was so far away in our ambitions from what we're actually able to achieve. In the middle of that I got a letter from a head hunter, I didn't feel too special because the other students in my department also got what was clearly an identical letter. And I later found out that a Wall Street bank, Goldman Sachs had told the head hunter make a list of entrepreneurs in Silicon Valley with PhDs in computer science from Stanford. So that was a serendipitous moment. I had never thought of finance or Wall Street in my life. Yet, it turns out that I'd been doing the preparation entrepreneur, Silicon Valley PhD in computer science from Stanford. I just had no idea what I was preparing for the universe as a does had not disclosed that bit of information to me. I went out to Goldman Sachs and thought what they were doing and got excited. That I was the fourth person to join a three person design team that had a modest ambition to build a piece of software that contained all the market data all the time series, all the trades, all the positions, all the risk all the models of Goldman Sachs. Starting off with one trader at a time, then eventually the whole foreign exchange business and continuing from there. We have to think about the tools that were available in 1993. None of the software existed to do this. So we wrote what you would recognize now. Many years later as no SQL Dynamo dB, some looks a lot like Python, a scripting language that in our case was optimized for counterfactual questions, what if questions. And it ended up being a great success because here's what we could do with that software. With this software, we'd gone from being a bunch of atoms and excel tools to the traders in the trading business, to where the platform and the business were one in the same. Everything you wanted to know about the business or could want to know about the business was a spent modeled represented in the platform. Once you've achieved that, which is quite an achievement in itself, you can now ask counterfactual questions of the software. And if it's a high fidelity representation, you'll get answers from the software that are equivalent to what you get if you actually did the experiment in reality. But I'll tell you something, it's a lot less painful to lose a billion dollars in software simulation in silico, as one says, then to lose it in real life. And if you lose it in software simulation, well, it didn't actually happen and here in the present, which is the only time you can actually act, there's plenty of things that you can do about it. And so this is the essence of risk management, seeing possibilities, asking questions as counterfactual questions, and then doing something about it in the present, to mitigate that risk, mitigate that possibility. And so I thought I was going to go for an interview at Goldman Sach's, I ended up staying for 26 years. Eventually I became the co-head of a group called The Strategists, The Strats for short which we would now call data scientists. People with the math and software skill set. Working on the trading desk side by side with the traders and the sales people to create this convergence of business and software. After that I was the co-head of our global equities trading business. And then eventually Chief Information Officer, Chief Financial Officer and co-head of global trading business equities. As well as fixed income currencies and commodities. I retired from Goldman Sachs on December 31st, 2019, and here I am now. In my first foray as a professor, what I would like to generate in this course, is the possibility that I bring what I know together with what you know and we inspire one another. And out of this course come some wonderful new businesses. In this course, I would like not really so much to share war stories though there will be a little bit of that. And I would very much like to answer all of your questions. I would also like to give you a framework that I put together based upon 26 years of working at the intersection of software and finance. The framework I will submit has observational power explaining what's going on right now. And predictive power giving you a guideline or roadmap, no guarantees about how the financial ecosystem is going to evolve in the future. So with that, let's turn to the slide. One second, please. How software ate finance. We're going to introduce the course and the framework and in this first segment, talk about money. So here's the core framework for the course. On Wall Street and in the financial ecosystem generally, we think often about dichotomies. Here are some of the traditional dichotomies. There's traders, and there's on the other side engineers, data scientists quants. And it used to be never the twain shall meet strict boundaries between the two. And those boundaries existed for a reason. But as software and business have converged and become the same thing, those boundaries have shifted, and I'll tell you about some of the new boundaries. By side, institutional asset managers and investors on the one hand, and then on the other hand, the sell side. The people, the institutions who provide liquidity who make markets to the buy side. We have regulated businesses and non regulated businesses and it's more complex than a dichotomy. It's actually a spectrum of different kinds of regulation. We have infrastructure providers, such as, the clearinghouses, exchanges, market data providers, and then, we have the users of those services. And then, we have data providers, as well as consumers of data. That was the old, traditional framework. But all of those distinctions are changing and colliding and evolving, and that framework is not so useful anymore. So here's the new framework. We're seeing it's happening now. Wall Street economics and economics broadly of the financial system are becoming software economics. They're becoming software businesses. And to me, it's that convergence of finance and software. If you would like, you can use the shorthand label then take the reality of courses. There has been software and finance for decades and decades, nearly half a century. What is happening in this new paradigm, is that the traditional players in the financial ecosystem are giving way to a new system, a new ecosystem. And that ecosystem I submit to you is organized around application programming interfaces or API's. The rise of API's together with open source and cloud platforms is creating a new generation of financial service providers. Many of them and eventually I would guess, submit estimate all of them operating in the cloud. And I would say this is the core of the course, that every financial, every participant in the financial ecosystem needs to take its services and products and surround them, encapsulate them in an API. And they need to be a world class producer of one or more APIs. And then for every activity where they do not wish to be cannot be a world-class producer of a service, become an astute consumer of services API provided by others. And for now Lets talk about what is an API? So let's talk first about application programming interfaces or API's for short. Without getting first into the details of it application programming interfaces, let's just talk about interfaces. As it happens we're all used to interfaces. They happen everywhere in our lives and they all have the same overall framework. Say I have a way to get something done, but I have no idea how it actually gets done in detail. I just want to press a button or turn something on, and then I have a side effect an action or result. All I want or need to know is that if I perform the action in the right way, then I get the positive reaction or result without having to know anything about the gory detail of how it gets done. But I do have a strong expectation, which could be contractual about the service level and the result. There are many ways to think about API's, but here are a few examples that we're all used to. Let's start with the standards for mobile phones. The 4G standard is the one that's current right now, we're on the threshold of 5G. But here's all I need to know. I get off the plane. And maybe I've arrived in a foreign country, and I turn on my phone and it just works. I don't need to know which frequency the phone is using. Maybe it's using a different frequency in the US and in this particular foreign country. I don't need to know who the mobile service provider is generally when everything is working. Seamlessly, all I know is that my provider in the US has some agreement with providers around the world. And I turn on my phone and it just works. Now the 4G standard is 1000s of pages of documents, many levels of technical abstraction and all that is crucial in the state of work. But those documents didn't exist if the implementations didn't exist. But I, as a phone user don't need to know anything about that. I turn on my phone and it works. There are internet standards that we're all used to as well, TCP/IP. Before that there was a different protocol called NCP. But then in the 80s, the the Internet, the ARPANET changes need to internet and moved to TCPIP. Again, elaborate complex the results of many years of research, ongoing research. I don't need to know all those details. All I need to know is that I've got TCPIP on my machine or my phone and it just works. Wi Fi is a particular implementation on top of TCPIP, and yet we all know how to use it. None of us has any idea how it actually works perfect example of an API. Here's another thing that almost all of us use, and many of us use daily. It's Google Maps. If you look inside your Uber Lyft, you'll notice that the maps all look kind of similar. And in fact, if you look very closely, you'll see that they are Google Maps. Google Maps is a classic example of an API. It is simple to call the Google Maps API. A Junior programmer can do it in a couple of lines of code you put into coordinates and you say whether you're going by car, on foot or by public transit. And it gives you back not only the time that it takes in current conditions to get from point A to point B, but it gives you some racks. Now think about what has to go on under the hood of Google Maps for that to work. Google Maps had to digitize the planet. It had to build these apps work on different kinds of machines, different kinds of phones. And to get the apps and the phones into the hands of millions of drivers. And to provide so much value that people leave the app on as they're driving around. And they're sending back to Google everyone's location. And then now the Google platform becomes almost this omniscient. They can see where all the cars are and how fast they're moving. There's a huge amount of complexity going on over there. But at the API level, it's simple. I call Google Maps. Here's a B, here's how I'm moving. And it gives me back a very simple answer. operating systems that we use Android, Mac OS, iOS, Windows Unix are all examples of interfaces. You can also think of an API is a contract between a consumer and a producer. And so the producer of the API, let's go back to the Google Maps example, is performing this expert and extremely complicated thing. And in general, that's a feature of powerful API's. But the consumer of the API just has to do a very simple incantation, all the complexity, all the magic gets hidden. And the consumer just gets the result. To continue that contract metaphor. In industrial applications, you might actually be paying for every API invocation. And the producer of the API might also make representations and guarantees about uptime and latency between the time it receives a call to its API. The time it delivers a result back to the consumer. In this example, the consumer doesn't know how to do anything except invoke the API. The consumer does not ought to know how the producer the API actually get its work done. API's are black box. And the fact that they're black boxes is actually a beautiful thing. Because it means among other things, that the producer can change the back end. Change what's under the hood completely. And the consumer doesn't even know that anything has changed. Doesn't need to know, doesn't care. The API hides information in a good and useful way. And again, why does the API do that? It says the producer can change the implementation without the consumer having to lift a finger. The essentials of an API than the essential features of an API are abstraction. I'm doing something really simple as the consumer of an API, the producer is doing something incredibly complicated. But I don't need to know standardization. As long as we're sticking to the same version of the API, the producer can completely change what's under the hood. And the consumer doesn't need to care at all. Which is closely related to in difference between implementations. It doesn't really matter how the producer gets worked up. It could use a little glen gleemen. It could use data centers, it could use clouds, it could use machine learning. It can do all kinds of things, but the consumer doesn't need to know. And in fact, the producer can over time really do suffer, expand what's happening under the hood, make it more powerful, make it faster, make it more complete. The consumer doesn't need to know anything about that. Doesn't need to do anything different. And again, we come back to information hiding. We're actually really used to information hiding interfaces and standards in our daily lives. Here's an example. I plug an appliance into a wall socket and I can now turn the appliance on. If you think about it, there are actually two API's there, the wall socket and the button or switch that turns the appliance on. I don't need to know anything about how to generate, transmit and distribute electricity. I just need to know that it's going to work in almost all states of the world. It does work. Another example is a gas pedal. We all know that we press the pedal on the right, and the car moves. In fact it might be a Tesla. It might not even have a gas pedal or an engine. I might still call the pedal on the right the gas pedal even though there's no gas and there's no engine. It's the pedal that makes it go. The details under the hood aren't important enough that under the hood of the Tesla you find empty space. Going back to original example and get off the plane in foreign country and my mobile phone almost always works because the 4G standard. Why is all this so important to software architects? Well, adding a person to a team of software engineers introduces a communication path between that new person and each pre existing member of the team. That means the number of communication paths in person and a team within people is n times n minus 1. All of that divided by 2, and so that's growing as the square of n. So it's show parabola. It looks pretty simple at first. In fact, you can see in the early days for small n, it doesn't look too different from a line. It's linear practically. But then right after n gets to some reasonably still pretty small numbers, but not down from 0 to 5. Suddenly the parabola essentially goes vertical. What does that mean? It means that in practice, teams work well until as it turns out they got about 20 engineers. But past that, a team starts to sink under the weight of all that communication. Number of engineers grosses in, the number of communication links grows as n squared. API's brilliantly allow us to factor teams into small teams. Indeed, it really is the only way that we will have to solve the mythical man month problem. The way you do it is that each protein team produces one or more API's. And it consumes one or more API's. Teams communicate exclusively through the API. You really got to enforce that. It means that the only way the teams communicate is through the API. They don't get to poke inside someone else's blackbox. As soon as one member of a team emails or calls a member of another team. We're back to that order n squared mythical man month problem. API's separate architecture from implementation. All right. So let me say a little bit more about API's beyond the doodle video. I talked about the mythical man month problem. This is a legendary problem in software engineering. So one will often say a project is a nine-man month, nine-person month problem. And so, well, why don't we just put nine engineers on it, and get it done in one month? And there are a ton of reasons why that doesn't actually work. There are some processes that you intrinsically can't run in parallel and then pervasively across all software projects. It turns out that communication among the people on the team is super important. And the number of communication links that we talked about grows as the square of the number of people in the team. And so pretty rapidly much beyond the team 5 to 20, you might get some more productivity by adding another engineer. But that's going to be greatly offset by the additional cost, complexity of the team, of all that communication. And so if you encapsulate the team's product or service in an API, then other teams can call that API. And each team can go about changing the implementation, making it better. And as long as it's API compatible, you'll be fine. So API is powerful antidote to the mythical man month problem. An important example of the value in the power of APIs in reality is of course, Amazon Web Services. There's a story, perhaps some of it is legend, that Jeff Bezoz wrote a memo. And in his memo, he said, all of you in Amazon who are delivering goods to consumers and building a website. So that consumers can find those goods, and ask for them to be delivered. All of you are going to be needing some data and compute services. And then there's other people at Amazon, who will provide those data and compute services. And when you in amazon.com wants some data and compute, you will call the API. You will not pick up the phone or send an email to your colleagues, you're working on data in the [INAUDIBLE]. The only communication I will allow between these two parts of Amazon is through the API. Some people, namely those building the website, delivering the goods are the consumers of APIs that others are producing. And those APIs that others are producing went on to become Amazon Web Services, which is a huge driver of the success of Amazon. So now let's shift over and talk about money. What is money? So right out of Wikipedia, it's an object or verifiable record that is generally accepted as payment for goods and services. And repayment of debt, within a particular socio-economic context. Each word is there for a reason, and especially that phrase at the end. It's within a particular socio-economic context. The standard set of attributes of money is that it's a medium of exchange. So I will give you a good, and in return, you give me the medium of exchange or some money. It's a measure of value and that term is synonymous with the unit of account. And so we price things in the socio-economic context of the United States of America in dollars, not another use case for money. And it is also a store of value. People might keep cash in a closet or under the mattress, and that is one kind of store of value. It has some complexity, there are things that could happen to that that store of value. And so we often keep money in a very different form, and I'll get to it and really go into the details, call the bank account. And that has some trade-offs as well, and we will talk about those. History of money in about seven minutes or less. So let's get through the history of money in seven minutes or less. There are two broad categories, the first category, money of account, and give it as debits and credits on the ledger. And the ledger can take many forms all the way from Papyrus to distributed ledgers on blockchains or Merkle trees. And the second category is money of exchange, tangible medium of exchange generally. Made of clay, leather, paper, bamboo, metal, cowrie shells, and so on. Though increasingly, money of exchange is taking an intangible electronic or digital format. So let's start with the first category, ledgers or records of account. On clay tablets, metal, Papyrus, they go back more than 7,000 years and they predate coins by several thousand years. So money of account, you can think of the tally stick as an extremely primitive ledger. And to put that in perspective, the oldest tally stick we know of dates back to the Amration Period. It's an upper Neolithic stone tool tradition associated with Homo sapiens and Neanderthals in Europe and parts of Africa. As an example, there's a 20,000 years old bone, it's called the Ishango bone, it's found near one of the sources of the Nile. It seems to use matched tally marks on the thighbone of a baboon to perform accounting. And archaeologists have also found accounting records dating back more than 7,000 years in Mesopotamia. These accounting records clearly show expenditures and lists of goods traded. Now let's move on to the second category, money of exchange. We have cattle, the first and oldest form of money, as far as we know, money of exchange going back to 9,000 BC. There's the Mesopotamian Shekel, going back to about 3,000 BC. It's an early coin that was a unit of weight and currency. And the Shekel circulated alongside barley, the pre-existing money, weighing the same amount, the word shekel actually means to weigh. It entered the English language from the Hebrew Bible and of course, it's the name of the modern currency in Israel. Cowries were shells of a mollusk that was widely available in the shallow waters of the Pacific and Indian Oceans, going back to China in 1200 BC. The first bronze and copper cowrie imitations were made in China in 1,000 BC. Modern coins appeared in Lydia in 500 BC. They're later refined by the Greek, Persian, Macedonian, and Roman Empires. Paper currency was invented in China in the 9th Century. And then later there was the gold standard from 1816 to 1930. And the Bretton Woods system from 1944 to 1970. The Bretton Woods Accord created the World Bank and the International Monetary Fund, the IMF. It established gold as the basis for the US dollars value and peg the other currencies to the US dollar. Then President Nixon suspended the dollars convertibility into gold In 1971, paving the way for the current system of floating exchange rates. The first bank accounts originated also in Mesopotamia in 1800 BC. In the barter economy, people paid for goods by exchanging them for items of equal value, usually livestock, grain, Precious metals, weapons and claw temples were well guarded and supplied with priests who were illiterate. And so they became the central storage venue for all those goods which took up a lot of space. Priests kept records of deposits, transactions, withdrawals those records were the first bank accounts. Checks and checking accounts first appeared in ancient Rome in 352 BC. Jewish merchants fleeing Spanish persecution settled in the wealthy Italian cities of Florence, Genoa and Venice after the Edict of expulsion from Spain in 1492. And they became bankers. Bands without laws retargeting merchants carrying large quantities of coins and other valuables. And so the Italian bankers invented paper based methods called bills of exchange for moving around large amounts of money. Unlike a modern check, a bill of exchange is a written document. Outlining a debtors indebtedness to a creditor is not payable on demand check. It's usually extended with credit terms of 90 days. For a long time bank accounts were only for rich people. That changed in 1810 when Reverend Henry Duncan established the savings and friendly society. What Americans would call a first mutual savings bank. Demand notes were an early version of United States paper money, and they were issued during the American civil war. The U S government to the North, used them to pay the salaries of workers and military personnel. They were printed with green ink on the reverse side, hence the term green back. The few remaining demand notes and still in circulation are the oldest valid currency in the US today. And believably, they are still valid, but you hardly ever see them. And I've never seen them accepted a collection, they're later replaced by Federal Reserve Notes. We'll talk more about those, and those Federal Reserve Notes inherited the greenback moniker. >> So, let's talk about the value of money. First of all, the value of money is an inter subjective reality. And many of you will have heard the term from the books of Yuval Harare, who's one of my favorites. If you've read Sapiens and Holidays, you will have encountered this term and you might have encountered it in many other places. And so what is an inter subjective reality? Was seeing the creation of inter subjective reality seems to be something that human beings are uniquely good at doing. In our minds, we create stories and then we share those stories with others. And those stories create thoughts in the minds of others. And then, collectively, we take actions. In reality, that are generated out of those shared thoughts and stories. So that's an inter subjective reality. So as an example, the United States of America is an inter subjective reality, we believe in it. And of course, it's got foundational documents, it's got geographical boundaries. But as we'll talk about those boundaries can extend in interesting ways. The United States of America is an inter subjective reality any corporation or institution or organization is also a kind of inter subjective reality. And so here's a definition from Thomas Scheff. He is an emeritus professor at UCSB. His fields of research are social psychology, emotions, mental illness, restorative justice, collective violence. He writes about a lot of topics and here's Thomas, with his cat. Let's just go with his short definition of an inner subjective reality. It's the sharing of subjective states, by two or more individuals. And I'm going to submit to you that any kind of money. Beyond money, which we're all used to, but also let's say Bitcoin is still the sharing of subjective states by two or more individuals. And of course, there's a tangible ramification of those subjective states. Bitcoin mining gear for instance, the software of the Bitcoin protocol which you could print it out and that would be tangible. But above all, the acceptance of it and the use of it as a medium of exchange. Store of value unit of account is something that depends on the sharing of beliefs between the payer and the recipient. So let's talk about some of the required properties for money to function effectively as a medium of exchange. And this is the canonical list, fungibility. So one dollar bill just as good as any other dollar bills from might be clean new others might be crumple. It still functions as a dollar bill, they'll have different serial serial numbers on them. But other than that one dollar bill just the same as any other dollar bill. Durability is important, we want them to laughed at least a little while if not forever. Portability will get into this, a dollar bill is indeed a bearer Bond. The holder of the dollar bill is the bearer of that Bond and it's really easy to carry that around. And to hand it from one person to another portability. Cognize ability, it means needs to be instantly recognizable. Of course, the sovereigns have done some work to change the appearance of the dollar to make it harder to counterfeit. Still important that anybody can look at it, maybe hold it up to light, do some other things with it. But recognize it as a valid medium of exchange store value, unit of account within a particular socio economic reality and also stability. Let's talk about what happens among other things when money loses stability. So, two kinds of stability loss can occur of course one is inflation. Of course, that hurts, they're holding the currency. It also hurts poor consumers. There will be some consumers whose wages will reset, they might even be indexed. And so maybe doesn't matter so much. But for many others, their wages won't reset fast enough to adjust to changes in the price level. And once inflation gets going, there's the possibility that it becomes hyper inflation. And there's an example I don't even know how many zeros are on there. But this 100 trillion Zimbabwe dollars, that's what happens and we know many instance from the history books where that has happened to money. On the flip side, deflation is also problematic because it can generate a contractionary spiral in which nobody wants to transact or really do anything. People count their bills and do nothing. They hold back on commerce and investment and that creates other dire problems for society. There are tomes and PhD dissertations indeed libraries written by economists on money. I'm going to talk about a few of my personal favorites. It's not like I'm right or wrong, of they're right or wrong, but here are some interesting statements from sociologists and economists whom I respect. So on the left, we have Geoffrey Ingham. And he does, I'll admit look a lot like Thomas Shot, but as far as I know, lacks attacked money, he said is a form of sovereignty. And as such, it cannot be understood without reference to an authority, important. But for us to consider as we ponder Bitcoin. Geoffrey Ingham, just for background, is British sociologist, a political economist and is the author of many books on capitalism and money. On the right we have Joseph Schumpeter of the Austrian School, one of my personal favorites. He's known for many, many things. He was a Harvard professor. He coined or was at least the popularizer of the term Creative Destruction. Many of you will be readers of the Schumpeter column in the Economist, my favorite column in the Economist. The Economist has called him a champion of innovation and entrepreneurship. And his writing showed the benefits and risks and dangers of business and he was present and ahead of his time in many ways. Wrote deep thought on so many topics related to money and the economy. But according to one of his close colleagues at Harvard, he was never able to get his ideas and money straightened out to his own satisfaction. I wouldn't say my ideas are straightened out anywhere near my satisfaction. I take some comfort in the fact that he never got to that satisfaction either. And is my intention that in this course, we will incrementally have a deeper understanding and even sharper and better and more useful ideas on what is money. So now let's talk about fiat money. >> So let's talk about fiat or sovereign money. Fiat as in let it be, as in what it had value. Value because the sovereign says it's valuable. Let's explore that a little bit. And in particular, let's get into the concept of legal tender. So, let's talk about US currency generally. Prior to centralized banking with Federal Reserve, each commercial bank in the US issued its own paper notes. The first institution that looked like a central bank had some of the responsibilities of a central bank in the US, was the First Bank of the United States. It was chartered in 1791 by Alexander Hamilton. In 1811, its charter was not renewed. In 1816, the second Bank of the United States was chartered. Its charter was also not renewed in 1836 after President Andrew Jackson campaigned heavily for its disestablishment. From 1837 to 1862, in the so called Free-Banking Era, there was no formal Central Bank and banks issued their own notes again. From 1862 to 1913, a system of national banks was instituted by the 1863 National Banking Act, which you can think of is a precursor to the Federal Reserve Act of 1913. Federal Reserve notes, also known as United States banknotes are the banknotes currently used in the United States of America. They're denominated in United States dollars, USD. Federal Reserve notes are printed by the United States Bureau of Engraving and Printing on paper made by cleaning company of Dalton, Massachusetts. Dalton notes are the only type of US banknotes currently being produced. Federal Reserve notes are authorized by section 16 of the Federal Reserve Act of 1913, it's in the reading list and I encourage you to have a look. They are issued to the Federal Reserve Banks at the discretion of the Board of Governors of the Federal Reserve System. The notes are then put into circulation by the Federal Reserve Banks, at which point they become simultaneously liabilities of the Federal Reserve Banks and obligations of the United States. Dollar bills say all kinds of interesting things on them, it's worth taking out a dollar bill and having a look. First of all, it says Federal Reserve note, note as in money. It is an IOU and in fact it is a bearer bond, and that whoever is holding it, who's ever bearing it is the owner of the bond. And it is an obligation or liability of the Federal Reserve. And here's the right, the bearer has the right to go to a Federal Reserve Bank, offer up that note and receive in return another note, it's entirely circular. Some will say well, it would be a good clean, brand new bill, but it doesn't have to be, it could be another old crumpled one. I'm so you can turn it in and get another one, it's circular. Dollar bill also says annuit coeptis, loosely translated as Providence Favours Our Undertakings. Of course it says in God we trust that was added much later. Says Novus Ordo seclorum, The New Order of the Ages. Grand decoration indeed, says all kinds of things. The thing it says that most gets my attention is the following. This note is legal tender for all debts, public and private. And as I said, to my mind, that's the most important thing. It breaks all the circularity we've discussed. The term legal tender is from a Middle English word, which was Tendren, which came from the French, which is Tendre which still exists, which just means to offer. The Latin root is tendren, which means to stretch out in the sense of the tenders and offer. It's related to the etymology the English word extend, to hold outward. Legal tender is a medium of payment recognized by legal system to be valid for meeting a financial obligation. Each jurisdiction determines what is legal tender, but essentially is anything which when offered tender in payment of a debt extinguishes the debt. There is no obligation on the creditor to accept the tendered payments. The debt is discharged at the moment of the tender as long as both sides of the transaction are within the boundaries of the sovereign. It's discharged with the creditor accepts the tendered payment or not. And here's the key part, we all need to go back and read our John Hobbs. The sovereign backs the discharge in debt with its monopoly on the use of force within his boundaries. So as we talk about Bitcoin and other currencies and the idea that it's somehow breaks the connection to the sovereign. I encourage us not to forget that the inter subjective reality called the sovereign, is indeed that entity. It's a shared concept that we have all invented in our minds and agree upon. But it is that entity that does have a monopoly on the use of force within its boundaries. It can deprive us, among other things of our liberty. And so when the sovereign says the debt is extinguished, that matters. >> So let me pause there, and I'll certainly switch over to the next section of the lecture, which you'll find in subsequent lectures.
