Quick answer: A BIN table is a reference database that maps the leading digits of a card number to the issuing bank, card brand, funding type, product tier, and available debit networks. It becomes valuable only when joined to your own authorization, settlement, and fee data. On its own it is a lookup file, not an asset.
The reference file everyone has and almost nobody uses
Ask a payments team whether they have a BIN table and the answer is almost always yes. Their acquirer sends one. The networks publish one. Someone downloaded a file eighteen months ago and parked it in a shared drive.
Ask the same team what that BIN table earned them last quarter and the room goes quiet.
That gap is the point of this piece. BIN data is not scarce and it is not hard to understand. What is hard is keeping it current, reconciling it against transactions that have already settled, and turning the result into a decision someone acts on. That is an operations problem rather than a data acquisition problem.
What is a BIN?
The Bank Identification Number is the leading set of digits on a payment card account number, and it identifies the institution that issued the card. BINs are assigned rather than random. The first digit indicates the network family, and the digits that follow map to the issuer and the specific card product.
One detail trips up older systems. The industry migrated from six-digit to eight-digit BINs, with Visa and Mastercard moving issuers and processors onto eight-digit support across 2021 and 2022. Any lookup rule, fraud check, or routing table still truncating at six digits is now collapsing multiple distinct card products into one record. The output looks fine and is silently wrong, which is the most expensive kind of wrong.
What does a BIN table contain?
A well maintained BIN record typically carries the following fields.
In practice, a single record looks something like this.
The last two rows deserve attention. Token eligibility and account updater coverage rarely appear in a standard BIN extract, and they are the attributes that tie BIN data to approval rates rather than only to routing cost. Every other field maps to a cost, a routing option, or a risk decision. None of them does anything while it sits in a file.
Three ways BIN data pays for itself
1. Routing debit at the right price
Regulation II prohibits issuers and networks from limiting debit transactions to fewer than two unaffiliated networks, and bars them from restricting a merchant's ability to direct routing. That right is only exercisable if you know, per BIN, which networks are actually enabled, and then compare realized cost across them. Teams holding BIN network availability alongside settled transaction cost can see what routing decisions cost them last month in dollars rather than in theory.
2. Validating that you were billed correctly
The regulated issuer flag on a BIN is a fee assertion. The US cap applies to issuers with $10 billion or more in consolidated assets, and smaller issuers are exempt. Under the current standard, a covered debit transaction's interchange is limited to 21 cents plus 5 basis points of transaction value, with a 1 cent fraud prevention adjustment for qualifying issuers. If your settlement file shows an unregulated tier fee against a BIN your table flags as regulated, that is either a data error or money you are owed.
3. Diagnosing declines by issuer instead of by guess
Authorization performance varies enormously by issuer, product tier, and geography. Aggregate approval rates hide this completely. Approval rate segmented by BIN attributes surfaces the exact issuer and product combinations where retries, network tokens, or account updater coverage would move revenue.
Here is what all three look like when BIN attributes sit next to settled transaction data.
The second row is the whole argument in one line. A BIN flagged regulated, billed at an unregulated rate, across a million transactions in a single month. The third row shows a downgrade pattern on commercial credit. The fourth carries no cost variance at all, yet its approval rate sits five points below a comparable regulated debit BIN, which is an authorization question rather than a pricing one.
None of that is visible in a BIN table. None of it is visible in a settlement report. It appears only when the two are held against each other, on a schedule, with someone accountable for the variance column.
Why most teams never get there
Four failure modes, in rough order of frequency.
The file goes stale. BINs are reissued, reassigned, and extended. A table refreshed quarterly is wrong somewhere by week three, and wrong in ways that quietly break routing rules and fee checks.
Sources disagree. Networks, acquirers, and third party vendors publish overlapping BIN data in different schemas, with different field names and different levels of granularity. Nobody owns reconciling them.
The transaction data lives somewhere else. Authorization data sits with the gateway, settlement with the acquirer, fees on a statement, refunds and chargebacks in a third place. The BIN table is the easy part. Assembling the transaction spine to join it to is the work.
The analysis is a one off. Someone builds the join in a spreadsheet, presents a finding, everyone agrees it matters, and it is never repeated because it took two weeks.
The pattern underneath all four is identical. BIN intelligence gets treated as a project instead of a pipeline.
The regulatory reason to build this now
The US debit economics that BIN tables encode are genuinely unsettled. The Federal Reserve has a pending proposal to lower all three components of the cap, to a base of 14.4 cents, an ad valorem component of 4 basis points, and a 1.3 cent fraud prevention adjustment, and to reset the cap every other year against issuer survey data. Separately, in August 2025 a federal district court in North Dakota vacated Regulation II in Corner Post v. Board of Governors, holding that the Fed exceeded its statutory authority, then stayed its own vacatur to avoid leaving interchange entirely unregulated while the Fed appealed. The appeal sits with the Eighth Circuit, with briefing completed in the first half of 2026.
Whichever way that lands, the fee tiers attached to your regulated flag BINs will move. Organizations already reconciling BIN attributes against realized transaction cost will detect the change within a settlement cycle and quantify it. Organizations relying on a quarterly acquirer report will find out considerably later, and will have to take someone else's word for the number.
How to operationalize BIN data
A working BIN practice has five properties.
- Ingested on a schedule rather than on request. Pull from the networks and your acquirers on their publication cadence, via SFTP, API, or webhook.
- Normalized to one schema. Resolve conflicting fields across sources with an explicit precedence rule, and retain lineage so you can explain any value later.
- Versioned. Store BIN attributes as they stood on the transaction date. Joining today's table to last year's transactions produces confidently wrong history.
- Joined to the full money lifecycle. Authorization, capture, settlement, fees, refunds, chargebacks. BIN attributes against authorization data alone answer risk questions but not cost questions.
- Wired to an owner. A variance nobody is accountable for is a report, not a control.
This is the layer Optimus was built for. Aggregating payment data across acquirers, processors, and gateways, normalizing it without engineering tickets, and reconciling fees and commissions against what was contractually owed is what makes BIN intelligence continuous instead of occasional. The BIN table becomes one more governed dimension on transaction data you already trust, rather than a file someone has to remember to download.
Frequently asked questions
1. What is a BIN table used for?
A BIN table is used to identify the issuing bank, card brand, funding type, product tier, issuing country, and available debit networks for any card presented for payment. Payment teams use it for least cost debit routing, interchange and fee validation, fraud screening, and authorization analysis segmented by issuer.
2. How many digits is a BIN?
BINs were historically six digits. Following the ISO driven expansion that Visa and Mastercard implemented across 2021 and 2022, they are now eight digits. Systems should handle both, because truncating an eight digit BIN to six collapses multiple card products into a single record and produces incorrect routing and fee logic.
3. Where should I get BIN data from?
The card networks and your acquirers are the authoritative sources. Third party BIN enrichment services are useful for filling coverage gaps, particularly for international issuers, but should sit below network and acquirer files in your precedence rules when fields conflict.
4. Is a BIN considered cardholder data under PCI DSS?
A BIN on its own is not a full primary account number and is not classified as cardholder data. However, BIN files are usually processed inside environments that already carry PCI DSS obligations, and BIN values often appear alongside truncated PANs and transaction records, so they should be governed under the same controls.
5. How often should a BIN table be refreshed?
Match your acquirer and network publication cadence, which is typically weekly or monthly, and automate the pull. BINs are reissued, reassigned, and extended continuously, so a table refreshed quarterly will be inaccurate in places within weeks, and those inaccuracies surface as broken routing rules and missed fee variances rather than as visible errors.
