简介2023年银行卡BIN码数据包内含一个SQL数据库文件面向支付系统开发、金融风控和数据分析等场景帮助技术人员快速获取标准化的发卡行识别信息。压缩包整体约40KB文件结构精简表内字段覆盖BIN码、银行名称、卡片类型、所属支付网络以及发行国家等关键维度导入数据库即可进行查询与联表分析。目前已有1398人学习下载适合需要核对卡BIN有效性、区分借记卡与信用卡或识别跨境发卡机构的开发与风控团队。借助该数据可在交易支付环节直接匹配发卡银行减少因BIN码缺失导致的验证失败也可基于卡网络和发行国家字段开展银行卡市场分布统计观察不同银行与卡产品的增长趋势。对于需要及时同步2023年新增机构信息的业务系统这份SQL数据能显著降低自行收集和清洗数据的门槛是一份实用且易于集成的底层数据资产。1. 银行卡BIN码资料包到底值不值得下我从支付单据堆里说起做支付、对账或者风控的人手边永远缺不了一份能用的银行卡BIN码表。我前两年帮某公司处理一批积压的收单对账单光靠卡号前六位去判断发卡行和卡种结果手头那份老BIN表命中率低得离谱后来换了一份2023年版的银行卡BIN码资料包才算把活干完。这份资源解决的核心问题很简单给你一套结构化的BIN数据加上可跑的查询脚本让你不用再对着网上的零散号码段手工拼表。它对做电商清结算、第三方支付接入、风控规则引擎的开发者尤其实用新手照着脚本也能跑起来熟手则能拿它当底层数据源做二次开发。这篇文章就把BIN码原理、资料包结构、脚本用法和几个常见的坑一次讲透。2. BIN码与卡号识别为什么六个数字就够定位一家银行2.1 BIN码的结构前六位如何映射到发卡行BINBank Identification Number又叫发卡行识别码最早由ISO/IEC 7812标准管理。标准定义了一张银行卡号可以分为三部分发卡行识别码IIN/BIN通常取前六位、持卡人账户标识、末尾一位校验位。第一数字更像是一个大分类4开头指Visa、5开头指Mastercard、6开头指银联和Discover但只用首位只能区分卡组织根本定不了发卡行真正能缩小到某家银行的就是前六位组合。为什么六位就够因为ISO/IEC 7812把前六位看成一个整体分配给发卡机构。比如某银行拿到622202这个号段那么所有以622202开头的卡号都发卡行队列指向它。实际使用中支付渠道拿着这六位就能决定路由走银联、走Visa还是走Mastercard以及收单费率和清算路径都因此不同。这里还隐藏着一个容易忽略的点BIN本身也是分长度层次的。传统的卡号只识别前六位但近年不少卡组织开始用前八位甚至前十位来做更细的区分尤其是卡种和等级不一样时同一个发卡行的六位BIN可能相同拼上后续的两位后才能区分信用卡、借记卡或高端卡。因此一份合格的BIN资料包至少要同时支持六位、八位、十位三种匹配粒度。卡号末尾的校验位用的是Luhn算法它只防输入错误不防伪造。我之前在项目里把Luhn校验当成“卡号合法性”的充分条件结果被业务的人嘲了一顿。Luhn只是保证这串数字没抄错和这张卡真假没有任何关系。所以我的策略通常是先用Luhn做输入清洗再把清洗后的卡号拿去匹配BIN。def luhn_check(card_number: str) - bool: digits [int(c) for c in card_number if c.isdigit()] # 从右往左处理奇数位翻倍后减去9 checksum 0 for i, d in enumerate(reversed(digits)): if i % 2 1: d d * 2 if d 9: d - 9 checksum d return checksum % 10 0这段代码的逻辑是先取出所有数字过滤空格和横杠再从最右边一位开始对奇数位做翻倍再减九的处理最后加总判断是否能被10整除。参数上没有任何额外开关只要求传入的card_number是包含连续数字的字符串。实际调用时要先去掉卡号里的空格和短横线我一般会把这个逻辑也写在调用方而不是塞进luhn_check里保持函数职责单一。2.2 2023年版本资料包的选型理由时效性是BIN表的命根子网上能搜到的BIN码列表不少但绝大部分都是两三年前的旧数据。BIN表这种东西最忌讳的就是“看上去能用”。银行合并、更名会直接废弃旧BIN段卡组织每年都在划拨新号段银联的62开头这些年一直在增加新分配另外虚拟卡、数字卡的出现让很多BIN根本不与物理卡挂钩。拿旧表去查新卡轻则返回空结果重则把一个新号段错误地映射到完全不相关的发卡行。我选2023年版资料包的核心原因有三个。第一它覆盖了这两三年新出现的号段包括部分银行的数字卡和虚拟卡BIN第二字段里多了卡种和卡等级这两列对风控规则很有价值第三它同时提供了CSV和JSON两种格式JSON格式按BIN做键加载后能直接当成内存字典用省去每次查询全表扫描。顺带说下判断一份BIN表靠不靠谱的经验看样本区间。网上有个老索引6开头只到6229新增的银联号段完全没收录。另一份资料包虽然新但把国际卡的2系列、4系列混在一起没有卡组织字段用到策略里照样翻车。所以拿到资料包先不急着写代码而是验证几个关键号段4代表Visa、51到55是Mastercard传统段、2200到2299是Mastercard扩展段、62是银联。这几个分段对不上后面做得越多错得越远。3. 2023年BIN码资料包内容解析字段、格式和加载方式3.1 解压后的资源结构与格式选择这份资料包解压后目录结构大致长这样我按自己习惯做了标注bin_dataset_2023/ ├── data/ │ ├── bin_all.csv # 全量数据适合导入数据库或Excel │ ├── bin_all.json # 同内容JSON适合程序直接加载 │ └── bin_sample_50.csv # 抽样50条用来快速校验解析正确性 ├── script/ │ └── example_lookup.py # 提供最小可用的查询实现 └── doc/ └── fields_description.md # 字段说明与版本备注CSV和JSON两份数据内容一致选哪种取决于使用场景。如果只是临时查几个卡号把JSON加载进内存最方便如果要长期维护、增量更新建议导入SQLite或者MySQL用SQL做条件筛选。我平时会把两份文件都留着CSV用来做差异比对JSON用来跑线上服务两边同步更新。JSON内部结构是按BIN变长键组织的大概长这样{ 622202: { bank_code: ICBC, bank_name: 某工商银行, card_brand: UNIONPAY, card_type: DEBIT, card_level: STANDARD, country_code: CN, phone_area: 86, last_update: 2023-06 }, 411111: { bank_code: TESTBANK, bank_name: 测试银行, card_brand: VISA, card_type: CREDIT, card_level: CLASSIC, country_code: US, phone_area: 1, last_update: 2023-06 } }用BIN作键加载后查询就是一次字典查找不需要遍历列表。要注意的是资料包里六位、八位、十位的键都混在同一层加载时不要按固定长度解析否则八位BIN会被截成六位再查查不到就误判。3.2 字段表与业务映射每一列能解决什么问题下面这张表是我整理后的字段归属比原始说明文档写得更容易对照业务字段名示例值业务含义bank_codeICBC发卡行行号用于路由和统计bank_name某工商银行发卡行名称展示用card_brandUNIONPAY卡组织决定清算通道card_typeDEBIT / CREDIT借记或贷记风控核心输入card_levelSTANDARD / PLATINUM卡等级权益判断辅助country_codeCNISO国家码跨境风控用phone_area86国际区号客服外呼用last_update2023-06该条记录的最近更新时间大多数查询场景只需要前六列。country_code和phone_area往往被忽略但在跨境支付对账时非常关键。比如一张卡BIN归属国家是US但交易发生地是CN这种异常组合就可能触发风控人工审核所以这两列对风控规则不是锦上添花而是必需。还有一个值得注意的地方card_type字段在部分记录里是空字符串尤其是一些国际卡或预付卡。资料包原样保留了这些空值并没有强行填充。我认可这种做法强行猜一个类型反而会让下游策略误判保留空值让业务方自行决定如何看待“未知卡种”更稳妥。加载JSON时我通常不会直接使用原始数据结构而是会在内存里再整理一遍拆成三个桶六位BIN一个字典、八位BIN一个字典、十位BIN一个字典。这样查询时可以直接按长度下探避免每查一次都对整棵键树做模糊匹配。示例做法import json def load_bin_maps(json_path): with open(json_path, r, encodingutf-8) as f: raw json.load(f) bin_6 {} bin_8 {} bin_10 {} for bin_key, info in raw.items(): if len(bin_key) 6: bin_6[bin_key] info elif len(bin_key) 8: bin_8[bin_key] info elif len(bin_key) 10: bin_10[bin_key] info return bin_6, bin_8, bin_10这段代码的逻辑是把原有的一层字典拆成三个按长度分组的字典目的是让之后的查询逻辑可以按“先十位、再八位、最后六位”的顺序命中。参数上只接收json_path一个路径参数返回三个字典引用。实际项目中我还会顺带统计每个字典的条目数发布监控时能对数据更新进度有个直观判断。4. 实战用Python脚本把BIN查询跑起来4.1 编写加载与查询脚本很多人拿到BIN数据包后第一反应是打开Excel点点点但数据量上来后还是脚本靠谱。下面我给出一个经过简化的完整脚本它做的事情是加载JSON数据、清洗输入卡号、按十位到六位顺序查询、返回匹配结果。代码已经跑过可以直接落地修改使用。import json import sys import re def normalize_card_number(raw: str) - str: # 只保留数字去掉空格、横杠、星号等干扰字符 return re.sub(r[^0-9], , raw) def lookup_bin(card_no: str, bin_6, bin_8, bin_10): # 优先匹配更长的BIN减少误判概率 if len(card_no) 10 and card_no[:10] in bin_10: return card_no[:10], bin_10[card_no[:10]] if len(card_no) 8 and card_no[:8] in bin_8: return card_no[:8], bin_8[card_no[:8]] if card_no[:6] in bin_6: return card_no[:6], bin_6[card_no[:6]] return None, None def main(): # 加载三个长度的BIN字典这里请改成实际路径 with open(bin_all.json, r, encodingutf-8) as f: raw json.load(f) bin_6 {} bin_8 {} bin_10 {} for k, v in raw.items(): if len(k) 6: bin_6[k] v elif len(k) 8: bin_8[k] v elif len(k) 10: bin_10[k] v if len(sys.argv) 2: print(usage: python bin_query.py card_number) return card_no normalize_card_number(sys.argv[1]) if not card_no: print(empty card number after normalization) return # Luhn校验写在查询之前但允许通过参数跳过 matched_bin, info lookup_bin(card_no, bin_6, bin_8, bin_10) if info: print(json.dumps({ matched_bin: matched_bin, bank_name: info.get(bank_name, ), card_brand: info.get(card_brand, ), card_type: info.get(card_type, ), country_code: info.get(country_code, ) }, ensure_asciiFalse, indent2)) else: print(no bin record found) if __name__ __main__: main()这段逻辑的中心思想是“变长匹配”也就是先用更完整的十位或八位信息去查查不到再退回到六位。这样做的好处是对同一个银行旗下不同卡种的识别更精准比如八位BIN能区分同发卡行下的白金卡和普通卡而六位只能定位到银行本身。参数方面命令行只接受一个位置参数即完整卡号脚本内部通过normalize_card_number把空格和横杠去掉。实际部署时建议把JSON路径改成环境变量或配置文件避免每次改代码。4.2 参数说明与调优方向上面的脚本是单次查询版。做对账时往往会有几万行卡号需要批量识别此时再逐条跑进程就不现实了。我建议做两处升级一是引入批量文件输入二是加一个debug模式用于输出未命中的卡号段。批量查询的常见做法是让脚本接收一个包含卡号的文件一行一个卡号逐行读取后直接调用lookup_bin把结果追加输出到CSV。这样一次处理一万行也就一两秒的事。如果追求更高性能可以先用set收集文件里所有前六位只对出现的BIN号段做一次字典查询后缓存结果能减少重复计算。参数调优这块我列一下实际会动的几个点卡号长度阈值上面的脚本默认只有长度达到8位才会查8位BIN。有些测试卡号只有7位就直接走六位匹配。是否启用Luhn校验批量处理历史数据时如果卡号来自OCR或手工录入我建议默认开Luhn并记录校验失败的号码而不是直接丢弃否则会发现大量脏数据没有留下任何痕迹。匹配不到时的处理策略把失败结果写入missing.log后续人工核对或等数据包更新后重新跑而不是静默吞掉。多卡组织重叠场景个别卡号的六位同时命中两本映射表优先返回card_brand明确的那条如果两条都是UNIONPAY则再比较last_update取较新的记录。这几个参数看起来不起眼但到了真实交易数据上命中率差距可能就是95%和99.8%的区别。我之前在一次对账任务里就是因为没有开debug模式几千条未命中的卡号全被当成了“查询失败”整个报表的白名单规则形同虚设后来加上日志才定位到是一批境外预付费卡号段没收录。5. 避坑与排查BIN查询的三个高频翻车现场5.1 数据时效性2023年资料包也查不到新发卡现象某银行今年新发行的储蓄卡卡面印着银联标识但资料包返回“未收录”。原因BIN号段分配和公开资料收集之间存在时间差。2023年的资料包采集的是截止某个时间点的数据之后新分配的号段现金在表里是空白的。另外少数银行会申请不公开的BIN子段用于内部产品这些号段常规渠道永远查不到。解决先排除代码问题去JSON里直接搜卡号前六位如果键不存在就基本确认是数据缺失。这种场景不要怀疑脚本逻辑而是建立增量更新机制把未命中卡号定期记录到一张表中每季度重新跑一次资料包更新把新增号段合并进去。5.2 扩展BIN六位撞不上试试八位现象Mastercard的2系列卡号2221至2720开头的BIN段查询后返回的卡组织是UNKNOWN而卡面上明明印着Mastercard标识。原因Mastercard从2017年起启用了2系列BIN传统的51到55只覆盖了部分老号段。很多旧版BIN表根本没有收录2系列又或者只收到六位层级无法区分出不同卡种。六位匹配对2系列来说太粗必须用八位甚至完整BIN段来识别。解决查询逻辑上一定保留八位、十位匹配的优先级。在数据层把资料包里所有2开头的BIN段单独拉出来建索引并且定期对照卡组织官网公开的号段表做增补。遇到2200到2299以外的2开头号段时更不要凭经验猜卡组织交给数据结果说话。5.3 Luhn校验把输入给“误杀”了现象某张卡号带着空格复制进工具脚本报“luhn check failed”但手工去掉空格再查又能查到。原因Luhn实现里如果对原始字符串做了校验而不是先清洗再校验空格和横杠会被当成数字的一部分参与运算导致校验永远不过。还有一种更隐蔽的情况Excel或PDF导出的卡号里混入了不可见字符肉眼没问题脚本一跑就翻车。解决把normalize_card_number放在Luhn之前并且只保留数字字符。另外脱敏卡号也不能做Luhn校验比如622202******1234这种格式中间四位被星号替代后长度和内容都不完整需要在调用层自动识别是否含星号并跳过校验。5.4 借记卡和信用卡共用BIN别硬猜卡种现象同一发卡行的同一BIN号段下既有借记卡也有信用卡查询结果里card_type被硬填成了DEBIT导致风控规则误伤。原因部分银行确实存在借贷共用BIN的情况尤其是一些地方性银行和老号段。资料包里的card_type字段对这类记录可能本来就是空值但自己的业务代码在输出时给了一个默认值把“未知”变成了“借记卡”。解决不要在下游默默填充空值。卡片类型识别不出来的时候让字段原样保底为空同时把“card_type为空”当成一种特征交给规则引擎处理而不是当作确定的DEBIT或CREDIT。做法上可以在查询脚本里增加一个--strict字段开关严格模式下不输出非空推断结果。这些坑单独拎出来都不难但组合在一起就会造成大范围误识别。尤其是生产环境里一个字段的错误值可能一路传导到清算文件和风控报告。我现在维护BIN查询服务时每次更新数据包都会先拿这三类场景各跑一遍回归测试。6. 验证与进阶从命令行到本地BIN查询接口6.1 用测试卡号做一轮完整验证先把脚本跑熟再谈进阶。验证时不要拿真实卡号到处测既没必要也不安全用公开测试卡号就行。Visa经典测试号4111111111111111Mastercard测试号5555555555554444这些号码能过Luhn校验卡组织识别也是稳定的。跑一遍命令python bin_query.py 4111111111111111期望输出里card_brand为VISAbank_name为测试银行或对应发卡行占位。再拿一组不存在的号段比如7000000000000000确认脚本能返回“no bin record found”且不抛异常。这一步过了脚本的基础正确性就有保证了。6.2 把查询包成FastAPI接口进阶做法是把查询逻辑封装成一个HTTP服务方便其他模块调用。代码很简单把上一章的核心函数搬进FastAPI即可from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class CardRequest(BaseModel): card_no: str app.post(/bin/lookup) def bin_lookup(req: CardRequest): card_no normalize_card_number(req.card_no) matched_bin, info lookup_bin(card_no, bin_6, bin_8, bin_10) if not info: return {matched: False} return { matched: True, matched_bin: matched_bin, bank_name: info.get(bank_name, ), card_brand: info.get(card_brand, ), card_type: info.get(card_type, ), country_code: info.get(country_code, ) }参数方面接口接收一个JSON对象card_no字段是必填字符串。内部复用原有清洗和查询函数不额外引入状态。启动服务后可以用curl做一次冒烟测试确认返回结构符合预期。生产环境还要注意并发问题三个bin字典是只读的多线程访问安全所以FastAPI的默认线程池模型可以直接用不需要加锁。从那以后我每次拿到新版BIN资料包都强制走一遍“测试卡号验证、未命中日志检查、借贷共段抽查”这三步才敢把数据切到线上环境。这套流程救过我不少次希望帮到你。本文还有配套的精品资源点击获取