課題と判断基準
技術・運用設計の基準日：2026年9月26日
不正取引を防ぐためにルールを強化したところ、決済完了率が下がりました。「自分のカードなのになぜ支払えないのか」という問い合わせも増えています。ただしルールを戻すと、防ごうとしていた被害が再発しかねません。遮断件数と決済完了率だけでは必要な対応を決められません。
まず自社FDSが遮断した取引、追加確認で止まった取引、PGやカード発行会社が拒否した取引を分けます。 そのうえで同じ取引集団の決済完了、確認済み不正、顧客離脱、審査遅延を一緒に見ます。危険信号をすべて遮断したり、顧客の不便を理由にすべて許可したりせず、各取引で何を追加確認できるかに応じて処理を分けます。
本記事のFDSは不正利用の可能性を評価する不正取引検知システムを指します。判断主体が常に加盟店とは限りません。Toss Paymentsも契約加盟店の取引を分析して不正決済を識別・遮断すると説明しています。決済拒否だけで自社の変更ルールを原因と決めてはいけません。[1]
決済が止まった段階と判断主体を先に特定する
認証成功画面、PGの決済承認応答、カード発行会社の承認、商品提供完了は別の出来事です。Toss Paymentsの注文書型決済連携ガイドは購入者の認証とサーバー側の決済承認を分けています。利用者取消のPAY_PROCESS_CANCELEDとカード会社拒否のREJECT_CARD_COMPANYも別のエラーです。どちらもエラー名だけで自社FDSの誤検知とは判断できません。[2]
Stripeもリスク評価と金融機関の拒否情報を分け、ネットワークに送る前に遮断される決済を例示しています。FDSの介入時点は供給者と連携方式ごとに確認します。[3]
運用記録には取引参照値とともに、段階、判断主体、結果コード、発生時刻、適用ポリシー版を残します。PGが詳細理由を返さなければ「PG応答上は拒否・詳細原因未確認」と保存します。不明な原因を「不正検知成功」で埋めないようにします。
この区分は指標の起点にもつながります。サーバー応答より先に顧客が実際に得た結果を定義する方法は、ユーザージャーニー中心の監視設計でも扱っています。
取引シグナルからリスク判断・再検討へ — アカウント、端末、決済行動を判定ルールにまとめ、審査結果をルールの調整に反映します。
一つの承認率ではなく分母が見える地図を作る
以下はオンライン前払いの運用設計例です。「購入意図」は一回の購入に対する複数の決済試行をまとめる内部単位で、特定PGのオブジェクト名と同じとは仮定しません。分割決済や複数注文の合算を扱うなら関連付け単位を別に定めます。
まず対象取引を定義します。例えば本番で対応決済手段を使って始めた実購入を対象とし、FDSに該当したことを理由に後から分母から外しません。 テスト取引や非対応手段を除くなら、理由と定義の版を残します。
| 区間 | 指標と分母：設計例 | 失敗原因と責任の確認先 |
|---|---|---|
| 流入・対象取引 | 決済開始の一意な購入意図数を記録。対象購入意図数 ÷ 決済開始購入意図数 | サービス・データ担当が商品・チャネル構成や測定定義の変化を確認 |
| FDS評価・遮断 | 評価完了試行数 ÷ 評価対象試行数。遮断率は当該制御で遮断した試行数 ÷ 同制御の評価完了数 | 自社・PG・発行会社の観測可能な主体別に区分。未評価・エラー・リスク不明を通常評価と分離 |
| 追加確認 | 確認要求のある対象試行数 ÷ 対象試行数。確認開始数 ÷ 確認要求数、確認成功数 ÷ 確認開始数を別記 | 自社方針とPG・発行会社要求を分離。画面未表示、取消、認証失敗、技術エラー、進行中を区分 |
| 承認 | 発行会社承認率は承認件数 ÷ 実際に発行会社へ送った要求数。PG承認API成功率は成功応答数 ÷ API要求数として別記 | 発行会社への送信を観測できなければ承認率を推定しない。PG APIとカード網指標を混同しない |
| 決済完了 | 決済完了の一意な購入意図数 ÷ 対象購入意図数 | 選択したPG・決済手段の状態定義で、承認だけか完了条件まで満たすかを確認 |
| 商品・利用権提供 | 提供期限到来済みの決済完了注文のうち期限内提供数 ÷ 同対象注文数 | 決済運用と提供担当が共同確認。期限未到来を提供失敗と数えない |
| 確認済み不正 | 特定期間に完了した決済集団の確認済み不正数 ÷ 同集団の全完了決済数。判定基準と観測終了日を併記 | リスク担当が証拠出所と判定日を管理。申告・疑い・確定を混ぜない |
| 紛争 | 特定期間の完了集団で紛争受付のある決済数 ÷ 同集団の全完了数。不正理由とその他を分離 | 紛争担当が理由と進行状態を区分。受付自体を不正確定にしない |
| 手動審査 | 同登録集団の判定完了数 ÷ 登録審査数。許可数 ÷ 判定完了数は審査結果構成比 | 審査責任者が未割当・進行中・期限超過と後続措置完了を別に確認 |
これらは本記事の提案定義であり、ベンダーダッシュボードの値をそのまま転記したものではありません。Stripeの分析文書も集計基準と取引日・紛争日の違いを説明しています。比較時には名称より実際の分子・分母を確認します。[8]
再試行で一購入意図が複数件になると、試行単位の承認率と購入意図単位の完了率は異なる動きをします。試行指標は障害・拒否原因分析、一意な購入意図指標は購入完了分析に使い分けます。同試行に複数評価イベントがあっても、制御段階ごとの集計規則を固定します。
分母ゼロは0%ではなく「該当なし」と表示します。進行中の認証・決済を離脱に変える時点も先に定めます。各行は別の問いに答えるため、比率を足して100%にしません。件数基準と金額基準を分け、換算根拠なしに異なる通貨を合算しません。
拒否した取引の正解はすぐには見えない
遮断取引が進んでいたら正常購入になったか、不正になったかは観測できません。Stripeも許可ルールの評価で、過去に遮断した決済の仮想的結果は分からないと明記しています。[7]
厳密な誤検知率と、現場で集めやすい指標を区別します。正常取引を不正として誤遮断する二値判定の誤検知率は次のとおりです。[9]
偽陽性率（FPR）＝誤遮断した正常取引数 ÷ 実際に正常な全取引数
一方、「異議申立後に許可へ変更した件数 ÷ 審査完了した異議申立件数」は異議処理の判断変更率です。「標本審査で正常と判定した遮断件数 ÷ 審査した遮断標本数」はその標本内の正常判定割合です。別の推定手続きなしに全体の誤検知率へ名称を変えることはできません。
この違いには運用上の限界があります。異議を申し立てずに離れた顧客は審査資料に残りません。審査しやすい取引だけを選べば結果も偏ります。人の許可判定はその時点の判断で、最後まで正常だったという確定証拠ではありません。標本の選び方、判定根拠、未確定数を結果とともに残します。
時間もそろえます。紛争や不正の情報は決済より遅く届くため、同じ決済集団の比率も後で変わります。全理由の紛争と不正理由の紛争も別指標です。[8][10]
十分観測した変更前取引と、昨日発生した変更後取引を比べて「不正率が下がった」としません。発生期間、観測終了日、経過時間を合わせ、未成熟な結果は暫定とします。遮断増によって取引自体が減る場合もあり、不正件数の減少だけで改善とは言えません。
許可・追加確認・保留・手動審査・遮断を分ける基準
リスクスコアは判断材料で、正解表ではありません。Stripeも通常リスクの決済が後に不正と判明する場合を説明し、未評価とリスク不明を区別しています。[3] 供給者や自社モデルの異なるスコアを同じ尺度とせず、その環境での意味を確認します。
以下はポリシー設計例です。不正可能性だけでなく、被害、可逆性、追加証拠の価値、顧客負担、審査費用と遅延を考慮します。保留と手動審査は併用でき、五つを必ず排他的なシステム状態にするという意味ではありません。
| 処理 | 優先して検討する条件 | 得られることと負担 | 必ず定める内容 |
|---|---|---|---|
| 許可 | 情報が整合し残余リスクを事業上受容できる | 摩擦は減るが後日の不正可能性は残る | 根拠と責任者。PG・発行会社の承認を保証する判断ではない |
| 追加確認 | 対応する認証・確認手続きで不確実性を減らせる | 証拠を増やせるが離脱・失敗・技術遅延が生じる | 必要な確認結果と、未完了・失敗・非対応時の次処理・案内 |
| 保留 | 証拠到着が期待でき、提供約束と決済期限内で待てる | 即時損失を防ぐ余地と引換えに顧客待機・運用負担 | 承認要求・代金確保・商品提供の何を止めるか、解除責任者、満了時対応 |
| 手動審査 | 信号が矛盾し、人が文脈を確認すると判断が変わりうる | 文脈を考慮できるが品質・業務量・遅延に依存 | 担当と代理、証拠、期限、審査中の決済・提供状態、後続実行担当 |
| 遮断 | 想定被害が受容できず、時間内にリスクを減らす確認手段がない | 試行を止めるが正常顧客を失う可能性 | 内部理由、顧客案内と異議経路、例外再審査権限。検知ルール自体は公開しない |
曖昧な取引をすべて審査キューへ送ることも解決ではありません。人が新たに確認できる情報がなければ、手動審査という名前の待ち行列です。増員より先に証拠収集経路と自動判断範囲を再設計する理由があります。
追加認証が終わっても正常取引の確定ではない
EMV 3-D Secureはオンラインカード決済で加盟店と発行会社が情報交換して利用者を認証する技術です。リスク判断により、追加入力なしのフローと顧客に追加認証を求めるフローに分かれます。3DS要求記録と実際の認証画面表示を同じ件数にしてはいけません。[5]
認証成功も最終承認や全問題の解消を意味しません。Stripeの3DS案内では認証後に決済処理が続き、実際の認証フローは発行会社の判断に影響されます。成功した3DSによる不正責任移転にも条件・例外があり、不正以外の理由の紛争まで一律免責されるわけではありません。[6]
韓国の決済でも、選択PG・カード・決済手段・連携方式がどの追加確認に対応するかを先に確認します。海外製品のRequest 3DSを韓国PGの同じ設定と仮定したり、一度何らかの確認を受ければ安全と結論づけたりしません。
取引異常から対応・決済事業者との協議へ — 症状別の確認手順で取引状態を調べ、障害、返金、繰り返す問題を共通の運用手順で処理します。
手動審査登録と決済・商品提供の保留は別である
Stripe Radarの審査キューには処理済み決済と後で代金を確保する決済が入ります。承認と売上確定を分離していなければ、審査対象は通常すでに処理済みです。また審査画面のApproveは審査を閉じるだけで決済自体を変更しません。[4]
手動審査導入時は審査状態、決済状態、商品提供状態を別に確認します。この区別なしにキューの存在だけで損失を防いだと考えてはいけません。
即時利用権を発行するサービスを設計するとします。決済直後に利用権を発行し同時に審査登録すると、結果が出る前に使われる可能性があります。これは架空の設計例で、顧客事例ではありません。発行前制御にするなら、提供が実際に待つか、待機期限、拒否時の決済後処理まで結び付けます。支払済み顧客へ未払いと案内する誤りも避けます。
Radarの手動審査・独自ルールはプラン・決済手段・APIオブジェクトで対応差があります。他PGの標準機能や全アカウントの提供範囲に一般化しません。[3][4][11]
人に渡すときは証拠と期限も渡す
運用ポリシーに次の記録を持つことを推奨します。製品が自動提供する機能一覧ではなく、判断を説明し後続措置を終えるための設計基準です。
| 記録 | 残す内容 |
|---|---|
| 割当と責任 | 審査担当・代理、判断承認権限、決済後処理と商品提供の実行担当 |
| 判断根拠 | 取引参照、内部リスク理由コード、情報の出所・時刻・信頼度、未確認項目 |
| 判断と実行 | 許可・追加確認・維持・遮断などの判断と理由。判断時刻と解除・取消・返金・提供の完了時刻を分離 |
| 期限と顧客案内 | 決済制約と提供約束を反映した判断期限、超過時の安全な処理、伝える現在状態 |
| 異議処理と変更履歴 | 別担当の再審査経路、変更理由、取引例外の範囲・再確認時点、ポリシー版・変更者・承認者・復帰条件 |
審査記録のために全決済原文と顧客情報を一画面へ集める必要はありません。取引参照と判断に必要な最小情報から始め、詳細情報の権限を分けます。実際の収集・保存範囲は別のセキュリティ・個人情報審査で決めます。
期限を普遍的な「何分」で定めません。決済手段の制約、証拠取得時間、提供約束、審査人員の可用性を合わせて判断します。担当者不在や期限超過で自動許可される抜け穴も作りません。
審査速度は平均だけで見ません。完了案件の待ち時間分布と実作業時間を分け、未完了案件の待ち時間・超過件数も確認します。長く待つ未完了案件を除くと、処理性能が良く見えるためです。
ルール変更後は同条件の取引を見直す
変更前に減らしたい失敗を文章にします。例えば追加確認段階の技術失敗を減らす目標と、不確実取引を審査へ回す目標では検証対象が異なります。ポリシー版、適用対象、決済手段・チャネル・商品構成、比較期間を残します。
過去取引に新ルールを当てて対象変化を確認する方法は有用です。Stripeもルール追加・変更前に過去取引との一致を確認する機能を説明します。ただし遮断取引の実際の正解を復元するものではありません。[7]
検証は次のように分けます。
動作検証では分岐の接続を確認します。 所有または明示許可のあるテスト環境で、認証失敗、確認期限切れ、審査未割当、提供保留・解除、遮断後案内を確認します。サンドボックス合格を実際の誤検知率や不正防止性能の証拠にしません。
ポリシー比較では当時利用できた情報だけを判断入力にします。 後で届いた紛争結果を過去判断に混ぜません。実措置を変えない観測も利用できますが、既存制御で見えない結果まで分かるわけではありません。正解取得のために遮断取引を無差別許可しません。
本番適用は責任者の承認範囲と停止条件内で行います。 完了率だけでなく不正の先行信号、損失、確認離脱、審査滞留、問い合わせを見ます。許容損失・遅延、停止や旧方針への復帰条件は事業条件に合わせて事前設定します。
最終評価には遅れて届く結果を反映します。 対象構成と観測経過時間をそろえ、標本が小さい、未確定が多い場合は効果を暫定とします。承認率向上と不正損失増が同時にあれば両方報告します。
次の対応は遮断増より責任の明確化かもしれない
PGの失敗情報、段階別指標、審査責任者がすでにあるなら、新ツール購入前に既存方針を整理できます。誰が拒否したか見えず、審査判断が決済・商品提供へ反映されないなら、まずPGと開発・運用担当で観測情報と制御範囲をそろえます。
FDS運用の目標を大量遮断にしないでください。受容できない被害を防ぎ、追加確認の価値がある取引に確認手段を割り当て、顧客と運用に残る費用まで説明できる必要があります。 不正率低下または承認率向上の片方だけでは達成を判断できません。
外部実装支援を検討する場合はIXCの不正取引検知（FDS）サービスの業務範囲を確認し、必要な判断・審査・後続処理を分けて相談できます。
