简介2023年银行卡BIN码数据库文件聚焦六位银行识别码Bank Identification Number的构成与管理标准面向支付系统开发者、金融风控工程师、数据分析师以及对卡组织规则有研究需求的从业者。压缩包仅含1个SQL文件整体约40KB轻量易导入表内包含bin_number、bank_name、card_type、card_network、issue_country等字段可快速查询发卡机构、判断卡种类型与所属支付网络支撑支付校验、风险识别及市场分析等任务。文件整合了2023年最新的BIN码分配信息参照ISO/IEC 7812标准整理方便开发者直接导入数据库或做二次加工。已有1395人学习下载。借助该数据表商家或支付平台可即时验证卡片有效性风控人员可结合发行国家与卡组织维度识别异常交易分析师也能从各类卡发行趋势中洞察市场动态适合作为本地开发测试或金融研究的基础数据样本。1. BIN码是卡号前6位但2023年的BIN数据跟你想的不一样做支付服务时经常会遇到一个需求用户绑定一张卡系统要在几百毫秒内判断它是不是本行卡、走哪个清算通道、用户填的卡种对不对。这个判断的第一层不是Luhn校验而是查BIN。银行卡BIN码是卡号开头的6到8位数字在2023年这个节点上它比网上那些“前6位查银行”的旧接口复杂得多——新发的数字银行卡大量改用8位BIN老数据里发卡行改名、卡种标签错位到处都是同一段BIN在不同来源里返回的银行甚至对不上。这篇笔记不打算重复那些“BIN是什么”的入门解释而是把一套能落地到2023年生产环境的数据整理、SQLite表设计、查询服务与避坑方案完整写出来。适合正在搭卡号识别、风控路由或后台绑卡接口的工程师新手可以照步骤把表建起来熟手建议直接看后半部分的坑和缓存策略。2. 读懂卡号里的发卡规律BIN结构、卡组织前缀与年份断层2.1 卡号前6位、前8位2023年的BIN为什么混着用银行卡BIN码的历史规则是ISO 7812最早规定发卡行标识是6位卡号就是“BIN 个人账户号 校验位”。6位BIN一共只有100万个组合早年够用但各家银行发行了太多借记卡、贷记卡、虚拟卡、行业卡之后资源很快吃紧所以ISO 7812-1在2017年就允许BIN扩展到8位。到了2023年老6位BIN仍在存量卡片上大量存在新发行的卡尤其是线上开户的二类户、数字银行卡不少已经切到8位BIN。这就带来一个很实际的数据问题网上能拉到的“银行卡BIN数据库”很多还是老口径只收录前6位。你用前6位去匹配新发的卡片运气好能匹配到发卡机构的大范围运气不好直接查无此卡。做识别服务时不能写死“取卡号前6位当BIN”必须准备一套“优先8位、失败回落6位”的查询顺序。这个顺序在后面的查询代码里会体现。另外要注意BIN码不等于卡号规则的全部。同一张银行卡的BIN区域可能覆盖连续好几百个卡号一个BIN区间通常对应某一家银行某一类卡产品但不同产品间BIN区间可能重叠。这也是为什么建表时要用“起始区间 结束区间”而不是单个前缀。2.2 卡组织前缀与银行号段一张表看清品牌归属BIN查询第一步通常是判断卡组织因为清算路由要用。卡号第一位基本决定了卡组织常见对应关系如下卡号开头卡组织/品牌说明4Visa全球通用5MasterCard全球通用但部分51-55老号段已被各家银行使用35JCB日系卡组织37American Express运通BIN是4位但国内接入时常按6位处理62银联国内主流借记卡/贷记卡9银联部分新卡/机构卡2023年银联发的新BIN里能看到9开头这张表只能帮你分品牌不能帮你分银行。62开头的卡既有工行也有建行4开头的卡既有真实Visa卡也有国内银行发行的双标卡。真正定位到银行还是要依赖BIN区间数据表。我一般会在清洗数据时把card_brand字段单独存下来而不是每次靠前缀判断。原因是有些数据源已经给出了品牌信息并且对9开头这类模糊号段有更细的标注你重新按前缀算一遍反而可能把信息丢掉。2.3 识别一个卡号需要哪几步BIN区间查询 Luhn校验组合顺序有讲究一个完整的卡号识别服务其实是两条线第一是判断这张卡是否属于某家银行靠BIN区间匹配第二是判断卡号本身是否合法靠Luhn算法。这两条线不互相替代但顺序会影响业务结果。Luhn校验的核心逻辑是从卡号最右边一位开始隔一位乘以2相乘结果大于9就减9最后累加能被10整除就是合法卡号。实现很简单def luhn_ok(card_number: str) - bool: # 去掉卡号中的空格和横线只保留数字 digits [int(c) for c in card_number if c.isdigit()] if len(digits) 13: return False total 0 # 从右往左处理偶数位翻倍 for i, d in enumerate(reversed(digits)): if i % 2 1: d * 2 if d 9: d - 9 total d return total % 10 0注意这里第8行的i % 2 1是从右侧数起的第2位、第4位。如果写成从左往右数就会全部错位。这个函数建议单独放在工具模块里不要和BIN查询混在一起因为两者的失败含义不一样Luhn失败说明卡号可能是手误或伪造BIN查不到则说明可能是新发卡号或数据源覆盖不全。实际组合时我习惯先做BIN识别、再做Luhn校验两个结果都返回给上游。很多测试卡号、预演卡号本身Luhn就是合法的但如果把Luhn放在前面一些内部测试专用的不合规卡号会被直接拦截连测试路由都进不去。这一点在避坑章节会展开。3. 把2023年BIN数据整理成本地银行识别表SQLite表设计与导入脚本3.1 选型为什么我不用在线BIN接口而是本地SQLite做BIN识别最省事的方案是调第三方在线接口传卡号前6位返回银行名和卡种。但真正在交易链路里用几次就会发现问题第三方接口有QPS限制促销活动期间流量一大就把你限流而且每次查询都是一次网络往返延迟不稳定。更关键的是卡号属于敏感信息你不能把一段真实的卡号前缀批量丢给一个不受控的外部接口合规上过不去。所以常见做法是本地维护一份BIN数据集用SQLite或MySQL存起来。我选择SQLite因为BIN数据量撑死几十万行单文件部署、零运维查询走索引后单次匹配在微秒级。而且SQLite支持只读模式打开多个服务进程同时读一个文件完全没问题更新时可以用“导入临时表再原子切换”的方式不会影响线上。如果你的公司已经有MySQL或Redis也可以把这份数据放到线上库里但表结构和查询思路是一样的。下面以SQLite为例。3.2 BIN表结构为什么bin_start和bin_end要用TEXT存BIN区间数据的核心是“起始号段”和“结束号段”比如622202到622202代表工行某类卡6229211000到6229211009代表一个更小的段。建表SQL如下CREATE TABLE IF NOT EXISTS bank_bin ( bin_start TEXT NOT NULL, bin_end TEXT NOT NULL, bank_name TEXT NOT NULL, card_type TEXT NOT NULL DEFAULT , card_brand TEXT NOT NULL DEFAULT , updated_at TEXT NOT NULL, PRIMARY KEY (bin_start, bin_end) ); CREATE INDEX IF NOT EXISTS idx_bin_start ON bank_bin(bin_start);字段说明字段类型说明bin_startTEXTBIN区间起始值可能6位或8位前导零必须保留bin_endTEXTBIN区间结束值单个BIN时与bin_start相同bank_nameTEXT发卡机构名称清洗后用官方简称card_typeTEXT借记卡/贷记卡/预付费卡等允许空card_brandTEXT卡组织或品牌updated_atTEXT数据版本日期排查时先看它这里必须强调一点bin_start和bin_end存TEXT不存INTEGER。卡号是纯数字但BIN开头可能有0比如某些9开头号段前面补0一旦转成整数前导零丢了匹配时就会出现“明明库里有却查不到”的诡异问题。而且SQLite的TEXT字段做字典序比较时对等长数字字符串来说和数值比较结果一致所以WHERE bin_start ? AND bin_end ?这种范围匹配直接用TEXT没问题。另外主键我用了(bin_start, bin_end)因为最怕的是同一数据源清洗不干净同一个区间被插两遍。加上主键后后续重复导入时INSERT OR REPLACE会直接覆盖天然做了幂等。3.3 从CSV到SQLite一趟清洗导入脚本公开的BIN数据源大多是CSV或JSON字段命名五花八门有的叫bin有的叫iin有的干脆只有卡号前缀没写区间。拿到手第一件事就是统一成bin_start, bin_end, bank_name, card_type, card_brand五列。下面是一个清洗导入脚本的框架import csv import sqlite3 import datetime def normalize_bank_name(name: str) - str: # 把 XX银行股份有限公司 统一成 XX银行 # 把 XX农村商业银行 保留为 XX农商行 这类简称按自己业务口径处理 return name.replace(股份有限公司, ).replace(有限责任公司, ).strip() def import_bin_csv(csv_path: str, db_path: str): conn sqlite3.connect(db_path) cur conn.cursor() cur.execute(BEGIN) rows [] with open(csv_path, encodingutf-8-sig) as f: reader csv.DictReader(f) for lineno, rec in enumerate(reader, 1): bin_start rec.get(bin_start) or rec.get(bin) or rec.get(iin) or bin_end rec.get(bin_end) or bin_start bank_name normalize_bank_name(rec.get(bank_name) or rec.get(bank) or ) card_type rec.get(card_type, ).strip() card_brand rec.get(card_brand, ).strip() bin_start bin_start.strip() bin_end bin_end.strip() # 跳过明显无效的行 if len(bin_start) 6 or not bin_start.isdigit(): print(fline {lineno}: skip invalid bin_start{bin_start}) continue if not bin_end: bin_end bin_start if bin_start bin_end: bin_start, bin_end bin_end, bin_start rows.append(( bin_start, bin_end, bank_name, card_type, card_brand, datetime.date.today().isoformat() )) # 每5000行批量落库一次避免内存堆积 if len(rows) 5000: cur.executemany( INSERT OR REPLACE INTO bank_bin VALUES (?,?,?,?,?,?), rows ) rows.clear() if rows: cur.executemany( INSERT OR REPLACE INTO bank_bin VALUES (?,?,?,?,?,?), rows ) conn.commit() cur.execute(VACUUM) conn.close() print(import done)这段脚本有几个值得说明的细节。第一读取CSV时用了utf-8-sig编码很多公开数据是从Excel导出的带BOM头不这么写第一列列名会多一个\ufeff。第二BEGIN手动开启事务executemany批量插入避免逐行提交把事务日志撑爆导入几十万行也能在一分钟内完成。第三bin_start bin_end时做一次交换有些数据源的起止字段是反着写的交换后可以避免范围匹配失效。最后执行VACUUM是SQLite的一个小习惯大批量写入后表文件和索引会留空洞执行一次既回收空间也能让后续范围查询的页扫描更紧凑。如果你导入后查询响应偏慢先跑一次VACUUM再谈索引优化。3.4 数据源与更新时机怎么标注数据版本BIN数据不是一份“拿来永用”的静态文件银行合并、新卡产品发布、卡组织回收号段都会让它悄悄过期。常见做法是每个月拉一次公开数据清洗后覆盖进本地库同时在库里留一张meta表记录版本CREATE TABLE IF NOT EXISTS meta ( key TEXT PRIMARY KEY, value TEXT ); INSERT OR REPLACE INTO meta (key, value) VALUES (bin_version, 2023Q4), (updated_on, 2023-12-01);查询接口里把这个版本号带在返回结果里排查问题时先看版本号能快速判断“是不是数据过期导致的识别错误”而不是去查代码和缓存。数据源怎么选我给三条底线第一必须包含至少6位和8位两种长度只有6位的老库直接放弃第二要有明确的银行名称字段不要只给卡组织品牌第三最好是能持续更新的公开数据集或商业授权数据而不是网上某个来源不明的直装包。2023年市面上流传的免费BIN数据包很多还是2019年前后的旧内容装进去之后62、9开头的号段错漏极多这就是另一个坑了。4. 查询性能与识别准确率前缀匹配、范围判断与缓存参数4.1 为什么范围匹配比LIKE更可靠BIN查询的本质是给定一个卡号找到库里“包含这个前缀”的区间。最容易想到的是WHERE bin_start ? AND bin_end ?这确实是最标准的区间匹配写法也正好能用上idx_bin_start索引。有人会直接写WHERE bank_bin LIKE 622202%但这里有两个问题LIKE的前缀匹配在某些SQLite版本和配置下不走索引数据量大时全表扫描更重要的是LIKE只适合单值前缀遇到是一个区间而不是单个前缀的BIN时就无从下手。所以建表时就要按“区间”来设计而不是按“前缀”设计。一个BIN区间可能是622202到622209对应多个连续卡号前缀范围匹配一次就能覆盖LIKE则要拆成多个查询。具体查询代码我会配合“优先8位、回落6位”来实现from functools import lru_cache # 单条连接只读模式打开 conn sqlite3.connect(file:bank_bin.db?moderouritrue, check_same_threadFalse) lru_cache(maxsize8192) def _lookup(prefix: str): # 这里按 8 位和 6 位分别处理库里存的是等长区间 row conn.execute( SELECT bank_name, card_type, card_brand, bin_start, bin_end FROM bank_bin WHERE bin_start ? AND bin_end ? ORDER BY LENGTH(bin_start) DESC, bin_start ASC LIMIT 1 , (prefix, prefix) ).fetchone() return row def identify_card(card_number: str): clean .join(c for c in card_number if c.isdigit()) if len(clean) 13: return None # 优先用 8 位 BIN查不到再用 6 位 BIN for length in (8, 6): row _lookup(clean[:length]) if row: return row return None这里的ORDER BY LENGTH(bin_start) DESC是关键参数如果你拿到一个8位前缀但库里既有8位区间也有6位区间8位区间更精确应该排在前面优先返回。如果某张卡的8位BIN恰好落在某个老6位大区间和某个新8位小区间的重叠处这一句排序能保证返回的是更具体的新区间而不是那种涵盖几十个发卡机构的大范围。LIMIT 1配合排序保证每次查询最多返回一行不会让上游业务收到多条候选银行。4.2 缓存参数LRU缓存多大合适更新数据后怎么失效BIN查询本身已经很快但交易系统里同一批卡号会反复查再加上每次查询要拼接SQL、走SQLite的语句解析还是有一定开销。我给查询函数加上lru_cache命中后直接在进程内返回单次延迟可以压到微秒级。缓存大小一般设置在4096到8192之间。银行卡号在交易里的分布有很强的局部性同一批活跃用户反复支付命中头几千个前缀就能覆盖大部分请求设太大反而浪费内存而且数据更新后要清理的范围也大。lru_cache是进程内存态的多进程部署时每个进程各缓存一份不必强行共享。重点是更新数据后一定要清缓存。数据导入脚本跑完后需要让线上服务重建缓存否则库里已经是新BIN老进程还在返回旧银行名。我一般的做法是单独暴露一个_lookup.cache_clear()调用加在管理接口里更新数据后触发一次。如果不做第二天会收到大量“卡号识别错银行”的投诉这种问题最难排查因为代码没变、数据库没变只有缓存是暧昧的黑匣子。4.3 并发部署SQLite只读模式与更新时的原子切换SQLite在很多人印象里是单机小工具扛不住并发但BIN查询场景下它是够用的。关键在于只读模式打开数据库file:bank_bin.db?moderouritrue这样多个进程可以同时读同一个文件不会出现写锁互斥。配合连接池每进程持有一到两条连接即可。更新的情况比较特殊。不能在线上库里直接DELETE FROM bank_bin再插入因为删除瞬间开始查询就会大量落空轻则识别失败重则路由断路。常见做法是先把新数据导入一张临时表bank_bin_new导入完成后用事务把旧表重命名再把新表改成正式表名。SQLite里可以用ALTER TABLE ... RENAME TO完成两步操作包在一个事务里线上读请求会看到旧数据直到切换完成业务无感。4.4 识别准确率怎么衡量回归集与判定口径数据表建好、查询服务上线后必须回答“识别准确率是多少”。我的做法是准备一份回归集里面存(卡号, 期望银行, 期望卡种)。卡号只用公开测试卡号和内部造数工具生成的虚拟卡绝不能用真实用户卡号做测试集。CASES [ # 公开测试卡号不会命中真实账户 (4111111111111111, Visa Test, credit), (6222020200000000, 工商银行, debit), (6217000000000000, 建设银行, debit), ] def run_regression(): failed [] for card, bank, ctype in CASES: row identify_card(card) if not row or row[0] ! bank: failed.append((card, bank, row)) if failed: print(Failed:, len(failed)) for f in failed: print(f) else: print(All passed)对回归结果要特别注意BIN识别只能识别到发卡机构级别个别测试卡号可能归属于发卡机构下的多个子品牌期望值要按数据源的实际粒度去写不要拍脑袋。回归集每天跑一次配合定时更新脚本就能在数据源变更后第一时间发现问题。5. 避坑2023年BIN数据常见的5个坑现象、原因、解决5.1 现象新卡查不到银行原因数据源只有6位BIN解决8位优先、6位回落有阵子测试组反馈新开的数字银行卡在绑卡页识别不出银行。查日志发现查询结果为空但卡号确实是真实卡。把卡号前8位拿进制数源里搜一个都搜不到而前6位能搜到发卡行。原因就是这批新卡的BIN已经用满8位老数据源只收录了6位版本同一家银行的8位BIN范围根本没录进去。解决方式就是前文说的双长度查询先用8位查查不到再用6位查同时更新数据源。这条坑提醒我们设计BIN表时一开始就要允许bin_start和bin_end长度不同并且查询SQL不能写死WHERE LENGTH(bin_start) 6。5.2 现象银行名识别出旧名称原因发卡行改名或合并解决银行名映射表某次线上反馈一张包头市商业银行的卡被识别成“包商银行”但这家银行早就改名蒙商银行了。数据源是2021年的老版本银行名字段没更新。公开BIN数据源对发卡行名称的更新经常滞后尤其是城商行、村镇银行合并为重组的敏感点。我后来加了一张bank_name_alias映射表把旧名称归一成当前官方简称。导入时对bank_name字段做一层过滤匹配到映射表就替换。这个映射表不用太大维护主流的几十个改名银行就够用。5.3 现象Luhn失败的测试卡被业务拦截原因Luhn放在BIN识别之前解决把两步解耦分开返回拦截逻辑是上游团队写的他们在调用识别服务时先看Luhn结果失败直接拒绝绑卡。结果内部压测用的特殊测试卡号全部被弹回来因为这些压测卡是手工拼的不走Luhn规则。这个坑的问题在于Luhn校验和BIN识别是两个不同语义的判断前者验证卡号格式合法性后者识别发卡机构。业务上测试卡、预演卡就是需要被识别出来走特殊路由。我最后的方案是识别接口同时返回luhn_valid和bin_info两个字段让上游自己决定拦截还是放行而不是把Luhn结果合并在识别失败里。5.4 现象同一BIN返回两家银行原因数据源区间重叠或字段拼错解决导入时去重优先按区间合并有一次查一个6228开头的区间库里竟然有两行一家标工行、一家标建行。检查原始数据后发现其中一家数据源把6228这个大前缀整个标成了某银行另一家则细分成多个子区间导致重叠。解决分两步导入时对完全相同的(bin_start, bin_end)执行INSERT OR REPLACE后导入的数据不能覆盖先导入的权威字段而对部分重叠但又不完全相同的区间保留更精细的子区间因为子区间信息量更大。实际清洗时我按“区间长度越短越优先”的原则先插细区间再插大区间作为兜底。5.5 现象更新数据后线上识别全部为空原因全量DELETE后插入失败事务没包裹解决临时表原子切换这个问题我在初版更新脚本里踩过。当时图省事先DELETE FROM bank_bin再逐条INSERT结果插入过程中连接中断表空了线上查询全挂。后来把更新流程改成两步第一步把新CSV导入临时表bank_bin_new第二步在单个事务里完成ALTER TABLE bank_bin RENAME TO bank_bin_old; ALTER TABLE bank_bin_new RENAME TO bank_bin;。这样即使第二步失败旧表还在顶多是线上读旧数据不会全空。这个习惯后来我一直保留着所有需要全量替换的数据表都按临时表切换来走。6. 验证与持续更新用测试卡号做回归让银行识别服务活到2024年BIN数据最大的特性是会“过期”但过期方式不是一瞬间报错而是静悄悄地让你多识别错几张卡。要让这套本地识别服务在2023年之后还能接着用我给自己定了一套最小验证流程。第一回归测试要每天跑。把公开测试卡号、内部造数工具生成的虚拟卡号整理成CASES列表跑identify_card并对比期望值。失败时重点看是不是数据源更新引入的银行名漂移还是区间覆盖发生变化。回归脚本用一个简单的if __name__ __main__: run_regression()挂在定时任务里跑完在运维平台输出一行PASS/FAIL。第二更新后必查四件事新库总行数、6位BIN数量、8位BIN数量、meta.bin_version。对比旧库的数值如果8位BIN数量不增反减说明这份新数据源比旧的还旧直接把版本回滚别让线上往里跳。第三我养成了一个习惯在识别接口返回结果里带上bin_version。排查任何“识别错银行”问题先看返回的版本号是哪个再决定是查缓存、查表还是查代码。没有这个字段每次问题都要把三层全部翻一遍。另外如果你的支付场景经常接触预付费卡、行业卡建议在数据表里给card_type字段建立单独的支持策略。有些预付费卡BIN对外不公布公共数据源永远覆盖不到这时候就要在接口层预留一个人工维护的补充表。补充表结构和主表完全一样查询时合并更新时手动管理但能解决公共数据源最后一公里的盲区。这套方案的核心不是算法而是数据治理习惯BIN识别服务的可靠性上限由数据源的更新频率决定不由查询代码决定。代码写得再快库里没有8位BIN照样识别不了2023年的新卡。所以请从建表那天起就把版本号、更新脚本、回归集这三样东西当成服务的组成部分维护而不是事后补作业。希望帮到你。本文还有配套的精品资源点击获取