What are 8 Digit BINs?

When the card networks expanded Bank Identification Numbers (BINs) from six digits to eight in April 2022, the industry's supply of unique identifiers jumped from roughly 100,000 to 10 million, and most of what was written about the change has been gathering dust ever since. 

That's a problem, because the PCI rules governing how you mask and store those digits have been rewritten, and fraudsters have turned BIN ranges into one of the busiest attack surfaces in payments, with an estimated 62 million Americans affected by credit card fraud in 2024 alone. 

Let's look at what 8-digit BINs are, what PCI DSS v4.x actually permits, and how to turn BIN data from a compliance chore into a routing and fraud-fighting advantage.

What 8-digit BINs are and why the industry needed them

A Bank Identification Number (BIN), also called an Issuer Identification Number (IIN), is the opening run of digits on a payment card that identifies the bank that issued it. For decades the first six digits did the job, but the fintech boom minted new issuers faster than a six-digit namespace could absorb them, so the International Organization for Standardization revised its numbering standard (ISO/IEC 7812-1) and the major card brands committed to 8-digit BINs starting in April 2022. The arithmetic explains the urgency, since moving from six digits to eight is the difference between a small town's phone book and a continent's.

The transition was designed as a long coexistence rather than a hard cutover. Visa has only assigned 8-digit BINs to new issuer requests since its April 2022 release, existing 6-digit BINs remain valid, and Mastercard has never set a sunset date for them. Four years on, both formats circulate side by side, nobody's card got reissued over it, and the PAN printed on yours is still 16 digits. What changed is how much of that number means "bank" and how much means "you."

What the change means for merchants

If you're worried about transactions breaking, relax. The full card number still travels to your PSPs, gateways, and receivers exactly as it always has, so the 6-versus-8 distinction has no effect on how payments move through an open payments platform. The action is all in BIN analysis, the practice of reading those opening digits to learn the issuing bank, country, and card type so you can make smarter decisions about routing, retries, and risk.

Here's where this refresh earns its dateline. The original version of this post explained that Spreedly returns the card's first_six_digits along with a newer issuer_identification_number field carrying the maximum digits PCI allows, and that the analysis was your job from there, probably involving a third-party BIN lookup service and a subscription someone forgot to cancel. Both fields still exist, and merchants who'd rather not consume the newer one yet can have it disabled per environment.

The better answer now is BIN Metadata: Spreedly maintains an internal database, refreshed monthly, that supports BINs up to 11 digits and returns up to 13 decoded attributes per BIN (card brand, issuing bank, issuing country, card type, and more) automatically on API and iFrame responses, available with Advanced Vault enabled at the organization level. You can feed those attributes straight into routing rules inside a workflow, which turns the BIN from a homework assignment into a decision your platform makes for you.

PCI DSS v4.x rewrote the rules for masking and truncation

The 2023 version of this post described PCI requirements that have since been retired with full honors. PCI DSS v4.x is now fully in force, including the future-dated requirements that came due on March 31, 2025, and the two requirements that touch BINs were renumbered and rephrased along the way. Masking now lives in Requirement 3.4.1, which limits what appears on screens and reports to the BIN and last four digits unless there's a documented business justification for seeing more. Storage protection lives in Requirement 3.5.1, which governs how you render the PAN unreadable when it's kept on disk.

Truncation, one of the accepted methods for doing that, got the headline update. Under the PCI SSC's acceptable truncation formats (FAQ 1091), a 16-digit PAN may now be stored as "first 8, any other 4," so the test card 4012 8888 8888 1881 can legitimately live in your database as 40128888xxxx1881, while shorter PANs keep their older formats.

And here's the caveat that deserves to be printed on a coffee mug: if you retain the full 8-digit BIN plus the last four, truncation alone no longer counts as adequate protection, and you'll need at least one additional method layered on top, such as encryption, hashing, or tokenization. The standard tightened hashing itself too, since every hash generated after March 31, 2025 must be a keyed cryptographic hash under Requirement 3.5.1.1. One more trap worth knowing about: when different systems hold differently truncated versions of the same PAN, you have to ensure nobody can correlate them, because two puzzles with different missing pieces can complete each other.

The pattern running through all of this is consistent. The rules became more generous about which digits you may keep and stricter about how you keep them, which is precisely the problem a universal vault exists to solve. If your PCI scope is making your auditor's eye twitch, our PCI compliance checklist and our breakdown of PCI DSS v4.0 cover the wider standard in detail.

BIN attacks turned card numbering into a fraud surface

The original post treated BINs as plumbing, and in 2023 that was a fair characterization. Since then, fraudsters have turned the predictability of BIN ranges into a business model. In a BIN attack, criminals take a known BIN, use software to generate thousands of candidate card numbers within that range, and brute-force the remaining variables (expiration dates and CVVs) by firing small authorization attempts at merchants until something sticks. It differs from classic card testing, which validates details from a single stolen card, because a BIN attack manufactures its own inventory. The scale has grown sobering, with some industry estimates attributing up to 80% of card fraud to BIN-based attacks.

The encouraging part is that the same intelligence powering your routing also powers your defense. Knowing instantly that a card is a prepaid product from an issuer in a country you've never shipped to is exactly the kind of signal a fraud and authentication layer is built to act on, and decoded BIN attributes give your risk rules something far sharper to chew on than raw digits.

The transition includes debit cards (and your local pharmacy)

Debit cards made the same move as their credit counterparts, expanding from six to eight digits under the same standard, so there's no separate timeline to track and no debit-specific exception to plan around.

The more entertaining proof of this transition's long tail comes from an unexpected counter: the pharmacy. In 2025, the Centers for Medicare & Medicaid Services published a rule updating the NCPDP Telecommunication Standard that pharmacies use to send electronic claims, expanding the processor ID field (which pharmacists also call a BIN) to accommodate 8-digit IINs by 2028.

Sit with that for a second. A numbering decision made by a standards body in 2017 will still be landing on systems at your local drugstore more than a decade later, like a glacier that started moving before your house was built and will arrive regardless of your renovation schedule. Long transitions reward infrastructure that absorbs change on your behalf, because the alternative is rewriting your own systems every time the glacier advances another field length.

Turn BIN data into an advantage

The 8-digit BIN transition is permanent, the compliance rules around it have matured, and the fraud stakes attached to it have risen, which makes this a fine moment to ask whether your payments stack hands you raw digits or real answers. The strongest position is one where BIN intelligence stays current without your team babysitting a lookup table, where your masking and storage practices already satisfy v4.x, and where the same decoded attributes feed both your routing logic and your risk rules. Talk to our payment orchestration experts to see how Spreedly keeps your BIN data fresh, your compliance posture tidy, and your engineers sane.