Standard Treasury as a Startup Bank

At Standard Treasury we are building an API banking platform, becoming our own bank, and doing so in the United Kingdom. I want to address these three aspects of our work and also talk about the long-term social potential for our bank.[1] 

Banking as a platform 

Over the last six years, we have seen a proliferation of startups at the application layer of banking. Some examples include LendingClub, OnDeck, Braintree, Stripe, WePay, Betterment, Wealthfront, Osper, TrueLink, Angelist, Seedrs, GoCardLess, FutureAdvisor, Square, LendUp, etc. 
Behind each one of those institutions is a bank. Sometimes these are big banks like Wells Fargo or JP Morgan, while sometimes they are small banks like BanCorp or WebBank. At either size, the technology is terrible at these banks. The interfaces which one has to deal with are foolishly designed, risk and compliance management are often done by hand, and the entire infrastructure often uses legacy technology that makes speed, consistency, and reliability very difficult. 
We are building the programatic banking platform which should underlie the new, growing application layer of finance. We want to be the Amazon Web Services of banking. Our wholesale commercial banking infrastructure will be unknown to most of the public, but it will power some of the biggest applications and companies in the world. 

Becoming a bank 

We must be our own regulated, deposit-taking institution in order to build the platform and product we are planning. We have to own the entire regulatory and technology stack.

On the regulatory front, we will be foot-forward on things like risk management, AML detection, sanction-list referencing, etc. We need to understand what our partners are doing and build our technology to work to underwrite and manage our risk. We have to understand our customers (specifically financial technology startups), so that we can help regulators understand our customers. In short, we have to be a purpose built communications layer between our partners and everyone else — including regulators and payment systems. Today, bankers are doing a bad job of this. (In fact, regulators have hit a lot of the small banks in this space with consent decrees, exactly because they did not manage risk properly).

On the technology front, after building out APIs for core banking systems in the US, we determined that none of the standard offerings met our desire to drive the entire bank with a secure API in a highly performant manner. We have been unimpressed with existing bank infrastructures. Both homegrown (often ancient) systems and the ones provided by vendors like FIS, Fiserv, and Jack Henry cannot fulfill basic requirements around security, auditability, reliability, speed, and usability.

Our core banking system is built using an API-first design. Every operation in the bank is controlled by a secured rest API, with a micro-services architecture on the backend. Because we started from scratch, we built our system with security, reliability, speed, and usability. We are using Clojure, PostgreSQL, Storm, docker, etc [2].

A bank in the United Kingdom

The UK regulatory environment favors more competition in the banking sector. They are actively encouraging new challenger banks. After extensive research, we have decided that it is more capital- and time-efficient to start a bank in the UK and build our wholesale services there with any number of great financial technology customers. We will then come back to the United States, either through a branch or agency (which traditionally emphasizes wholesale commercial banking activities) or through a US-based subsidiary.

By working closely with our UK regulators (the Prudential Regulatory Authority and the Financial Conduct Authority), by being competently run, and by proving our business model in the UK, we will be able to return to the United States more easily than we could pivot a purchased bank's model to it. 
Additionally, the US is averse to granting new banking licenses, and buying a bank often leads to more headaches than opportunities. (See my post Startup Banking’s Looming Leviathan). 

The long-term opportunities

When we talk to venture capitalists, we talk about the size of the opportunity. We have a small target market (financial technology startups) and also a clear larger target market (the $259 billion a year wholesale banking market). 
But I want to touch on something else. I care about the potential social impact of a bank that changes the cost structure of financial services. I want to build a bank that disrupts banking. And not just because I might do well economically, but because it would be one of the most powerful ways for me to help others do well economically.

Many people cannot access financial services because banks simply cannot make money off them. Starting a business, raising one’s family out of poverty, or just saving for a rainy day are all far more difficult without access to a bank. I hope to radically change the equation through our systems, allowing many more people to have access to the financial system.

By creating a platform which makes it cost-effective for smart folks everywhere to build applications, companies, and non-profits that use our services, I believe that we will impact millions of Americans and tens (if not hundreds) of millions of global citizens.

That might sound grandiose, but fixing the banking system is not an abstraction to me. It is what gets me up every morning — and reminds me that even though we likely have to do six or seven nearly impossible things to make this dream of an open, safe, compliant, risk-managed, technologically-enabled, and regulated banking API platform a reality, it is all worth it. 


[1] Once when I was in college, I asked a professor about an unusually short page limit for an assignment. He responded that "to be abstract is not to be vague." I have tried to live up to that notion in this post. There is a lot of abstraction here. Examples include getting regulated in the UK, the particular hardships of getting regulated in the US (whether de novo, purchase, or partnership), capital requirements and how to grow infinitely while following the rules, technical architecture, feature rollout, risk and compliance management, foreign operating licenses (branch, agency, or subsidiary), how we would specifically support individual companies, what social impact for the underbanked would actually look like, and the list goes on, and on, and on. Some of these topics I will write follow-up posts about, while others are secret Standard Treasury sauce. 

 [2] If this sounds interesting to you, email :). Our product engineering team is staying in San Francisco.