Crypto Debit Card Infrastructure
BIN Sponsorship, Card Networks
& Programme Management

A crypto debit card is not a blockchain product. It is a traditional debit card — issued under a card network licence, processed by a traditional card processor, settled through traditional banking rails — with a crypto asset management layer that converts digital assets to fiat at (or before) the moment of spend. The card network sees fiat. The merchant sees fiat. The only part of the transaction that touches crypto is upstream of the authorisation request, and the card network has no visibility into it.

Understanding this architecture is critical for three reasons. First, it defines the regulatory perimeter: the crypto firm is regulated for the crypto asset management layer (custody, conversion, AML), while the bank/BIN sponsor is regulated for the card issuance layer (e-money, payment services). Second, it defines the failure modes: an outage in the card processor or BIN sponsor takes down the card programme regardless of the health of the crypto platform. Third, it defines the unit economics: interchange, scheme fees, BIN sponsor fees, and processor fees are set by counterparties the crypto firm cannot negotiate with from first principles — they must be understood and modelled before programme launch.

┌────────────────────────────────────────────────────────────┐
│                   CARDHOLDER EXPERIENCE                    │  ← Mobile app, virtual/physical card
├────────────────────────────────────────────────────────────┤
│                PROGRAMME MANAGER (PM) LAYER                │  ← Controls card UX, limits, rewards
│   Card management · Spending controls · Customer service   │
├────────────────────────────────────────────────────────────┤
│           CRYPTO ASSET MANAGEMENT LAYER                    │  ← Crypto-specific, PM or separate
│   Custody · Real-time liquidation · FX conversion          │
│   Stablecoin/token balance · Compliance screening          │
├────────────────────────────────────────────────────────────┤
│        CARD ISSUER / BIN SPONSOR (Licensed Bank)           │  ← Holds Visa/MC membership
│   BIN ownership · Regulatory licence · Settlement accounts │
├────────────────────────────────────────────────────────────┤
│            CARD PROCESSOR / ISSUER PROCESSOR               │  ← Tech layer between bank & network
│   Authorisation decisions · Transaction routing            │
│   Ledger management · Network connectivity                 │
├────────────────────────────────────────────────────────────┤
│           CARD NETWORK (Visa / Mastercard)                 │  ← The rails
│   Network routing · Interchange rules · Scheme fees        │
│   Dispute resolution · Compliance enforcement              │
└────────────────────────────────────────────────────────────┘

The crypto firm typically sits at the Programme Manager layer — or controls both the PM layer and the crypto asset management layer — but does not and cannot sit at the BIN sponsor or card network layer without either acquiring a bank charter or obtaining a principal membership in the card networks (which itself requires significant capital, compliance infrastructure, and processing volume). Most crypto card programmes work through a BIN sponsor relationship because direct network membership is unreachable for early-stage firms.

A Bank Identification Number (BIN) — formally called an Issuer Identification Number (IIN) since 2017, when the standard expanded from 6 to 8 digits — is the first 6–8 digits of any card number. The BIN identifies the card network (Visa, Mastercard, Amex), the issuing bank, the card type (debit, credit, prepaid), and the product programme. Every card in existence traces back to a BIN, and every BIN is owned by a licensed bank that is a principal member of the relevant card network.

Non-bank entities — including crypto firms — cannot directly own a BIN. To issue cards under a Visa or Mastercard BIN, a crypto firm must partner with a bank that holds principal membership and is willing to sponsor the programme. This sponsoring bank is the BIN sponsor.

What a BIN Sponsor Actually Does

Major BIN Sponsors in the Crypto Card Market

Visa and Mastercard operate four-party network models. Understanding this model is non-negotiable for anyone running a card programme because it defines who bears risk, who captures value, who sets rules, and what the contractual obligations are at each node.

Interchange: The Economics of Card Acceptance

Interchange is the fee paid by the acquirer to the issuer for each card transaction. It is set by the card network (not negotiated between the parties) and varies by card type, merchant category code (MCC), geography, and transaction method. In the US, Visa consumer debit interchange is regulated at a maximum of ~$0.21 + 0.05% plus a $0.01 fraud-prevention adjustment (Durbin Amendment). In the EU, interchange is capped at 0.2% for debit and 0.3% for credit (Interchange Fee Regulation). In markets without fee regulation — including most of Southeast Asia, UAE, and parts of Latin America — interchange can reach 1.5–2.5%.

// Per-transaction P&L for a crypto debit card programme (illustrative)
// Assumptions: USD100 transaction, unregulated market, Visa debit

Revenue:
  Interchange_earned    = $100 × 1.50%            = $1.50
  FX_spread_revenue     = $100 × 0.50%            = $0.50   ← crypto→fiat spread
  Total_revenue                                   = $2.00

Costs:
  Scheme_fees           = $100 × 0.14%            = $0.14   ← Visa assessment
  BIN_sponsor_fee       = $0.15 (fixed per txn)   = $0.15
  Processor_fee         = $0.08 (fixed per txn)   = $0.08
  Network_access_fee    = $0.02                   = $0.02
  Crypto_liquidation    = $100 × 0.10%            = $0.10   ← DEX/OTC slippage
  Fraud_reserve         = $100 × 0.08%            = $0.08
  Total_cost                                      = $0.57

Gross_margin            = $2.00 − $0.57           = $1.43 (71.5%)
// Gross margin before: overhead, customer support, disputes, rewards

// Margin compression factors:
// → Regulated markets (EU/US): interchange cap → margin ~$0.50–0.70/txn
// → Rewards programmes: cashback typically 0.5–1.5% → can wipe entire margin
// → High chargeback rates: each dispute costs $15–35 in processing fees

The Programme Manager (PM) is the entity that designs, operates, and is commercially accountable for the card programme. In most crypto card deployments, the crypto firm is the PM — or uses a third-party PM platform (Marqeta, Galileo, i2c) that abstracts the BIN sponsor relationship while still requiring the crypto firm to operate as an agent of the programme. The PM role is simultaneously the most powerful and most constrained position in the card stack: maximum flexibility over the user experience, minimum control over the underlying rails.

PM Platform APIs: The Technical Interface

Modern PM platforms expose REST APIs for the core card management operations. The crypto firm integrates against these APIs to issue cards, configure spending controls, and receive real-time transaction webhooks. The critical integration point for crypto-specific behaviour is the Just-In-Time (JIT) funding API — a webhook fired at authorisation time that allows the crypto firm to approve or reject the transaction and provide the exact fiat amount needed for settlement. JIT funding is the mechanism that enables real-time crypto liquidation on card spend.

// JIT Funding webhook fires when cardholder taps card at POS
// Crypto PM has ~1500ms to respond before network timeout

// INCOMING REQUEST from PM Platform (webhook):
POST /jit-funding
{
  "token": "txn_9f3a2b...",
  "user_token": "usr_kk82...",
  "amount": 87.50,
  "currency_code": "USD",
  "merchant": {
    "name": "Whole Foods Market",
    "mcc": "5411",           // Grocery stores
    "city": "Singapore",
    "country": "SGD"
  },
  "type": "authorization",
  "card_token": "card_mn71..."
}

// CRYPTO PM INTERNAL PROCESSING (~200-400ms budget):
async function processJIT(request) {
  const user = await getUser(request.user_token);
  const balance = await getCryptoBalance(user.id);          // USDC balance
  const fxRate = await getFXRate("USDC", "USD");            // ~1.0 for USDC
  const usdcNeeded = request.amount / fxRate;
  const available = balance.usdc_balance * fxRate;

  // Spending controls check
  if (request.mcc in user.blocked_categories) {
    return { result: "DECLINED", memo: "Merchant category blocked" };
  }
  if (request.amount > user.daily_limit_remaining) {
    return { result: "DECLINED", memo: "Daily limit exceeded" };
  }
  if (available < request.amount) {
    return { result: "DECLINED", memo: "Insufficient balance" };
  }

  // Reserve the funds (do NOT liquidate yet — wait for capture)
  await reserveBalance(user.id, usdcNeeded);

  return { result: "APPROVED", amount: request.amount };
}

// OUTGOING RESPONSE to PM Platform:
{ "result": "APPROVED", "amount": 87.50, "memo": "JIT funded" }
// Response must arrive within 1500ms or the transaction auto-declines

A card transaction that completes in under a second involves a sequence of network hops, protocol translations, authorisation decisions, and database writes that most end users never see. Understanding the authorisation flow is essential for engineering the crypto PM layer correctly — and for diagnosing the inevitable production incidents.

T+0ms    CARDHOLDER taps card / chip at merchant POS terminal

T+5ms    POS TERMINAL reads EMV chip data (card number, expiry,
         cryptogram) via NFC/contact interface

T+10ms   ACQUIRER PROCESSOR receives ISO 8583 authorisation request
         message from POS terminal; routes to Visa/Mastercard network
         based on BIN range

T+40ms   CARD NETWORK (Visa VisaNet / Mastercard Banknet) receives
         authorisation request; checks:
         ● BIN ownership → routes to issuer processor
         ● Basic network-level fraud rules (Visa Advanced Auth / MC Expert)
         ● EMV cryptogram validation (card present authentication)

T+60ms   ISSUER PROCESSOR (e.g., Marqeta, Galileo, i2c) receives
         authorisation request; fires JIT webhook to crypto PM layer

T+70ms   CRYPTO PM LAYER receives JIT webhook; checks:
         ● User balance (USDC / BTC / ETH)
         ● Spending controls (daily limit, MCC restrictions, geo blocks)
         ● AML transaction screening
         ● FX rate for conversion estimate
         ● Reserves/pre-funds fiat equivalent

T+250ms  CRYPTO PM responds to JIT webhook: APPROVED / DECLINED

T+270ms  ISSUER PROCESSOR receives JIT response; applies additional
         issuer-level fraud rules; forms ISO 8583 response message

T+290ms  CARD NETWORK receives issuer response; logs transaction;
         returns authorisation response to acquirer

T+310ms  ACQUIRER PROCESSOR receives network response; forwards
         to POS terminal

T+350ms  POS TERMINAL receives response; displays APPROVED or DECLINED
         to cardholder and merchant

────────────────────────────────────────────────────────────────
NOTE: Actual timings vary by region, terminal type, and network
      load. Contactless typically faster than chip+PIN.
      Online purchases (card-not-present) follow the same
      logical flow but without the EMV cryptogram step.

Authorisation vs Clearing vs Settlement: Three Distinct Events

A card transaction is not a single event — it is three distinct events that can be separated by hours or days, and each has different implications for the crypto PM's balance management.

The FX conversion architecture is where crypto card programmes diverge most significantly from traditional debit card programmes. Traditional debit draws from a fiat bank account — no conversion required. Crypto debit must convert digital assets to fiat in a window that is either tightly constrained (real-time conversion at authorisation) or designed to absorb conversion timing risk (pre-funding). Each approach has distinct trade-offs in latency, cost, complexity, and user experience.

Settlement Pre-Funding: The Liquidity Mechanics

// Pre-funding requirement at BIN sponsor settlement account
// Must maintain sufficient fiat to cover T+1 and T+2 settlement batches

daily_spend_avg   = Σ(authorised_amounts_per_day)
settlement_window = 2 days                         // T+2 settlement lag

base_prefund      = daily_spend_avg × settlement_window
volatility_buffer = daily_spend_avg × 0.30         // 30% buffer for spend spikes
dispute_reserve   = total_outstanding × 0.008      // 0.8% chargeback reserve

min_prefund_balance = base_prefund + volatility_buffer + dispute_reserve

// Example: $500k daily spend average
// base_prefund      = $500k × 2    = $1,000,000
// volatility_buffer = $500k × 0.30 = $150,000
// dispute_reserve   = $30m × 0.008 = $240,000
// min_prefund       ≈ $1,390,000

// This capital is idle — a direct cost of capital for the programme
// Programmes at $100M+ daily volume maintain $200M+ in prefunded fiat
// This is why large crypto card programmes require significant balance sheets

Cross-Border FX: Currency Conversion at the Card Network Layer

When a cardholder spends in a currency different from the card's base currency (e.g., a USD-denominated card used at a EUR-priced merchant), a second layer of FX occurs at the card network level. Visa and Mastercard apply their own currency conversion rates — typically benchmarked to wholesale FX with a 1–3% margin added — and pass the converted amount to the issuer for settlement. The crypto PM must account for both the crypto-to-fiat conversion spread and the card-network FX markup when quoting foreign transaction fees to cardholders.

Some programmes offer “no foreign transaction fee” by absorbing the network FX markup (monetising via wider crypto conversion spreads). Others charge explicit foreign transaction fees of 1–3%. The choice affects customer acquisition (no-FTF is a strong marketing claim) and programme economics (absorbing network FX markup compresses margin on every international transaction).

Crypto debit card programmes operate at the intersection of two regulatory regimes that were not designed to interact: traditional card network compliance requirements (PCI DSS, network operating rules, chargeback rules, anti-money laundering for card issuers) and crypto-specific regulatory requirements (VASP registration, travel rule compliance, DeFi exposure policies, on-chain transaction monitoring). Engineering both simultaneously — without violating either — is the most underestimated challenge in building a crypto card programme.

The Five Compliance Layers

The card infrastructure market has consolidated significantly since 2018. A handful of platform providers now handle the BIN sponsorship, processing, and programme management layer for the majority of new fintech card programmes — including crypto programmes. The build vs buy decision at each layer is consequential: building too much creates regulatory exposure and operational overhead; buying too much creates vendor dependency that can constrain the programme at scale.

Programme Launch Phases: A Realistic Timeline