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.

Building the Next Generation of Financial Infrastructure

(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.

APIs, App Stores, and the Era of Mass Customization in Banking

Banks have a nearly one-size-fits-all product model which leaves value on the table. For instance, when a bank releases a new online or mobile banking system, it will often be an identical system, with the exact same interface, for all clients of a particular segment. But oil companies like Chevron have different banking needs than do retail companies like Home Depot, even though they may be the same size. This type of mass standardization and lowest-common-denominator mentality applies even more to the retail customers — usually there are just two online and mobile banking options: one for normal customers and one for private wealth clients.

Technology that is new to banking is ushering in an era where mass customization is feasible, safe, and profitable.

Banks of all sizes have spent the last half-decade cleaning themselves up in the wake of the financial crisis. They have been implementing new requirements from the European Banking Authority, the United States Consumer Financial Protection Bureau, and other regulators, as well as adapting to Basel III and other new capital requirements. Many have built new risk management and compliance frameworks in response to sector-wide malfeasance.

Now, though, banks are refocusing themselves on growing top-line revenue. Many banks have organized new teams focused on revenue growth through “the innovation agenda” and “customer experience”. Technology is understood to be a potential driver of the sought-after revenue growth. One such technology will be “API banking” – a concept that, though it seems to have achieved buzz-phrase status, represents a new and revolutionary way of thinking about bank services and how to deliver them to customers.

API refers to the Application Programming Interface: the standards and protocols which allow outside software developers to build applications on everything from Apple’s iOS platform to Facebook’s social graph. This technology and the attitude of open development that goes along with it are now second-nature at Silicon Valley’s leading companies. Apple, Facebook, Amazon, and others capture the imagination and skill of tens of thousands of software developers through an open platform and simple profit-sharing.

With their new compliance and risk management systems, banks are now positioned to open themselves up just as technology companies have. They can build similar platforms for innovation and customer-facing customization. These financial innovations will not be used to obscure risk (as most innovations of recent years have done) but rather to improve how customers, both commercial and retail, experience banking.

We are entering an era of technologically customized banking. Trusted risk-and-regulation-sensitive financial institutions will provide the core financial services via APIs. Then they will leave many of the last-mile implementation details to trusted partners and software developers. Millennial bank customers could have their customized mobile banking with special tools focused on paying down their student debt, while Boomer customers would have an entirely different online banking suite, which could be focused on either building up or spending down their retirement, depending on individual circumstances.

Developers, and the technology that they bring, can make the unprofitable profitable for the platform provider. Just as it might not be profitable for Apple to build and then acquire customers for a variety of bird-focused games — Angry Birds, Flappy Bird, Tiny Wings, et al. — it is also not profitable for banks to build the skill sets necessary to acquire and optimally serve every potential customer. With API banking, specialized third-party developers can profitably provide services that banks couldn’t afford to build, by giving both banks and the new developer companies access to swathes of the banking market, including the underbanked.

As in the Apple App Store, bank clients will be able to find and experience banking in the manner that makes the most sense for them, in a co-branded and protected environment. Customer satisfaction increases with a more personalized user experience, and revenue increases as banks are able to target and display their offerings more precisely.

Crédit Agricole and Deutsche Bank are the only major banks with APIs and app stores in the market right now. But APIs are one of the best and most talked-about ways to increase top-line revenue in the face of decreasing fee and interest income. Many banks are working toward releasing their own this year.

Amid this renewed focus on innovation and customer experience, using APIs and the mass customization they foster is just the first of many lessons that banks will learn from technology companies in the coming years.

Republished from BankInnovation.Net.

Startup Banking's Looming Leviathan

“The skill of making and maintaining Commonwealths consisteth in certain rules, as doth arithmetic and geometry; not, as tennis play, on practice only: which rules neither poor men have the leisure, nor men that have had the leisure have hitherto had the curiosity or the method, to find out.” ― Thomas Hobbes, Leviathan

Jack Gavigan wrote a blog post yesterday titled "What would a disruptive bank look like?" Read it. It is well worth the time.

I basically have the same blog post written. I actually also have the same blog post written as a detailed fifteen-page business plan ready to pitch Marc Andreessen. I outline the technology needed in a bank, the product offerings and their rollout, the legal structure I'd use, the capital structure, relevant bank regulations. Ah and therein lies the rub.

Regulation. I know I am supposed to be a big, bad startup entrepreneur who spurns restrictions of all kind. Particularly those restrictions put on me by the government. But that's just hard to do in this case since you need a license to operate.

Banks don't often fail. They don't often fail because there are real limitations on who can buy a bank and how one can run a bank in the US. Those two ideas – hard-pressed to fail and deeply restrictive operations – are two sides of the same coin.

So, how does that manifest directly for the bank-running entrepreneur?

  1. Maddening capital and other ownership restrictions;
  2. Deep restrictions on personnel and hiring;
  3. Writing a initial seven year business plan and sticking with it for seven years; and,
  4. Deep restrictions in the operations of a bank.

The key problem of restrictive category number (4), and why I walked away from spending so much time on building a bank, is that regulators artificially restrict a bank’s growth rate. The number one historical indicator of a shady bank is rapid, radical growth. Very good lawyers, regulatory advisors, and current regulators at the FDIC, Fed, and the FFIEC have all told me that any new bank would be restricted from growing more than 25% a year. Is that enshrined in law? No. However, latitude and discretion is.

25% a year. A good startup grows 25% a month for years.

I think you're left with four choices then:

  1. Figure out how to bring technology into the banking sector in a high-margin, fast-growing way (that's Standard Treasury);
  2. Build a bank and hold it for a long-time or buy an already big bank (despite all I've said, several investors have approached us about this);
  3. Build a bank someplace in the developing world that has less restrictive laws and then port it back to the US later (ready to talk when you are Marc); and,
  4. Avoid banking, per se, altogether. Build out different parts of banking like lending (Lending Club, SoFi, Capital Access Network, On Deck) and payments processing (Stripe, bitcon startup du jour).

The Path Not Taken by Simple (Bank) to Remake Finance

This morning Simple sold for $117M to BBVA. It's great news for the team, and I think it's going to be great news for retail banking.

Simple had amazing potential but also ran into many problems and difficulties caused by being built on top of Bancorp, not owning their own rails, and starting on the retail side. Simple could never build the infrastructure they needed for the product they really wanted to ship because what they have is not a bank account as people understand it. BBVA will change that.

We chatted with Shamir for awhile in Standard Treasury’s early days. Simple walked down the path of trying to get a bank charter but never followed through. It was partially timing — they were looking into buying or becoming a bank at the worst time possible — and partially that they did not build the company's capitalization to allow them to go down that path.

Also, looking at their history, it seems like they didn’t become a bank because along the way, at every step, it appeared to be the wrong choice — why build infrastructure when seemingly there are off-the-shelf options? But when one looks at the course of the company in aggregate and all the trouble they had with their service providers (I think they restarted their integrations three times), it would likely have been easier for them and better for their customers (not to mention their shareholders) if they had gone down the bank route.

It also seems like Simple never considered starting with the business-and-commercial side of banking. From the start (according to Josh’s blog post) they were focused on retail. We think starting on the other side is the right strategy to build a large bank. That’s why Dan and I have written a step-by-step product plan for a commercial bank.

Let me talk about what I see in the idea of building a bank. (Bear in mind, though, that this is not a likely outcome for Standard Treasury).

Building A Bank Directly

Everyday I read the Financial Times because it is wise to study the ways of one’s customers. But it can be depressing. With the headlines focused on bad bets, fines and settlements, price-fixing, and inquiries into malfeasance, it can be hard to focus on what I think of as the positive power of banking. To me banking is not about capital markets, investment banking, "the one percent", or high-frequency trading. Banking's true potential is not even seen in a better retail product experience like Simple. Instead, banking is about making commerce simpler and easier for businesses and consumers alike. It’s about empowering calculated risks and enabling trade in all its forms.

I want to build a bank with the simple mission of making it easier to do business - easier to be a business and easier to be a customer of businesses. Build a bank that had that simple creed at its center and you would make different product decisions and different hiring decisions than most banks do today.

This is not a casual interest of mine (although it’s a side interest to the business I am running now). Standard Treasury builds software for banks. That is the first approximation I can get to making the world I want inside the sanity and capital bounds that most venture capitalists seem to operate under.

We need a small — technology driven — bank.

Dan and I have chatted with former and current regulators at the Federal Deposit Insurance Corporation, the Office of the Comptroller of Currency, and the Federal Reserve. We have also chatted with lawyers and bankers in the business of buying and forming banks. There is no doubt that building a bank is hard. It is the ultimate schlep. But it is possible. Every conversation seems to start with people thinking we're a little bit crazy. Every conversation seems to end with an agreement that our dream is not only possible but desirable.

I won't publish our full step-by-step product plan but I do just want to talk about what a bank run like a technology company might mean in the abstract.

Bank As Startup

One key and obvious idea to anyone who works in technology is that banks have way too many people working for them. As Dan reminds the Standard Treasury team and all our customers, the banks that will survive in the future will be those that are most able to alter their cost structures.

One senior banking official recently told us that banks are likely to go through the same type of restructuring that the airlines went through in the 80s and 90s. They had large costs and outdated ways when the money was easy. But when the well dried up and airlines had to remake themselves, many airlines simply died. Well, now, the easy money is drying up for banks, This is the moment to build the Southwest Airlines of banking.

Without focusing in on capital markets, a new bank could defeat banks on product, technology, segmentation, and customer acquisition. The bank could do this with few people (mostly engineers) and a lot of software. This is because today’s business customers don't want to talk to their banker and rarely need a branch. They want to be able to trust their bank, to feel like the goals of the bank and their goals are one, and they’d like a great product experience with a customizable and open ecosystem at its core.

What does this mean in reality? It means the elimination of the physical (“wet”) signature and the start of instant risk determinations, easy to use but powerful tools to manage money laundering and customer identification requirements, and dynamic offerings targeted to the needs of the customer, with simple user interfaces and transparent pricing. In short, the anthesis of today's banking experience.

(Notice that banks are one of only two retail categories where you walk in and cannot find a list of products or their prices. The other is healthcare.)

The Problems

Regulations. Politics. More regulation. Acronym soup. Capital requirements. Passivity requirements. Etc. I won't bore you with the details but this isn't for the faint of heart. I think that most venture capital is ignorant to the nuances of just how complicated (and expensive) this gets, and just how quickly.

We have had a lot of these ideas floating around for awhile as have others, and as we participated in a recent Twitter conversation and after today’s sale, I wonder if maybe someone is willing to take the jump with us.

Ultimately, Banks are ‘Big Data’ and Technology Companies

The Financial Times published a letter of mine:

From Mr Zachary Townsend.

Sir, Banks are “Realising the promise of new technologies” (The Connected Business,, September 30), despite being saddled by outdated and outmoded core banking technologies. Some of the best but least studied innovation is happening inside treasury management and commercial banking groups. There, far from the public eye, new technologies – such as application programming interfaces – are allowing financial institutions and businesses of all sizes to interact in new, faster ways. These technologies speed the flow of transactions for the business while decreasing risk and delivery costs for the bank.

Unfortunately, Eric Openshaw and Larry Albin continue the false dichotomy between the business and technology functions of banks. Ultimately, banks are “big” data and technology companies. At the centre of every bank is simply a data store that records who has how much money and the rules governing transaction processing. We call this data store a core banking system, which is then surrounded by delivery channels, risk management and other technologies. Banks, their boards and their shareholders will come to realise that huge portions of bank budgets and headcounts can be replaced by modern web technology if architectured correctly. Those financial institutions that remake themselves fastest in the model of software engineering first companies such as Google or Facebook, including picking a forward-thinking technologist as chief executive, will be the true benefactors of this new era in finance.

Zachary Townsend, Co-founder, Standard Treasury, San Francisco, CA, US