📋 What's in this article:
- What fleet card issuance actually involves beneath the card itself: BIN sponsorship, authorization, and settlement, and why unified fleet card issuance and settlement is becoming the real evaluation question for fuel retailers and card issuers.
- What BIN sponsorship is, and why it decides how fast a fuel retailer or issuer can actually launch a program.
- Whether open-loop and closed-loop issuance can run on one platform, and what breaks when they don't.
- A side-by-side look at point-solution issuance stacks versus a unified platform, plus a checklist for evaluating any issuance platform before you sign.
Reading time: ~10 minutes
Most fuel retailers and fleet card issuers start their platform search with a transaction-fee question: whose interchange is lowest, whose network accepts the most sites, whose rebate tier is most competitive. Those are real numbers, and none of them are the right starting point.
The question that actually determines whether a card program launches on time, scales into new markets, and survives a shift to open-loop is a different one: who is issuing the card, who is sponsoring it into the Visa or Mastercard network, and whether authorization and settlement for every card type, fuel, EV, prepaid, closed-loop, run through one system or three. Interchange is a line item. Issuance architecture is the thing the rest of the program is built on top of.
That distinction matters more now than it did five years ago, because more programs are trying to do more at once, fuel and EV charging on one card, closed-loop today with an open-loop migration planned for next year, a white-labeled program for a retail partner. Each of those ambitions runs directly into the issuance layer. Get it right, and new card types and new markets become a configuration change. Get it wrong, and every new ambition becomes a new vendor contract.
What Does Fleet Card Issuance Actually Involve?
"Issuance" sounds like a single step: a card gets made, a card gets sent. In practice, it's a stack of distinct capability areas, each of which a retailer or issuer either owns directly or depends on a partner for.
BIN sponsorship. A card can only carry a Visa or Mastercard mark if it's issued under a Bank Identification Number sponsored by a licensed bank or program manager. Most fuel retailers and fleet issuers aren't banks themselves, so this relationship, who sponsors the BIN, and what that sponsor requires, sets the real timeline for how fast a program can launch.
Authorization. The decision engine that approves or declines a transaction in real time, checking spend limits, site restrictions, fuel-type rules, and fraud signals before the pump releases fuel.
Card management. The system of record for the card's full lifecycle: issuance, activation, limits, status changes, and the account hierarchy above it.
Settlement. Where authorized transactions actually get priced, reconciled, and turned into invoices, statements, and payouts, for every card type the program runs.
Most point-solution vendors are strong in one or two of these areas and treat the rest as someone else's problem, often literally a different company your team now has to manage.
What Is BIN Sponsorship, and Why Does It Decide How Fast You Can Launch?
This is the part of issuance that general payments content rarely explains in fleet or fuel terms, and it's where most launch-timeline surprises come from.
The sponsor sets the compliance bar, not just the brand. A BIN sponsor is on the hook to the card network for every program issued under its number, so it sets its own risk, KYC, and program-type requirements on top of network rules. Two retailers launching what looks like the same open-loop fleet card can face very different onboarding timelines depending on their sponsor's own risk appetite.
Sponsorship and processing are often separate relationships. It's common for the BIN sponsor, the processor running authorization, and the platform managing cards to be three different companies with three different contracts, three different onboarding processes, and three different places where a change request can stall.
A platform that holds the sponsor relationship changes the math. When BIN sponsorship, authorization, and card management sit inside one platform relationship instead of three separate vendor relationships, launching a new card type or expanding into open-loop is a configuration and compliance step inside an existing relationship, not a new procurement cycle.
None of this is a reason to avoid BIN sponsorship, every open-loop fleet program needs it in some form. It's a reason to ask, early, exactly who holds that relationship and how many other relationships sit between a retailer and the card they want to issue.
Can You Run Open-Loop and Closed-Loop Issuance on the Same Platform?
Yes, but it's worth being specific about what "on the same platform" actually needs to mean, because the phrase gets used loosely.
It isn't enough for a platform to simply support both card types somewhere in its product catalog. The test is whether a closed-loop transaction and an open-loop transaction, authorized through the same card program, land in one settlement and reporting system, or whether open-loop activity has to be exported, reconciled, and reported separately because it runs through a different internal module or a different acquired product line bolted onto the original platform.
That distinction is exactly why the shift toward open-loop, moving fleet programs from proprietary closed networks to scheme-based Visa and Mastercard acceptance, is as much an issuance-architecture decision as a commercial one. A fuel retailer planning a phased open-loop migration needs a platform where closed-loop and open-loop issuance share one authorization server and one settlement engine from day one, not a platform that promises to "add" open-loop later through a second system.
The One Thing That Breaks Most Issuance Projects: Settlement That Doesn't Reconcile Across Loops
This is worth isolating on its own, because it's the failure mode that shows up latest, usually well after a program has already launched.
Authorization is the visible part of issuance, a transaction gets approved or declined, drivers notice immediately if it fails. Settlement is where the real complexity hides. When closed-loop and open-loop transactions are authorized through connected systems but settled through separate pipelines, reconciling them back into one statement, one invoice, one view of program performance becomes a manual, recurring task. Finance teams end up running two settlement processes and merging the output by hand, every billing cycle, for the life of the program.
This is rarely visible during a sales process, because most demos show authorization working cleanly for both card types. It shows up three months into production, when the first full billing cycle closes and someone has to explain why fuel and open-loop spend don't appear on the same statement.
What Is It Costing You to Run Issuance Through Multiple Vendors?
None of this shows up as a single line item, which is exactly why it's easy to underweight when comparing platforms on fees alone.
- Every new card type, EV charging, a co-branded program, a new region, becomes its own procurement and integration project instead of a configuration change, because issuance, authorization, and settlement sit in different systems with different change-request processes.
- Compliance and PCI DSS or PSD2 scope has to be managed and re-verified separately for each vendor in the chain, instead of once at the platform level.
- Reconciliation between closed-loop and open-loop settlement becomes a recurring manual task for finance, not a one-time integration cost.
- Launch timelines stretch from a configuration cycle to a full vendor-onboarding cycle every time the program needs something the current issuance stack wasn't built to do.
- Each additional vendor relationship is a separate point of failure and a separate contract renewal, renegotiated on its own schedule, with its own leverage dynamics.
Each of these is a recurring cost, not a one-time one, and most of it is invisible until a retailer tries to do something the original issuance stack wasn't built for.
Point-Solution Issuance vs. a Unified Issuance and Settlement Platform
| Dimension | Traditional / point-solution setup | Reins |
|---|---|---|
| Card issuance | Often a separate vendor per card type | Fuel, EV, prepaid, and open-loop scheme cards on one platform |
| Authorization | Bundled into the processor, limited configurability | Dedicated, configurable authorization server |
| Open + closed loop | Usually requires separate systems and data models | Run in parallel on one unified system |
| Billing & invoicing | Manual reconciliation across markets and currencies | Automated, multi-language, multi-currency, tax-compliant |
| Compliance | Managed separately per component | PCI DSS, PSD2, and scheme requirements built into the infrastructure |
| Best for | Programs that only need to move money from A to B | Programs that need issuance, processing, and billing to work as one system |
The pattern worth noticing: a platform that's excellent at one piece of this stack, authorization, say, still leaves the rest of the chain, sponsorship, card management, settlement, for a retailer to assemble and maintain separately. A unified platform doesn't make any single piece more powerful on its own; it removes the integration and reconciliation work that sits between the pieces.
What Should You Ask Before You Sign With an Issuance Platform?
Who actually holds the BIN sponsorship relationship, and is it included in this contract? If sponsorship sits with a separate entity, find out how changes, new card types, new markets, get approved and how long that typically takes.
Do open-loop and closed-loop transactions settle through one system or two? Ask to see a real settlement statement that includes both, not just a demo of authorization working for both.
How many vendor relationships would a new card type require? If launching EV charging or a co-branded card means a new procurement process, the platform isn't unified, regardless of what the product page says.
Is PCI DSS and PSD2 compliance built into the infrastructure, or managed separately by each component? Separately managed compliance means re-verification work every time any one component changes.
What's the actual implementation timeline, start to first live transaction? Point-solution stacks assembled from multiple vendors commonly run 18 months or longer; a genuinely unified platform should be measured in months, not years.
Frequently Asked Questions: Fleet Card Issuance and Settlement
Can you suggest a reliable platform for issuing fleet payment cards?
Look for a platform that holds the BIN sponsorship relationship, authorization, card management, and settlement together, rather than assembling them from separate vendors. That combination is what determines whether launching a new card type is a configuration change or a new procurement cycle.
What is BIN sponsorship, and does every fleet card program need it?
BIN sponsorship is the relationship with a licensed bank or program manager that allows a card to carry a Visa or Mastercard mark under its Bank Identification Number. Any open-loop fleet card program needs it in some form; the question that matters is how many other vendor relationships sit between that sponsorship and the platform actually issuing and managing the cards.
Can one platform really run open-loop and closed-loop fleet cards together?
Yes, when authorization and settlement for both card types run through the same system rather than two connected-but-separate ones. The test isn't whether both card types are supported somewhere in the product; it's whether a single statement can show both without manual reconciliation.
How long does it typically take to launch a new fleet card issuance program?
Point-solution stacks built from multiple vendors commonly take 18 months or more, largely due to separate onboarding and compliance cycles for each component. A platform where issuance, authorization, and settlement are unified can bring that down to under 6 months.
Does unified issuance and settlement include PCI DSS and PSD2 compliance?
It should. When compliance is built into the infrastructure rather than managed separately by each vendor in the chain, a retailer or issuer isn't re-verifying scope every time one component of the stack changes.
The MVNO Lesson: You Don't Need to Own the Network to Run the Brand
Mobile phone carriers that operate without owning a single tower, Mint Mobile, Google Fi, dozens of regional brands, run on network capacity leased from one of the handful of companies that actually built the towers. The customer never sees that arrangement. They see a brand, a plan, a bill, a signal icon. The MVNO owns the relationship and the experience; the underlying network operator owns the physical infrastructure and the regulatory licensing that makes it legal to transmit at all.
Fleet card issuance works on the same logic, with a BIN sponsor standing in for the network operator. A fuel retailer or fleet issuer doesn't need to become a bank to issue a branded, fully-featured card program, the same way an MVNO doesn't need to build cell towers to sell phone plans. What it needs is a platform that holds the sponsor relationship, the authorization engine, and the settlement system together well enough that the complexity underneath never becomes the retailer's problem to manage piece by piece. The MVNOs that struggle are, almost without exception, the ones juggling multiple network agreements instead of one clean relationship. Card issuance has the identical failure mode, just with BIN sponsors and processors in place of towers.
So, Who Is Actually Running Your Card Program?
That's the question underneath "which platform has the lowest fees." Not what the per-transaction cost looks like on a rate card, but how many separate companies, contracts, and change-request processes stand between a retailer's ambition for the program and a live transaction.
Ask it directly: if you needed to launch a new card type next quarter, EV, open-loop, co-branded, would that be a configuration change inside your current platform relationship, or a new vendor search?
If the honest answer involves a new vendor search, the issuance stack isn't unified yet, no matter how smoothly it authorizes the card types it already supports.
Reins builds fleet payment infrastructure for fuel retailers and fleet card issuers, from BIN-sponsored card issuance and a dedicated authorization server to unified open-loop and closed-loop settlement and PCI DSS and PSD2-compliant processing.
Contact us to learn more.
