關於信用卡 BIN 碼的合規處理，看完這篇就懂（儲存與顯示篇）
近年來，隨著發卡量激增，傳統 6 碼 BIN（卡號前 6 碼，全稱 Bank Identification Number）逐漸「不夠用」，8 碼 BIN 開始普及。這也讓不少支付產業從業人員感到困惑：
「8 碼 BIN 到底能不能存？」
「給客服看『前 8 後 4』算違規嗎？」
「6 碼與 8 碼，處理邏輯真有差別嗎？」
「給客服看『前 8 後 4』算違規嗎？」
「6 碼與 8 碼，處理邏輯真有差別嗎？」
今天我們拋開複雜理論，只圍繞大家最關心的「顯示（看）」與「儲存（存）」兩大情境，拆解 PCI DSS v4.0.1 標準下的合規實務作法。
一、顯示篇：我能「看」到多少碼？（PCI DSS 隱碼處理安全上限）
這是客服、風控人員最常問的問題——PCI DSS 的核心原則只有一句話：非必要，不顯示全碼。
1. 安全的「通用顯示格式」
根據 PCI DSS v4.0.1 要求，螢幕或紙本顯示卡號時必須進行隱碼處理（Masking），業界公認的「安全上限」是：「BIN 碼前綴 + 後 4 碼」
- 6 碼 BIN 卡片：123456******1234（前 6 後 4）
- 8 碼 BIN 卡片：12345678****1234（前 8 後 4）
結論：無論 6 碼還是 8 碼，「前 BIN + 後 4 碼」是目前最穩妥的顯示規則，既滿足業務識別需求，又不觸碰合規紅線。
2. 什麼時候能看超過隱碼的安全上限（包含完整卡號）？
可以，但必須滿足兩個條件：
- 有明確的業務需求（例如風控調查異常交易）；
- 經過文件化授權（僅特定角色可見，且全程留存稽核軌跡）。
最佳實務：系統需實作「動態遮蔽（Dynamic Masking）」——
一般客服驗證身分：只顯示後 4 碼（***********1234）；
觸發風控規則（如偽冒交易查核）：才依需求展示更多卡號（包含完整卡號），且系統自動記錄「誰看了、什麼時候看、為什麼看」。
一般客服驗證身分：只顯示後 4 碼（***********1234）；
觸發風控規則（如偽冒交易查核）：才依需求展示更多卡號（包含完整卡號），且系統自動記錄「誰看了、什麼時候看、為什麼看」。
二、儲存篇：我能「存」哪些資料？（卡號截斷儲存規範）
除了加密儲存，最常被拿來儲存的就是部分卡號，例如大家常說的「前 6 後 4」，在 PCI DSS 中，這種方式稱為「截斷（Truncation）」。
截斷儲存的「紅線」：6 碼 vs 8 碼
為了識別發卡行以進行推廣、折扣、行銷或統計等作業，以及為了呈現給客戶、帳務、交易紀錄等需求，不少系統都會儲存「截斷後的卡號」。因此這裡依據各國際發卡組織的「可儲存」格式進行說明：
卡號截斷格式規範
| 卡號 / BIN 長度 | 發卡組織 | 可接受的截斷格式 |
|---|---|---|
| 16 碼卡號 6 碼或 8 碼 BIN |
Discover JCB Mastercard UnionPay Visa |
至少移除 4 碼 最多儲存前 8 碼 + 其他任意 4 碼 |
| 15 碼卡號 | American Express | 至少移除 5 碼 最多儲存前 6 碼 + 後 4 碼 |
| < 15 碼卡號 | Discover | 最多儲存前 6 碼 + 其他任意 4 碼 |
允許儲存方式與建議對比
| 允許儲存方式 | 範例（16 碼卡號） | 建議 |
|---|---|---|
| 6 碼 BIN + 後 4 碼 | 456318******1234 | 中間空缺 6 碼，猜測成本高（猜中機率約 1/100,000） |
| 8 碼 BIN + 後 4 碼 | 52395310****1234 | 中間僅剩 4 碼未知，結合卡號檢核規則後猜測機率顯著提升（約 1/1,000） |
重點提醒：
雖然 PCI SSC 針對多數發卡組織允許儲存 8 碼 BIN，但從資料安全（Data Security）的角度出發，除非有明確的業務需求，否則一般仍建議儲存為「前 6 後 4」即可，以降低資料外洩風險。
雖然 PCI SSC 針對多數發卡組織允許儲存 8 碼 BIN，但從資料安全（Data Security）的角度出發，除非有明確的業務需求，否則一般仍建議儲存為「前 6 後 4」即可，以降低資料外洩風險。
