Skip to main content
Commerce Security Authority
Category: Cardholder Data

Account Range

Also known as: BIN Account Range
Simply put

An account range is a defined block of payment card numbers, based on the leading digits of the card, that identifies which issuer and card product a card belongs to. Card networks such as Visa and Mastercard maintain and publish this assignment information so that parties in the payment ecosystem can correctly route and process transactions. Because the range is derived from the beginning digits, every card falls within some account range.

Formal definition

An account range is a contiguous span of payment card numbering space, typically defined by the leading digits of the Primary Account Number (PAN), used to associate a card with a specific issuer, card product, and processing attributes. Per Mastercard's documentation, account ranges are defined on the first 11 digits of a card, with Bank Identification Numbers (BINs) — the first six to eight digits — falling within an account range; thus multiple BINs may map into or under a single account range. Networks distribute this data through account range tables (for example, the Simplified BIN Account Range Table) that provide current assignment information to ecosystem participants for routing, product identification, and related processing decisions. Note that these leading digits form part of the PAN, which is cardholder data under PCI DSS; the account range itself is a classification construct and is distinct from sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks. Numbering formats and assignment practices are defined by each card brand and may change, so implementers should confirm structure against current network specifications.

Why it matters

Account ranges are foundational to how payment transactions are routed and processed. Because the leading digits of a Primary Account Number (PAN) determine which issuer and card product a card belongs to, ecosystem participants rely on accurate account range data to send each authorization request to the correct network and issuer, to identify the card product for pricing and eligibility decisions, and to apply the appropriate processing rules. Errors or stale data in this mapping can cause misrouting, declined transactions, or incorrect product identification.

Card networks such as Visa and Mastercard maintain and publish this assignment information — for example through the Simplified BIN Account Range Table — precisely because the mapping changes over time as issuers are assigned new numbering space and as network numbering practices evolve. Participants that route, switch, or classify transactions depend on keeping their account range tables current; using outdated assignment data may lead to processing decisions based on incorrect issuer or product attributes.

It is important to note that the account range is a classification construct derived from the leading digits of the PAN. Those leading digits are part of the PAN, which is cardholder data under PCI DSS, so systems that store, process, or transmit full PANs remain in scope for the relevant controls. The account range classification itself is distinct from sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks, which must not be retained after authorization.

Who it's relevant to

Payment Processors and Acquirers
Processors and acquirers use account range data to route authorization requests to the correct network and issuer and to identify card products for pricing and processing decisions. Keeping account range tables current is essential, since assignment information changes over time and outdated data can lead to misrouting or incorrect product classification.
Merchant and Payment Engineering Teams
Engineers building payment integrations rely on account range and BIN data to identify card products and apply the correct processing logic. They should confirm numbering structure against current network specifications, and remember that the leading digits are part of the PAN — cardholder data under PCI DSS — so systems handling full PANs remain in scope for the relevant controls.
Compliance and Data Governance Teams
Compliance teams should distinguish the account range as a classification construct from the underlying PAN it is derived from. While the account range itself is used for routing and product identification, the PAN is cardholder data and is distinct from sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks, which must not be stored after authorization.
Fraud and Risk Analysts
Analysts may use account range and BIN information to identify the issuer and card product associated with a transaction as one input to risk assessment. Because network assignment data changes and varies by brand, analysts should treat account range attributes as one signal among many rather than a definitive control, and confirm data against current network sources.

Inside Account Range

Issuer Identification Number (IIN/BIN)
The leading digits of a payment card number that identify the issuing institution and card product. An account range is defined by a span of these leading digits, historically six digits and now commonly eight digits following industry moves to longer IINs.
Range boundaries (low and high values)
A pair of numeric endpoints that delimit which account numbers fall within a given range. Routing, product, and processing rules are associated with the range rather than with each individual account number.
Associated routing and product metadata
Attributes tied to a range such as card brand, product type, funding source, country, and processing rules. These attributes drive authorization routing and acceptance decisions and are distinct from the account number itself.
Relationship to the full account number
An account range describes a segment of the numbering space that contains many possible primary account numbers (PANs). The PAN is cardholder data; the leading digits that define a range are a portion of that PAN and should be handled according to the applicable data-protection controls.

Common questions

Answers to the questions practitioners most commonly ask about Account Range.

Is an account range the same thing as a BIN?
Not exactly. The term BIN (Bank Identification Number) historically referred to the first six digits of a PAN, while account range refers to a defined span of PAN values (typically expressed as a low-to-high range) that identifies the issuer and product. As card networks expanded identification to eight digits, account ranges became the more precise construct used in routing and product identification tables. Treating a BIN and an account range as interchangeable can lead to errors when the identifying digits and the range boundaries do not align.
Does an account range reveal the full cardholder account or expose sensitive data?
No. An account range identifies a segment of issuer/product number space, not a specific cardholder account. It does not by itself constitute sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks, which must not be stored after authorization. However, when an account range is used alongside a full PAN, the PAN remains cardholder data subject to PCI DSS protection, masking, and truncation controls; the account range designation does not change how the PAN itself must be handled.
How should we source and maintain account range data in our systems?
Account range data is typically distributed by the card networks and updated on their published schedules. Implementations generally consume these updates through processor or network-provided files and load them into routing and product-identification tables. Because ranges are added, split, or reassigned over time, teams should establish a defined update cadence and validate that stale ranges do not cause misrouting. Confirm current formats and distribution mechanisms against your network and processor documentation rather than assuming a fixed structure.
How do account ranges affect PCI DSS scope in our environment?
An account range reference on its own is not cardholder data, but systems that store, process, or transmit full PANs alongside range lookups remain in scope. Whether a component is in scope depends on the actual data it handles and how it is segmented, not on the presence of range tables. Techniques such as truncation, masking, tokenization, or encryption may reduce scope depending on implementation and validation. Confirm scoping decisions against the current published PCI DSS rather than assuming a specific requirement number, as numbering and wording differ between versions.
How do we handle the transition from six-digit to longer account range identifiers?
Systems that assume a fixed six-digit identifier may misclassify or misroute transactions when longer identifying digits are in use. Implementations should parse account ranges using the full range boundaries provided by the network rather than truncating to a fixed length. Test routing, product identification, and any downstream logic against ranges that require the longer identifiers, and confirm supported formats against current network documentation.
What can go wrong if account range tables are outdated or incorrectly matched?
Stale or mismatched account range data can cause transaction misrouting, incorrect product or issuer identification, and errors in downstream logic such as fee assignment or eligibility checks. Because such logic may feed fraud screening, inaccurate range matching can contribute to false positives or false negatives in those adjacent controls. Establish validation and update processes, and treat range-based classification as one input among several rather than a definitive control.

Common misconceptions

An account range is the same as a BIN and the two terms are interchangeable.
A BIN/IIN identifies an issuer or product via leading digits, while an account range describes a bounded span of account numbers that may map to specific routing and product rules. Ranges are often defined using IIN values but are a distinct concept, and longer IINs have changed how ranges are expressed.
Because the leading digits of a PAN are not the full number, they are not cardholder data and fall outside data-protection controls.
The PAN is cardholder data under PCI DSS. Whether a partial value such as leading digits triggers a control depends on how much of the PAN is exposed and how it is masked, truncated, or otherwise handled. Truncation, masking, and full PAN storage have different implications, and the effect on scope depends on implementation and validation rather than the label alone. Confirm handling against the current published standard.
The range metadata alone determines whether a transaction is legitimate.
Account range attributes support routing and acceptance decisions but do not authenticate the cardholder or confirm the transaction is genuine. Fraud controls such as EMV chip authentication, 3-D Secure, and other checks address different risks at different points and are governed by separate standards and network rules; range data may inform, but does not by itself mitigate, fraud.

Best practices

Maintain account range tables from authoritative sources and update them to accommodate longer IINs, since assumptions about six-digit prefixes can misroute or misclassify transactions.
Treat the PAN, including its leading digits, as cardholder data and apply masking or truncation according to your documented data-protection controls, confirming requirements against the current published PCI DSS rather than a fixed requirement number.
Do not store sensitive authentication data such as full track data, card verification values, or PIN blocks after authorization, even when encrypted, regardless of any range-based processing logic.
Keep range-based routing and product logic separate from fraud-decisioning logic, and document which attributes drive routing versus which inform risk assessment.
Validate that any truncation, masking, or tokenization applied around range data is verified in practice, since the effect on PCI DSS scope depends on implementation, not on the terminology used.
Coordinate with acquirers, processors, and card brands when interpreting range attributes, and confirm that routing and acceptance rules reflect current, region-specific network rules that can change over time.