BIN sponsorship: what it is and how card programs actually launch

A BIN — also called an IIN, Issuer Identification Number — is the first six to eight digits of a card number. When a transaction hits the network, the BIN is what routes it: it identifies the issuing institution, the card scheme, the product type (debit, credit, prepaid), the country of issue and often the currency. Everything downstream — authorisation routing, interchange, chargeback rights, regulatory reporting — is anchored to that number.

Because the BIN is the anchor of financial responsibility, the networks only assign one to a licensed principal member. A principal member holds a direct contract with Visa or Mastercard, posts collateral, meets capital requirements, is supervised by a financial regulator and settles directly with the scheme. That is a multi-year, multi-million project — and it is why almost no fintech starts there.

Under BIN sponsorship, a licensed institution — the BIN sponsor — lets you issue cards on its BIN range. Legally the sponsor is the issuer of record: it holds the scheme membership, carries the regulatory obligations and settles with the network. Commercially, the cards are yours: you decide who gets them, what they are used for, what the limits are, what the app looks like and how the economics work.

The sponsor typically sits behind a processor — the platform that authorises transactions in real time, keeps ledgers, exposes APIs and delivers webhooks. In many programs the sponsor and the processor are separate companies; in others, a single provider bundles both, which is what most teams actually want, because integrating two vendors doubles the work.

• Scheme membership and licensing — the sponsor's responsibility
• Settlement and network reporting — the sponsor's responsibility
• Compliance oversight, program rules, KYC standards — shared, sponsor has final say
• Cardholder onboarding, funding, limits, support, branding — yours
• Product economics and go-to-market — yours

Direct membership gives you the best unit economics and full control over the BIN, but you pay for it in time, capital and headcount. You need a regulated entity in the right jurisdiction, scheme collateral, a compliance function, network certification and an ongoing audit burden. Realistic timelines run 18 to 36 months.

Sponsorship inverts that trade-off. You give up some margin and some independence — the sponsor can veto use cases, geographies and risk profiles — but you can be in market in weeks rather than years, with no licence of your own. For most card programs, and for essentially every crypto-funded card program, sponsorship is the only realistic route to launch.

A useful way to think about it: direct membership is a strategic bet you make once the program is already large and the economics justify the infrastructure. Sponsorship is how you get the program large enough to justify that bet.

Sponsors carry the regulatory risk, so onboarding is a real diligence process, not a signup form. Expect to describe the business in detail before any BIN range is allocated.

1. 1.Corporate KYB: entity documents, ownership structure, ultimate beneficial owners, source of funds.
2. 2.Program description: who the cardholders are, what they spend on, expected volumes, average ticket, geographies.
3. 3.Funding flow: where the money comes from and how it reaches the card — this is where crypto-funded programs get the most scrutiny.
4. 4.Compliance framework: your KYC procedure, sanctions screening, transaction monitoring, complaint handling.
5. 5.Risk controls: limits per cardholder, velocity rules, merchant category restrictions, fraud handling.

The single biggest cause of rejected applications is a vague answer on funding flow and end-user identity. Sponsors want to see that you know exactly who your cardholders are and exactly where the money originated.

In a prepaid or debit-style sponsored program, funds sit in a pooled account controlled by the sponsor, with a ledger that attributes balances to individual cardholders. When a card is used, the processor checks the cardholder's available balance in real time, authorises or declines, and the sponsor settles with the network on the usual scheme cycle.

For crypto-funded programs there is an extra leg: stablecoin comes in, is converted, and lands in the fiat pool that backs the cards. From the cardholder's point of view this is invisible — they top up in USDT and spend in USD. From the program's point of view, this conversion step is where FX, scale and rounding rules have to be exactly right, because the card ledger and the crypto ledger use different currencies and different decimal precision.

2328 runs a sponsored virtual card program you consume as an API. You do not negotiate with a sponsor, integrate a processor and reconcile two ledgers separately — you register cardholders, issue cards, fund them from your USDT wallet, and read balances and transactions through one REST interface with Bearer authentication.

• Cards are issued under an existing sponsored BIN — no licence needed on your side
• Funding comes from your USDT wallet, converted to USD card balance
• Freeze, unfreeze, unload and close are single API calls
• Asynchronous operations are tracked through orders and confirmed by webhooks

The practical consequence is that the launch question stops being "which sponsor will take us" and becomes "can we describe our cardholders and our funding flow clearly" — which is a question you can answer this week.