Card Issuing and BIN Sponsorship: The Operator's Guide to Program Management

Every article on this site about the acquiring side assumes a merchant's chair: you accept cards, you pay interchange, you eat chargebacks, you negotiate a PSP contract to get better terms on money flowing out. Card issuing is the other chair. Interchange is revenue instead of cost. Disputes are something you investigate and pay out on, not something you defend. And the contract you're signing isn't with a processor who takes your money — it's with a bank whose licence you're borrowing.

Operators who reach for a card program — an expense card, a driver payout card, a BNPL instrument — usually arrive from the acquiring side and import the wrong instincts wholesale. This is the reference for the chair they haven't sat in: what BIN sponsorship actually buys you, who the issuer-processors are and where they stop, who is legally the issuer of record and why that decides who eats a loss, what the economics actually look like, and the contract terms that determine whether you can leave.

BIN sponsorship vs direct scheme membership

A BIN — the six-to-eight digit prefix that identifies the issuing bank, network, and card type on every card scheme transaction — can only be held by an entity with scheme principal membership. That's a bank (or an e-money institution in the UK/EU) that has met Visa's or Mastercard's capital, operational, and certification bar directly. Almost no operator wants to clear that bar for a first card program, which is what makes BIN sponsorship exist: a principal member licenses out the right to issue under its BIN.

Visa's own partner-type taxonomy draws the chain in four layers. The BIN sponsor is the issuing bank: it owns the BIN, holds cardholder funds, manages risk and local regulatory compliance, and typically acts as settlement agent. The issuer-processor maintains the system of record — authorization, clearing, settlement, the card lifecycle. The program manager runs the day-to-day program: onboarding, marketing, cardholder support. An end-to-end partner bundles more than one of these roles under a single commercial relationship, which is what most operators actually buy.

The trade is exactly the trade on the acquiring side, mirrored: a bundled relationship gets you to market in months instead of years and removes the compliance build entirely, at the cost of control over pricing, product configuration, and — critically — what happens to your BIN if the relationship ends. Marqeta's own comparison of licensing routes puts numbers on only two of its three: the programme-manager route at three to six months, and scheme principal membership at six months or more with the highest setup investment. It gives no month figure for the BIN-sponsor route itself — only a threshold, framing principal membership as generally worth pursuing once a programme clears roughly 50,000 cardholders, the point where owning the margin and the relationship starts to outweigh the setup cost and the multi-year compliance build. The wider ranges in the build-versus-buy table below are this site's own framing across a broader set of routes, not Marqeta's, and should not be read as its figures.

The issuer-processor landscape

The technology layer between the BIN sponsor and the operator is where most of the vendor selection decision actually happens, because it's the layer with an API. Seven names cover most of the market an operator will actually evaluate:

• Marqeta — issuer-processor with modular architecture; program-manager and processor-only tiers, so operators can bring their own sponsor bank, KYC vendor, or ledger as they mature out of a fully managed program.
• Galileo (a SoFi Technologies company) — a technology platform, not a bank, operating on top of partner issuing-bank relationships; broad account, card, lending, and business-banking product surface beyond pure card issuing.
• i2c — issuer-processing platform spanning credit, debit, and prepaid, marketing very broad geographic reach (216+ countries and territories) and a heavily configurable, low-code product build.
• Stripe Issuing — partners with multiple issuing banks and with both Visa and Mastercard directly, so a Stripe-based program can issue on either network without the operator holding a separate scheme relationship.
• Adyen Issuing — positions itself as running "in the background" while the platform owns the cardholder relationship; issued through Adyen's own banking licence in the markets where it holds one.
• Enfuce — EEA/UK specialist operating as BIN sponsor in its own right through two regulated entities (an EEA e-money institution and an FCA-authorised UK entity), offering both a full issuing-and-settlement model for operators without their own licence and a lighter settlement-only model for operators that already hold an EMI licence.
• Thredd (formerly Global Processing Services) — issuer-processor with BIN sponsorship capability across APAC, UK/Europe, and the Americas, positioned around fast time-to-launch for new programs.

The boundary that actually matters when evaluating any of these: does the vendor hold its own BIN sponsorship capacity (Enfuce, and Adyen in its licensed markets), or does it sit on top of separately contracted sponsor banks (Marqeta, Galileo, i2c, Stripe, Thredd in most configurations)? That answer determines whether you're signing one contract or two, and whose name is actually on the scheme membership when something goes wrong.

Diligence beyond the account count

Vendor selection at this layer usually reduces to a features scorecard plus a headline account or volume number from a deck or press release. But "accounts" and "revenue" aren't self-defining metrics for a platform embedded inside a bank-charter parent with its own other business lines — and most issuer-processors give a buyer no way to check what sits behind the number at all. Of the names above, three sit in entities that disclose anything comparable: Marqeta (NASDAQ: MQ, quoted directly above), Galileo — inside SoFi Technologies, NASDAQ: SOFI — and Adyen, which is itself public (Euronext Amsterdam: ADYEN) and publishes shareholder letters, earnings-call materials, and financial statements directly through its own investor-relations site. i2c, Thredd, Stripe, and Enfuce are privately held and disclose no equivalent financial detail. SoFi's Q2 2026 Form 10-Q (filed 6 August 2026, period ended 30 June 2026) is used below not because it says something uniquely damning about Galileo, but because it is the rare case where a buyer can check the mechanics of an issuer-platform metric against a primary filing at all.

One scope point the filing itself doesn't flag for the reader: SoFi reports a Technology Platform segment, not a "Galileo" segment. It bundles Galileo (card-issuing and event processing) with Technisys (core banking software) and related services, so every dollar figure below is segment-wide, not Galileo-specific — attributing it narrowly to Galileo would overstate the precision the filing supports. Total accounts is the one metric the filing defines as Galileo-specific: "the number of open accounts at Galileo as of the reporting date."

The headline year-over-year comparison actually understates the segment's external decline. Technology Platform total net revenue was $84,505K in Q2 2026 versus $109,833K in Q2 2025 — down 23% as filed (H1: $159,591K vs. $213,260K, down 25%). That total includes intercompany fees SoFi's own Financial Services segment pays for using the platform. A Note 17 footnote discloses those separately: $27,805K (Q2 2026) and $52,542K (H1), up from $18,182K and $34,377K — an increase of roughly 53%. Netting the disclosed intercompany fee out gives a derived external-revenue figure, not one SoFi reports directly: roughly $56,700K versus $91,651K for Q2 (down about 38%), and $107,049K versus $178,883K for H1 (down about 40%). Cross-checked on a different basis, Note 3's ASC 606 table shows "Total technology platform" revenue (which nets out intercompany amounts under revenue-recognition rules) of $55,528K vs. $90,544K for Q2 (down about 39%) and $104,870K vs. $177,168K for H1 (down about 41%) — within about a point of the derivation either way. MD&A confirms the mechanism directly, citing "an increase in intercompany revenue of $9.6 million, primarily attributable to increased usage of technology platform services during the 2026 period by our Financial Services segment." The as-filed 23%/25% figures aren't wrong — they're the correct as-reported numbers — but a segment total blending external clients with the parent's own internal usage will systematically understate how the external base is actually trending, and a buyer should ask what share of any quoted total is intercompany before reading a growth or decline rate as an external signal.

The accounts metric carries the same caveat, and the filing says so directly rather than leaving it implicit. Total accounts on the Galileo platform were 134,804,238 at 30 June 2026 versus 160,046,369 a year earlier — down about 16%, a period-end count, not an average. The filing states: "We include intercompany accounts on the Galileo platform as a service in our total accounts metric to better align with the Technology Platform segment revenue reported in Note 17 … which includes intercompany revenue." Some share of that 134.8 million is SoFi's own consumer accounts running on Galileo's rails, not third-party clients — and the split is not disclosed anywhere. The figure is verifiable only as a blended processing-scale statement, never as a claim about the size of Galileo's external client base, because that number simply isn't published.

Segment contribution profit — a non-GAAP measure SoFi defines as segment net revenue less directly attributable expenses and provision for credit losses — fell further than revenue: $11,772K in Q2 2026 versus $33,195K (down 65%), and $23,771K versus $64,108K for H1 (down 63%). MD&A attributes much of the underlying decline to a single, unnamed departure: "the exit of a large client who fully transitioned off our platform in 2025," citing a $39.1 million drop in technology services fees for the quarter ($76.3 million for H1). The client is not named, and "primarily" is doing real work in that sentence — it's management's own attribution of the main cause, not a claim of the complete explanation.

The filing also supports a less one-sided read. Directly attributable segment expenses fell $3.9 million (5%) in the quarter, attributed to lower "payment processing network association fees associated with decreased activity" — cost moving down with volume, not a fixed base grinding against falling revenue. SoFi also acquired Peach Finance, a cloud-native loan management and servicing platform, in Q2 2026, "intended to further expand our enterprise technology capabilities." Equally worth naming is what's absent: no disclosed new-client signings, no pipeline or backlog commentary, no forward guidance, and no "return to growth" language anywhere tied to this segment specifically.

The point this is building toward is about the diligence process, not about Galileo. Even the Technology Platform segment's numbers only exist because they're bundled into a public parent's segment reporting — a disclosure obligation with nothing to do with helping a card-program buyer evaluate a vendor. i2c, Thredd, Stripe, and Enfuce disclose nothing at this resolution at all: i2c's platform claims (geographic reach, uptime, configurability) are entirely vendor-published, and its public developer portal, fetched directly this session, returned only an unrendered client-side loading shell rather than browsable documentation. None of that makes i2c's platform worse than Galileo's — it makes it unauditable in a way Galileo, imperfectly, is not. A buyer who reads the segment's quarter as a red flag simply because the numbers exist to be read, while giving a private processor a pass because it discloses nothing, is rewarding opacity over disclosure — backward from what diligence is for.

Concrete questions worth asking any issuer-platform vendor before signing, regardless of which one it is:

• Does a quoted "accounts" or "clients" figure include the vendor's own affiliated or intercompany usage, and in what proportion?
• Is a quoted revenue or growth figure net of intercompany fees, or does it blend platform revenue with revenue billed to the vendor's own corporate affiliates?
• What is client concentration, and has a large client exited or been onboarded in the past 12–24 months?
• For a metric with no independent source — most of them, for a private processor — is the basis an audited disclosure, a management representation, or marketing copy with no stated methodology?
• If the vendor is a segment inside a larger public parent, are the figures segment-wide or specific to the card-issuing product being evaluated?

None of this favors one processor over another on its own. It's a reason to ask the same questions of whichever vendor is on the table, public or private, and to treat "we don't disclose that" as an answer with its own cost, not a null result.

Who is the issuer of record, and why it decides liability

"Issuer of record" is not a branding choice. It's the entity whose name sits on the scheme membership, whose capital backs the program, and — in the US — the entity that Regulation E and the 2016 interagency CIP guidance point to when something breaks. The interagency guidance is explicit on this: when a bank issues cards through a third-party program manager, the program manager is treated as the bank's agent, not as the bank's customer, and the issuing bank remains ultimately responsible for compliance performed by that agent. The same logic runs through dispute handling — under Regulation E, it is the financial institution, not the program manager or issuer-processor, that must investigate an error notice and post provisional credit within statutory timelines.

Practically: if your program runs on an issuer-processor sitting on top of a sponsor bank, the sponsor bank is who a regulator calls, whose balance sheet absorbs an enforcement action, and who can unilaterally decide the program is no longer worth the risk. Your issuer-processor and program manager are downstream of that decision, however deep your integration with them runs. This is the single fact every other section of this guide traces back to.

Program economics: interchange as revenue, inverted

The acquiring-side version of this site treats interchange as a cost line to minimize. On the issuing side it's the revenue line. A debit or prepaid card program earns interchange on every transaction its cardholders make, and in the US the size of that number depends heavily on which bank is issuer of record.

Regulation II caps interchange for issuers with $10 billion or more in consolidated assets at $0.21 plus 0.05% of the transaction value, with a further $0.01 available if the issuer meets specified fraud-prevention standards. Issuers below that $10 billion threshold are exempt from the cap entirely — and the gap is not theoretical. In 2024, average interchange on exempt-issuer transactions ran $0.51 per transaction (1.21% of value) against $0.23 (0.47%) for covered-issuer transactions — more than double. The choice of sponsor bank asset size is, in itself, close to the single biggest lever on program economics available to an operator building on interchange revenue.

Issuer-processors typically pass a share of that interchange back to the operator under one of two structures. Gross interchange pays a fixed percentage of processing volume regardless of the interchange actually earned — Stripe's own guide gives the example of 1% gross revenue share on $100K processed yielding a flat $1,000, operationally simpler and more predictable. Net interchange pays a percentage of interchange after scheme and bank fees are deducted — more transparent about the underlying economics, harder to forecast. Layered on top are the fees an operator negotiates directly with the issuer-processor: per-card and per-transaction platform fees, and — because cards need to be funded before they can be spent — prefunding or reserve requirements against the BIN sponsor's settlement risk.

Marqeta's own FY2025 results illustrate where the market is drifting: management attributed part of its revenue growth to "faster growth of card programs where we provide processing services with minimal or no program management" — a mix shift toward operators taking on more of the program-manager function themselves as they scale, rather than staying fully bundled indefinitely. That's the same build-vs-buy trajectory this guide covers below, visible in a public company's own revenue mix.

Liability from the issuer's seat

This is the genuinely inverted section. Every dispute and fraud article on this site is written from the merchant's chair, defending against a chargeback initiated by an issuer. From the issuing seat, you are the issuer, and the obligations run the other way.

Disputes. Under Regulation E, when a cardholder reports an unauthorized transaction or an error, the financial institution — not the program manager, not the issuer-processor — must investigate and, if it can't resolve the claim within 10 business days, provisionally credit the cardholder's account within that same window while the investigation continues (extendable to 45 days generally, 90 for certain transaction types). The institution may withhold up to $50 pending a finding of unauthorized use. There is no equivalent to "defend the chargeback" from this seat: the clock runs against you by statute, and your program manager's operational speed at surfacing and documenting the claim is what determines whether you make the 10-day window.

Fraud. The same issuer-acquirer-gateway-psp payment stack that frames fraud liability shifting to the issuer under 3D Secure, from the acquiring side, is fraud liability landing on your program from the issuing side. Fed data on covered debit issuers shows the fraud-loss split moving structurally since Regulation II: issuers absorbed 59.8% of fraud losses in 2011 versus 28.3% by 2023, with merchants picking up the difference — but 28.3% of covered-issuer transaction fraud is still a real cost line an issuing program has to underwrite, monitor, and reserve against, not a number that disappears because the acquiring side is carrying more of it than a decade ago.

Settlement risk. The BIN sponsor is on the hook to the scheme for every transaction that clears under its BIN, which is why sponsors require prefunding or reserves from the program in the first place — the same instinct as a rolling reserve on the acquiring side, aimed the other direction.

Program losses. If cardholders overspend, default, or the program's credit losses run hot, that loss sits with whoever extended the credit — the sponsor bank if it's the lender of record, or the operator if the program is structured with the operator bearing credit risk contractually. Get this allocation in writing before launch; it is not implied by who processes the transaction.

Compliance obligations

KYC/CIP. The 2016 interagency guidance draws the line precisely: a bank must apply its own Customer Identification Program to reloadable or credit-enabled card programs even when a program manager collects the underlying data, because the program manager is the bank's agent, not its customer. Non-reloadable, non-credit programs with pooled funding can treat the program manager itself as the customer, which is a materially lighter compliance lift — the reloadable/credit-enabled distinction is worth designing around deliberately rather than discovering after the fact.

PCI DSS. Visa's own bulletin on issuer PCI obligations is unambiguous: all issuing and acquiring members and their sponsored agents, processors, and service providers that store, process, or transmit card data must comply with PCI DSS, and issuers directly connected to VisaNet must validate compliance annually. Tokenization at the issuer-processor layer narrows scope but does not remove it — the vault and detokenization environment stay in scope.

Third-party risk management. US banking regulators' interagency guidance on third-party relationships requires the sponsor bank to run a full lifecycle on its relationship with your program manager or issuer-processor: due diligence before signing, contract terms covering audit rights and termination, ongoing monitoring proportional to risk, and — the piece operators most often discover too late — a documented termination and transition plan. That obligation runs on the bank, but it flows straight through to your program: expect audit requests, expect monitoring questionnaires, and expect the bank's risk appetite to change the deal terms mid-program if your volume, MCC mix, or loss rates move.

Jurisdictional differences. In the EU/UK, the EBA's outsourcing guidelines apply the same logic through a different mechanism: an e-money or payment institution outsourcing a "critical or important function" (issuing almost always qualifies) must document an exit strategy in advance, cannot sub-outsource without approval, and must maintain a register of the arrangement for supervisory review. The substance converges with the US model — the licensed entity cannot contract away its regulatory responsibility — but the EU/UK route runs through EMI licensing and BIN-sponsor accreditation (Mastercard's 2026 "BIN Sponsor Plus" programme, discussed below) rather than bank-charter oversight.

Contract red flags — the issuing-side parallel

PSP contract red flags covers what to redline on the acquiring side. The issuing-side list rhymes, but the leverage runs differently — you're borrowing a bank's licence, not renting a processor's rails.

• Exclusivity. Some program-manager and issuer-processor agreements require the operator to run exclusively on that vendor's rails for the contract term. Fine at launch, expensive the moment you want a second BIN for redundancy or a different market's licensing regime.
• Volume minimums. Ramp schedules and minimum-fee floors are standard, but the reserve and prefunding terms attached to missing them should be capped and disclosed up front, not left to the sponsor's discretion.
• BIN portability on exit. This is the load-bearing clause and the one operators skip. A BIN is licensed to the sponsor, not to you — nothing in scheme rules guarantees you can take "your" BIN, or even your card number ranges, to a new sponsor or processor. Confirm in writing what happens to in-market cards, tokens, and the number range itself if you switch issuer-processor or sponsor bank.
• Data access. Mirroring the 2016 interagency guidance's own contract checklist for CIP data, insist on your own explicit, immediate access to cardholder and transaction data your program manager collects — not access mediated entirely through their dashboard, and not contingent on the relationship staying healthy.
• Termination and wind-down. A sponsor bank exiting your program vertical (a recurring event — see below) needs a defined transition period long enough to migrate cardholders, not a 30-day notice that leaves live cards stranded.
• Audit rights. The interagency guidance requires the bank to have audit rights over its program manager. Push for the mirror image in your own agreement with the issuer-processor: your right to audit fee calculations, interchange pass-through, and reserve mechanics, the same ask this site makes on the acquiring side.

Build vs buy vs own licence

The decision isn't really about which row looks best in isolation — it's about which row your current cardholder volume and loss rates can actually justify, and whether card issuing is a feature of your platform or the platform itself. Embedded finance for operators covers the equivalent build-vs-buy decision one layer up the stack, across ledger, KYB, and licensing as well as card issuing specifically.

Card program failure modes

The sponsor bank exits the vertical. This is the issuing-side equivalent of a PSP terminating your merchant account, and it happens for the same reason: a bank's own regulators tighten scrutiny of its BaaS or card-sponsorship book, and the bank retreats from programs it now considers disproportionate risk relative to the fee income. Programs on that bank's BIN get migrated or shut down on the bank's timeline, not the operator's.

Processor migration. Moving issuer-processors — even while keeping the same sponsor bank — means re-platforming card issuance, authorization logic, and (per the BIN portability point above) potentially the card number ranges themselves. This is a heavier lift than a PSP migration on the acquiring side, because the thing moving is closer to core infrastructure than a payment integration.

BIN portability in practice. Mastercard's 2026 "BIN Sponsor Plus" accreditation programme in the UK is a useful signal of where this is heading: schemes are visibly tightening quality standards on BIN sponsors — enhanced due diligence, mandatory ongoing compliance maintenance, accreditation that can be withdrawn — because the old model, where a principal member handed over "the keys to the kingdom" and stepped back, produced enough compliance failures that the schemes themselves are now intervening. The practical read for an operator: BIN sponsorship quality is not static, sponsor accreditation can change mid-program, and the portability clause you didn't negotiate at signing is the clause you'll wish you had the day your sponsor's risk appetite — or its scheme accreditation — changes.

What to read next

This guide stops at structure — once BIN sponsorship, the processor relationship, and the program manager are in place, issuing programme operations picks up the day-to-day: card production and token provisioning, spend controls, card lifecycle and BIN migrations, issuer-side disputes, funding, and the portfolio KPIs that keep a program healthy after launch.

This guide sits opposite the acquiring-side depth already on this site. Understanding PSP contracts and PSP contract red flags cover the merchant's chair in the same clause-by-clause depth applied here to the issuer's chair. Issuer, acquirer, gateway, PSP maps the full stack operators contract with. Network tokens vs PSP tokens covers the issuer side of the token relationship this guide's BIN-portability warning depends on. Embedded finance for operators is the broader build for platforms adding card issuing as one layer among several — ledger, KYB, sponsor bank, and licensing — rather than the sole focus of the program.