審査ツール

Stripe のプログラムによるシステムの機能によって不正な身元が検出されますが、手動審査を実行することで不正防止を強化できます。

たとえば、以下のような場合に本人確認の審査が必要になることがあります。

• 顧客が予期しない国から書類を提出した
• 本人確認に誤りがあるのではないかという問い合わせが顧客からあった
• お客様のビジネス要件が Stripe Identity のデフォルトのリスクのしきい値と異なっている

Stripe Identity の手動審査とインサイトを使用すると、通常と異なる本人確認を調査して、確認ステータスを更新することができます。

本人確認を審査する

本人確認の審査は 2 種類の方法で行うことができます。リストビューでは本人確認の詳細を表示せずにリストを見ることができ、詳細ビューでは、さらに具体的な情報を確認できます。

リストビュー

リストビューには、それぞれの本人確認のステータスを素早く把握できる情報が表示されます。本人確認のステータス、書類の国、抽出された氏名、個々の確認のステータスに関する情報などが表示されます。

詳細ビュー

決定を行う前に本人確認に関する詳細情報を確認するには、リストビューから本人確認を選択して、詳細ビューに移動します。このビューでは、利用できるインサイトのほか、収集された個々の画像を検証できます。

アクション

本人確認の審査を行った後、以下のいずれかのアクションを実行します。

• ステータスの上書き: 自身の判断に合わせて、顧客の本人確認ステータスを手動で確認済みまたは未確認に更新します。Stripe から新しいステータスを設定した Webhook イベントが送信されます。
• ブロックリストに追加: 書類をブロックリストに追加すると、同じ書類を使用して実行される以降の本人確認は、プログラムによってブロックされます。

生体認証データの重複

新たに本人確認を行う際、Stripe は生体認証データ (顔写真など) を使用して、完了済みの本人確認を審査して重複した身元がないか確認し、それぞれの身元が一意であることを検証します。

顔写真の重複が検出された場合、重複が検出された確認セッションと各セッションで検出された回数のリストを共有します。

ブロックリスト

Stripe Identity がプログラムによる確認で書類や顔写真を使用することを防止するには、それをブロックリストに追加します。確認にブロックリストの項目と一致するデータが含まれる場合、お客様がそれをダッシュボードでレビューするまで、Stripe は確認のステータスを自動的に ‘unverified‘ に設定します。

次のタイプのブロックリストエントリーの追加に対応しています。

• 書類: 書類のタイプ、書類番号、書類の国の組み合わせに対して照合します。
• 顔写真: 本人確認の際にアップロードされた顔写真の画像のフェイシャルマッピングと照合します。

ブロックリストエントリーを追加する

ダッシュボードの Identity ページで、ブロックリストに追加するデータが格納された確認セッションを見つけます。右上にあるオーバーフローメニュー () をクリックして、ブロックリストに追加を選択します。

ブロックリストエントリーを無効化する

ブロックリストエントリーの詳細ページで、右上の無効にするをクリックします。無効にしたブロックリストエントリーでは、Stripe Identity が一致する確認に unverified を自動的に設定することはありません。

無効にしたブロックリストエントリーは再度有効化できません。無効化したエントリーを復旧するには、書類や顔写真を含む Verification セッションを開き、同じデータで新しいエントリーを作成します。

本人確認の分析

本人確認ダッシュボードの分析タブでは、使用状況と検証率を経時的に表示し、検証ファネルの各段階でユーザーの進行状況を追跡できます。このデータは本番環境の検証セッションから取得されるものであり、テスト環境のセッションは除外されます。

データについて

Stripe では、VerificationSessions の分析を次のように計算します。

• 作成された確認: 作成された確認の総件数。破棄、キャンセル、編集、その他の未完了の件数も含まれます。
• 開始された確認: ユーザーがアクセスし、確認プロセスを開始した確認件数。
• 送信された確認: ユーザーが作成して送信した確認件数。確認結果に関係なく、送信されたすべての確認が請求対象です。
• 完了している確認: 送信後に確認が正常に完了した確認の件数。
• 完了率: 開始された確認のうち、ユーザーが作成して送信した割合。送信された確認件数を開始された確認件数で割って求められます。
• 確認率: 送信された確認のうち、確認が正常に完了した割合。確認が完了した確認の数を送信された確認の数で割って求められます。

確認セッションでは複数回試行されることがあります (最初の試行でユーザーを確認できなかった場合)。試行ごとに新しい VerificationReport (確認レポート) が生成され、確認レポートの複数の指標が計算されます。

• 作成された確認レポート: 作成され、送信された確認試行数。
• 成功した確認レポート: 送信後に確認が正常に完了した確認試行数。

ベストプラクティス

審査を最大限に活用し、効率的に作業するには、以下のベストプラクティスを利用します。

• 人間の判断や手動審査が、顧客の身元が確認済みかどうかの適切な決定につながる場合は、人間の審査に基づく本人確認を重視します。

  ほとんどの本人確認は、Stripe システムによる確認セッションで決定を下すことができますが、一部のケースでは人間の判断によって精度を高めることができます。

• インサイトとビジネスの状況を使用して、情報に基づく決定を行います。

  インサイトセクションにあるデータを使用して、Stripe が書類または顔の画像に対してどのように判断したかを確認します。インサイト、ビジネスに関する知識、人間による判断を組み合わせることで、Identity によって示されたリスクシグナルを信頼するか無視するかを、状況に基づいて選択することができます。

• 審査担当者が学んだことを活用し、不正防止戦略を作成します。

  審査担当者は本人確認の調査を続けるにつれて、不正防止のための洞察力が鍛えられるため、Identity の実装の更新に反映させることができます。

• 審査時にビジネスに固有のデータを提示してプロセスをカスタマイズします。

  顧客の追加情報をメタデータとして渡し、審査の際にダッシュボードであらゆる関連情報を使用できるようにします。

• 顧客の体験を滞らせません。

  審査を行うと、本人確認が完了してから顧客がビジネスでケイパビリティを利用できるようになるまでに時間がかかる可能性があります。ビジネスの性質上このような遅延が生じる傾向にある場合は (Identity がより長期の審査プロセスの一部である場合など)、本人確認の審査に時間を割いても顧客体験は損なわれません。ただし、遅延の発生が前提とされていない場合は、審査プロセスを追加すると、顧客体験の遅延を生じさせる可能性があります。審査プロセスを導入する前に、顧客への影響を考慮してください。たとえば、顧客の本人確認が完了した際に確認ステータスを変更するといった、状況に対応するためのワークフローを構築します。

• 顧客サポートのワークフローを実装します。

  顧客の本人確認ステータスに関する顧客のリクエストに対処し、リクエストされた場合に生体認証以外の確認方法を提供できるように準備します。