Today I'm going to talk about a part of banking infrastructure that many people aren't aware of.

First, a little context: if you're a modern financial technology firm, your business moves money around. A lot of it. The catch is, that money probably doesn't belong to you. For instance, consider PayPal or Lending Club - most of the money in their systems belongs to their end users.

Legally, in most Western countries, Anti-Money-Laundering (AML) regulations prevent entities that aren't banks from handling this money directly. So firms like PayPal, Lending Club, etc. end up partnering with banks, and these banks are responsible for actually holding the cash in "custodial" or "for-benefit-of" (FBO) accounts. The client firm (the fintech) typically controls the underlying bank accounts using a technology platform supplied by the bank.

This type of banking is commonly referred to as "wholesale", "white-labelled" banking, or "infrastructure" banking.

Now that we've set our terms, let me lay out a thesis: infrastructure banking is broken.

It's broken for four reasons, and these four reasons compound each other's problems. The result is that it is expensive and time-consuming for new fintechs to get their products to market. These complicate things so severely that they act as an effective barrier to entry for many firms.

The four reasons are:

  1. Poor unit economics
  2. Bad product
  3. Slow process
  4. A broken risk model

To see how these issues prevent many fintechs from succeeding, let's break each one down in sequence.

UNIT ECONOMICS

The technology platforms most banks rely on are expensive. The underlying "core" systems are ancient and expensive to maintain or license, and banks are terrified of the risk involved in changing or migrating off of them. This puts them in a tough spot, because they know they need to have modern products and features (like fancy mobile apps) to satisfy their customer bases. So, instead of modernizing, they spend tons of money building spaghetti middleware that enables them to provide modern APIs on top of their ancient cores.

This creates unit economics that don't work out in anyone's favor: expensive legacy tech X + expensive modern platform Y = Z, where Z is a cost so high that the bank can only make a profit if it's cross-selling multiple other products to its clients. These products typically include treasury management, invoice factoring, credit cards or loans. There's a great chart from a Wells Fargo's Investor Day deck from one-to-two years ago that shows that if they're not cross-selling 3 or more products to a wholesale customer, then they can't make a profit on that customer relationship at all.

As a result, banks in the wholesale business only want to work with firms that are big enough to need all of the things the bank wants to cross-sell. Small and nimble fintechs that only need a few services don't meet that criterion. Plus, banks aren't eager to sell to fintechs that may eat into their cross-selling market opportunities.

PRODUCT

In addition to being expensive, existing banking technology platforms are awfully designed. They're awfully designed because the people responsible don't see fintech startups as valuable customers (see above), and therefore don't understand or care about what fintechs want out of a technology platform. Instead, they're designed by committee, for large corporations that are lucrative for the bank and have the resources and timeframe to eat the cost of integration with a crappy API.

In addition to being badly designed, documentation and pricing on wholesale technology platforms are typically obscured or secret. Client firms rarely know what they're getting until they've wasted time selling the bank on why they should be allowed to do business on the bank's platform in the first place. Stripe has spoken about these sorts of arrangements somewhat openly - they say part of why YC was so instrumental for them was that it helped them get deals with banks.

One effect of the banks' secrecy here is that if you're running a fintech, and you're just getting started, you have no idea how much investment (in both time and money) will be required to integrate with a given bank. This uncertainty creates a significant barrier to entry for new companies and has a chilling effect on the financial technology industry as a whole.

PROCESS

Even banks that have good platforms tend to have bad processes around them. For instance, we've spoken to fintechs that have had to go through 6 month onboarding processes just to get an API key (and that seems to be standard!) Half a year is a veritable lifetime for a startup that's trying to get to market as quickly as possible. Similarly, while other firms can get you up and running quickly, their execution once you're beyond their basic product line is so bad that their customers eventually go to a competitor or try to get a regulatory license that'll enable them to avoid a relationship with such a firm in the future. It's as if nobody's ever thought of offering a Stripe-style self-serve experience.

The biggest pain point, though, is in risk and compliance.

RISK/COMPLIANCE

Even though AML regulations are the same for all banks, each bank interprets them differently. The obligation to manage that compliance burden is pushed onto the firms that are building on top of the bank, in order for the bank to have the least liability.

This works out well for very small firms, where the bank is able to oversee the compliance process easily, and for very large firms, where the amount of revenue generated for the bank incentivizes the bank to work closely with the client. It fails abysmally for successful fintechs and startups that are growing quickly; as the fintech gets to be of medium size, they discover the bank's no longer comfortable with their size and they're not yet generating enough revenue for the bank to make the headache of closer oversight worthwhile.

It's at this point in time that the fintech gets a 90-day notice that they're going to be kicked off of the banking platform (I've spoken to multiple firms that this has happened to). This sort of wholesale ejection is a huge business risk for these firms - they're required by law to work with a banking partner, so if they only have one when they're kicked off the platform, then they have to close up shop until they find another. This problem is not unique to fintechs, either; I've spoken to a large asset manager that ran into the same issue.

These firms mitigate the risk of getting kicked off a banking platform by integrating with multiple banking partners. This leads them to pay the cost of bad incentives, bad product, and bad process multiple times: once for each extra banking partner they partner with just to manage their counterparty risk.


Modern fintechs expect more from their banking partners. Fintechs are tired of working with banks that have awful, undocumented APIs. Fintechs are tired of working with banks where onboarding takes half a year or more. And fintechs are tired of working with banks that don't even really want to do business with them in the first place.

Here at Griffin, we do things differently. We're making a banking platform engineered for the modern financial technology firm. We're building something that's RESTful, easy to use, transparently documented, and thoughtfully-constructed - a platform built by technologists, for technologists.

Today, we're happy to announce the release of the alpha specification for our platform's public API. We're making the spec public now in order to get feedback from the community - especially from UK-based fintechs that know how difficult banks can be to work with.

We don't yet have public pricing, but we plan on releasing our pricing plans in the next couple of months.

The current alpha API spec covers the following:

// Example: list current accounts

GET /v1/accounts HTTP/1.1
Host: api.griffin.sh
Content-Type: application/json; charset=utf-8

[
  {
    "id": "4c4dbaa1-dbfe-4430-a0be-878a54bf353b",
    "resource": "account",
    "customer_id": "913684e7-6f07-4334-a290-00f389e05854",
    "account_type": "checking",
    "sort_code": "12-34-56",
    "balance": 586050,
    "currency": "GBP",
    "account_number": 31926819
  },
  ...
]

By releasing the spec now, we're hoping for feedback on:

  • Functionality: does this let you do what you need? Are we missing anything that your business requires from a banking partner?
  • Compliance: are we asking for too much information about your customers? Too little?
  • Simplicity: is this easy to use? Are we making it harder than it should be?

We want to make sure we're building something people want, so we'd love to hear any other feedback you might have -- whether good or bad. Shoot us an email at api-feedback@griffin.sh. If now's not a good time, just add your email address to our subscribers' list by using the form at the bottom of this page.

Thanks!

~ David Jarvis (Cofounder & CEO)

P.S.: We're fundraising! If you're interested in what we're up to, shoot me an email.



  1. Just FPS, CHAPS, and SEPA for now -- we'll be adding direct debit (BACS) and SWIFT next month. ↩︎ ↩︎ ↩︎