简介这份资源为银联官方2020年4月25日发布的银行卡BIN数据整理包面向支付系统开发、金融风控建模、银行卡识别与清算对账等场景的工程师与数据分析人员。原始数据已由作者整理为可直接导入的SQL文件共9868条记录字段涵盖银行卡BIN、BIN长度、发卡行、银行卡名称、银行卡类型及卡号长度等官方来源保证了数据的齐全与准确。压缩包共7个文件以5个xls表格和1个sql脚本为主另含少量系统隐藏文件整体约1.12MB体积轻便便于快速部署。其中xls按非标卡、农民工卡、跨行转账卡、单位结算卡及通用卡表分类呈现sql文件则方便直接入库使用。目前已有3491人学习下载适合需要权威BIN库支撑卡种识别、路由判断与数据校验的开发者参考使用。1. 银行卡 BIN 数据到底能干什么从支付路由到风控画像的底层逻辑很多做支付系统或风控引擎的同行第一次接触银行卡 BIN 数据时往往以为它只是一张“卡号前几位对应哪家银行”的对照表。直到某天线上出现一笔跨行交易路由失败或者风控规则把一批正常用户误杀才回头翻出这份 Excel 或 MySQL 表发现 BIN 段里藏着卡组织、卡种、发卡行标识这些决定交易命运的关键字段。银行卡 BINBank Identification Number就是卡号前 6 到 8 位它决定了这笔交易走哪条清算通道、适用什么费率、能不能享受某些银行的优惠活动。2020 年银联官方发布的这份 BIN 数据覆盖了当时国内主要商业银行和部分外资行的发卡段以 Excel 和 MySQL 两种格式提供适合做支付网关路由、收单风控、用户绑卡校验的团队直接落地。如果你正在搭建聚合支付系统、银行卡实名认证模块或者需要给风控规则补充卡维度特征这份资源能省掉大量手工整理和交叉验证的时间。但要注意BIN 数据不是静态的2020 年的快照放到今天用必须配合增量更新机制否则会出现“卡号识别为 A 行实际发卡行已变更为 B 行”的翻车场景。2. 拆开这份 BIN 资源Excel 与 MySQL 两种形态的选型与导入拿到一份 BIN 数据第一件事不是急着写代码查表而是先搞清楚它的字段结构和两种存储形态各自适合什么场景。Excel 适合做人工核对、小批量验证和规则配置前的抽样检查MySQL 适合线上服务实时查询尤其是 QPS 较高的绑卡接口和交易路由模块。这一章把两种形态的导入流程和字段含义拆开讲确保你拿到文件后能在一小时内跑通第一条查询。2.1 Excel 版字段解读与快速校验常见做法是先用 Excel 或 LibreOffice 打开文件看表头有哪些列。典型的 BIN 表会包含BIN 号6 位或 8 位、发卡行名称、发卡行标识码、卡种借记卡/贷记卡/预付卡、卡品牌银联/ Visa / Mastercard 等、卡号长度。有些版本还会带省份、城市、客服电话。打开后先做三件事确认 BIN 列没有前导零丢失Excel 默认会把 622202 这种数字当数值处理导致 062220 变成 62220检查是否有重复 BIN 记录看卡种字段的枚举值是否统一。如果发现 BIN 列被 Excel 自动转成科学计数法或去掉了前导零用下面这个 Python 脚本重新读一遍强制按字符串处理import pandas as pd # dtypestr 强制 BIN 列按字符串读取避免前导零丢失 df pd.read_excel(unionpay_bin_2020.xlsx, dtype{BIN: str, bin: str}) # 统一列名兼容不同版本的表头 df.columns [c.strip().lower() for c in df.columns] # 检查 BIN 长度分布正常应该是 6 或 8 print(df[bin].str.len().value_counts()) # 检查重复 BIN dup df[df.duplicated(subset[bin], keepFalse)] print(f重复 BIN 条数: {len(dup)}) # 导出干净 CSV 供后续导入 MySQL df.to_csv(bin_clean.csv, indexFalse, encodingutf-8)这段代码的关键参数是dtype{BIN: str}它告诉 pandas 不要对 BIN 列做数值推断。str.len().value_counts()用来快速判断数据质量如果出现长度 5 或 7 的记录说明源文件有截断或格式问题。重复 BIN 检查是为了避免后续查询时返回多条冲突记录线上路由如果命中重复 BIN可能随机选到错误的发卡行。2.2 MySQL 建表与批量导入线上服务用 MySQL 查 BIN表结构设计要考虑查询模式和更新频率。BIN 查询通常是等值查询WHERE bin ?所以 BIN 列必须建唯一索引或主键。卡种、卡品牌这些字段可以冗余存储避免联表。下面是一个经过生产验证的建表语句CREATE TABLE bank_bin ( bin varchar(8) NOT NULL COMMENT 卡号前6或8位, issuer_name varchar(64) NOT NULL COMMENT 发卡行名称, issuer_code varchar(16) DEFAULT NULL COMMENT 发卡行标识码, card_type tinyint(2) NOT NULL DEFAULT 0 COMMENT 0未知 1借记卡 2贷记卡 3预付卡, card_brand varchar(16) NOT NULL DEFAULT UNIONPAY COMMENT 卡品牌, card_length tinyint(2) DEFAULT NULL COMMENT 卡号总长度, province varchar(32) DEFAULT NULL, city varchar(32) DEFAULT NULL, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (bin), KEY idx_issuer (issuer_code), KEY idx_card_type (card_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT银行卡BIN对照表;主键直接落在bin上因为 BIN 本身唯一且查询频率最高。card_type用 tinyint 而不是 varchar是为了节省空间并加快风控规则里的枚举判断。updated_at字段在增量更新时非常有用可以追踪哪些 BIN 最近被修改过。导入时用LOAD DATA LOCAL INFILE比逐条 INSERT 快一个数量级但要注意 CSV 的编码和分隔符LOAD DATA LOCAL INFILE /path/to/bin_clean.csv INTO TABLE bank_bin FIELDS TERMINATED BY , ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 ROWS (bin, issuer_name, issuer_code, card_type, card_brand, card_length, province, city);如果 MySQL 报The used command is not allowed说明服务端没开local_infile需要让 DBA 在 my.cnf 里加local_infile1并重启。导入后跑一条验证查询SELECT bin, issuer_name, card_type FROM bank_bin WHERE bin 622202 LIMIT 1;返回结果里的issuer_name应该和 Excel 里看到的一致。如果查不到先确认导入时 BIN 有没有被当成数值处理导致前导零丢失。2.3 查询接口的缓存策略线上服务如果每次绑卡都查 MySQLQPS 一高数据库压力就上来了。常见做法是在应用层加一层本地缓存或 Redis 缓存key 用 BIN 号value 存发卡行和卡种。缓存过期时间设 24 小时比较稳妥因为 BIN 数据本身不会频繁变动。但要注意2020 年的数据放到现在部分 BIN 的发卡行已经变更缓存过期后重新查库时如果库里还是旧数据就会一直返回错误结果。所以缓存策略必须配合数据更新流程不能只设 TTL 不管数据源。3. 把 BIN 数据接进支付路由匹配逻辑与性能取舍BIN 数据导入数据库只是第一步真正产生价值是在支付路由和风控规则里用起来。这一章讲清楚匹配逻辑怎么写、性能怎么优化、和现有系统怎么对接。很多团队在这一步踩坑不是因为数据不对而是因为匹配规则写得太粗或太细导致路由错误或性能瓶颈。3.1 6 位匹配与 8 位匹配的优先级银联 BIN 有 6 位和 8 位两种长度。6 位 BIN 覆盖范围广但精度低8 位 BIN 精度高但数据量少。实际查询时应该先按 8 位匹配命中则直接返回未命中再降级到 6 位匹配。这个逻辑用 SQL 写就是两次查询用应用层代码写就是先查 8 位缓存再查 6 位缓存。def query_bin(card_no: str, db): # 先取前8位查精确匹配 bin8 card_no[:8] row db.query(SELECT * FROM bank_bin WHERE bin %s, bin8) if row: return row # 降级到前6位 bin6 card_no[:6] return db.query(SELECT * FROM bank_bin WHERE bin %s, bin6)这个逻辑看起来简单但有一个边界坑如果 8 位 BIN 在表里存在但对应的发卡行字段是空的而降级到 6 位后能拿到完整信息这时候应该优先返回 6 位的结果还是 8 位的结果我的经验是如果 8 位记录的关键字段发卡行、卡种为空就继续降级到 6 位并在日志里记一条 warn提醒数据维护人员补全 8 位记录。否则线上会出现“卡号识别成功但发卡行为空”的玄学问题。3.2 路由规则里的 BIN 白名单与黑名单支付路由经常需要根据 BIN 做通道选择。比如某家银行和通道 A 有优惠费率就把该行所有 BIN 加入白名单优先走通道 A某些 BIN 段被风控标记为高风险就加入黑名单直接拒绝或走人工审核。白名单和黑名单的存储可以用同一张表加一个route_tag字段也可以用 Redis Set 单独维护。用 Redis Set 的好处是查询 O(1)适合高频路由决策# 把某通道支持的 BIN 加入集合 SADD route:channel_a:bin 622202 622203 622204 # 路由时判断 SISMEMBER route:channel_a:bin 622202但 Redis Set 的缺点是更新时要同时维护数据库和缓存容易出现不一致。我一般会写一个定时任务每 5 分钟从 MySQL 全量同步一次到 Redis同步期间用旧缓存继续服务避免路由抖动。如果业务对实时性要求极高可以用 MySQL 的 binlog 监听做增量同步但复杂度会上升不少。3.3 批量查询与单笔查询的性能差异绑卡接口通常是单笔查询QPS 高但每次只查一个 BIN。对账或批量风控场景则是批量查询一次要查几千个卡号。这两种场景的优化方向完全不同。单笔查询靠缓存和索引批量查询靠批量接口和内存计算。批量查询时不要循环调单笔查询接口那样网络开销和数据库连接开销会拖垮系统。正确做法是把所有卡号的前 8 位去重一次性从数据库或缓存拉取然后在内存里做映射def batch_query_bin(card_nos, db): bins list({c[:8] for c in card_nos} | {c[:6] for c in card_nos}) # 一次查询所有 BIN placeholders ,.join([%s] * len(bins)) rows db.query(fSELECT * FROM bank_bin WHERE bin IN ({placeholders}), *bins) bin_map {r[bin]: r for r in rows} result {} for card in card_nos: result[card] bin_map.get(card[:8]) or bin_map.get(card[:6]) return result这段代码的关键是bins集合同时包含 6 位和 8 位一次 IN 查询搞定。如果 BIN 数量超过 1000要分批查避免 SQL 语句过长被数据库拒绝。批量查询的耗时主要花在数据库 IO 上内存映射部分几乎可以忽略。4. 避坑与排查BIN 数据落地时最容易翻车的五个场景这一章记录的是我在实际项目里踩过的坑每一个都对应线上真实故障。如果你正准备把这份 2020 年的 BIN 数据接入生产环境建议逐条对照检查。4.1 前导零丢失导致 BIN 匹配失败现象Excel 里明明有 622202 这个 BIN导入 MySQL 后查不到或者查出来的发卡行不对。原因Excel 默认把纯数字列当数值处理622202 没问题但 062220 这种以 0 开头的 BIN 会被存成 62220长度变成 5 位。导入 MySQL 时如果目标列是 int 类型同样会丢前导零。解决Excel 读取时强制dtypestrMySQL 建表时 BIN 列用varchar(8)而不是int。导入前用str.len()检查一遍长度分布发现异常长度立即停下来修数据。4.2 6 位 BIN 与 8 位 BIN 冲突现象卡号前 8 位在表里查不到降级到前 6 位查到了但返回的发卡行和实际发卡行不一致。原因2020 年之后部分银行调整了发卡段8 位 BIN 被重新分配但 6 位 BIN 还是旧数据。降级查询时命中了过时的 6 位记录。解决在应用层加一个数据版本标记如果 8 位未命中且 6 位命中的记录updated_at早于某个阈值就打标提醒人工复核。更彻底的做法是定期从卡组织获取最新 BIN 增量覆盖旧记录。4.3 MySQL 导入时字符集不匹配现象导入后发卡行名称显示为乱码或者查询时中文条件匹配不上。原因CSV 文件是 GBK 编码MySQL 表是 utf8mb4导入时没有指定字符集转换。解决导入前用iconv -f GBK -t UTF-8 bin_clean.csv bin_utf8.csv转码或者在LOAD DATA语句里加CHARACTER SET gbk。建表时统一用utf8mb4避免生僻字发卡行名称存不进去。4.4 缓存与数据库不一致导致路由错误现象数据库里已经更新了某个 BIN 的发卡行但线上路由还是走旧通道导致交易失败。原因应用层缓存 TTL 设了 24 小时数据更新后没有主动失效缓存。解决数据更新流程里加一步缓存清除操作用 Redis 的DEL命令删掉对应 key。如果缓存是本地内存如 Guava Cache需要走配置中心推送刷新或者把 TTL 缩短到 5 分钟用短过期换一致性。4.5 批量查询时 IN 子句过长被截断现象批量风控任务查 5000 个卡号的 BIN结果只有前 1000 个有返回后面的全是空。原因MySQL 的max_allowed_packet限制了单条 SQL 的长度IN 子句里的参数太多导致语句被截断或直接报错。解决分批查询每批 500 到 1000 个 BIN用for循环拼接结果。或者改用临时表把 BIN 列表插入临时表后 JOIN 查询避免 IN 子句过长。5. 让 2020 年的 BIN 数据活到今天增量更新与验证技巧2020 年的 BIN 快照放到今天最大的问题不是数据本身有错而是它已经过时了。银联每年都会新增和调整发卡段部分银行合并或更名后 BIN 归属也会变。如果你直接拿这份数据上生产短期内可能没问题但半年后就会陆续出现识别错误。这一章讲几个让旧数据保持可用的实操技巧以及怎么验证你的 BIN 库是否还准。第一个技巧是建立“未知 BIN 收集机制”。线上查询时如果某个卡号的前 8 位和前 6 位都没命中不要直接返回空而是把卡号前 8 位写入一张unknown_bin表记录出现次数和首次出现时间。每周跑一次统计把出现次数超过阈值比如 100 次的未知 BIN 拉出来人工确认发卡行后补进主表。这个机制能让你在不依赖外部数据源的情况下逐步补全缺失的 BIN 段。CREATE TABLE unknown_bin ( bin varchar(8) NOT NULL, hit_count int(11) NOT NULL DEFAULT 1, first_seen timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, last_seen timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (bin) ); -- 查询时未命中则记录 INSERT INTO unknown_bin (bin) VALUES (%s) ON DUPLICATE KEY UPDATE hit_count hit_count 1;第二个技巧是用卡号长度和 Luhn 校验做辅助验证。BIN 表里通常有card_length字段查询到 BIN 后用 Luhn 算法校验卡号是否合法再比对长度是否一致。如果 BIN 识别为某行借记卡但卡号长度是 19 位而表里记录是 16 位说明这条 BIN 记录可能已经过时需要打标复核。def luhn_check(card_no: str) - bool: digits [int(d) for d in card_no[::-1]] total 0 for i, d in enumerate(digits): if i % 2 1: d * 2 if d 9: d - 9 total d return total % 10 0第三个技巧是定期和公开的卡组织 BIN 列表做交叉比对。虽然不能保证完全一致但可以快速发现大面积偏差。我一般每季度抽 200 个高频 BIN人工在银行官网或客服渠道验证发卡行如果错误率超过 5%就说明整份数据需要重新获取或大规模修正。从那以后我每次接入任何 BIN 数据都强制走一遍“长度检查 → 前导零检查 → 重复检查 → 抽样验证”四步流程再上生产。这份 2020 年的银联 BIN 数据在结构完整性和覆盖面上仍然有参考价值但一定要配合增量更新和未知 BIN 收集机制使用别把它当成一劳永逸的黑匣子。希望帮到你。本文还有配套的精品资源点击获取