Georgia's Payments Charter Is a Bigger Deal Than It Looks

Between April 2025 and the middle of this year, three of the best-known names in payment processing put the same obscure state bank charter to work. Fiserv ran its first transaction under it. Checkout.com was approved and went live on direct acquiring. Stripe had its charter cleared and kept its existing banking relationships running alongside it. The charter is Georgia’s Merchant Acquirer Limited Purpose Bank, usually shortened to MALPB, and it has been available since 2012.

It’s an easy story to miss. There’s no consumer product attached to it, nothing changes on anybody’s checkout page, and the acronym does it no favours. But it touches the part of the payments chain I think is most underrated as a source of risk: the sponsor bank sitting behind a processor, which almost nobody downstream of it thinks about until the day it matters.

One thing up front, so nobody reads this as a to-do item: this is infrastructure for processors and platforms with serious volume. If you’re a merchant running on one processor, a charter is not something you will ever apply for, and whether your processor holds one is not the first question to ask about your own setup. There’s a section near the end on what, if anything, this changes for you.

What the Georgia MALPB charter does

A processor that isn’t a bank reaches Visa and Mastercard through a sponsor bank. The sponsor bank holds the connection to the card networks, and the processor rents access to it. Everything the processor does for its merchants runs through that rented access, which means the processor’s ability to operate depends, at the most basic level, on the sponsor bank continuing to want it as a client.

The MALPB charter is Georgia’s alternative to that arrangement. It’s a state bank charter scoped to merchant acquiring, and holding one lets a processor connect to the Visa and Mastercard networks directly instead of renting that access through somebody else’s bank. Georgia has offered it since 2012.

What’s new is who is using it. As PYMNTS reported:

• Fiserv processed its first MALPB transaction in April 2025.
• Checkout.com had its charter approved in January 2026 and is live on direct acquiring.
• Stripe had its charter cleared in mid-2026, and is keeping its existing sponsor-bank relationships running alongside the new charter rather than replacing them.

Fiserv’s first transaction came thirteen years after the charter became available. Then three large processors took it up within about fifteen months of each other.

Why sponsor-bank dependency is a structural risk

From a merchant’s point of view, the payments chain looks like two parties: the business and its processor. In reality there is at least one more link, and it’s the one with the most discretion. The sponsor bank decides whether it’s comfortable with the processor’s portfolio, meaning which industries and which countries the processor serves on the bank’s behalf. When that comfort changes, the processor has to change what it does, and the merchants on that processor feel it without ever having dealt with the bank directly.

For most businesses, this layer stays invisible for their entire life. In high-risk it doesn’t. Gambling, iGaming, crypto, adult, nutra, forex: these are the verticals where a bank’s appetite is most likely to move, and where it can move for reasons that have nothing to do with any individual merchant. A bank reviews its overall exposure, decides a category is more trouble than it wants this year, and asks the processors it sponsors to carry less of it.

Let’s imagine a processor that has built a strong book of iGaming merchants on the back of a single sponsor bank. The processor is well run. Its merchants are licensed and compliant, and their dispute levels are unremarkable. Then the sponsor bank’s risk committee decides it wants less gambling exposure across its whole portfolio. Nobody at the processor did anything wrong, and neither did its merchants. The processor still has to choose between shrinking the part of its business the bank no longer likes and finding a new sponsor bank at short notice, and a bank willing to take on a large iGaming book is exactly what’s hardest to find in a hurry. Either way, some of those merchants receive a letter.

From the merchant’s side, none of that arrives labelled as a banking decision. It shows up as a processor that suddenly wants new documents, a narrower list of accepted countries, a higher reserve, or an offboarding notice. I’ve argued before that there’s no such thing as a bad payment provider, only a provider whose particular banking connections behave a particular way at a particular moment. The sponsor bank is the clearest case of that argument I know of. A processor can be doing everything right and still be one bank’s decision away from running a very different business.

This is why I treat sponsor-bank dependency as a structural risk rather than a relationship problem. A relationship problem gets solved with better account management and a few good meetings. A structural risk is built into how the processor reaches the networks in the first place, and good behaviour on the processor’s side can reduce it but can’t remove it, because the final decision belongs to the bank.

There’s a concentration problem layered on top. Because the sponsor bank sits behind the processor, it sits behind every merchant on that processor at the same time. One decision upstream lands on all of them at once. It’s natural to think about payment risk merchant by merchant: this merchant’s disputes, that merchant’s refund window. A sponsor bank making a portfolio decision may not be looking at any individual merchant’s numbers at all.

Seven years in payment orchestration, most of it around high-risk verticals, has left me with a fairly firm view on where the risk in this chain tends to hide. It’s usually upstream of wherever people are looking. Merchants watch their processor. Processors watch their merchants. The bank in the middle is the party both sides assume will stay put.

What changes when a processor holds its own charter

A processor with an MALPB charter has removed one of the parties that could tell it no. Its access to Visa and Mastercard no longer runs through a bank whose risk committee it has no seat on. That is a real change in who gets to decide what the processor does and which merchants it can serve, and it’s the reason I think this story deserves more attention than its acronym invites.

It’s worth being precise about what the charter doesn’t change. The card networks still have their rules, and a processor connected to them directly answers to those rules without a sponsor bank standing in between. A charter is also a regulatory relationship in its own right, with the state that issued it. The dependency doesn’t disappear. It moves from a commercial counterparty that can decide to walk away, to a set of rules the processor can read in advance and plan around.

For a processor with real volume in categories banks get nervous about, I’d take that trade. Rules that apply to everyone, and that you can see coming, are a much easier thing to build a business on than the risk appetite of one institution you don’t control.

Why Stripe keeping its sponsor banks is the most interesting detail

Of the three, Stripe’s approach is the one I keep coming back to. Its charter cleared in mid-2026, and it’s keeping its existing sponsor-bank relationships running alongside the charter rather than retiring them.

I don’t know Stripe’s internal reasoning, and I’m not going to pretend to. Read from the outside, though, it looks like the same principle I’ve spent years arguing for at the merchant level, applied one layer further up. A company that has just gained direct access to the networks is choosing not to make that its only path. It keeps its existing routes open even though it now holds a route no sponsor bank can close.

That’s the orchestration argument in its plainest form. The value of a second path was never that the first one is bad. It’s that no single path, however good, should be the only thing standing between a business and its ability to take money. I’ve described this before as optionality, the ability to move volume, compare routes and survive a bad month, and it’s notable to see a processor of Stripe’s size apparently make the same call about its own infrastructure.

It’s also a useful counterexample to the idea that keeping a second route is a sign you don’t trust your main one. The company with the most direct route available to it is keeping more than one, which makes redundancy look like ordinary good engineering.

The same principle carries well outside payments. I apply it to orchestrating AI agents in much the same way as I’d apply it to payment routes, with redundancy and without trusting any one path’s report on itself; the systems page describes how that works in the AI system I built for my own sales pipeline.

Who this matters for, and who can ignore it

This is the section I’d most like a smaller merchant to read, because the risk with a story like this is that it gets filed under “things my payments setup is missing.”

If you run a processor, or a platform processing real volume on behalf of many merchants, and a meaningful share of that volume sits in categories banks periodically reconsider, the MALPB route is worth understanding properly. Your exposure to a sponsor bank’s appetite is the exposure of your entire merchant book at once, and a charter is a way to reduce that exposure at its source rather than manage around it.

If you’re a merchant, this almost certainly isn’t your problem to solve. You won’t hold a charter, and whether your processor holds one is one consideration among many rather than a reason on its own to choose or leave a processor. What the sponsor-bank story does tell you is that your processor’s stability depends partly on decisions neither you nor your processor fully controls. That’s the same argument for a second processor that existed before any of this news, and this news doesn’t make it stronger or weaker for you.

And if you’re a genuinely single-market, single-product business whose one processor already covers the payment methods your customers use, at an approval rate that works for your volume, none of this is urgent for you. That includes the second processor. An extra layer costs something to run and monitor, and you’d be paying for protection against a risk you aren’t meaningfully carrying.

For clarity about where I sit in this: an orchestration layer, which is what we build at Corefy, isn’t a processor and doesn’t hold a charter. It sits above processors, whether they reach the networks through a sponsor bank or directly. What MALPB changes, from my side of the table, is the shape of the risk behind some of the processors an orchestration layer connects to. It doesn’t change the reason for connecting to more than one of them.

What I’ll be watching next

The question I care about most is whether direct access changes how chartered processors treat high-risk categories. In principle, a processor that no longer answers to a sponsor bank’s risk appetite has more room to decide for itself which verticals it serves. Whether any of them use that room, or keep exactly the same risk posture with one fewer counterparty involved, is what will matter for the merchants I spend my working weeks around. It’s too early to tell, and I’d be wary of anyone who claims otherwise at this stage.

The second, smaller question is whether Stripe’s mixed model, a charter with sponsor banks still running alongside it, becomes the norm for processors that take the charter. I’d bet on it, for the reasons above. It’s still a bet.