---
title: "The Crypto Card Program Stack: BIN Sponsorship, Scheme Membership, and Programme Management"
slug: crypto-card-program-bin-sponsorship
publishedAt: 2026-06-02T11:30:00Z
author: Finconduit Editorial Team
tags: PSD2, EMD2, MiCA, Interchange Regulation
canonicalUrl: https://finconduit.com/resources/crypto-card-program-bin-sponsorship
---
# The Crypto Card Program Stack: BIN Sponsorship, Scheme Membership, and Programme Management

A crypto card is five regulated layers — scheme, BIN sponsor, programme manager, processor, settlement. Map the stack before the economics collapse.

**Every crypto firm wants a card.** A branded debit or prepaid card is the most visible product a **CASP**, exchange, or wallet can ship — it puts the brand in a pocket and turns balances into spend. But the request that lands on a payments lead's desk is almost always the **wrong starting question**: "how do we get a card?"

Beneath every card sits a **five\-layer stack**: a **card scheme**, a **BIN sponsor**, a **programme manager**, a **processor**, and a **settlement bank**. Each layer holds a different licence, owns a different slice of the economics, and carries a different compliance burden. **Get the layering wrong and your card economics collapse** — interchange leaks to the wrong party, funding cost eats the float, and scheme fines arrive before the first transaction settles.

This guide breaks the stack into its five layers, maps who holds the licence at each one, and prices the **interchange, scheme\-fee, and funding economics** that decide whether a **crypto card program** makes money or quietly bleeds. We name the card **schemes** — **Visa** and **Mastercard** — but treat every licensed party as a category, because the right **BIN sponsor** depends entirely on your model, not on a brand name.

## Why "Get a Card" Is the Wrong Starting Question

A card is not a product you **buy**; it is a **program you assemble** from regulated components. The firm whose logo appears on the plastic is rarely the firm that **issues** the card, holds the **BIN**, or touches the **settlement money**. Those functions are split across separately licensed entities — and the split is where the economics live.

Ask "how do we get a card?" and a vendor will happily sell you a **turnkey programme** where they keep the **interchange**, set the **FX spread**, and lock you into their **processor**. Ask instead "**which layer do we own, and which do we rent?**" and you start designing a program whose **margin you actually control**.

The layering is forced by law. In the EEA, issuing a payment instrument and holding customer funds requires either an **EMI licence** under the **Electronic Money Directive** or a credit\-institution licence; the framework that defines e\-money and its safeguarding is [Directive 2009/110/EC \(EMD2\)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32009L0110)¹[^1]. Most crypto firms do not hold one — so they **ride a sponsor's BIN** instead.

> **Tip:** Reframe the brief before you scope vendors. The question is not "how do we get a card?" but "which of the five layers do we own, which do we rent, and where does each euro of interchange land?" That single reframe changes which contracts you sign.

## The Five\-Layer Crypto Card Stack — Overview

We call the model **The Five\-Layer Crypto Card Stack**. From the network down to the money, every card program is built from these five layers — and **each one is a separate commercial and regulatory relationship**:

- **Layer 1 — The Card Scheme.** **Visa** or **Mastercard**. The network that routes the authorisation, sets the rules, and clears the money between issuer and acquirer.

- **Layer 2 — The BIN Sponsor / Issuer.** The **licensed EMI or bank** whose **Bank Identification Number** your cards ride on. It is the regulated **issuer of record**.

- **Layer 3 — The Programme Manager.** The party that runs the **day\-to\-day programme**: onboarding, card lifecycle, customer service, and scheme reporting. Can be **in\-house or outsourced**.

- **Layer 4 — The Processor.** The technical engine: **authorisation**, **clearing**, **tokenisation**, and **3DS2** strong\-authentication.

- **Layer 5 — Settlement & Funding.** The **settlement account**, the **prefunding** that backs spend, and the **float** — where treasury and crypto custody collide.

The trap is assuming these map one\-to\-one to vendors. In practice a single **programme manager** often bundles Layers 2, 3, and 4 into one contract — convenient, but it means **you no longer own the interchange or the processor relationship**. The more layers you outsource into one box, the **less of the economics you keep**.

## Layer 1: The Card Scheme \(Visa / Mastercard\)

The **card scheme** — **Visa** or **Mastercard** — is the network that sits above everything. It does not issue cards or hold money; it **sets the rulebook**, **routes authorisations**, and **clears settlement** between the issuing side and the acquiring side. Every other layer ultimately answers to its **scheme rules**.

Scheme membership comes in **three tiers**, and the tier you sit at decides how much you control and how much you pay:

- **Principal member.** You join the scheme **directly**. You hold your own **BIN ranges**, set your own programmes, and deal with the scheme as a peer — but you carry **full membership capital, scheme fees, and compliance obligations**.

- **Associate member.** You join **under a principal's umbrella** with some independent rights but reduced obligations — a **middle tier** rarely used by early\-stage crypto firms.

- **Sponsored / programme participant.** You **ride a principal member's membership** entirely. You hold no scheme membership of your own; your **BIN sponsor** is the principal and you are their programme. **Cheapest and fastest** — and where almost every crypto card starts.

For a first crypto card, the answer is almost always **sponsored participation**. **Principal membership** costs hundreds of thousands in upfront capital and scheme onboarding, takes **12–24 months**, and only makes sense once volume is large enough to justify owning the network relationship directly.

## Layer 2: The BIN Sponsor / Issuer

The **BIN sponsor** is the **licensed EMI or bank** whose **Bank Identification Number** — the first six to eight digits of every card number — your cards are issued under. It is the **regulated issuer of record**: legally, the sponsor issues the card, the sponsor holds the customer funds, and the **sponsor answers to the regulator** if anything goes wrong.

That is not a technicality. Under the EEA framework, issuing e\-money and executing payment transactions are **regulated activities**; the rules on authorisation, conduct, and customer\-funds handling sit in the [Payment Services Directive \(PSD2\)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015L2366)²[^2], which sets the perimeter your sponsor must sit inside.

Choosing a sponsor is the **single most consequential decision** in the stack. The right sponsor depends on:

- **Risk appetite for crypto.** Many EMIs and banks will not sponsor a **crypto\-funded** card at all. The sponsors that will are a **small, specialist category**.

- **BIN range and scheme.** Whether the sponsor offers **Visa**, **Mastercard**, or both, and whether you get a **dedicated BIN** or sit on a **shared BIN**.

- **Interchange share.** How much of the **interchange** the sponsor keeps versus passes to you — often the difference between a **profitable and an unprofitable program**.

- **Geographic reach.** Which **countries and currencies** the sponsor's licence and scheme membership actually cover.

> **Warning:** Never pick a sponsor on price alone. A sponsor that is cheap on setup but keeps most of the interchange, restricts your BIN, or has a thin crypto risk appetite will cost you far more over the program's life — and a sponsor that loses its own scheme membership or banking can strand your entire card base overnight.

## Layer 3: The Programme Manager — In\-House vs Outsourced

The **programme manager** runs the program day to day: **cardholder onboarding**, **card lifecycle** \(issue, replace, freeze, close\), **customer service**, **dispute handling**, and **scheme and sponsor reporting**. It is the operational spine between your product and the regulated layers beneath.

You can run this **in\-house** or **outsource** it — the trade\-off is control versus speed:

### Outsourced programme management

A third\-party **programme manager** — often bundled with a BIN sponsor and processor — gets you to market **fastest**, with **least upfront build**. The downside is **thinner margins, less control over the customer experience, and lock\-in** to their stack. Good for a **first launch** or a firm that wants the card as a feature, not a business line.

### In\-house programme management

Running the programme yourself means **more capital, more compliance headcount, and a longer build** — but you **own the economics, the data, and the roadmap**. It only pays off at **scale**, once volume justifies the fixed cost. The advantage is **full control of interchange, FX, and the cardholder relationship**.

## Layer 4: The Processor — Authorisation, Clearing, Tokenisation, 3DS2

The **processor** is the technical engine that makes a card actually transact. When a cardholder taps, the processor handles the **real\-time authorisation** — checking funds and risk in milliseconds — then later the **clearing and settlement** file exchange with the scheme. No processor, no transaction.

Four processor functions matter most for a crypto program:

- **Authorisation.** The **real\-time approve/decline** decision, including any crypto\-to\-fiat conversion check at the moment of spend.

- **Clearing & settlement.** The **batch file exchange** with the scheme that moves money between issuer and acquirer.

- **Tokenisation.** Replacing the real **PAN** with a device\-specific token for **Apple Pay / Google Pay** and card\-on\-file security.

Strong customer authentication. The processor delivers **3DS2** — the protocol that satisfies **SCA** for online card payments. The technical standards sit in the EBA's [SCA\-RTS and guidance on the security of internet payments](https://www.eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money)³[^3], and a processor that handles **3DS2** and **SCA exemptions** well directly improves your approval rates.

In a **bundled programme**, the processor is the sponsor's choice and invisible to you. If you want to **own approval rates, latency, and the spend\-time crypto conversion logic**, you contract the processor **directly** — which means owning more of the stack.

## Layer 5: Settlement & Funding — Prefunding, Settlement Accounts, the Float

Cards spend money the program does not yet have. Between a cardholder's tap and the scheme pulling settlement, the **issuer** must already have funds available — so every card program runs on **prefunding**. You wire money into a **settlement account** **ahead of spend**, and the scheme draws against it daily.

Three things define this layer:

- **The settlement account.** A **fiat account at the sponsor's bank** \(or a partner bank\) from which the scheme settles. It must be **funded before spend**, not after — a working\-capital drag many crypto firms underestimate.

- **Prefunding.** The **buffer of cash** you keep in the settlement account. Too thin and authorisations decline; too thick and you **strand capital** that earns nothing.

- **The float.** The gap between when you collect from the cardholder \(or convert their crypto\) and when the scheme settles. **Managed well, the float is a funding benefit**; managed badly, it is a **liquidity hole**.

Where customer money sits, **safeguarding** applies. E\-money float and customer funds must be **segregated and safeguarded** under the EMI rules — the UK framework for this is set out by the [FCA's payment services and e\-money regime](https://www.fca.org.uk/firms/payment-services-electronic-money)⁴[^4], and the equivalent EEA rules flow from EMD2 and PSD2.

## The Five Layers at a Glance — Licence, Economics, Compliance, Cost

This is the master map of the stack. **Read it once before you talk to any vendor** — it tells you who holds the licence, who owns the money, and who carries the compliance at each layer.


*Table: The Five\-Layer Crypto Card Stack — who holds the licence, who owns the economics, who owns the compliance, and the primary cost driver at each layer.*

| Layer | Who Holds the Licence | Who Owns the Economics | Who Owns the Compliance | Primary Cost Driver |
| --- | --- | --- | --- | --- |
| 1 — Card Scheme | The scheme \(Visa / Mastercard\) is the network; no consumer licence | Scheme keeps scheme fees; sets interchange caps | Scheme rules; PCI mandates | Scheme & membership fees |
| 2 — BIN Sponsor / Issuer | Licensed EMI or bank \(issuer of record\) | Sponsor keeps a share of interchange \+ setup/monthly fees | Sponsor is regulated; owns AML/SCA accountability | Interchange share \+ per\-card / monthly fees |
| 3 — Programme Manager | Usually unlicensed \(acts for the sponsor\) | Margin on services; or you keep it if in\-house | Operational AML/KYC, disputes, reporting | Build vs vendor fees; headcount if in\-house |
| 4 — Processor | Technical provider; not the issuer | Per\-transaction / per\-card processing fees | PCI\-DSS, tokenisation, 3DS2 delivery | Per\-transaction processing fees |
| 5 — Settlement & Funding | Sponsor / settlement bank \(safeguarding\) | You bear funding cost; benefit from the float | Safeguarding, segregation, reconciliation | Prefunding working\-capital cost |

## The Crypto\-Specific Wrinkles

A crypto card is not just a card with a crypto logo. Three **crypto\-specific wrinkles** sit on top of the standard stack and reshape every layer beneath them.

### Crypto\-to\-fiat conversion at the point of sale

Cards spend **fiat**; the scheme settles in **fiat**; merchants are paid in **fiat**. So a "crypto card" almost always **converts crypto to fiat at the moment of authorisation** — the user holds crypto, but the network sees a fiat transaction. That conversion logic lives in the **processor and programme layer**, and its **spread is a core revenue line**.

### Custody of the funding asset

If the card is funded from a crypto balance, **someone must custody that crypto** and convert it reliably at spend time. That pulls **qualified custody** and **liquidity** into the funding layer. The risk: a **custody or conversion failure** at the moment of authorisation declines the card — a **reliability problem the standard stack never has**.

### The MiCA \+ EMD2 overlap

Where the funding asset is a **stablecoin**, two regimes overlap. The card sits under **EMD2** and **PSD2**; the stablecoin sits under [the Markets in Crypto\-Assets Regulation \(MiCA\)](https://eur-lex.europa.eu/eli/reg/2023/1114/oj)⁵[^5]. A **euro e\-money token \(EMT\)** under **MiCA** is also e\-money under **EMD2**, so the issuer can face **two overlapping frameworks at once** — a structuring question to resolve before you build, not after.

## Card Economics: Interchange, Scheme Fees, and Funding Cost

A card program lives or dies on three numbers: **interchange earned**, **scheme and processing fees paid**, and **funding cost**. Understand these and you can tell in an afternoon whether a proposed program is **viable or a slow leak**.

### Interchange — your main revenue line

Interchange is the fee the merchant's acquirer pays the issuer on each transaction — and in the EEA it is **capped by law**. Under the [EU Interchange Fee Regulation \(Regulation \(EU\) 2015/751\)](https://eur-lex.europa.eu/eli/reg/2015/751/oj)⁶[^6], consumer **debit interchange is capped at 0.2%** and consumer **credit at 0.3%** of transaction value in the EEA. Commercial cards and non\-EEA transactions are uncapped and earn far more — which is why card economics swing hugely on **card type and geography**.

The practical point: in the EEA, a **consumer debit crypto card earns roughly 0.2%** of spend before any sponsor split — so on €100 of spend you gross around **20 cents**, and the sponsor may keep half. **Volume is everything**; thin interchange only works at scale or with a generous sponsor split.

### Scheme fees and processing

Against that revenue you pay **scheme fees** \(assessment, authorisation, cross\-border, and a long tail of line items\) and **processing fees** \(per transaction and per card\). These are **largely fixed per transaction**, so they **compress margin hardest on small\-ticket spend** — exactly the everyday\-spend use case crypto cards chase.

### Funding cost — the silent line

The **prefunding** you park in the settlement account is **capital that earns nothing** while it sits there. The larger your **prefunding buffer** and the longer your **settlement float**, the higher your **real funding cost** — a line many crypto firms ignore until it shows up in treasury.

## Build vs Buy: Principal Membership vs BIN\-Sponsored Programme

The biggest structural decision is **build vs buy**: become a **principal scheme member** and own the stack, or launch a **BIN\-sponsored programme** and rent it. The table below frames the trade across capital, time, control, and economics.


*Table: Build vs Buy — principal scheme membership versus a BIN\-sponsored programme, across capital, time\-to\-launch, control, economics, and best\-fit profile.*

| Dimension | Principal Membership \(Build\) | BIN\-Sponsored Programme \(Buy\) |
| --- | --- | --- |
| Upfront capital | High — scheme membership capital, EMI/bank licence, full build | Low — setup \+ per\-card fees; no own licence needed |
| Time to launch | 12–24 months \(licence \+ scheme onboarding\) | 3–6 months on an existing sponsor \+ manager |
| Control | Full — own BINs, processor, roadmap, data | Limited — sponsor and manager set the rails |
| Interchange economics | Keep nearly all interchange \(less scheme fees\) | Share interchange with the sponsor |
| Compliance burden | You are the regulated issuer — full accountability | Sponsor is the issuer of record; you run operations |
| Best fit | High volume, card\-as\-a\-business, long horizon | First launch, card\-as\-a\-feature, speed to market |

> **Note:** The default for almost every first crypto card is BUY: a BIN\-sponsored programme reaches market in 3–6 months without a licence of your own. BUILD — principal membership and your own issuer licence — only earns its 12–24 month timeline and capital once volume is large enough that owning the interchange beats sharing it.

## The Compliance Stack: SCA, AML, Sanctions, and Disputes

Every card program carries a compliance stack that sits **alongside** the commercial one. Four obligations dominate, and **the regulated issuer ultimately owns all of them** — even when you run the operations.

- **SCA and 3DS2.** **Strong customer authentication** under **PSD2** applies to card\-not\-present payments, delivered through **3DS2**. Done well it lifts approval rates; done badly it bleeds declines.

- **AML / KYC on cardholders.** Every cardholder is a customer to be **identified, screened, and monitored**. Card spend generates **transaction\-monitoring** obligations on top of your existing crypto AML program.

- **Sanctions screening.** Cardholders and, where relevant, merchants and counterparties must be **screened against sanctions lists** — continuously, not just at onboarding.

- **Chargebacks and disputes.** The scheme's **dispute and chargeback rules** impose strict timelines and evidence standards. **Poor dispute handling** drives fines, loss provisions, and scheme scrutiny.

The structural reality: in a **sponsored programme**, the **BIN sponsor** is the regulated issuer and is **accountable to the regulator for all of this** — which is exactly why sponsors are selective about who they let onto their BIN, and why **your AML and dispute operations are part of the sponsor's due diligence on you**.

## Frequently Asked Questions

### How does a crypto card actually work?

A **crypto card** is a normal **Visa** or **Mastercard** card whose funding source is a crypto balance. When you spend, the program **converts crypto to fiat at the point of authorisation** — the merchant and the scheme only ever see a **fiat transaction**. Underneath sits the full five\-layer stack: a **scheme**, a **BIN sponsor / issuer**, a **programme manager**, a **processor**, and a **settlement and funding layer** that prefunds the spend.

### What is a BIN sponsor?

A **BIN sponsor** is a **licensed EMI or bank** whose **Bank Identification Number** your cards are issued under. The sponsor is the **regulated issuer of record**: it issues the cards, holds the customer funds, and is **accountable to the regulator**. Riding a sponsor's BIN lets a crypto firm launch a card **without holding its own issuer licence** — the most common route to market.

### Do I need an EMI licence to launch a crypto card?

Not necessarily. If you launch under a **BIN sponsor**, **the sponsor's licence covers the issuing** — you do not need your own **EMI licence**. You only need your own **EMI or credit\-institution licence** if you want to be the **issuer of record yourself** — typically via **principal scheme membership** — which is a **12–24 month, capital\-heavy** path most firms defer until scale.

### What does a crypto card program cost to run?

Costs split across the stack: **scheme fees**, **BIN sponsor setup and per\-card / monthly fees**, **processing fees** per transaction, **programme\-management** cost \(vendor margin or in\-house headcount\), and **funding cost** on prefunding. Against that you earn **interchange** — capped at **0.2% on EEA consumer debit** — so the program only works if **volume and sponsor split** cover the largely fixed per\-transaction costs. **Funding cost is the line most firms underestimate**.

> **Call to action:** Building a crypto card program? Finconduit maps the BIN\-sponsor and programme\-manager options, models the interchange economics, and runs the scheme onboarding. Book a free card\-program scoping call.

## Related Guides

- [IBAN Architecture for Crypto Exchanges](/resources/iban-architecture-crypto-exchange): how named\-account and settlement\-account structures underpin the funding layer of any card program.

- [EMI Safeguarding Architecture](/resources/emi-safeguarding-architecture): how customer funds and the card float must be segregated and safeguarded under the EMI rules.

- [BaaS Due Diligence Checklist](/resources/baas-due-diligence-checklist): the diligence framework for vetting a BIN sponsor and programme manager before you commit.

- [Multi\-Currency Treasury Operations](/resources/multi-currency-treasury-casp): how to manage prefunding, the float, and settlement currency across a multi\-currency card program.

A crypto card is never bought; it is **assembled from five regulated layers** — and the firm that understands which layer it **owns** versus **rents** is the one that keeps its **interchange**, controls its **funding cost**, and survives a sponsor's bad day. Map **The Five\-Layer Crypto Card Stack** before you sign a single vendor contract, decide whether you are **building or buying**, and you will ship a card whose **economics you actually control** — not one that quietly bleeds beneath someone else's BIN.

## Footnotes

[^1]: Directive 2009/110/EC of the European Parliament and of the Council on the taking up, pursuit and prudential supervision of the business of electronic money institutions \(EMD2\), OJ L 267, 10.10.2009. <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32009L0110>
[^2]: Directive \(EU\) 2015/2366 of the European Parliament and of the Council on payment services in the internal market \(PSD2\), OJ L 337, 23.12.2015. <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015L2366>
[^3]: European Banking Authority — Regulatory Technical Standards on Strong Customer Authentication and common and secure communication \(SCA\-RTS\) under PSD2. <https://www.eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money>
[^4]: Financial Conduct Authority — Payment services and electronic money: authorisation, safeguarding and conduct requirements for payment and e\-money institutions. <https://www.fca.org.uk/firms/payment-services-electronic-money>
[^5]: Regulation \(EU\) 2023/1114 of the European Parliament and of the Council on markets in crypto\-assets \(MiCA\), OJ L 150, 9.6.2023. <https://eur-lex.europa.eu/eli/reg/2023/1114/oj>
[^6]: Regulation \(EU\) 2015/751 of the European Parliament and of the Council on interchange fees for card\-based payment transactions, OJ L 123, 19.5.2015. <https://eur-lex.europa.eu/eli/reg/2015/751/oj>


---
Source: https://finconduit.com/resources/crypto-card-program-bin-sponsorship