Today I'm going to talk about a part of the banking world 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 Funding Circle‍—‌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, Funding Circle, etc. end up partnering with banks, and these banks are responsible for actually holding the cash in "client money", "custodial", or "for-benefit-of" accounts (the term varies by locale and by business model). The fintech typically controls these bank accounts using a technology platform supplied by the bank.

This type of banking is commonly referred to as "white-label" banking, or more recently as "platform" banking.

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

It's broken for four reasons, and these add up to make it costly and time-consuming for new fintechs to get their products to market. These hurdles are so painful that they act as a serious 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 layers on top of them to enable them to provide modern products on top of their ancient cores.

This creates unit economics that don't work out in anyone's favor: costly legacy tech X + fancy 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 things like 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 one of these customers, then they can't make a profit on that relationship at all.

As a result, banks in this 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 just aren't worth it. Plus, banks aren't eager to sell to fintechs that may one day compete with them for 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 corporate customers that are lucrative for the bank and have the resources and time to eat the cost of integration with a crappy API.

In addition to being badly designed, documentation and pricing on wholesale technology platforms are deliberately obscured and kept 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 YCombinator 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 get your banking needs taken care of. 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, it's not at all unusual for fintechs to spend 6 months getting onboarded just in order to get an API key. 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. For the most part UK banks still have highly manual and expensive KYC processes, so neither the fintech nor the bank really wants the bank to have to do those checks. The end result is that the compliance burden is pushed onto the firms that are building on top of the bank.

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

We're trying to 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 priced, and built with the end customer in mind‍—‌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:

• [Customer registration]^[1]
• [Current account creation and visibility]^[2]
• [Payments]^[3]

// 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. I.e. for your end customers, whether retail users or businesses. ↩︎

2. At the moment the API spec only covers custodial/FBO accounts‍—‌we'll be adding endpoints for handling your own firm's accounts in the coming months. ↩︎

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