信用卡 BIN 合规指南 | PCI DSS 对 8 位 BIN 存储与显示的规定

卡 BIN 合规指南：卡号（PAN）的存储与显示

近年来，发卡量激增已使传统的 6 位 BIN（银行识别码）空间耗尽，加速了向 8 位 BIN 的转换。这项迁移让许多支付、电商与安全从业人员面临关键的合规问题：

「存储完整的 8 位 BIN 是否合规？」
「向客服显示「前 8 码、后 4 码」是否违反 PCI DSS？」
「处理 6 位与 8 位 BIN 时，实际的逻辑差异是什么？」

本文跳过复杂的理论，直接拆解 PCI DSS v4.0.1 标准下的实务合规要求，聚焦于两个最常见的作业场景：卡号显示（遮蔽）与存储（截断）。

1. 显示：卡号可以显示到哪个程度？（PCI DSS 遮蔽上限）

这是客服与欺诈分析人员最常提出的问题。PCI DSS 对卡号显示的核心原则很简单：除非有正当的业务需求，否则不得显示完整卡号。

1.1 安全的「通用显示格式」

依据 PCI DSS v4.0.1，主账号（PAN）在屏幕、纸质单据或日志上显示时必须遮蔽。普遍接受的显示「最大允许位数」为 「BIN 前缀 + 后 4 码」。

结论：无论是 6 位或 8 位 BIN，显示「BIN + 后 4 码」都是最安全的基准。它能满足作业上的路由与识别需求，又不会触碰合规红线。

1.2 什么情况下允许查看超过遮蔽上限的内容？

查看完整卡号是被允许的，但必须同时满足两项严格条件：

最佳实践：在系统中实施动态遮蔽
层级 1（一般客服）：仅显示后 4 码（***********1234）以进行基本身份验证。
层级 2（欺诈侦测／风险管理）：仅在触发风险规则时（例如查证盗刷卡片），系统才会显示更多位数（或完整卡号），并自动记录「何人存取、何时存取、为何存取」的严格审计轨迹。

2. 存储：可以保留哪些数据？（卡号截断规则）

除了强加密之外，存储部分卡号最常见的方法是截断（Truncation）。这让系统能保留部分卡号以支持业务逻辑，而无须保护完整卡号。

2.1 截断界线：6 位 vs. 8 位

为了便于营销、折扣、交易路由与客户单据，系统通常会存储「截断后的卡号」。可接受的截断格式因卡片品牌而略有差异。以下是标准指引：

可接受的卡号截断格式

• 16 位卡号，6 位或 8 位 BIN — Discover、JCB、Mastercard、UnionPay、Visa：至少移除 4 码。最大可存储：前 8 码 + 其他任意 4 码。
• 15 位卡号 — American Express：至少移除 5 码。最大可存储：前 6 码 + 后 4 码。
• 15 位以下卡号 — Discover：最大可存储：前 6 码 + 其他任意 4 码。

存储格式与安全影响

• 6 位 BIN + 后 4 码 — 456318******1234：缺少 6 码。暴力破解的成本很高（约 1/100,000 的概率）。
• 8 位 BIN + 后 4 码 — 52395310****1234：仅剩 4 码未知。若结合卡号验证规则（Luhn 算法），暴力破解的概率将显著提高（约 1/1,000）。

重要安全提醒：
尽管 PCI SSC 与多数卡片品牌允许存储 8 位 BIN，但从严格的数据安全角度来看，除非您的业务逻辑明确需要 8 位 BIN，否则强烈建议继续仅存储「前 6 码 + 后 4 码」。存储越多位数，一旦发生数据外泄，卡号被重建的风险将呈指数级上升。