Balance sheet as a service
APIs and market-making
The contest over the future institutional structure of money is taking clearer shape. The competing interests can be understood in various ways, but roughly we could say that crypto is trying to disrupt the system, central banks to contain the disruption, and the banks are trying to pick the best horse in the race. With the release of last month's Stablecoin Report, regulators are trying to re-establish the regulatory fence around the new entrants.
A final compromise is still some way off. A reader pointed me toward several pieces by Tony McLaughlin of Citi's Treasury and Trade Solutions, the division of the commercial bank that serves the liquidity and payment needs of corporate treasurers. From this vantage point, close to the center of the commercial banking system, McLaughlin is in a good position to have some insight into changes in the monetary plumbing. In particular, a piece called "Balance sheet as a service" caught my eye, as it highlights the value that banks see in DeFi.
APIs for monetary theory: a short introduction
The world that McLaughlin sees is built in a fundamental way on APIs. These are a key component of modern Web 2.0 services: the internet would be very different without them. Those Soon Parted readers whose interest in platform finance starts from money, rather than from tech, might thus far have avoided thinking much about APIs, but that ends now.
An API, or application programming interface, can be understood as the combination of a networked server and a protocol according to which that server sends and receives messages. The server is always listening, and when it receives a correctly formatted message from an appropriately identified sender, the server performs some action according to the message and transmits information about the results of that action back to the sender. Importantly, the message protocol is carefully specified, so messages can be exchanged by computer programs in a fully automatic way.
APIs thus allow programmable machine-to-machine communication without central control: clients and servers only need to agree on the protocols for communication between them, while behind the scenes they can do whatever they want.
The Twitter API provides one simple example, familiar and ubiquitous. The Twitter API allows, among other capabilities, any webpage to embed a user's latest tweets in a way that updates automatically, as we have come to expect from Web 2.0 services. When the page is viewed, the server hosting it automatically makes a request to Twitter's servers, which delivers the latest tweets in a predictable format, which can be embedded by the outer page. Neither server needs to know anything beyond what is in the API specification. Indeed, the API program running on Twitter's server could be completely redesigned, but as long as it continues to correctly respond to API requests, it would make no difference to the website using the data.
Banking through APIs
APIs are central to the vision for platform finance that Citi's McLaughlin spells out. A very concrete example is provided by instant installment financing or "buy now pay later," recently popularized by Klarna and AfterPay. These T accounts illustrate the financial steps. A retail customer purchases goods online from a merchant, creating a payable entry for the customer and a receivable entry for the merchant. Immediately, triggered by an API request through the merchant's e-commerce website, the customer can finance the purchase by borrowing the full amount from a bank. The merchant is paid with a bank deposit now, and the bank ends up with a loan to the merchant's customer. The bank is compensated for the lending, perhaps by discounting its payment to the merchant.
The financial structure of these transactions is unremarkable—this is trade finance, which has been a standard banking transaction for centuries. The crucial innovation of platform finance, not visible in the T accounts, is that no human intervention is required by either the merchant or the bank. Instead, the bank's balance sheet expansion is initiated by an automatic API request.
For that to be possible, the terms of the transaction must be mostly set in advance, something like a line of credit. The bank will want to limit the size of transactions as well as the total amount of loans outstanding, it will have a fee structure that is known in advance, and so on. Within these constraints, API banking creates a new kind of automated access to the bank's balance sheet.
There is a deep connection between APIs and market-making
A bank is its balance sheet, and more specifically a bank is a balance sheet with highly liquid liabilities. To make sure that that is so, banks must act as market-makers in their own liabilities, creating and redeeming them smoothly at par to allow normal payments. Banks make markets in money, and their balance sheet capacity is what allows them to do so.
There is a deep connection between APIs and market-making that is difficult to see, I think, for those coming from one side or the other. The API function is carried out by always-on servers that do not initiate requests, but instead stand ready to handle requests initiated by client computers. The abstract service provided by APIs is availability, handling client requests predictably and quickly. For any specific API, that abstract availability becomes the availability of a particular service.
The market-making function is carried out by dealers who do not initiate transactions, but instead stand ready to complete transactions initiated by their customers. The abstract service provided by dealers is liquidity, executing customers' transactions predictably and quickly. For any specific market-maker, that abstract liquidity becomes liquidity in the market for a particular security.
Citi's idea is to allow API requests that go directly to the bank's balance sheet, tying together these two already structurally similar functions. The result will be a programmable, automated market-making system for the bank's own liabilities.
Programmable banking
By my reading, this analysis captures, at least from the banks' point of view, a part of the future for the financial system that could emerge from current conversations about programmable contracts, decentralized ledgers, and central bank digital currencies. McLaughlin says that "the inevitable destination" for platform finance "is the provision of balance sheet through API." It will take some time to understand what this could mean for the liquidity of the financial system as a whole.
good article
The API-enabled BNPL analogy is great. Never actually seen such a succinct explanation for what DLT use cases are driving for! It strikes me that Mr. McLaughlin and what he shares about the RLN is equally well articulated.