BIN（Bank Identification Number，银行标识码），自2022年起ISO/IEC 7812标准正式更名为IIN（Issuer Identification Number，发卡机构标识码），是银行卡号前6位（部分新标准扩展到8位）的数字组合，用于唯一标识发卡机构、卡品牌和卡类型。BIN管理是发卡业务的核心基础设施，直接影响交易路由、风控策略、成本控制和用户体验。
银行卡号的编码遵循ISO/IEC 7812标准，一个完整的卡号（PAN，Primary Account Number）由以下部分组成：
| 部分 | 长度 | 说明 | 示例 |
|---|---|---|---|
| MII | 1位 | Major Industry Identifier（主要行业标识） | 4（银行业与金融业） |
| IIN/BIN | 6位（或8位） | 发卡机构标识码 | 453201（某银行Visa卡） |
| 账户标识 | 9-12位 | 发卡机构分配的账户号 | 1234567890 |
| 校验码 | 1位 | Luhn算法校验 | 通过Luhn计算得出 |
MII编码含义：
| MII | 行业类别 |
|---|---|
| 0 | ISO/TC 68 及其他行业 |
| 1 | 航空业 |
| 2 | 航空业 / MC 2-series BIN（Mastercard新发卡） |
| 3 | 旅游与娱乐（Amex 34/37，Diners Club 300-305等） |
| 4 | 银行业与金融业（Visa） |
| 5 | 银行业与金融业（Mastercard 51-55，MC 2已接替） |
| 6 | 商业与金融业（Discover 6011/65，银联62，部分MC借记卡） |
| 7 | 石油业 |
| 8 | 医疗/通信 |
| 9 | 国家/地区标准 |
卡号最后一位是通过Luhn算法（ISO/IEC 7812-1）计算得出的校验码，用于检测输入错误。
计算步骤（以卡号 4532 0112 3456 789 为例，缺少校验码）：
原始号码（去掉校验码）：4 5 3 2 0 1 1 2 3 4 5 6 7 8 9
位置（从右到左，1-based）：15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
步骤1：从右向左，偶数位数字乘2
位15(4)：4
位14(5)：5×2=10 → 1+0=1
位13(3)：3
位12(2)：2×2=4
位11(0)：0
位10(1)：1×2=2
位9(1)：1
位8(2)：2×2=4
位7(3)：3
位6(4)：4×2=8
位5(5)：5
位4(6)：6×2=12 → 1+2=3
位3(7)：7
位2(8)：8×2=16 → 1+6=7
位1(9)：9
步骤2：求和
4 + 1 + 3 + 4 + 0 + 2 + 1 + 4 + 3 + 8 + 5 + 3 + 7 + 7 + 9 = 61
步骤3：计算校验码
(10 - (61 mod 10)) mod 10 = (10 - 1) mod 10 = 9
完整卡号：4532 0112 3456 789 9
Luhn算法验证伪代码：
def luhn_checksum(card_number: str) -> int:
"""计算Luhn校验码"""
digits = [int(d) for d in card_number]
# 从右向左，偶数位乘2
for i in range(len(digits) - 1, -1, -2):
digits[i] *= 2
if digits[i] > 9:
digits[i] -= 9
total = sum(digits)
return (10 - (total % 10)) % 10
def verify_luhn(card_number: str) -> bool:
"""验证Luhn校验码"""
digits = [int(d) for d in card_number]
return luhn_checksum(card_number[:-1]) == card_number[-1]
| 卡组织 | BIN前缀 | 说明 |
|---|---|---|
| Visa | 4xxxxx | 全球最广泛，标准6位BIN |
| Mastercard | 51xxxx-55xxxx, 2221xxxx-2720xxxx | 旧BIN 51-55（16个），新BIN 2-series（8位） |
| American Express | 34xxxx, 37xxxx | 卡号为15位，BIN占前4位 |
| Discover | 6011xx, 622126-622925, 644xxx-649xxx, 65xxxx | 4个BIN范围 |
| 银联 | 62xxxx | 中国银联标准卡，也支持62+8位BIN |
| JCB | 3528xx-3589xx | 日本信用卡品牌 |
| Diners Club | 300xxx-305xxx, 309xxx, 36xxxx, 38xxxx | 多个BIN范围 |
| Maestro | 50xxxx-59xxxx, 6xxxxx | 借记卡品牌，6/12/15位卡号 |
重要趋势： Mastercard从2016年起启用2-series BIN（2221xx-2720xx），以补充即将消耗完的51-55范围。新BIN采用8位长度，标志着行业从6位BIN向8位IIN的过渡。
申请机构 → 选择卡组织 → 提交资质文件
↓
审核机构资质（牌照、资本金、合规记录）
↓
分配BIN范围（卡组织分配固定BIN或BIN池）
↓
BIN注册（在卡组织中注册BIN，绑定卡产品参数）
↓
BIN开通测试（交易测试、清算测试、争议处理测试）
↓
正式运营（BIN可用，可开始发卡）
BIN赞助（BIN Sponsorship）是金融科技发卡领域最常见的模式：
| 角色 | 职责 | 示例 |
|---|---|---|
| 赞助行 | 持有卡组织会员资格，提供BIN资源，承担最终清算风险 | 渣打银行、花旗银行、银联国际成员行 |
| 发卡平台 | 提供卡片管理系统、BIN路由、交易处理 | Marqeta、Stripe Issuing、Adyen |
| 卡产品方 | 品牌运营、获客、用户管理 | 金融科技公司、数字银行、企业 |
赞助模式的数据流：
持卡人交易 → 商户 → 收单行 → 卡组织
↓
赞助行（清算责任方）
↓
发卡处理商 → BIN路由
↓
卡产品方（授权决策）
真实案例： Stripe Issuing 通过其赞助行（如高盛、Evolve Bank & Trust）的BIN发卡。Stripe本身不是银行，但通过BIN赞助机制，可以为客户发行Visa/Mastercard实体卡和虚拟卡，每张卡都归属于赞助行的BIN范围。
BIN是卡产品的标识入口，一个BIN可以映射到多个卡产品，但一个卡产品通常绑定一个主BIN。映射关系包含以下层级：
BIN (453201)
├── 卡品牌: Visa Classic
├── 卡类型: 借记卡 / 贷记卡 / 预付卡
├── 卡产品: "企业员工卡-银卡级别"
├── 卡片参数:
│ ├── 单笔限额: ¥50,000
│ ├── 日累计限额: ¥100,000
│ ├── 月累计限额: ¥500,000
│ ├── 支持交易类型: 线上消费、线下POS、ATM取现
│ ├── 支持币种: USD, CNY, EUR, GBP, JPY
│ └── 清算汇率: 卡组织汇率+0.5%
└── 风控配置:
├── 3DS认证: 强制
├── CVV验证: 启用
├── AVS验证: 可选
├── 高风险MCC限制: 禁止(如7995赌场、5960直销)
├── 黑名单国家: 制裁国家列表
└── 单日交易次数上限: 20次
-- BIN产品配置表（简化示例）
CREATE TABLE bin_product_map (
bin_prefix VARCHAR(8) PRIMARY KEY, -- BIN前缀
brand VARCHAR(20) NOT NULL, -- 卡组织品牌
card_type ENUM('DEBIT','CREDIT','PREPAID','VIRTUAL'),
product_name VARCHAR(100), -- 卡产品名称
single_limit DECIMAL(15,2) DEFAULT 50000, -- 单笔限额(元)
daily_limit DECIMAL(15,2) DEFAULT 100000, -- 日累计限额
monthly_limit DECIMAL(15,2) DEFAULT 500000, -- 月累计限额
fx_markup DECIMAL(5,4) DEFAULT 0.0050, -- 换汇加价率
require_3ds BOOLEAN DEFAULT TRUE, -- 是否强制3DS
status ENUM('ACTIVE','SUSPENDED','CLOSED'),
created_at TIMESTAMP,
updated_at TIMESTAMP
);
-- 多BIN策略：按卡产品路由
SELECT * FROM bin_product_map WHERE brand = 'Mastercard' AND status = 'ACTIVE';
| 卡产品名称 | BIN前缀 | 卡组织 | 卡类型 | 单笔限额 | 日限额 | 换汇加价 |
|---|---|---|---|---|---|---|
| 企业差旅普卡 | 453201 | Visa | 贷记 | ¥20,000 | ¥50,000 | 0.50% |
| 企业差旅金卡 | 453202 | Visa | 贷记 | ¥50,000 | ¥200,000 | 0.30% |
| 企业采购卡 | 453203 | Visa | 贷记 | ¥200,000 | ¥500,000 | 0.20% |
| 营销场景虚拟卡 | 522211 | MC | 预付 | ¥5,000 | ¥10,000 | 0.80% |
| 员工福利卡 | 522212 | MC | 预付 | ¥3,000 | ¥5,000 | 1.00% |
| 跨境平台结算卡 | 625001 | 银联 | 借记 | ¥100,000 | ¥500,000 | 0.15% |
BIN是风控系统的第一道屏障。在交易链路中，BIN检查发生在最前端，效率最高：
交易到达 → BIN查询 → BIN级黑/白名单 → 卡产品级风控 → 账户级风控 → 行为分析
↓ ↓ ↓ ↓ ↓ ↓
T0 T0.01 T0.02 T0.05 T0.2 T0.5
| 规则类型 | 说明 | 配置示例 |
|---|---|---|
| BIN白名单 | 仅允许指定BIN的交易通过 | 仅BIN 453201-453205可交易 |
| BIN黑名单 | 禁止指定BIN的所有交易 | 冻结BIN 522211下所有卡片 |
| MCC限制 | 按BIN限制商户类别 | BIN 453201禁止赌博类MCC |
| 地区限制 | 按BIN限制交易国家 | BIN 522211仅限亚太地区 |
| 交易类型限制 | 按BIN限制交易方式 | BIN 453203禁止ATM取现 |
| 速度限制 | 按BIN整体交易速率 | BIN 522211单日≤1000笔 |
| 金额阈值 | 按BIN的单笔/日累计 | BIN 453201单笔≤$50,000 |
BIN运营团队需要实时监控以下指标：
| 指标 | 行业基准（健康） | 预警阈值 | 危险阈值 |
|---|---|---|---|
| 授权成功率 | > 95% | < 90% | < 80% |
| 欺诈率（chargeback率） | < 0.1% | > 0.3% | > 0.65% |
| 平均响应时间 | < 500ms | > 800ms | > 2s |
| 拒付比例 | < 0.5% | > 1.0% | > 2.5% |
| 3DS挑战率 | 2-5% | > 10% | > 20% |
| 跨地区交易占比 | < 15% | > 30% | > 50% |
真实案例： 某发卡平台发现BIN 522212下的员工福利卡Chargeback率在一天内从0.05%飙升至0.8%。分析发现，该BIN被用于购买虚拟商品（MCC 5816），且集中在东南亚IP地址。风控策略调整为：对该BIN下所有卡新增3DS认证要求，并在MCC 5816上设置单卡日限$100。Chargeback率在2小时内回落至0.08%。
成熟的发卡业务通常持有多个BIN，用于不同的业务场景。
| 策略 | 描述 | 适用场景 |
|---|---|---|
| 品牌分流 | Visa用于北美，MC用于欧洲，银联用于亚太 | 降低单一卡组织依赖 |
| 产品分层 | 普卡BIN发卡量大但限额低，金卡BIN审核严但额度高 | 差异化定价和风控 |
| 地区分流 | 中国BIN用于人民币交易，香港BIN用于港币交易 | 满足监管合规要求 |
| 成本优化 | 不同BIN的清算费率不同，路由到成本最低的BIN | 控制交易成本 |
| 备用BIN | 主BIN出问题后切换到备用BIN | 高可用性保障 |
接收交易请求
↓
提取卡BIN（前6/8位）
↓
路由决策引擎：
├── 卡组织选择策略（费用优先 / 成功率优先 / 均衡）
├── 地区合规检查（该BIN是否允许在交易地区使用）
├── 成本计算（选择最优费率的BIN）
└── 健康检查（排除异常BIN）
↓
返回路由结果（选定BIN + 卡组织路径）
↓
执行交易
费用对比示例：
| 卡组织 | 交换费（%+固定） | 授权费 | 跨境费 | 最适合地区 |
|---|---|---|---|---|
| Visa | 1.15% + $0.05 $0.01 | 0.40% | 北美、全球 | |
| Mastercard | 1.10% + $0.04 $0.01 | 0.35% | 欧洲、亚太 | |
| 银联 | 0.60% + ¥0.25 | ¥0.01 | 无 | 中国大陆 |
| JCB | 0.80% + $0.03 $0.01 | 0.30% | 日本 |
注意：上述费率为代理商参考费率，实际费率取决于发卡行与卡组织的协议等级和交易量。
BIN数据的核心需求是低延迟（通常 < 10ms），因为每次卡交易都需要实时查询BIN信息。
常见BIN数据存储方案对比：
| 方案 | 延迟 | 查询量级 | 优点 | 缺点 |
|---|---|---|---|---|
| Redis缓存 | < 5ms | 百万级QPS | 极低延迟，高并发 | 占用内存，需维护一致性 |
| 进程内HashMap | < 0.1ms | 千万级QPS | 零网络开销 | 启动加载慢，更新需重启 |
| 数据库 | 10-100ms | 万级QPS | ACID强一致 | 延迟高，不适合高频查询 |
| Trie树（前缀树） | < 1ms | 百万级QPS | BIN前缀匹配最优 | 实现复杂 |
BIN查询数据模型（Java示例）：
public class BinRouter {
// 使用Trie树优化BIN前缀匹配
private final PrefixTrie<BinInfo> binTrie;
public BinInfo lookup(String cardNumber) {
String bin = cardNumber.substring(0, 6);
return binTrie.search(bin);
}
// BIN查询结果
public record BinInfo(
String binCode,
String brand, // VISA, MC, CUP, JCB, AMEX
String cardType, // DEBIT, CREDIT, PREPAID
String issuerName, // 发卡行名称
String countryCode, // ISO 3166-1 alpha-2
int cardLength, // 卡号长度
String productCode, // 卡产品代码
boolean isCommercial, // 是否商务卡
boolean isVirtual // 是否虚拟卡
) {}
}
| 报表类型 | 频率 | 内容 | 使用部门 |
|---|---|---|---|
| BIN交易统计日报 | 每日 | 按BIN的成功/失败/拒付统计 | 风控 |
| BIN欺诈分析月报 | 每月 | Chargeback排名Top 10 BIN | 风控/合规 |
| BIN成本分析表 | 每周 | 各BIN的卡组织费用分析 | 财务 |
| BIN利用率报告 | 每月 | 已发卡数量、活跃卡数量 | 运营 |
| BIN余额监控 | 实时 | 各BIN待结算余额 | 资金 |
| BIN卡产品健康度 | 每周 | 成功率、响应时间、用户增长 | 产品 |
┌──────────────────────────────────────┐
│ BIN 监控中心 │
├──────────────┬───────────────────────┤
│ 交易监控 │ 风控监控 │
│ ├ 授权成功率 │ ├ Chargeback率 │
│ ├ 交易量趋势 │ ├ 欺诈交易占比 │
│ ├ 平均响应时间 │ ├ 3DS失败率 │
│ └ 失败原因分布 │ └ 风控拒绝率 │
├──────────────┼───────────────────────┤
│ 资金监控 │ 运营监控 │
│ ├ 结算延迟 │ ├ 卡片激活率 │
│ ├ 换汇损益 │ ├ 卡片使用率 │
│ └ 头寸余额 │ └ 卡片生命周期状态 │
└──────────────┴───────────────────────┘
alerts:
- name: bin_success_rate_drop
metric: authorization_success_rate
condition: < 90%
window: 5min
action: [webhook_slack, send_email]
severity: critical
- name: bin_chargeback_spike
metric: chargeback_rate
condition: > 0.5%
window: 1h
action: [webhook_slack, create_incident]
severity: high
- name: bin_response_slow
metric: p99_response_time
condition: > 2s
window: 5min
action: [webhook_slack]
severity: warning
申请 → 激活 → 发卡期 → 成熟期 → 萎缩期 → 冻结 → 回收
↓ ↓ ↓ ↓ ↓ ↓ ↓
申请 BIN 卡片量 卡片量 卡片量 停止 BIN
成功 开通测试 快速增长 稳定运营 开始下降 新发卡 归还
卡组织
| 场景 | 触发条件 | 操作 |
|---|---|---|
| BIN利用率过低 | 6个月内发卡<1000张 | 合并该BIN下的卡产品，考虑回收 |
| BIN欺诈率过高 | Chargeback率>2%且无法控制 | 立即冻结BIN，发起争议调查 |
| BIN成本过高 | 清算费用>收益 | 评估是否停用或替换 |
| 合规风险 | 制裁名单关联或监管处罚 | 紧急停用 |
BIN回收流程：
from fastapi import FastAPI, HTTPException
import redis.asyncio as redis
import json
app = FastAPI()
r = redis.Redis(host='localhost', port=6379, decode_responses=True)
# 本地BIN缓存（HashMap）
BIN_CACHE: dict[str, dict] = {}
@app.on_event("startup")
async def load_bin_cache():
"""启动时从Redis加载所有活跃BIN到本地缓存"""
keys = await r.keys("bin:*")
for key in keys:
data = await r.get(key)
if data:
bin_prefix = key.split(":")[1]
BIN_CACHE[bin_prefix] = json.loads(data)
@app.get("/bin/lookup/{card_number}")
async def lookup_bin(card_number: str):
"""BIN查询接口（要求<5ms响应）"""
if len(card_number) < 6:
raise HTTPException(400, "卡号长度不足")
bin_prefix = card_number[:6]
# 1. 本地缓存命中（最快路径）
if bin_prefix in BIN_CACHE:
return BIN_CACHE[bin_prefix]
# 2. Redis查询（次优路径）
data = await r.get(f"bin:{bin_prefix}")
if data:
bin_info = json.loads(data)
BIN_CACHE[bin_prefix] = bin_info # 回填缓存
return bin_info
# 3. 数据库查询（最慢路径）
# ...
raise HTTPException(404, f"BIN {bin_prefix} 未找到")
BIN数据需要定期从卡组织和数据供应商更新：
| 更新源 | 更新频率 | 数据量 | 传输方式 |
|---|---|---|---|
| Visa BIN表 | 每月 | ~50,000条 | FTP/SFTP下载 |
| Mastercard BIN表 | 每月 | ~60,000条 | API/SFTP |
| 银联BIN表 | 每周 | ~30,000条 | 银联平台API |
| 第三方（如BINBase） | 实时/每日 | 全球~300,000条 | REST API |
批量更新伪代码：
async def update_bin_database(bin_records: list[dict]):
"""批量更新BIN数据"""
pipe = r.pipeline()
for record in bin_records:
key = f"bin:{record['bin_prefix']}"
pipe.set(key, json.dumps(record))
pipe.expire(key, 86400 * 45) # 45天过期，强制刷新
await pipe.execute()
# 更新本地缓存（热更新）
for record in bin_records:
BIN_CACHE[record['bin_prefix']] = record
print(f"已更新 {len(bin_records)} 条BIN记录")
| 场景 | 缓存策略 | P50 | P99 | QPS |
|---|---|---|---|---|
| 本地HashMap命中 | 全部在内存 | 0.05ms | 0.2ms | >500,000 |
| Redis命中 | 缓存穿透 | 1.2ms | 5ms | 50,000 |
| Redis未命中-数据库 | 冷启动 | 15ms | 50ms | 5,000 |
| Redis未命中-空结果 | BIN不存在 | 15ms | 100ms | 1,000 |
生产环境建议采用"本地缓存+Redis二级缓存+数据库兜底"的三层架构，确保P99延迟<5ms。
| 卡组织 | 连接方式 | 接口类型 | 主要功能 |
|---|---|---|---|
| Visa | VPN/SFTP | VAP(通过CyberSource) | BIN注册、交易监控、费用报表 |
| Mastercard | VPN/SFTP | MDES、McM | BIN管理、Token化服务、清算数据 |
| 银联 | 专线 | CUPS API | BIN注册、密钥管理、TMS终端管理 |
| JCB | API | JCB Portal | BIN注册、对账报表 |
发卡机构需要遵守以下BIN管理规定：
PCI DSS对BIN数据的要求：
| 数据类型 | 存储限制 | 加密要求 | 访问控制 |
|---|---|---|---|
| 完整卡号(PAN) | 必要最小化 | 强加密(AES-256) | 角色级别 |
| BIN前6位 | 允许明文 | 不需要 | 可开放 |
| BIN后4位 | 允许明文 | 不需要 | 可开放 |
| CVV/CVC | 禁止存储 | — | — |
| 磁条数据 | 禁止存储 | — | — |
某跨境支付平台通过BIN赞助模式发行Visa和Mastercard卡，采用三路BIN策略：
| BIN | 卡组织 | 路由比例 | 场景 | 费用率 |
|---|---|---|---|---|
| 453201 | Visa | 45% | 北美广告费支付 | 1.25%+$0.05 |
| 522211 | Mastercard | 35% | 欧洲SaaS订阅 | 1.10%+$0.04 |
| 625001 | 银联 | 20% | 国内供应商付款 | 0.60%+¥0.25 |
路由优化算法： 系统在每次交易发起时，根据商户所在地、支付金额、预计DCC费用，自动选择成本最低的BIN路径。每月节省约$12,000的卡组织费用。
某金融科技公司的虚拟卡BIN（522210）在发现刷单攻击后的应对：
16:00 - 系统检测到BIN 522210下的Chargeback率从0.1%升至1.2%
16:01 - 自动冻结该BIN下的所有新卡
16:02 - 分析发现攻击模式：批量开卡后在虚拟商品网站测试
16:05 - 开启该BIN的3DS强制认证
16:10 - Chargeback率稳定在0.3%
次日 - 恢复发卡，但新增MCC限制和速度限制
损失对比： 人工响应需要约4小时，自动响应15分钟，预计减少损失$8,500。
| KPI | 优秀 | 良好 | 需改进 |
|---|---|---|---|
| BIN授权成功率 | >98% | >95% | <90% |
| BIN Chargeback率 | <0.05% | <0.15% | >0.65% |
| BIN利用率 | >80% | >60% | <30% |
| BIN查询P99延迟 | <2ms | <5ms | >10ms |
| BIN级风控命中率 | >0.5% | >0.2% | <0.1% |
相关页面：