银行卡上的长号码通常叫 PAN（Primary Account Number，主账号）。 当前 ISO/IEC 7812-1:2017 定义了发卡机构识别和 PAN 的编号体系；在 8 位 IIN 体系下， PAN 仍然是可变长度，标准范围为 10～19 位。现实世界里最常见的是 15、16、19 位等具体长度， 不同品牌和发卡体系会采用不同格式。

这里最容易混淆的是 MII（Major Industry Identifier）。 MII 是 IIN 的第一位，用来表示一个较宽泛的行业类别；它并不是一个独立放在 IIN 前面的字段。 所以更准确的结构是：

IIN（Issuer Identification Number）是 ISO/IEC 7812 的正式术语。 支付行业更习惯说 BIN（Bank Identification Number）。 今天讨论银行卡时，两者经常被当作近义词使用；不过 “IIN” 更准确，因为发行主体并不一定只限传统银行。

一个经过授权和及时更新的 BIN / Account Range 数据源，通常可以给支付系统提供诸如： 发卡机构、发行国家或地区、资金来源类型、产品代码、账单币种以及 PAN / Token 等属性。 这些信息会成为支付决策的重要输入。

为什么不能只看第一位就判断 Visa、Mastercard、银联？

第一位首先是 MII，不是一个全球统一的 “Card Scheme ID”。 的确有一些非常有辨识度的品牌范围，例如 Visa 大量使用 4 开头， American Express 常见 34 / 37，UnionPay 常见 62； 但 Mastercard 除 51～55 外还有 222100～272099 的 2-series。 Discover 也存在 6011 等 6 开头范围。

上表用于理解“品牌范围必须匹配完整前缀”，并不是一张完整的全球品牌路由表。 生产系统应使用卡组织、收单机构、处理商或获授权的数据源。

只看 BIN，很多时候只能看到第一层信息。现代支付网络会继续把一个 BIN 细分成更具体的账号区间， 并把产品类型、资金属性、处理参数等信息定义在更细粒度上。

Visa 的公开资料给了一个非常清楚的例子：Visa 的 BIN 可以是 PAN 前 6 或前 8 位， 但 Visa 的 Account Range 是 PAN 的前 9 位，大量处理属性定义在 Account Range 层。 当 8 位 BIN 使用 9 位 Account Range 时，一个 8 位 BIN 就天然对应 10 个 9 位 Account Range。

发行机构当然可以在内部系统里继续细分账户，但如果希望某段号码在支付网络层拥有独立的产品属性、 路由或处理配置，就需要进入对应卡组织、处理商和项目的网络配置体系。

随着发卡机构、数字银行、预付项目、虚拟卡和 FinTech 发卡计划不断增加， 6 位 IIN 的号码空间越来越紧张。ISO 因此修订 ISO/IEC 7812， 将新 IIN 从 6 位扩展为 8 位。

“扩两位”为什么能缓解资源压力？

对一个既有 6 位前缀来说，再增加两位数字，理论上可以细分为 100 个不同的 8 位前缀。ISO 当年的说明也指出，既有 6 位 IIN 可以对应一个包含 100 个 8 位 IIN 的号码块。

如果只做一个固定 16 位 PAN 的理论例子：6 位 IIN 后，扣除最后一位校验位， 还剩 9 位账户识别数字；8 位 IIN 后则剩 7 位。 因此单个前缀下的理论账号组合从 10⁹ 缩小到 10⁷， 但可分配前缀数量大幅增加。实际发行容量还会受到保留范围、产品划分和网络规则影响。

对支付网关、收单机构、处理商和卡组织来说，BIN / Account Range 的价值不是“查归属地”， 而是让系统在极短时间内获得一组与这张卡相关的处理属性。

① 路由与支付成功率

支付处理商可能结合卡片网络、发行国家、商户所在地、可用收单关系、网络成本和实时风控， 选择符合规则的处理路径。BIN / Range 是其中一个输入，但不是“看到某国 BIN 就必然走某条线路”的单一开关。

② Interchange 与产品属性

资金来源类型、产品类型、商户类别、交易场景、地区和监管状态都可能影响 interchange qualification。 因此“高端卡一定固定收多少费率”并不准确；支付网络通常根据一组规则共同决定费率和资格。

③ DCC：动态货币转换

当持卡人在境外消费时，支持 DCC 的商户或 ATM 可能提供“按商户当地币种支付”或“按持卡人账单币种支付”的选择。 BIN / Range 数据里的 Issuer Billing Currency 可以参与判断，但币种不同并不等于 DCC 必然触发。 商户 / ATM 需要实际提供 DCC 服务，并按卡组织规则展示本币和持卡人币金额、汇率和额外费用， 最终由持卡人选择接受或拒绝转换。

④ 风控

发行国家、Funding Source、产品类型等可以成为风控特征。 例如系统可以把“发卡国与当前设备环境明显不一致”作为一个风险信号， 但不能仅凭这一项就认定欺诈。旅行、跨境消费、代理网络、海外订阅等都可能产生正常差异。

美国 Regulation II 对 debit routing 有一项非常重要的网络非排他要求： 发行方不能把电子借记交易限制在少于 两个互不隶属的支付卡网络， 同时也不能妨碍商户在发行方已经启用的网络之间选择路由。

这不是“卡面上必须印两个 Logo”的视觉要求，而是支付网络可用性和商户路由权的问题。 2023 年起生效的规则更新还明确覆盖 card-not-present 等交易场景。

Regulation II 还对特定大型发行方的借记卡 interchange fee 设置上限： 基础结构是 21 美分 + 交易金额的 5 个基点； 符合反欺诈标准的发行方可再获得最高 1 美分的 fraud-prevention adjustment。 小型发行方和某些政府 / 预付项目在 interchange limitation 上存在豁免，因此不能把这组数字理解成“美国所有借记卡统一费率”。

很多数字银行、跨境支付产品、企业卡平台和虚拟卡产品，并不是自己从零变成一家传统银行。 更常见的做法，是和具有相应资格的发行机构、Sponsor Bank、处理商、Program Manager 以及卡组织合作， 共同搭建一个发卡 Program。

日常交流里常把 BIN Sponsorship 简化成“FinTech 租一个 BIN 或某段 Account Range”。 这个比喻方便理解号码空间被某个 Program 使用，但法律和运营上远比“租号码”复杂： KYC / AML、资金管理、争议处理、卡组织合规、数据安全和监管责任仍然要按照项目结构承担。

BIN 本身不是秘密，但完整 PAN 属于需要保护的账户数据。 PCI DSS 对“显示 PAN”和“存储 PAN”分别使用不同概念： Masking 解决屏幕 / 报表上展示多少位， Truncation 是把存储中的部分 PAN 永久截断。

“前 6 后 4”仍然是一种非常常见、兼容性很强的保守格式。 如果业务需要利用 8 位 BIN，应先明确当前需求属于显示、存储、路由还是数据分析， 再依据收单机构、支付品牌和 PCI DSS 的具体要求设计。

BIN Attack / Enumeration Attack 是什么？

攻击者可能利用银行卡号码结构和自动化请求，对账号、有效期等支付凭据进行大规模枚举， 再从授权响应中寻找有效组合。防御通常依赖速率限制、行为聚合、设备与网络信号、 风险模型、3DS 以及卡组织的专用风险能力。 这里真正需要保护的不是“一个神秘 BIN”，而是完整支付凭据和交易系统的抗自动化能力。

EMV Payment Tokenisation 的核心思想非常直观： 把真实 PAN 替换成一个可以参与支付的替代值——Payment Token。 更重要的是，这个 Token 可以被限制在特定设备、商户或交易场景中使用。

这样做最大的安全收益是：即使某个 Token 被泄露，它通常也受到 Token Domain Restriction Controls 限制， 不能像一张完全暴露的 PAN 那样在任意环境中使用。

Token BIN / Token Account Range 是什么？

支付网络可以为 Payment Token 管理专门的 Token Account Range，并在授权 BIN 数据中提供 PAN / Token Indicator、Token Range 等信息。 但并不存在一个可以写进科普文章的“Visa 全球统一 4802 Token BIN”规则； 具体 Token Range 属于网络、发行方和 Token Programme 的配置。

Apple 的平台安全文档明确说明：把银行卡加入 Apple Wallet 时， 完整卡号不会存储在设备或 Apple Pay 服务器中。 发卡机构或其授权服务提供方会为设备创建一个唯一的 Device Account Number，加密发送给 Apple，并存入设备的 Secure Element。

每笔 Apple Pay 支付还会生成 transaction-specific 的支付 cryptogram。 支付网络和发行方可以据此验证交易。至于 Token 在网络内部何时映射到 underlying PAN、 哪些报文字段继续携带 Token、授权消息怎样组织，会因支付网络和实现模式而不同； 对科普理解来说，抓住“设备凭据 + 动态密文 + 受控网络映射”就够了。

Tokenization 带来了一个新的识别难题： 同一个 underlying PAN 可以产生多个不同 Payment Token。 如果用户在 iPhone、Apple Watch 和某个网站分别使用不同 Token， 单看这些 Token 值，它们看起来可能完全是三张不同的支付凭据。

EMVCo 的 Payment Account Reference（PAR） 就是为这种场景设计的。它可以帮助生态把使用 EMV Payment Token 的交易与 underlying PAN 关联起来， 支持反欺诈、忠诚度、交通等需要跨支付凭据识别同一账户的场景。

PAR 本身不是一张可以拿去刷卡的 PAN。 EMVCo 还维护 BIN Controller ID（BCID）注册机制，PAR 的前 4 个字符用于标识负责 PAR 治理的 BIN Controller。

这里要把“国际标准”和“支付网络内部的 BIN 管理”分成两个层次理解。

因此，不能简单理解成“ISO 把一大块号码批发给卡组织，卡组织再零售给银行”。 ISO/IEC 7812 的全球注册框架和 Visa、Mastercard 等支付网络内部的 BIN 许可 / 配置体系是相互衔接但不同的治理层。