A BIN range is a contiguous block of Bank Identification Numbers — the first six to eight digits of any payment card — allocated by Visa or Mastercard to a licensed Principal Member or sponsored programme manager. The range encodes issuer identity, card type, currency, and product tier before a single transaction is processed. This article examines the structure and lifecycle of BIN ranges, how card schemes allocate them, how fintechs gain access through sponsorship, the significance of the 2022 six-to-eight-digit expansion, and the regulatory obligations that attach to ownership of a range.
A Bank Identification Number (BIN) — formally defined as an Issuer Identification Number (IIN) under ISO/IEC 7812-1:2017 — is the leading numeric sequence of a payment card's Primary Account Number (PAN). Historically comprising the first six digits, the IIN uniquely identifies the institution that issued the card to a cardholder. A BIN range extends this concept: it is the ordered, contiguous block of IIN-prefixed PANs — for example, all card numbers from 476200 0000 0000 0000 through 476200 9999 9999 9999 — formally assigned by a card scheme to a single programme.
The term "BIN" has persisted in industry usage despite the ISO body's preference for "IIN," and both Visa and Mastercard continue to use BIN in their technical documentation. The distinction is worth noting for compliance purposes: when PCI DSS 4.0 (published March 2022) refers to "truncation" or "masking" of PANs, it references the IIN in the sense of ISO 7812. In practice the terms are interchangeable in programme management contexts.
A BIN range must be distinguished from a single BIN and from a sub-BIN. A single BIN is the specific six- or eight-digit prefix; the range is the full population of valid PANs beneath that prefix; and a sub-BIN (sometimes called a programme identifier or derivative BIN) is a narrower slice carved out of a parent range by a Principal Member and delegated to a programme manager or sponsored entity — covered further in section 02. The concept is also closely related to BIN sponsorship, the contractual mechanism by which a non-member institution gains access to an allocated range without holding direct scheme membership.
From a scheme-rules perspective, ownership of a BIN range carries hard obligations. The Principal Member to whom the range is assigned bears ultimate liability for every transaction processed under it — for chargebacks, fraud losses, settlement finality, and scheme-rule compliance. This is why the identity of the BIN owner matters profoundly in card-issuing structures: regulators and schemes treat the BIN owner as the accountable party, regardless of downstream commercial arrangements.
Scheme allocation. Visa and Mastercard each operate centralised BIN registries. A licensed Principal Member — a bank or electronic-money institution (EMI) holding direct scheme membership — applies to the scheme's member portal (Visa's BIN Manager or Mastercard's BIN table management tooling) for allocation of a new range. The application specifies product type (credit, debit, prepaid), currency, country of issuance, card-present/card-not-present capability, and whether 3-D Secure or tokenisation support is required. The scheme validates that the applicant holds the appropriate licence tier and sufficient settlement capacity, then issues a formal BIN allocation confirming the range, effective date, and product parameters. Allocations are recorded in the scheme's global BIN table, which is distributed to all acquirers and processors — this is how a merchant's acquirer knows, within milliseconds, which issuer to route an authorisation request to.
The six-to-eight-digit transition. For decades, ISO 7812 mandated a six-digit IIN. In practice this ceiling began constraining the supply of available BINs as the global number of card programmes multiplied. Visa announced the migration to eight-digit BINs in 2017, with Mastercard following. Both schemes completed mandatory industry adoption by April 2022. Under the expanded format, every issuer's six-digit BIN is logically "extended" — for example, a former BIN of 476200 becomes a family of BINs spanning 47620000 through 47620099. The transition required updates across the entire payments stack: processors, acquirers, merchants, and any system that performs BIN-table lookups had to expand their data fields and logic from six to eight digits. Card-not-present merchants that used six-digit BIN databases for fraud decisioning or routing were particularly affected. Programme managers launching new products after 2022 receive eight-digit allocations natively; existing six-digit allocations were grandfathered with scheme guidance on parallel operation.
Sub-BIN slicing for programme managers. A Principal Member holding a large BIN range typically does not use it for a single product. Instead, it partitions the range into sub-BINs — narrower prefixes differentiated by the seventh and eighth digits (under the eight-digit model) or by internal programme codes — and assigns each slice to a distinct programme. A corporate expense card programme might occupy one sub-BIN; a consumer prepaid programme another; a white-label partner's portfolio a third. The scheme recognises only the parent BIN; sub-BIN management is an internal affair of the Principal Member. This structure is central to how fintechs and payment companies participate in card issuing without needing their own scheme membership: a sponsor bank or EMI allocates a sub-BIN to the programme manager, who configures card products within that space. Processing rules, velocity limits, authorisation parameters, and spend controls can all be set at the sub-BIN level within the issuer-processor platform, enabling each programme to behave as a distinct product while sharing the parent institution's scheme relationship. See BIN sponsorship for the full contractual and regulatory breakdown of this arrangement.
PCI DSS scope. Any system that stores, processes, or transmits PANs bearing a BIN under a given programme falls within that programme's PCI DSS cardholder data environment (CDE). PCI DSS v4.0 (effective March 2024 for new requirements) requires that the first six digits and last four digits of a PAN are the maximum that may appear in plaintext in logs or displays; the intervening digits must be masked or tokenised. Because a BIN range defines the universe of PANs in scope for a programme, BIN-range ownership directly determines the boundary of the CDE — and therefore the scope of the annual Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) the programme manager and its principal must satisfy.
KYC and AML ownership. Under the EU's Sixth Anti-Money Laundering Directive (6AMLD) and the revised Payment Services Directive (PSD2), the regulated entity issuing a payment instrument — invariably the BIN owner or its licensed sponsor — bears the Customer Due Diligence (CDD) obligation. Where a programme manager operates under a BIN sponsorship arrangement, the Principal Member/EMI typically retains the obligation to approve the programme manager's KYC framework and may require pass-through access to cardholder data for SAR filing. Scheme rules (Visa Core Rules; Mastercard Rules) additionally require that BIN owners maintain records sufficient to identify the beneficial owner of any transaction processed under their range.
EMD2 / EMI licensing (EU). In the European Economic Area, issuing payment cards generally requires either a banking licence or an electronic money institution (EMI) licence under the Electronic Money Directive 2 (2009/110/EC), transposed nationally. The EMI is typically the entity that holds — or sponsors access to — a BIN range. Pan-EU passporting under EMD2 allows an EMI licensed in one member state to issue cards across the EEA without requiring local licences in each country served by the programme.
Obtaining a BIN range requires either direct Principal Membership of Visa or Mastercard, or access via a sponsored arrangement through an existing member. The two paths differ substantially in cost, timeline, regulatory burden, and operational control.
Principal Membership grants the institution its own seat at the scheme table: it can request BIN allocations directly, set its own product parameters without a sponsor's approval, settle directly with the scheme, and bear first-loss liability. The barriers are correspondingly high. Visa and Mastercard each require applicants to hold a qualifying banking or EMI licence in the target market, demonstrate minimum net settlement exposure capacity (often in the tens of millions of euros or dollars), pay annual scheme membership fees, and undergo a detailed technical certification process covering authorisation, clearing, and dispute management. Full principal membership from initial application to live processing typically takes twelve to twenty-four months. For most fintechs and payment companies, this timeline and capital requirement is prohibitive at launch.
BIN sponsorship is the practical alternative. A fintech or programme manager contracts with an existing Principal Member — a sponsor bank or licensed EMI — which allocates a sub-BIN from its own range. The sponsor remains the scheme-accountable party; the programme manager operates within the sponsor's BIN under a commercial and compliance framework negotiated bilaterally. Scheme rules require the sponsor to conduct due diligence on programme managers and to maintain oversight of card-programme activity — Visa's Third-Party Agent programme and Mastercard's Service Provider registration requirements formalise this obligation. For the programme manager, sponsorship dramatically compresses time-to-market (weeks rather than years), eliminates direct scheme capitalisation requirements, and delegates settlement infrastructure to the sponsor. The trade-off is dependency: the sponsor's risk appetite, fee structure, and product roadmap constrain what the programme manager can build. Choosing a sponsor with both Visa and Mastercard relationships — and with experience in the programme type (prepaid, corporate, crypto-linked) — is therefore a material commercial decision.
For crypto-native programmes, the BIN-range question intersects with an additional layer of complexity: on-the-fly conversion from digital assets to fiat must occur within the authorisation window — typically under two seconds — which requires tight integration between the BIN-level processing rules and the crypto conversion engine. This architecture is explored further in Codego's white-label crypto card documentation.
Codego operates as a European Banking-as-a-Service infrastructure provider, holding BIN sponsorship relationships with both Visa and Mastercard. This dual-scheme position — uncommon among mid-market sponsors — means programme managers launching through Codego's card-issuing platform can choose scheme, product type, and geography without switching infrastructure partners.
When a client onboards via the programme intake flow, Codego's team provisions a dedicated sub-BIN within days. Virtual cards are live within 24 hours of BIN provisioning; physical cards reach cardholders within 15 days end-to-end. Apple Pay and Google Pay tokenisation is provisioned within 24 hours of virtual-card activation, using the scheme's token requestor infrastructure bound to the allocated BIN. The self-service portal allows programme managers to configure spend controls, velocity limits, and MCC restrictions at the sub-BIN level without engineering tickets.
For crypto and stablecoin programmes, Codego's crypto card infrastructure handles on-the-fly conversion at the BIN level, ensuring that authorisation requests denominated in fiat are fulfilled from digital-asset balances within scheme-mandated response times. Codego's regulatory perimeter — operating under an NBB electronic-money distribution licence, with Codego Europe SIA in the EMI authorisation process and pan-EU passporting in place — means the BIN sponsorship carries a compliant KYC and AML framework across all 12 served countries. Clients requiring native IBAN issuance alongside their card programme can combine BIN-range access with SEPA and SEPA Instant account infrastructure through the same platform. Full platform capabilities are detailed at Codego White-Label Bank and Core Banking.