(This started as an email to the Standard Treasury team to summarize the many conversations that my cofounder Dan and I had with them over lunch, dinner, coding, and a ton of product discussions. The team thought it made sense to share it publicly.)
I often get asked to tell the story of Standard Treasury: Why are we building it? What is our vision? How did we come to this thing over all others?
When asked questions like that one, I think it can be easy to fall into simple narratives or platitudes: we are revolutionizing banking, and have been, since day one! I'm not exactly sure what that sentence means, and nothing worth doing actually comes in a flash of genius. Certainly not by folks like us, who have always gotten on in the world through persistence first, and smarts a distant second.
The bigger problem is that I never have the time to tell the folks who ask the questions all that is on my mind, so I ended up telling them bits and pieces. This [blog post] is designed to tell much of the story although I still haven't captured it all by any means.
The Underbanked and Engineering Financial Operations
For me, the genesis of Standard Treasury was based in the two experiences I had in the year before founding the company.
The first was when I was working in public policy and civic technology in New York City and Newark. Particularly when I was working for Cory Booker and staff in Newark, I became curious about underbanked people — or the problem of financial empowerment as it is sometimes called. I talked to a ton of people about their use of payday lenders and check cashers. What I found was surprising to me (in my ignorance): most underbanked people or small business owners are familiar with banking products, their use, and their relative value over the options they were using.
So, why didn't they use banks? The answers fell into one of two buckets. The first is that they wanted lending products they couldn't get, since the banks considered them too much of a risk. The second was that banks just wouldn't offer them other products even if they had nothing to do with lending. I found this second answer rather perplexing, so, I went to talk to a bunch of banks. What they told me was simple: it cost money to maintain bank accounts — serious money — and if you weren't going to cross-sell customers something, it didn't make sense to bank them.
That surprised me. The more research I did with banks, the more I realized that it was their legacy technology that led to their cost structures. Cost structures that prohibit them from banking some people. In essence, there are folks that banks don't market to and avoid banking because the banks' business models makes those people unprofitable customers.
The second experience was when I was working at Stripe. I won't go into a huge amount of detail here — I try to be careful about my nondisclosure requirements. Having said that, financial operations is a serious engineering challenge at Stripe (see CTO Greg Brockman's Quora answer and the section on financial operations). While working there, I got to see, firsthand, how difficult it was to operate in systems, protocols, and technologies that were designed and built in the 1970s.
Starting Standard Treasury: Commercial Banking API
Standard Treasury started because we experienced the difficulty of working with banks firsthand. Way before the company started, Dan and I had been thinking about why ACH is flat-file driven, slow, and seemingly from a different technological age. Having worked on issues of the underbanked, I realized the real-world impacts of legacy technologies, and working at Stripe highlighted how much of the credit card system was driven by similar technology. The same ideas were highlighted for Dan when he was working on pre-paid cards and stored value.
Standard Treasury was born.
We were focused on the problems we knew firsthand, and used the cases we understood best from our friends. In the early days, we talked to nearly one hundred folks about their banking experience. Some were running small companies, others were the treasurers of Fortune 500 companies. They all said roughly the same thing: "The technological interfaces around my commercial banking experience are terrible and limit my capabilities." Many mentioned Twilio, Stripe, AWS, and Heroku as models of what they wish their banks would be: technology platforms providing services.
From that, we started working on a white labeled commercial banking API platform. This first product was clear to us: companies, big and small, want to build financial functions — primarily on information about their accounts and cash payments — directly into their applications. In the coming months, we will finally be able to see the result of all that work as more than our Make Believe Mutual demo site: after a series of proofs-of-concept we have the option to launch our first, full production platform.
Developers, with a bank account at the bank in question, will be able to go to developers.[bankname].com and use an API platform, developer portal, and SDKs in half a dozen languages to interact with their bank accounts programmatically. Hopefully, a number of our other proofs-of-concept projects will convert into full production platforms with some of the biggest banks in the country and around the world.
Taking Steps Beyond V1.0 of the Commercial Banking API
From there, some product expansions in commercial banking will be inevitable: more information reporting, more cash payments, liquidity management via API, and other banking functions like foreign exchange and lending against receivables (factoring).
The most exciting thing that we've built, however, is an OAuth service that allows commercial customers — some of whom will have no idea what an API is — to use the bank's authorization service to delegate access to the API to third-party developers. With that service, developers will be able to build apps that access their financial information and cash payments, just like Facebook Connect allows granular, secure access to the social network. We hope that folks like Xero and Intuit will build apps, but we are starting to get to the real goal here: allowing developers to think of banks as platforms.
Broadening the Vision
In investor meetings and in candidate pitches when we got into YC, we made the idea of Standard Treasury bigger by abstractly focusing on the idea of bank software being broken. We did not really know what that meant. It was a hard-to-unpack intuition from the state of online banking, rather than something we really understood in particular. Something was wrong. We would find it, and we would fix it.
Over the last year, though, we have learned a great deal about the particulars. We have picked the brains of bankers; fund managers; treasurers of big corporations; startup founders working on finance; startup founders trying to avoid finance who, nevertheless, touch it more than they'd like; executives at our competitors; academics; journalists; experts and leaders from card networks and credit card processors; folks concerned about financial access like the Gates Foundation, Cities for Financial Empowerment, and Omidyar Network; and many more. I read the Financial Times and books on obscure parts of the financial system every day. Dan and I also went through Silicon Valley Bank's and MasterCard's joint product accelerator, Commerce.Innovated, and the NYC FinTech Innovation Lab where banks choose the companies in the program which they are going to mentor. The banks that chose to mentor us were Goldman Sachs, Credit Suisse, Morgan Stanley, and Deutsche Bank, who have been very helpful in highlighting areas of expansion for us.
In that deluge, several things became clear. First, we learned that bank software is a very big market. Even bigger than the number I made up with some back-of-the-envelope math for my YC Demo Day pitch!
Second, we learned that the market is dominated by large public companies that no one in Silicon Valley is aware of, much less really competing against. Banks, almost universally, have bad things to say about the technology and the pricing schemes of these vendors.
Third, we learned that API Banking is much more than a cool feature for banks to have for corporate clients: anywhere that customers interact with their banks is a place that a bank might imagine a well-built API. Banks have approached us about building white-labeled API platforms for lending, sales and trading execution, broker/dealer settlement and exception handling, prime brokerage, card processing (acquisition and issuing), custody accounts, fund administration, retail banking, private wealth banking, repo and other money markets, trade finance, know your customer and anti-money laundering procedures, risk management, and more. (What keeps me up at night is the possibility that we're passing up opportunities by not scaling much bigger, much faster.)
Fourth, we learned that as we build interfaces for external customers to access legacy systems, banks are facing internal and external pressures (e.g. stress test requirements) to build cross-functional interfaces for their own use. Some of the biggest pain points that banks face is talking to their own internal systems.
Fifth, we learned of this platform's potential impact on the world. Every week Dan and I get referred to folks who are starting financial technology companies or not-for-profits. None of them want to be in our business, but nearly every one of them would be able to make their work easier, faster, and better if banks used our products. Despite all that is happening in fintech, there is a lot of pent-up developer and technological potential — potential that would actually help banks, which their unwieldy technology keeps them from enabling.
Banking Today and Tomorrow
There are two types of common innovations happening around financial services: tools that provide some gateway into the financial system, but abstract it away (like Stripe, WePay, Plaid, Spout, WealthFront) and shadow-banking alternatives to a common financial product (Lending Club, OnDeck, Upstart, LendUp, ZestFinance).
We are doing something different: we are working to build the next generation financial infrastructure by building products, interfaces, and developer tools directly.
No matter what changes will happen in the next 10-20 years in finance, we believe that: (1) Banks are here to stay. Banks will exist in the future. The center of the financial system will include banks. (2) Banks need 21st-century technology. (3) Standard Treasury is uniquely positioned as a Silicon Valley startup focused on banking infrastructure to sell to that need.
Enabling the Next Generation of Commerce
So why does all this matter? Well, partially, it matters because I already have friends who are building mobile apps for underbanked folks that are built directly on abstractions that we're helping them with. That really matters to me; it's a huge part of what originally got me into this business. But beyond that, at a more abstract level, we care about building the financial infrastructure because banks are at the center of commerce.
Sometimes, it is easy to think that banks are an end unto themselves and all they do is extract wealth through speculation or innovative wizardry to screw their clients. They do far more than that, too.
Financial and payments systems — including the money markets, foreign exchange, credit cards, ACH, CHIPS, FedWire, debt markets — are all designed to facilitate trade. However, trade is hampered because, although we've entered the Internet age, the technology at and between banks is often in the Sputnik age.
Standard Treasury aims to improve the ways that companies and households do their financial business. We hope to enable developers of all types to build the next generation of tooling on top of banks. We want to improve the ways that clients interact with financial institutions; financial markets; financial market utilities; and payment, clearing, and settlement systems. We build systems to increase global trade, global commerce, and maybe global GDP.
That is an audacious goal and comes with a core thesis: if we improve interfaces inside banks, between banks, between banks and customers, between banks and (technologically sophisticated) resellers of financial services, and between banks and other counterparts, then we can change the very nature of trade and commerce. We can reduce friction. We can lower transaction costs: both the literal costs of transactions and just the pain that exists in the financial system. Ideas that were impossible become possible. Businesses that didn't make economic sense suddenly do. People that were unbanked before suddenly become bankable customers for someone.
Our goal is to make it easier to run businesses — online or off — in the United States or around the world. And as we serve as a data, abstraction, and tooling layer between different banking systems and between different parties that are doing banking, we become a permanent feature of the banking system. That last part is good for us and our investors, sure, but I hope it's also good for the world.
What's next
Through Dan's prodigious marketing and sales efforts, we have come to own a lot of "mindshare" around API banking. That ownership allows us to dream what I've written above: to build the coming generation of financial infrastructure.
We have also done something that is nearly impossible: we are a seven-person company that is being paid by a bank for a product that is loved by nearly everyone we've shown it to. Tons of feedback, yes. Tons of feature requests, yes. But our potential users, nearly universally, loved its execution and, perhaps, more importantly, its potential.
Thank you, all of you, for helping to take this crazy idea and make it a reality.