How Card Issuing Works: The Stack Behind Every Fintech Card Program

Every fintech card, from a neobank debit card to a corporate spend card, sits on the same four-layer stack: a network license, a sponsor bank that holds the regulatory relationship, an issuer processor that authorizes transactions in milliseconds, and a program manager that owns the customer. Most executives evaluating a card program have never seen those layers drawn, which is why the two most common planning errors are so consistent. The first is assuming the processor is the hard part, when the processor is the most competitive and commoditized layer in the stack. The second is assuming interchange revenue accrues to the program, when interchange arrives at the sponsor bank and reaches the program only after everyone above it has taken a cut. The layer that actually determines whether a program launches, and when, is the sponsor bank, and the supply of sponsor banks willing to take on new programs contracted sharply after a wave of regulatory action. This guide covers what each layer does, who earns what, what modern processors changed, what a launch actually requires, and the unit economics that separate a card business from a card feature.

Key Takeaways

• Four layers, and only one is genuinely scarce. Networks license the rails, sponsor banks hold the regulatory relationship and the money, issuer processors authorize transactions, and program managers own the customer. Processors compete hard and are readily available. Sponsor bank capacity is the binding constraint on nearly every program timeline.
• Interchange is the revenue, and it does not arrive at the program directly. It flows to the sponsor bank as the issuer of record, and reaches the program as a residual after network fees, processor fees, and the bank's own share. The program's economics are what remains at the bottom of that waterfall.
• The most consequential economic fact in United States debit issuing is the Durbin exemption. Banks below ten billion dollars in assets are not subject to the regulated debit interchange cap, which is why fintech debit programs are overwhelmingly sponsored by smaller banks. The entire sponsor bank market structure follows from this.
• Modern issuer processors changed the product, not the plumbing. API-driven instant issuance and real-time authorization webhooks, where the program approves or declines inside the authorization window, made spend controls and just-in-time funding possible. That capability is what enabled corporate spend cards as a category.
• The launch bottleneck is compliance capacity, not engineering. Sponsor banks now conduct far deeper diligence, impose higher minimums, and decline more programs than they did before the enforcement wave, so timelines are set by bank onboarding rather than by integration work.

The Four Layers

Layer one: the network

Visa, Mastercard, American Express, and Discover operate the rails: the message formats, the authorization and settlement infrastructure, the dispute rules, and the brand. They license participation and assign the bank identification number ranges under which cards are issued.

Networks earn assessment fees on transaction volume plus various service fees. Critically, networks do not earn interchange, a persistent misunderstanding. Interchange flows from the merchant's side to the issuing side; the network takes a separate, smaller cut for operating the system and setting the rules that determine interchange rates. The full mechanics are covered in interchange fees explained.

Networks also set the rules that determine where fraud losses land, which matters to a program's economics because chargeback and fraud exposure sits with the issuing side for some patterns and the merchant side for others, a division mapped in payment fraud liability.

Layer two: the sponsor bank

Only a licensed financial institution can be a network member and issue cards. A sponsor bank, often called a BIN sponsor, holds that membership and lends it to the program.

This layer holds everything regulators care about. The sponsor bank is the issuer of record, holds customer funds on its balance sheet, owns the anti-money-laundering and sanctions program, is examined by its regulator, and is accountable for the program's compliance whether or not it performed the work. That accountability is the reason sponsor banks conduct extensive diligence: a fintech partner's failure becomes the bank's regulatory problem.

Sponsor banks earn a per-account or per-card fee, a negotiated share of interchange, and, on debit programs, the economic benefit of holding customer deposits. The deposit relationship is frequently the real motivation, since it supplies funding at a cost of capital most banks find attractive.

Layer three: the issuer processor

The processor is the technical engine. When a card is presented, the network routes an authorization request to the processor, which validates the card, checks available balance or credit, applies program-configured controls, and returns an approval or decline, typically within a few hundred milliseconds. It maintains the ledger, manages card lifecycle from issuance through replacement, handles tokenization for digital wallets, and produces the transaction data the program sees.

Two generations coexist. Legacy processors, including the platforms operated by FIS, Fiserv, and Global Payments, run the majority of traditional bank card portfolios: enormous scale, deep functionality, batch-oriented integration patterns, and long implementation cycles. Modern processors, including Marqeta, Lithic, Galileo, and Highnote, are API-first, with instant virtual card issuance and developer-oriented tooling.

Layer four: the program manager

The program manager owns the customer relationship: the brand, the application experience, underwriting or approval decisions, spend policy, customer service, and the economics that remain after everyone else is paid. This is the fintech itself in a direct program, or a middleware platform that packages bank and processor access for others.

The program manager receives the residual interchange and bears the costs that scale with customers: support, fraud losses not otherwise allocated, card production, and rewards if offered.

Who Actually Earns What

Interchange is the primary revenue in most card programs, and understanding its path explains the whole business.

A purchase is made. The merchant's acquirer pays interchange toward the issuing side. That interchange arrives at the sponsor bank, because the sponsor bank is the issuer. The network deducts its assessment. The processor is paid its per-transaction fee. The sponsor bank retains its negotiated share. What remains flows to the program manager.

The program is therefore last in the waterfall, and its margin is the residual. This is why interchange rate differences that look small compound decisively.

The Durbin exemption is the single most important variable in United States debit issuing. The Durbin Amendment capped debit interchange for banks with ten billion dollars or more in assets at a level substantially below unregulated rates. Banks below that threshold are exempt and may earn materially higher debit interchange. The consequence shapes the entire market: fintech debit programs are sponsored almost exclusively by smaller banks, because the same transaction generates several times the interchange under an exempt sponsor. A program that sponsors with a large bank has structurally worse debit economics regardless of how well it negotiates.

Beyond that, three factors move the rate. Credit interchange exceeds debit by a wide margin, which is why credit programs have more revenue headroom and correspondingly more regulatory and credit-risk burden. Commercial and corporate cards earn more than consumer cards, which is the economic engine behind corporate spend platforms and the virtual card programs examined in virtual cards in B2B payments. And card-not-present transactions generally carry higher interchange than card present, so a program whose spend concentrates online earns more per dollar than one concentrated in physical retail.

What Modern Processors Changed

The shift from legacy to API-first processing changed what a card program could be, and two capabilities account for most of it.

Instant programmatic issuance. A card can be created by API call in under a second, virtual and immediately usable in a digital wallet. Legacy issuance assumed physical production and mailing measured in days. Instant issuance is what makes single-use and per-vendor cards viable, and therefore what makes fine-grained spend control a product rather than a policy document.

Real-time authorization webhooks. This is the more consequential change. Legacy processors decided authorizations against a stored balance and rules configured in advance. Modern processors can call the program's own systems inside the authorization window, giving the program a few hundred milliseconds to approve or decline using its own logic and data. If the program does not answer in time, the processor falls back to a default.

Two things follow. Just-in-time funding means the program does not need to pre-fund every card, since the account can be funded at the moment of authorization, which transforms working capital requirements for a spend program. And arbitrary spend policy becomes enforceable at authorization: merchant category, per-transaction amount, vendor identity, remaining project budget, or any rule the program can evaluate in milliseconds. The controls that define corporate spend management exist because this hook exists.

The trade-off is operational. A program that decides its own authorizations owns an availability requirement measured in milliseconds. If those systems are slow or down, transactions decline at the point of sale, which customers experience as a broken card. Programs adopting real-time decisioning acquire a payments-grade reliability obligation, which is a different engineering posture than most application teams are used to.

What It Takes to Launch

Timelines commonly run from roughly six months to well over a year, and the variance is driven almost entirely by the sponsor bank rather than by integration.

Sponsor bank selection and diligence is the long pole. Banks now review the business model, the compliance program, the management team, financial condition, and the specifics of how customer funds will be held and reconciled. Programs are declined regularly, and finding a bank is genuinely difficult for novel models or thin balance sheets.

The compliance build runs alongside and is non-negotiable, because the sponsor bank cannot approve a program that lacks it. That means a documented anti-money-laundering program with a designated officer, customer identification and verification, sanctions screening, transaction monitoring, dispute handling under the applicable regulation for debit or credit, and complaint management. Credit programs add fair lending and underwriting compliance, which is a substantially heavier load.

Processor integration is usually the shortest phase with a modern processor. This is the part engineering teams estimate accurately and the part that rarely determines the date.

Certification and testing with the network follows, then a controlled launch with limited volume.

The dominant misperception is that this is an engineering project with a compliance component. It is a bank partnership and compliance project with an engineering component, and staffing it the other way around is the most reliable way to miss the timeline.

The Sponsor Bank Reality

The sponsorship market tightened materially, and any current plan needs to reflect that rather than the conditions of a few years ago.

Regulators intensified scrutiny of banks with substantial fintech partnership businesses, and multiple such banks received formal enforcement actions requiring remediation of third-party risk management, anti-money-laundering programs, and oversight of partner activity. Separately, the 2024 collapse of the middleware provider Synapse left end customers unable to access funds while ledger records between the platform and its partner banks were reconciled, which put the question of who maintains the authoritative record of customer balances at the center of regulatory attention.

Four consequences follow, and they are the current operating conditions.

Fewer banks, deeper diligence. Some institutions exited or paused new partnerships. Those remaining ask harder questions and take longer.

Higher minimums. Sponsors increasingly want programs with credible scale, which raises the bar for early-stage entrants.

Direct scrutiny of ledger and reconciliation practices. Banks now examine how customer balances are tracked and how records reconcile with the bank's own, and expect the ability to reconstruct balances independently of a middleware provider.

Pressure on the middleware layer. The value proposition of a program manager that abstracts the bank relationship weakened, because that abstraction was exactly what obscured the reconciliation problem. Sponsor banks increasingly want direct visibility into, and sometimes a direct relationship with, the program.

Direct Versus Program Manager

The decision reduces to whether the card is the business or a feature of it. When interchange is a primary revenue line, the economics of going direct compound and the control matters. When the card is a retention or convenience feature attached to a different business, the platform route is usually correct, and the same build-versus-partner logic that governs the broader banking stack applies, as laid out in how to build a neobank.

The counterparty consideration deserves more weight than it historically received. A middleware dependency between a program and its customers' funds is a real risk, not a theoretical one, and diligence on that layer's own bank relationships and reconciliation practices is now part of the decision.

Unit Economics: Business or Feature

The arithmetic is straightforward, and it determines everything.

Revenue per active card is average spend multiplied by the effective net interchange rate after the waterfall. Costs are per-card processor fees, sponsor bank per-account fees, card production and shipping for physical cards, customer support, fraud losses net of recoveries, and rewards if offered.

The structure has one dominant feature: most costs are per active card and largely fixed, while revenue scales with spend. A card with modest monthly spend generates interchange that struggles to cover its own fixed costs. A card with heavy spend covers them many times over. Programs therefore succeed on spend per active card, not on card count, and a program measuring cards issued rather than spend per active card is measuring the wrong thing.

Three implications follow directly. Consumer debit is the hardest category, because spend per card is modest and the fixed costs are the same as any other card, which is why consumer neobank programs need either very high engagement or a second revenue line. Commercial and corporate cards are structurally the most attractive, combining higher interchange with much higher spend per card. And dormancy is the silent killer, since an inactive card carries its fixed costs indefinitely while producing nothing, making activation and engagement the operative metrics rather than acquisition.

Fraud deserves explicit modeling rather than a contingency line. Card fraud losses are a normal operating cost, and the allocation between issuer and merchant depends on the transaction type and authentication used. A program that models interchange carefully and treats fraud as an afterthought will find its margin absorbed by a category it never forecast.

Frequently Asked Questions

What is a BIN sponsor bank?

A licensed bank that holds network membership and allows a fintech to issue cards under its bank identification number. The sponsor bank is the legal issuer, holds customer funds, owns the anti-money-laundering and compliance program, and answers to regulators for the program's conduct. It earns per-account fees, a negotiated share of interchange, and the economic benefit of holding deposits. It is the scarcest layer in the stack and usually determines the launch timeline.

What does an issuer processor actually do?

It authorizes transactions in real time. When a card is presented, the network routes an authorization request to the processor, which validates the card, checks funds or credit, applies configured controls, and returns an approval or decline in a few hundred milliseconds. It also maintains the ledger, handles card lifecycle and replacement, manages digital wallet tokenization, and supplies transaction data. Modern processors add API issuance and real-time webhooks that let the program decide authorizations itself.

Who earns the interchange on a fintech card?

It is shared, and the program manager is last in line. Interchange arrives at the sponsor bank as issuer of record. The network takes its assessment, the processor takes per-transaction fees, the sponsor bank retains its negotiated share, and the remainder flows to the program. This is why the sponsor bank agreement matters more to program economics than almost any other commercial term.

Why do fintechs use small banks as sponsors?

Because of the Durbin exemption. Banks with ten billion dollars or more in assets face a regulatory cap on debit interchange; banks below that threshold do not, and can earn materially higher rates on the same transaction. A debit program sponsored by an exempt bank generates several times the interchange of one sponsored by a large bank, which is why the sponsorship market is concentrated among smaller institutions.

How long does it take to launch a card program?

Typically six months to over a year, with the sponsor bank as the long pole rather than the technology. Bank diligence and the compliance build, including an anti-money-laundering program, customer verification, sanctions screening, transaction monitoring, and dispute handling, dominate the timeline. Processor integration is usually the shortest phase. Timelines lengthened after regulators increased scrutiny of bank fintech partnerships and several sponsors exited or paused new programs.

The Bottom Line

The most useful correction for anyone planning a card program is that the difficulty is inverted from where teams expect it. Engineering assumes the processor integration is the challenge, and it is the most predictable part of the project, served by a competitive market of vendors who have done it many times. The genuinely hard parts are securing a sponsor bank that will accept the program, building a compliance function the bank will approve, and reaching spend per active card sufficient to cover fixed costs.

The economics reinforce that. Because the program sits last in the interchange waterfall and most of its costs are per active card, viability turns on spend concentration rather than card volume. That is why corporate and commercial programs work more readily than consumer debit, and why consumer programs generally need a second revenue line or unusual engagement.

The environment has also changed in a direction planning should reflect. Sponsor capacity is tighter, diligence is deeper, minimums are higher, and regulators now look directly at how customer balances are tracked and reconciled. A plan built on the assumption that a sponsor bank is a procurement exercise with a known timeline is planning against conditions that no longer hold.