What if you could get a complete dataset without taking on the compliance liability, facilitating the switch from 6- to 8+ digit BINs, or sifting through inaccurate information?
We've previously discussed Durbin 2.0's very clear intent to give merchants Debit Routing choices. In the recent Visa and Mastercard mega merchant settlement, the anticipated savings of $30B to merchants due to reduced swipe fees got a lot of attention. However, this almost overshadowed a more significant shift - the ability for merchants to steer their customers to the merchants' preferred payment methods and place a surcharge (or discount) on purchases made with specific card types. Merchants now have the option to apply surcharges on certain cards and can charge consumers more depending on the type of card they're using.
Both of these are powerful market forces attempting to give merchants more control over their payments. But there is a gap. While well-intentioned, we believe both attempts miss the mark in digital payments.
Why?
In an effort to avoid onerous PCI obligations, most merchants often just store a token of the card. They work with PSPs that provide a PSP-specific token that obfuscates the PAN, which blocks the merchant from the additional information they could have gleaned from it.
While effective in helping create sleek card-on-file experiences while maintaining a secure posture, Card Tokens mask the card's details. In the Card-Not-Present (CNP) world, merchants must decode the raw PAN (16-digit card number) to understand the card attributes.
However, most card-not-present merchants don't have the raw card numbers, or the full PAN.
PAN vs BIN Lookup
But why do merchants need the full PAN, you ask. They already have the BIN Lookup and have had it for years. They can get the card attributes from there. What are they going to achieve from looking up the full PAN that they can't get from the BIN Lookup?
Hold on to that thought.
BIN Attributes vs PAN Information
As the diagram shows, merchants have historically worked with a 6-digit BIN lookup and built sophisticated BIN mapping logic. CNP Merchants would often store cards in the 6+4 format. This meant merchants would store the first 6-digits of the card (the BIN) in addition to the last 4 (personal identifier).
When a network assigns an issuer a BIN range, networks and issuers populate the PAN range file (or the ARDEF file as Visa calls it). The BIN gives merchants a basic list of attributes that cover:
- Network (card brand)
- Card type (debit, credit)
- Prepaid card type (eg: reloadable, non reloadable)
- Issuing bank
- Issuing country code
- Card category (business, personal)
- Issuing country
- Maximum PAN length (16 or 19)
- Regulated vs non-regulated bank (from banks with assets of over or under $10 Billion)
While these attributes likely provide sufficient information to allow merchants to steer customers to preferred payment instruments or decide which cards should have premiums (“surcharge”) based on their interchange rates (which are typically higher for rewards cards), there are some issues:
Most important
- Debit Routing Affiliated Networks (eg: Star, Pulse)
- Billing Currency (eg: USD, Yen)
- Prepaid Card Sub-Type (eg: Reloadable vs non reloadable)
- Currency Minor Digits (eg: decimal point precision on exchange rate)
- Savings or Checking Account
- Prepaid Card Type (eg: Reloadable, non reloadable)
- Prepaid Subtype (eg: Brazil Cargo, Meal Voucher)
- Gaming Payout (i.e. allowed or not; useful for Gaming-related companies)
This is particularly helpful for large enterprise merchants since Currency and Debit Routing Network are two examples of fields only available with the full PAN.
Changing BIN Requirements
Merchants cannot continue with 6-digit BINs indefinitely. Issuers are moving to 8+ digit BINs, and going all the way to 11 in select countries.
If a card uses 8+ digit BINs, the existing 6-digit BIN lookup will no longer be sufficient.
In fact, if the issued card now had an 8+ digit BIN and merchants do a lookup with a 6-digit BIN construct, they will either get wrong or incomplete information.
Merchants who deal in tokens will suddenly lose significant data fidelity. The images here shows the different fields returned for 6+ digit lookup and highlights how data returned can be incredibly inaccurate. In this example, a 6 digit lookup for a 9 digit BIN would get a "Visa Credit Platinum card from Australia" - which is actually a "Visa Debit prepaid reloadable from the US."
Incomplete Information
Whether the BIN is 6 digits, 11 or somewhere in between, it doesn't show the account range.
- Assume Visa assigned a large bank (e.g. Chase) an account range from 4441-1100-0000-0000 to 4441-1199-9999-9999.
- Chase can reassign or resell a small portion of the account range from 4441-1100-8888-8888 to 4441-1199-9999-9999 to another issuing bank that can offer this as BIN sponsorships to a fintech.
Looking at just the BIN wouldn't provide the information of the actual issuing bank, and make for an inaccurate lookup.
Ok, so the full PAN gives me more information than a BIN Lookup. But what are the PCI-DSS implications?
Before we talk about securely handling PANs, let's discuss any BINs longer than the 6-digits that merchants handle today. Longer 8+digit BINs are even more complex for merchants to handle from a data security and PCI compliance standpoint. Migrating to these introduces a new layer of complexity to PCI compliance because:
- PCI rules will prevent merchants from holding 10 BIN + Last 4. For instance, PCI DSS Requirement 3.3 requires that no more than the first six and/or last four digits of the PAN are displayed on computer screens, reports, etc. unless there is a documented business justification for seeing more digits.
- At the same time, PCI DSS Requirement 3.4 specifies four acceptable methods for rendering PAN unreadable when stored, one of which is truncation, as discussed in the call-out above. As the length of the BIN expands to 8 and beyond, merchants will need to rework routing systems and update their infrastructure to secure card data to protect their customers while staying compliant with PCI DSS.
Changing BIN Length
Card numbers have been typically retained in truncated form as a 6-digit BIN and the last 4 digits of the card number for 16—or 15-digit PANs from Visa, Mastercard, Discover, American Express, JCB, UnionPay, and others. However, card networks have realized that the popularity of cards and a growing number of issuers, including fintechs, meant that the number of desired cards would soon exceed the number of available combinations. This necessitated a move to longer BINs, starting with 8 digits. Visa and Mastercard committed to 8-digit BINs in April 2022, rapidly continuing the transition.
So what do we suggest?
Situation Today
Our position is that a PAN Lookup is more valuable than the standard BIN Lookup. A PAN Lookup maximizes the card attributes you can get access to, making for stronger business decisions on needle-movers like the currency, exchange rate, debit routing networks and gaming payouts.
Plus, BINs are fundamentally changing by getting longer. Even if they weren't, just BINs do not indicate the account range as we saw above, making these as an inaccurate source of information. Trying to accommodate a lengthening BIN is a slippery slope where you create security and compliance risks.
Finally, if you don't hold the PAN, and instead get your tokens from your PSPs, they may not be fully aligned with your business objectives. PSPs extract a lot of value from having routing decisioning authority. They may not be overly eager to provide the decoder ring that informs you to route away from them.
Our Solution
VGS solves all these issues by holding the full 16-digit card information.
Our Card Attributes product lets merchants query and hold important attributes such as the affiliated network associated with the card (in support of Durbin 2.0) and the card type (to enable surcharging) - while the merchant still maintains only tokens.
By using the full PAN, while still not being liable for holding sensitive data, merchants can enable several key business decisions:
- Intelligent Payment Orchestration: Payment routing for faster authorization and lower costs using card-specific data
- Subscription Payment Management: Identify non-reloadable prepaid cards to optimize subscription payment flows and minimize failed retries
- Advanced Fraud Detection: Using BIN data and other risk factors
- Streamlined Transaction Troubleshooting: Using additional BIN data fields and card attributes
- Future Proofing: Get continuous access to card attributes for decision-making regardless of the BIN length requirements today and in the future
Takeaway
You've probably heard about BIN lookup, but a full PAN lookup gives you the most complete and accurate set of card attributes. Instead of committing the extra time and resources and coming into PCI scope to accommodate the inevitable longer BINs, you could store and have access to the full PAN and use any attribute you desire to make informed payment decisions.
Working with a third-party tokenization provider like VGS would:
- Securely provide the PAN for access to enriched card data
- Free you from chasing a moving target for BIN length requirements now and in the future
- Keep you out of increased PCI compliance scope from managing longer BINs
