简介这份银行卡BIN数据集来自银联官方2020年4月25日发布的最新最全版本共收录9868条银行卡BIN记录涵盖BIN码、BIN长度、发卡行、银行卡名称、卡类型、卡长度等核心字段。资源面向支付开发、风控建模、银行系统测试及数据分析人员可用于银行卡识别、渠道路由、卡BIN校验等典型场景。压缩包共7个文件包含5个Excel分类表标准卡表、单位结算卡表、农民工卡表、非标卡表及跨行转账卡表和1个可直接导入MySQL的SQL文件整体仅1.12MB轻量易用。Excel与SQL双重格式既方便人工查阅也便于程序化批量导入省去自行整理清洗的步骤。目前已有3489人学习下载数据源权威、字段完整是2020年较稀缺的银联官方银行卡BIN全套数据配合SQL文件可快速搭建本地BIN数据库显著提升相关开发与测试效率。 做支付对接、绑卡验证或者单纯给客服查“这张卡是哪家银行”的人大概率都经历过同一个瞬间手里只有一串 16 到 19 位的卡号却要先回答“这是什么卡、能不能收”再决定放不放行。银行卡BIN数据就是为这个场景准备的——BIN 是卡号前 6 位部分卡种已按前 8 位扩展它决定了这张卡的发卡行、卡类型和卡组织归属。这套 ExcelMySQL 双格式、标注 2020 最新最全的银联官方发布版本Excel 文件用来人工筛选核对MySQL 表用来给线上接口做实时联查相当于一份可以长期维护的发卡行字典。如果你在写支付接口、做风控规则或者核对账单流水下面这套落地流程可以直接照着改。2. 拆开 2020 银联版 BIN 表先看清字段再谈导入把文件下载下来之后第一件事不是双击打开堆图表而是先想清楚这张表到底在描述什么。BIN 表不是一张“卡号大全”它是一张“前缀对照表”用卡号前 6 位去定位发卡行。2020 年银联官方渠道发布的这张表拆开看基本逃不开下面这几类字段只是列名写法各有差异。先看懂列后面不管是导入 MySQL 还是留在 Excel 里用都不会跑偏。2.1 BIN 字段为什么是“卡号前6位”而不是整张卡号BINBank Identification Number银行标识码在 ISO/IEC 7812 标准里就是卡号前 6 位。银联标准的 62 开头卡号以及早期 9 开头的存量卡都靠这段前缀定位到发卡机构。2020 年发布的时候主流口径还是 6 位 BIN后来行业里讨论的 8 位 BIN 扩展本质上是把同一前缀下的卡种细分再往后挪两位落表时用 VARCHAR 存别用数字存原因后面会讲。把 BIN 表当“前缀表”而不是“卡号表”来用能少踩一半坑。因为它描述的是前 6 位相同的整批卡号同一个 BIN 可能同时覆盖一张借记卡和一张信用卡所以数据里经常出现“BIN 相同、卡类型不同”的多行记录。常见做法是同一 BIN 保留多条独立记录而不是合并成一行。这个细节直接影响导入 MySQL 时的主键设计要不要把 card_bin 设为主键我的答案始终是不要。字段示例常见类型落地用途card_bin卡号前 6 位查询主键允许重复bank_name发卡行名称展示给用户或风控判断card_type借记卡 / 信用卡 / 预付卡绑卡限制、交易路由card_org卡组织标识判断是否银联卡card_brand卡品牌或卡产品展示卡等级可选region发卡地区分行统计可选列名可以按自己的习惯改但这几个维度最好单独成列不要拼在一个备注字段里。特别是 bank_name 和 card_type分开存才能在 MySQL 里按条件过滤在 Excel 里按列筛选否则后面每条查询都要做字符串截取性能和可维护性都会变差。2.2 用 pandas 读取 Excel 检查列结构与样本Excel 文件拿到手我一般先不直接导入 MySQL而是用 pandas 扫一遍。这一步花不了两分钟却能确认列名、行数、空值分布避免把一份带脏数据的表直接灌进库。import pandas as pd # dtypestr 是关键把整列读成字符串避免前导零被吃掉 df pd.read_excel(bank_bin_2020_unionpay.xlsx, sheet_name0, dtypestr) print(df.columns.tolist()) # 列名清单 print(df.shape) # 行数、列数 print(df.head()) # 前 5 行样本逻辑说明dtypestr是最容易被忽略的一步。BIN 看起来是数字但以 0 开头的卡段虽然少见确实存在如果用默认的 int 去读前导零会直接丢失导入 MySQL 之后再怎么补救都晚了。sheet_name0表示读第一个工作表银联发布的文件有时会带说明 sheet别读错。head()打印样本用来确认 bank_name 这类中文字段没有乱码。参数说明读.xlsx需要环境里装 openpyxl读旧版.xls需要 xlrd。pandas 版本不同read_excel的底层引擎解析行为有细微差异如果文件打不开先检查这两个库的版本再检查是不是文件本身加密或带了宏。2.3 数据质量自检空值、重复 BIN 与版本核对导入之前先跑一遍质量检查别把这张表当黑匣子。重点看三件事空值分布、重复记录、哪些 BIN 对应多个卡种。print(df.isna().sum()) # 每列空值数量 print(df.duplicated(subset[card_bin]).sum()) # 重复 BIN 的数量 print(df.groupby(card_bin).size() .sort_values(ascendingFalse).head(10)) # 出现次数最多的 BIN逻辑说明空值检查解决的是“字段缺失能不能容忍”的问题。bank_name 为空可以后面补card_bin 为空就该直接删掉否则查询时会出现 NULL 匹配不到任何卡。duplicated统计重复 BIN但注意这里的“重复”只是 BIN 重复不一定是脏数据——同一个 BIN 下有多张卡很正常重点看重复组合。参数说明groupby(card_bin).size()会返回每个 BIN 出现的次数sort_values(ascendingFalse).head(10)只看重复最厉害的前 10 个。这些高重复 BIN 往往是同一家银行下面多个卡种共用一个前缀段导入 MySQL 后必须靠 card_type 再做一层区分。版本核对是很多人忽略的环节。2020 版是发布当时的口径不代表 2026 年还能覆盖所有新发卡。拿到文件后把发布日期或文件版本号记在一个固定位置要么写在 Excel 备注列要么建一张 meta 表后面会给建表 SQL。这样半年后有人问“这张表是哪年的”不用再翻下载记录。3. 把 Excel 版 BIN 数据搬进 MySQL建表、导入与索引设计如果电脑上还没有 MySQL 环境常规的 MySQL 安装配置教程已经够用这里不再重复。假设你已经有一个可用的实例下面直接从建表开始。这套流程的核心不是把数据塞进去而是塞进去之后还能高效查出来并且方便以后换 2021、2022 新版数据。3.1 建表 DDLBIN 列为什么选 VARCHAR 而不是 BIGINT先给出一版可以直接执行的建表语句字段按前面 Excel 表的常见列设计额外加了一列 source_version 用来记录数据版本。CREATE TABLE bank_bin ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, card_bin VARCHAR(8) NOT NULL COMMENT 卡号前6位兼容8位BIN扩展, bank_name VARCHAR(128) NOT NULL COMMENT 发卡行名称, card_type VARCHAR(32) NOT NULL DEFAULT COMMENT 借记卡/信用卡/预付卡, card_org VARCHAR(64) NOT NULL DEFAULT COMMENT 卡组织如银联, card_brand VARCHAR(64) NOT NULL DEFAULT COMMENT 卡产品/品牌, region VARCHAR(64) NOT NULL DEFAULT COMMENT 发卡地区, source_version VARCHAR(32) NOT NULL DEFAULT 2020 COMMENT 数据版本来源, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_card_bin (card_bin) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci COMMENT银行卡BIN字典;逻辑说明主键用自增 id而不是 card_bin。原因在前面提过同一 BIN 在数据里可能对应多行直接拿 card_bin 做主键导入时必然撞主键。card_bin 用 VARCHAR(8) 是为了兼容 6 位和 8 位两种口径如果用 BIGINT 存储前导零丢失的问题会从 Excel 一路带进 MySQL而且 BIN 查询永远是前缀匹配字符串类型在业务语义上更准确。参数说明source_version不是业务字段是给数据更新留的后门。没有这一列将来导入新版数据时要先全部 DELETE 再灌一旦出问题没有后悔药。有了版本字段可以保留多个版本对比也可以随时回退。字符集用 utf8mb4因为发卡行名称里有中文生僻字的情况并不少见排序规则用 utf8mb4_unicode_ci查询时中文排序和比较更稳定。3.2 两种导入方式LOAD DATA 与 Python 写入按数据量取舍Excel 文件不能直接导入 MySQL常见做法是先另存为 CSV再用 LOAD DATA 批量加载如果数据量不大或者导入之前还需要清洗用 Python 写也很快。先看 LOAD DATA 的写法和参数。LOAD DATA LOCAL INFILE /path/bank_bin_2020_unionpay.csv INTO TABLE bank_bin CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (card_bin, bank_name, card_type, card_org, card_brand, region, source_version) SET source_version 2020;逻辑说明IGNORE 1 LINES跳过 CSV 里的表头行。OPTIONALLY ENCLOSED BY 处理发卡行名称里本身带逗号的情况否则一个“XX银行股份有限公司”可能被拆成两列。source_version是临时变量配合最后的SET统一给这一批数据打上版本标记。参数说明CHARACTER SET utf8mb4必须和 CSV 文件实际编码一致。Excel 另存 CSV 时默认是 GBK 编码如果你直接指定 utf8mb4导入后中文全是乱码两个解决办法要么 CSV 保存时选择 UTF-8 格式要么把这里的CHARACTER SET改成gbk。另外 LOCAL 关键字需要 MySQL 服务端开启 local_infile 参数否则会报 “command not allowed”。另一种方式是用 Python 批量写入适合几万行以内、导入前还要做清洗的场景。import pymysql import pandas as pd df pd.read_excel(bank_bin_2020_unionpay.xlsx, dtypestr) df df.where(df.notna(), None) # 把空字符串统一转成 None conn pymysql.connect(host127.0.0.1, userroot, password***, databasepay_db, charsetutf8mb4) cursor conn.cursor() sql INSERT INTO bank_bin (card_bin, bank_name, card_type, card_org, card_brand, region, source_version) VALUES (%s, %s, %s, %s, %s, %s, 2020) data df[[card_bin, bank_name, card_type, card_org, card_brand, region]].values.tolist() cursor.executemany(sql, data) conn.commit() cursor.close() conn.close()逻辑说明df.where(df.notna(), None)把 pandas 里的 NaN 替换成 None这一步不能省。如果不替换pymysql 会把 float 类型的 NaN 写进字符串列轻则告警重则字段值变成 “nan” 字符串。executemany批量插入比循环里逐条execute快一个数量级数据量在几万行时差距非常明显。参数说明charsetutf8mb4和表字符集保持一致。executemany适合一次性写入如果文件到了几十万行还是优先用 LOAD DATA。写入过程中如果中断先SELECT COUNT(*)看下有没有半截数据再决定是清空重导还是从断点继续。3.3 查询走索引的姿势精确匹配、前缀匹配与隐式类型转换数据落库之后最常见的查询就是“给我这个卡号的发卡行和卡类型”。看三条 SQL前两条是对的第三条是典型的翻车写法。-- 精确匹配走 idx_card_bin 索引 SELECT bank_name, card_type, card_org FROM bank_bin WHERE card_bin 622200 AND source_version 2020; -- 前缀匹配处理 8 位 BIN 扩展 SELECT bank_name, card_type FROM bank_bin WHERE card_bin LIKE 622202%; -- 隐式类型转换慢查询通常长这样 SELECT bank_name, card_type FROM bank_bin WHERE card_bin 622200;逻辑说明第三条把622200写成了数字 622200。MySQL 遇到字符串列和数字比较时会把 card_bin 这一列隐式转成数字再比索引直接失效几十万行的表就会变成全表扫描。用EXPLAIN SELECT ...看执行计划type 字段从const变成ALL就是索引没走上的铁证。参数说明LIKE 622202%这种左前缀匹配能走普通 B-tree 索引但LIKE %6222%会全表扫描业务里别这么写。如果要把查询封装成 MySQL 存储过程入参类型同样用 VARCHAR不要用 INT否则隐式转换一样会出现。调试阶段顺手加一句ORDER BY card_bin, bank_name肉眼核对数据比无序输出轻松得多。4. 留在 Excel 里用 BIN 数据VLOOKUP、条件格式与卡顿自救不是所有同事都用 MySQL。运营、财务、对账岗手里只有 Excel他们拿这份 2020 银联版 BIN 数据主要做两件事按卡号查发卡行、核对批量账单里有没有非银联卡。这一章讲的是不留数据库、只在 Excel 里完成这些操作的做法。4.1 先把卡号列改成文本格式避免科学计数法吃后几位卡号超过 11 位 Excel 就会显示成科学计数法超过 15 位精度直接丢失。BIN 表本身只有 6 位没有这个问题但你要拿去匹配的原始卡号列很容易中招。常见表现是卡号显示成6222 0000 0000 0000后几位全部变成 0。操作步骤选中卡号列菜单栏点“数据 → 分列”前两步直接下一步第三步选“文本”完成。这个技巧在 Excel 函数公式大全里常年排在前几页。已经保存过的文件用分列能恢复一部分但被转成 0 的后几位基本找不回来还没保存就发现显示不对直接关闭文件不保存是最快的后悔药。更根本的做法是先把目标列设置成文本格式再粘贴卡号数据。不要从系统里复制出来直接 CtrlV那等于把决定权交给 Excel 的自动类型识别。对账场景里原始文件比技巧值钱原始文件一翻车后面所有 VLOOKUP 结果都不必看了。4.2 用 VLOOKUP 把整表卡号匹配成“银行卡类型”一行公式就能完成卡号到发卡行的映射VLOOKUP(LEFT(A2,6), BIN!$A:$D, 2, FALSE)LEFT(A2,6)取卡号前 6 位作为查找值BIN!$A:$D是 BIN 表的数据区域数字 2 表示返回第 2 列也就是发卡行名称FALSE要求精确匹配。要同时带出卡类型和卡组织就再写两列公式把最后的参数改成 3、4。多取几列时也可以用 INDEXMATCH 替代但 VLOOKUP 在这个场景里够用。真正需要注意的是VLOOKUP 永远返回第一个匹配行。前面讲过同一个 BIN 可能同时存在借记卡和信用卡两条记录如果你直接把公式拉下去很可能出现“卡号是借记卡匹配出来的却是信用卡发卡行”的情况。常见解法是加辅助列。在 BIN 表里新建一列用A2B2把 card_bin 和 card_type 拼起来再用VLOOKUP(LEFT(A2,6)借记卡, BIN!$A:$E, 3, FALSE)查。把卡类型写进查找键结果就不会串。再配一个条件格式公式ISNA(VLOOKUP(LEFT($A2,6), BIN!$A:$D, 1, FALSE))把匹配不到的整行标红批量对账时未识别卡一眼就能扫出来。4.3 Excel 打开卡顿、复制粘贴没反应时的替代做法2020 银联发布的这份文件如果 BIN 段位和发卡行信息做得比较细行数不会少。直接在原文件上操作公式很容易遇到“Excel 未响应”“复制粘贴没反应”的情况。这不是玄学多半是公式重算队列太长、加载项被禁用叠加导致的。做法一选中数据区域按 CtrlT 转成 Excel 表格再用“数据 → 从表格”进入 Power Query 做筛选和分组。转表之后Excel 的公式计算范围会跟着表自动扩展不会出现公式拉到一半、新增行匹配不上的问题。做法二如果机器配置确实带不动别硬扛。把匹配逻辑丢给 MySQL结果导出成精简版 Excel 再分发给同事。导出用 pandas 写一行就够import pandas as pd from sqlalchemy import create_engine engine create_engine(mysqlpymysql://root:***127.0.0.1/pay_db?charsetutf8mb4) sql SELECT card_bin, bank_name, card_type, card_org FROM bank_bin WHERE source_version2020 df pd.read_sql(sql, engine) df.to_excel(bin_export.xlsx, indexFalse)逻辑说明to_excel输出的是纯数据不带 VLOOKUP 公式、不带条件格式文件体积小很多打开和筛选都流畅。对账同事拿到这份导出表直接在“数据 → 筛选”里下拉选银行比在一堆公式里翻效率高得多。参数说明indexFalse让 pandas 不写第一列序号不然导出的表多一列没用的行号。SQL 里按source_version过滤是什么版本就写什么版本避免混入历史数据。5. BIN 数据落地避坑五个常被数据本身带偏的坎下面这些坑大多来自项目上线后的血泪经验每一条都按“现象 → 原因 → 解决”写。别觉得低级我见过不止一次线上支付接口因为其中一个坑直接拒绝了一类卡。5.1 Excel 与 CSV 文件层的两个坑科学计数法和中文乱码坑 1卡号列变成科学计数法后几位变 0。现象从系统导出的原始卡号表在 Excel 里显示成6.222E18后四位全是 0。原因Excel 对超过 11 位的数字自动转科学计数法超过 15 位精度丢失卡号里的有效数字变成 0。解决还没有保存文件就直接关闭不保存重新导出已经保存的选中卡号列数据 → 分列 → 第三步选文本能恢复部分内容但已经丢掉的位数找不回来。根治办法是复制卡号前先把目标列设置为文本格式粘贴时用“选择性粘贴 → 值”别让 Excel 自动识别成数字。坑 2CSV 导入 MySQL 后中文乱码。现象LOAD DATA 之后读表bank_name 字段显示成“锟斤拷”或“鏄熷尯”这类乱码。原因Excel 另存 CSV 时默认用的是 GBK 编码而 LOAD DATA 里指定的是 utf8mb4两边对不上。解决两个方向都行。要么在 Excel 里把 CSV 另存为 UTF-8 格式导入语句不改要么保留 GBK 文件把导入语句里的CHARACTER SET改成gbk。另外检查一下 MySQL 服务端character_set_server参数如果建库时字符集就是 utf8mb4通常不需要动这里。导入后先SELECT * FROM bank_bin LIMIT 5看样本别急着跑全量逻辑。5.2 MySQL 导入与查询层的两个坑隐式转换和排序规则坑 3同一个查询测试环境毫秒级生产环境几百毫秒。现象线上接口每次调用 BIN 查询都耗时EXPLAIN看执行计划是typeALL全表扫描。原因生产代码里把卡号参数拼成了数字类型SQL 变成WHERE card_bin 622200MySQL 对字符串列做隐式类型转换索引失效。解决SQL 里永远写引号WHERE card_bin 622200。代码侧用 String 类型传参不要用 Long。如果有一批老代码一时改不完可以在表上加一列card_bin_num BIGINT生成列配合索引先兜底再逐步切到字符串查询。坑 4导入时主键冲突。现象拿 card_bin 当主键灌数据跑到一半报Duplicate entry。原因同一个 BIN 在银联发布的数据里对应多条记录比如同一前缀段既有借记卡又有信用卡card_bin 根本不唯一。解决用自增 id 做主键card_bin 建普通索引。业务查询按card_bin card_type定位统计去重时写COUNT(DISTINCT card_bin, card_type)不要默认一个 BIN 只有一行。这个坑在 Excel 里容易被忽略因为 VLOOKUP 永远只取第一行不会报错只会给错结果。5.3 业务判断层的那个坑把快照数据当永久数据坑 5新发的卡在 2020 版 BIN 表里查不到业务直接拒绝交易。现象用户拿着一张开卡不满一年的银行卡接口返回“非银联卡”或“未知发卡行”。原因2020 版是发布当时的最新最全快照不包含之后新增的 BIN 段。BIN 数据是动态的银联会随发卡行申请持续新增卡段快照数据必然过期。解决给每行数据打 source_version 标记保留更新入口上线后记录“查无此 BIN”的日志定期统计未命中卡号判断是否需要升级数据版本。如果团队没有专人维护 BIN 表至少给风控留一个“人工复核”的兜底路径不要因为查不到就一刀切拒绝。6. 用 Luhn 校验和版本登记把 BIN 表收编进日常流程BIN 表解决的是“卡号前缀是谁家”的问题它不负责验证卡号本身合不合法。把 BIN 查询接入线上之后还需要一个校验手段挡住明显不存在的卡号Luhn 算法就是最常用的那一个。6.1 卡号整体校验BIN 只负责前缀Luhn 负责最后一公里Luhn 算法是绝大多数银行卡号的校验规则对卡号逐位加权求和最后一位校验位让整个结果能被 10 整除。BIN 表只能告诉你“前缀存在”Luhn 能告诉你“这串数字至少结构合法”两者结合脏数据能挡掉一半。def luhn_ok(card_no: str) - bool: digits [int(c) for c in card_no if c.isdigit()] if len(digits) 13 or len(digits) 19: return False checksum 0 reverse_digits digits[::-1] for i, d in enumerate(reverse_digits): if i % 2 1: d * 2 if d 9: d - 9 checksum d return checksum % 10 0逻辑说明从卡号最后一位开始奇数位数字乘 2乘完大于 9 就减 9偶数位保持原值全部求和后看能否被 10 整除。调用方式很简单luhn_ok(6222 0012 3456 7890)返回 True 说明通过校验。测试方法从 BIN 表里随机抽 100 个 card_bin用随机尾号拼成 16 位卡号逐条跑 Luhn。理论上这些拼出来的卡号大部分能通过校验因为在构造时已经符合规则真正要盯的是原始账单文件里的卡号如果大比例 Luhn 不过先怀疑文件传输截断再怀疑卡号列被 Excel 转成了科学计数法。6.2 把版本号写进 MySQL 元数据表一条 UPDATE 说清数据来源数据更新是 BIN 表长期维护里最容易被忽略的一环。建一张很小的元数据表把每个版本的来源记录清楚下次更新时只要改一个值所有查询都能按版本过滤。CREATE TABLE bin_meta ( version VARCHAR(32) PRIMARY KEY, file_name VARCHAR(128), imported_at DATETIME DEFAULT CURRENT_TIMESTAMP ); INSERT INTO bin_meta (version, file_name) VALUES (2020, bank_bin_2020_unionpay.xlsx);逻辑说明bin_meta不存业务数据只存“当前库里跑的是哪一版”。导入新版数据时先查这张表看当前版本再决定是覆盖导入还是追加导入。给旧版本统一补标记的 UPDATE 也很好写UPDATE bank_bin SET source_version 2020 WHERE source_version ;参数说明这条 UPDATE 使用的是 MySQL 的常规 update 语法不需要额外引包。执行前先SELECT source_version, COUNT(*) FROM bank_bin GROUP BY source_version确认空版本的行数防止把新导入的行也误标成 2020。这个习惯我保留了很久每次拿到新版 BIN 文件先用 pandas 跑一遍空值和重复检查抽 10 条人工核对发卡行名称再导入 MySQL 并把版本信息写进 meta 表。多花这十分钟线上少踩一堆“查不到卡”的工单。希望帮到你。本文还有配套的精品资源点击获取