April 2024: Revisiting: Common Problems with Banking partners

Some problems are far more common than I originally thought

Apr 10, 2024

3 years ago I wrote about some common problems with bank partners: https://kunle.app/august-2021-common-problems-with-bank-partners.html

It delved into the issues that arise between fintechs and their bank partners, particularly in card issuing + deposits, but might be generally applicable to other programs (like lending, bnpl etc) particularly as all fintechs basically touch identity information in some way, and many problems arise from identity data being misused in some way.

I called out 3 types of problems that you might encounter running a program: Regulatory Problems, Network Problems and Operational Problems. The full original/unedited essay is below the fold.

In hindsight the thing I was most wrong about was this statement about Regulatory Problems:

“This is a low probability, high impact way things could go wrong”

If you’ve been following fintech over the last 18 months it’s clear that regulatory problems are much higher probability as a meaningful number of the banks that underwrite fintech programs in the United States have since been hit with a number of consent orders. Examples include:

Given what’s played out, if you’re a financial technology company launching a program with a new bank, or you’re not a financial services company but you’re launching a financial product, you not only have to be far more diligent than before when picking a banking partner (in full disclosure, I’m on the board of, and obviously a giant fan of Lead Bank), you also have to be far more disciplined running your program.

–

Common problems with bank partners

August 2021

If you’re issuing cards or building a neobank, a subtle but important choice to make is who you partner with as an issuing bank.[1] The bank is a critical part of the banking as a service ecosystem. Roughly speaking, you as the neobank play the marketing and customer facing role, the banking-as-a-service partner you work with plays the technical infrastructure (and usually ledger) role, and the bank plays the regulatory and compliance role. In this role, they are the repository for several crucial relationships that rarely matter until they really matter, and when they really matter, they are all that matters. These roles include

The regulatory interface: most banks you’ll interact with will be regulated by the FDIC. Whenever something happens and the FDIC needs to talk to someone, they’ll most likely talk to the bank and not you.
The regulated entity: most banks you’ll work with will be Durbin exempt and as a result be able to rely on relatively high interchange for consumer debit (if your business is consumer focused and dependent on card interchange as revenue, this will be key).
The compliance entity: the bank’s charter is on the hook if a card issuer breaks the rules (like not resolving disputes on time, money laundering, or holding people’s money) so most banks will maintain some control over how card programs comply with the various rules.
The network interface: the bank is typically the entity with a contractual relationship with a network like Visa, Mastercard or others

All these things simply mean, if you’re issuing cards, you can’t avoid working with a bank in some way, shape or form. In some cases, you can outsource working directly with a bank by allowing your issuer processor handle “program management” responsibilities (and by extension outsourcing all your interactions with the bank), but ultimately if you’re issuing cards or accounts, there’s going to be a bank in your stack. But which bank you work with can materially impact you. In short, a good choice allows you to focus on building a great customer experience and running your business well. A bad choice forces you to focus on the bank relationship. While building the Cash Card I had the “luck” to work on 6 bank partnerships and 5 card issuing integrations over 3 years. This meant seeing many ways things could go wrong.

Regulatory Problems

This is a low probability, high impact way things could go wrong. The bank is responsible to the regulators for making sure customers are protected. This includes everything from

ensuring there are no lies in marketing materials, (and you don't inadvertently or intentionally violate UDAAP)[2]
promptly responding when a customer disputes a transaction
making cardholders whole for fraudulent transactions
transparently disclosing fees that cardholders might face
adequately identifying cardholders and preventing money laundering
ensuring that the card program adheres to regulations
and much more

Regulators have an incredible range of remedies when they think a bank is misbehaving, including literally stopping the bank from creating new accounts, setting up new card programs, restricting / banning marketing, putting a bank under a “consent order” which is a way of severely limiting the business(es) that a bank can operate within, all the way to (in rare cases) revoking the banks charter entirely, or (more commonly) seizing the bank, and handing over it’s management and customers to another entity. From the regulator's perspective, any cards underwritten by the bank are the banks responsibility. So as a neobank issuing cards or accounts, or enabling money movement - when you make a regulatory mistake, the thing you’re ultimately putting at risk is the bank’s regulatory standing.

Network problems

This is another low probability, high impact way things could go wrong. The network (eg MasterCard or Visa) also cares that you as the program, and the bank underwriting you are doing the right things in terms of identifying customers, preventing money laundering and more. In addition to ensuring you won’t create regulatory problems, card networks, as mediators between card issuers and ultimately merchants, also care deeply that your program is set up correctly, that you’re not doing weird hacks to artificially inflate your interchange and are dutifully following network rules. Several types of interchange hacks exist, for instance,

decoupled debit; using a balance in bank 1, typically durbin regulated, to fund card transactions in bank 2, typically unregulated (thus earning higher interchange on transactions than bank 1 is eligible for)
authorized user; issuing cards on a commercial debit bin for a use case that is truly consumer focused
charge card: issuing a credit or charge card but not actually extending credit in a meaningful way (eg autopay in a week)
regional arbitrage: issuing a card from a region with high interchange (eg the US) to cardholders who actually reside and primarily operate in a low interchange region (eg Europe)

Networks, because they've been around for a while, and have seen all types of behavior, are generally fairly sophisticated about these interchange hacks and will often pressure the neobank, the bank, the program manager (whoever plays that role) or the baas provider to reduce the odds that these things happen.

Networks are also highly sensitive about the ways their brands are used[3]. There’s a lot to unpack here, but the cliff notes: Visa and MasterCard are some of the most well known, widespread brands in the world. They invest hugely in their brands and care deeply about how those brands are used. This means you’ll need to be extremely thoughtful about everything from your card art, your site, your app, and your usage of the network brand logo on all your online and offline marketing materials.

Card networks, over the decades, have developed a ton of levers to ensure partners comply. These include everything from

Technical levers: they can simply make your cards stop working (as in stop processing transactions). As the card network, they’re literally in the loop for every single card transaction. This is why, the one or two times a year when a card network has an outage, it *sucks* for everyone on that card network.
Economic levers: they pay you interchange, and they can just . . . stop paying. The card network contracts are also typically designed with a variety of commercial incentives baked in, which are (by design) paid at the end of a period (month/quarter/year) based on performance during that period. Very often, as you scale, these incentives become sufficiently material that you’ll bake them into your earnings projections. To get you to comply, the card network can simply refuse to pay these incentives (typically called rebates) until you comply, thus putting your earnings at risk. Your CFO or your Finance team estimating accruals won’t like this.
Operational levers: physical card designs are approved at the level of a batch of cards (rather than at the level of a program) so if the card network wants you to comply, they can just deny a batch. What this means is:
- Growing card programs typically order physical cards to be manufactured in batches (depending how fast you’re growing, this would range from thousands to hundreds of thousands of literal cards per batch)
- Each batch is approved by a team at your card network. Typically they just ensure the design meets the specifications, the network brand is represented correctly, there’s nothing offensive on the design, etc
- If there are any issues with the design, they’ll engage with the issuer, program manager, or the bank to rectify the issues before approving the cards to be manufactured. The card manufacturer will not produce a batch without the card network approval, so, if they run out of card stock before a new batch is approved, you won’t be able to ship any new cards to customers. For fast growing programs, this is a death knell, and an insanely effective way to guarantee good behavior

There are many others - these are just the ones I’ve seen deployed. Depending on the severity of the problem, these levers can be applied in combination with one another to achieve the desired result (aka compliant behavior.) A good bank partner can help you navigate these problems, and great bank partners will design the partnership to reduce the odds that you stumble into one of these traps, because (depending on the relationship) often when these levers are pulled, they apply to the bank as well. As your program gets bigger, you’ll likely bypass the bank partner entirely and deal directly with the network(s).

Operational Problems

Your bank partner is typically closest to the metal operationally on every part of your program. This means that most intermediaries or counterparties will pick up the phone if your bank calls, and many will literally not respond to you (try getting a routing number for yourself as a non-bank and see how that works out for you). As a consequence of this, there’s lots of little things at the lowest level of offering financial services that you typically don’t see, but if they go wrong, your bank partner really matters. These range from:

Batch Processes: Many banks rely on batch SFTP system to process ACH transactions. The number of batches a day affect when your ACH transactions are initiated or received. This can be the difference between an ACH transaction completing on Friday or the following Monday (which will deeply matter to your cardholders). In addition many banks have built human based workflows around these processes, so making changes to them require a human component, in addition to technical ones. I once saw a program go a whole day without any ACH transactions processed, only to discover the next day that the person responsible for ACH at the bank had taken a personal day. No backup person existed and no one thought about this single point of failure risk, so thousands of customers waited an extra day to get their paychecks deposited. This is unfortunately typical and something to keep an eye on.
Exceptions: when things go wrong with a transaction, you’re often reliant on the bank to investigate the transaction and figure out what happened, how to fix it and how to prevent it. However, your customer only knows and cares about your role. As a result, you’re dependent on a bank process and the responsiveness of their people, which you don’t control, to fix a customer problem, for which you’re responsible. Fun times.
Reconciliation: if you manage your own ledger, you’ll need reconciliation to ensure that your view of what money has moved and how, matches the external world’s view. To properly reconcile card transactions, you’ll often need direct access to the settlement files (where the card networks include final transaction amounts including tips, etc). These aren’t error proof. Handling interruptions in these, and good discipline investigating errors are hallmarks of operational excellence. (I think more recently, with the flourishing of BAAS providers, some have turned this part of the process into a webhook based process rather than a file based process, which I fully support).
Float & Credit: as a card issuer you’ll need to have funds available to settle, and typically, even for a program with a “good funds” model, you’ll have cases where funds should be available for a customer to spend, before the funds actually arrive in the customer’s bank account or balance. The average bank partner will require you to put up enough funds - measured from weeks at the start to days when you’ve scaled - so you always have money available when the networks come to settle. A good bank partner will figure out an underwriting model that allows you to scale without tying up tons of equity capital as working capital. This is something that you ask about, monitor and optimize downwards as you scale so your Treasury can ensure maximum, low/no risk investing return efficiency for the dormant tranche of your customer’s cash.
Risk tolerance for emergent use cases: one concept that every startup benefits from is emergent use cases - customers using your product in a way that you didn't originally intend, hacking it to solve some problem that wasn't apparent or clear to you (or to anyone else in market) when you started out. This is the lifeblood of a new product - you're capturing latent demand, and you now have an insight no one else does. Banks absolutely hate emergent use cases, because their risk systems rely on historical patterns that have proven safe, and an emergent use case is a new pattern, that by definition doesn't show up in the history. An example of this could be a sorority pooling funds for a group purchase, but doing it on a single player debit card. Several of the sorority members have access to the account. To the bank, this can look like several, different mobile devices logged into to a user account, which traditionally would be suspicious. Issuers that started out with branches often have literally no way for more than one person to be logged into an account, or more than one linked email address, phone number etc. To the neobank, this looks like additional spend that no competitor or incumbent has as yet captured, and a user behavior to build products around. As the ultimately regulated entity, the bank can (and will) close accounts they find suspicious, without and the sorority will now have a bad experience where their money is locked or their card is cancelled, and ultimately don't care who caused it, and thus will blame you.

Diligence

The way the ecosystem is set up today, it's pretty much impossible to tell the differences between different potential banking partners. There’s no equivalent of yelp reviews- they’re pretty opaque from the outside looking in, and often you will face this tension where your banking-as-a-service platform or issuer processor wants to completely own the relationship and shield you from dealing with the bank in anyway (there’s lots of good reasons and bad reasons why this happens). In addition, because neobanks, processors and BAAS providers are all so dependent on their bank partners, they have no incentive to air their dirty laundry publicly, as that would put their relationship(s) at risk. The result is, your options for diligence are fairly limited - you either have to have done it before, know someone who has, or be in one of the many private slack groups that have sprung up around these topics for neobank startups over the past few years. When choosing a bank partner, it helps to talk to programs that are already live with that bank to understand what they’re like to work with, and in particular how they deal with problems: disputes, exceptions, disagreements on how the program should be run, etc. Easiest starting point that I've seen is by using the open source list of banks and processors curated by Aaron Frank[4]. If necessary, there are also compliance consultants who can help you think through bank selection.

Some things are unavoidable

In the best case, you’ll encounter a few of these problems. In the likely case, you’ll encounter a lot of them as you scale. I think the reasonable approach is to design your plan around dealing with these problems well, rather than not having them at all. For what it’s worth, across the several dozen card issuer programs I’ve encountered, not a single one has scaled without hitting one or more of the above problems with their bank partner. In most cases, the problems start before the programs have even started to scale. There’s a reason why every single neobank program that’s scaled over the last half decade in the US has relationships with more than one bank partner.

Thanks to Timothy Thairu, Aaron Frank, Ryan Lea, and Jim Esposito for reading this in draft form

Notes

[1] This discussion is scoped to the domain where I have expertise, which is neobanks, challengers banks and others on the card issuing and account issuing side. This discussion might not apply to card acquiring, lending, investing or crypto, so take it for what it’s worth.

[2] https://files.consumerfinance.gov/f/documents/102012_cfpb_unfair-deceptive-abusive-acts-practices-udaaps_procedures.pdf

[3] https://productbrandstandards.com

[4] https://docs.google.com/spreadsheets/u/1/d/1r1WT0hbTlh3bswOPZk8ssKRjF9U33FVkpq74jN8cw4A/edit#gid=0

Kunle.app

Discussion about this post