クレジットカードBINコンプライアンスガイド｜8桁BINの保存・表示に関するPCI DSSの規定

カードBINコンプライアンスガイド：PANの保存と表示

近年、カード発行枚数の急増により従来の6桁BIN（Bank Identification Number）の空間が枯渇し、8桁BINへの移行が加速しています。この移行により、決済、EC、セキュリティの実務担当者の間では、コンプライアンス上の重要な疑問が生じています。

「8桁BINをそのまま保存してもコンプライアンス上問題ないのか」
「カスタマーサポートに『先頭8桁＋末尾4桁』を表示することはPCI DSS違反にあたるのか」
「6桁BINと8桁BINでは、取扱いのロジックに実際どのような違いがあるのか」

本記事では複雑な理論は脇に置き、PCI DSS v4.0.1における実務上のコンプライアンス要件を、最も一般的な2つの運用シーン、すなわちPANの表示（マスキング）と保存（切り捨て）に焦点を当てて整理します。

1. 表示：PANはどこまで見せてよいのか（PCI DSSのマスキング上限）

これはカスタマーサポートや不正調査の担当者からよく寄せられる質問です。PANの表示に関するPCI DSSの原則は単純です。正当な業務上の必要がない限り、PANの全桁を表示してはなりません。

1.1 安全な「共通表示フォーマット」

PCI DSS v4.0.1によれば、プライマリアカウント番号（PAN）は、画面、紙のレシート、ログに表示する際にマスキングしなければなりません。表示が広く認められている「最大桁数」は「BINプレフィックス＋末尾4桁」です。

結論：6桁BINでも8桁BINでも、「BIN＋末尾4桁」の表示が最も安全な基準となります。これにより、業務上のルーティングや本人識別のニーズを満たしつつ、コンプライアンス上のレッドラインを越えずに済みます。

1.2 マスキング上限を超えて閲覧できるのはどのような場合か

PANの全桁を閲覧することは可能ですが、厳格な2つの条件を満たす場合に限られます。

ベストプラクティス：システムに動的マスキングを実装する
レベル1（一般のカスタマーサポート）：本人確認のために末尾4桁のみを表示します（***********1234）。
レベル2（不正検知・リスク管理）：リスクルールが発動した場合（盗難カードの確認など）に限り、システムがより多くの桁数（または全桁）を開示し、「誰が、いつ、なぜ参照したか」の厳格な監査証跡を自動的に記録します。

2. 保存：どのデータを保持できるのか（PANの切り捨て規定）

強力な暗号化のほかに、PANの一部を保存する最も一般的な方法が切り捨て（Truncation）です。これにより、PAN全体を保護することなく、業務ロジックに必要な範囲でカード番号の一部を保持できます。

2.1 切り捨ての境界：6桁と8桁の比較

マーケティング、割引、取引ルーティング、顧客向けレシートなどの目的で、システムは「切り捨てたPAN」を保存することがあります。許容される切り捨てのフォーマットはカードブランドごとに若干異なります。標準的な指針は以下のとおりです。

許容されるPAN切り捨てフォーマット

• 16桁PAN、6桁または8桁BIN — Discover、JCB、Mastercard、UnionPay、Visa：少なくとも4桁を削除すること。保存できる最大範囲は、先頭8桁＋任意の他の4桁。
• 15桁PAN — American Express：少なくとも5桁を削除すること。保存できる最大範囲は、先頭6桁＋末尾4桁。
• 15桁未満のPAN — Discover：保存できる最大範囲は、先頭6桁＋任意の他の4桁。

保存フォーマットとセキュリティ上の含意

• 6桁BIN＋末尾4桁 — 456318******1234：6桁が欠落しています。総当たり攻撃のコストは高く、確率はおよそ10万分の1です。
• 8桁BIN＋末尾4桁 — 52395310****1234：不明な桁は4桁のみです。PANの検証ルール（Luhnアルゴリズム）と組み合わせると、総当たり攻撃の成功確率はおよそ1,000分の1まで大きく上昇します。

重要なセキュリティ上の注意：
PCI SSCおよび大半のカードブランドは8桁BINの保存を認めていますが、厳密なデータセキュリティの観点からは、業務ロジック上8桁BINが明確に必要でない限り、引き続き「先頭6桁＋末尾4桁」のみを保存することを強く推奨します。保存する桁数が増えるほど、情報漏えい時にPANが再構成されるリスクは指数関数的に高まります。