What to check before your card programme moves.
B2B
The enquiry that has replaced "we want to launch a card" this year is "our card provider is leaving and we have ninety days."
I look after digital asset programmes at Monavate, so these calls tend to reach my desk. The details differ. The underlying pain does not. A sponsor bank has de-risked. A licence perimeter has shrunk. A provider has decided a market is no longer worth serving. Almost none of it is about your product. Your cards can be working, your users happy, your volumes growing, and the programme still stops, because somebody you have never met put down something heavy.
And it is heavy. At the start of the month we wrote a LinkedIn post about regulation being the moat. Provider exits are the same fact seen from the other side. Obligations that are expensive to carry get put down, and the ninety-day letter is what putting them down looks like from below. Nobody in the chain is a villain. That is what makes it dangerous: there is no misconduct to spot in advance, only a balance sheet somewhere deciding you are no longer worth the weight.
Most migration checklists will not protect you from any of this, because most migration checklists are processor checklists. BIN transfer or reissue, KYC portability, balance handling, scheme approvals. All real, all necessary, and none of it the reason you are migrating in the first place. Before you compare checklists, ask three questions of the provider you are moving to.
Who holds the licence? Who holds the BIN? Who carries the settlement position?
If those are three different companies, you have three counterparties and three ways to stop. You have not diversified your risk. You have collected it. Any one of the three can put its weight down, and your programme stops just the same, only now the other two are pointing at each other while your users are pointing at you.
In Issuing is not a feature, our COO wrote about what those three things cost to carry: the supervisory relationship, the scheme rules, the daily netting across currencies. When you migrate, you are not choosing a platform. You are choosing whose name sits on all of that, and how many names there are.
Then there is the gap, and it matters more in digital assets than anywhere else. A cardholder taps for petrol at 03:10. Authorisation resolves in under a second, against a balance sitting on a chain with its own idea of when things are final. The chain calls that balance final a minute later. The merchant is paid in fiat, on the scheme timetable, and the merchant does not know what a block is and has no plans to learn. Somebody is carrying the obligation across that gap, at that hour, in a currency the cardholder never touched.
This is why the settlement conversation should come before the feature conversation. Token support is a menu. Settlement is the kitchen. Stablecoin balances, chain coverage and reward mechanics are decided at the product layer, and every provider's menu looks lovely. Whether the merchant gets paid while the chain is congested is decided at the settlement layer, and the settlement layer is the thing you are migrating.
And the move itself? Done properly, it is an anticlimax. Cards keep working. Balances arrive where they should. The user finds out from an email they barely read, if they find out at all. Nobody has ever congratulated us on a cutover, and that is the review we aim for. The paperwork is long, and your new provider should walk you through every line of it. Judge them on the part the paperwork cannot capture.
Monavate issues, processes and settles on one platform, under our own licences, across Monavate's regulated jurisdictions. One counterparty, carrying the licence, the BIN and the settlement position together. We built it this way because we would rather carry the weight than explain, at 03:10, whose turn it was.
If you are planning a migration, or would like to make sure you never need one, come and talk to us. Bring your current provider's answers to the three questions. We will tell you plainly what they mean, including where our own answers are strong and where you should push us.
Elliott Shreeves