保存された顔は生体認証の参照画像も兼ねます。ユーザーの
vendor_dataを指定し、portrait_imageを省略して生体認証セッションを作成すると、Diditは保存済みの顔を自動的に再利用します。優先順位は、承認済みのライブネスチェックで取得した顔、ePassportチップの写真、本人確認書類の顔写真、手動で登録したプロフィールの顔の順です。顔がユーザーに紐付く仕組み
1
ライブネス検知中に撮影
ユーザーがライブネスを有効にしたセッションを開始すると、Diditはセルフィーを撮影し、パッシブライブネス検知を実行します。続いて最も大きく写っている顔を抽出し、検索用のベクトルエンベディングを生成します。
2
ユーザープロフィールに保存
顔はセッションと、その親であるユーザーエンティティに紐付けられます。顔写真のURLは、ユーザープロフィール上で
portrait_imageとして表示されます。3
検索用にインデックス化
エンベディングは検索インデックスに追加されます。以降のセッションでは、このインデックスに対して1:N検索を実行できます。
顔検索 (1:N)
顔検索では、画像をアップロードし、アプリケーションに登録されているすべての顔と照合することでユーザーを見つけられます。 ユースケース:- オンボーディング時の重複検出:同一人物が2つのアカウントを作成するのを防ぎます。
- 逆引き検索:防犯カメラの映像のフレームや、不正調査で得た画像に写っているユーザーを特定します。
- リピーターの識別:再訪した顧客のKYCを省略します。
POST /v3/face-search/:単体の顔検索
重複検出
新しい顔はそれぞれ、登録済みの顔と比較することで重複を検出できます。Diditは各顔にapproved_duplicate_statusを割り当てます。
ワークフローでは次のいずれかを設定できます。
- 重複フラグが付いたセッションを自動的に却下する。
- レビュー対象としてフラグ付けする:アナリストによる手動レビューに回します。
- 警告のみ:通過させたうえでリスクタグを付与します。
顔ブロックリスト
セッションが却下されると(ルール、アナリスト、ワークフロー設定のいずれによる場合も)、関連する顔はアプリケーションの顔ブロックリストに自動的に追加されます。以降、顔が一致するセッションは拒否されます。インポートした顔をユーザープロフィールにアップロードする
別のKYCプロバイダーから移行する場合は、先にユーザーを作成してから、信頼できる顔画像をそのプロフィールに添付できます。ユーザーは引き続きvendor_dataをキーとして管理されますが、顔のアップロード用エンドポイントでは対象を一意に特定するため、Didit内部のユーザーID(didit_internal_id)を使用します。
1
ユーザーを作成または取得する
安定した
vendor_dataを指定してPOST /v3/users/create/を呼び出します。ユーザーがすでに存在する場合はGET /v3/users/{vendor_data}/を呼び出します。2
didit_internal_idを読み取る
ユーザーのレスポンスには
didit_internal_idが含まれます。自社システムでは引き続きvendor_dataを使用し、didit_internal_idはプロフィールへの添付用エンドポイントでのみ使用してください。3
顔をアップロードする
base64でエンコードした顔画像を指定して、
POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/を呼び出します。ブロックリストへの追加が行われる仕組み
ブロックリストに顔をアップロードする
プログラムから顔によってユーザーをブロックするには、専用のリストへの顔のアップロードエンドポイントを使い、顔タイプのブロックリストに顔画像をアップロードします。Diditは顔エンベディングを抽出して照合用インデックスに登録します。以降、ライブネスのセルフィーが一致したセッションはすべて自動的に却下されます。プロフィールへの顔のアップロードと、顔ブロックリストへのアップロードは別の操作です。信頼できるインポート済みの顔を、証跡、重複検出、顔検索のためにユーザーへ添付するには、プロフィールへのアップロードを使用します。顔をブロックし、以降に一致したセッションを拒否するには、Lists APIを使用します。
ブロックリストから顔を削除する
コンソールの Blocklist → Faces → 行のアクション → Remove からエントリーを削除するか、エントリーの削除エンドポイントを使用します。セッション削除後に保持される生体認証テンプレート
セッションを削除すると顔画像が削除され、デフォルトでは顔エンベディングも削除されます。そのため、その人物は重複検知と顔検索の対象から外れます。承認後すぐにセッションを削除しつつ、重複登録は引き続き検出したい場合は、アプリケーションで生体認証テンプレートの保持を有効にするか、削除呼び出しでretain_face_embeddings: trueを送信してください。
この場合、Diditは通常どおりセッションとそのすべてのデータを削除し、ユーザーに紐づけて、画像を含まない顔の生体認証テンプレートを1件、別途管理して保持します。
- このテンプレートに含まれるのは、数値化された顔テンプレートと保持に関するメタデータのみです。顔画像、ライブネス動画、書類データ、抽出された本人情報のフィールド、判定、削除されたセッションのIDは一切含まれません。
- このテンプレートは、通常のセッションの顔とまったく同じように、重複検知、顔検索、生体認証、および顔リストの対象になります。一致は
source: "retained_template"、ユーザーのvendor_user_idとvendor_data、およびbiometric_template_idとともに報告されます。 - このテンプレートは有限の
expires_atを持つ生体データです。ユーザーが削除されたとき、そのユーザーのいずれかのセッションがdeletion_instruction: "privacy_erasure"で削除されたとき、有効期限に達したとき、またはLists → 生体認証テンプレートや生体認証テンプレートAPIで削除したときに完全に削除されます。 vendor_dataなしで作成されたセッションには、テンプレートを紐づけるユーザーが存在しません。このセッションを削除するとineligible_no_vendor_userが報告され、エンベディングはセッションとともに削除されます。- 保持されたテンプレートがブロックリストに登録されることはありません。削除されたセッションから作成された顔ブロックリストのエントリは、独自の生体認証エントリとライフサイクルを持ちます。
顔のライフサイクルの概要
コンソールから顔をアップロード
コンプライアンス担当者は、顔を手動でアップロードできます。- Users → [user] → Actions → Upload faceに移動します。
- 画像を選択します。Diditは最も大きな顔を抽出し、ユーザーに紐づく新しいFaceレコードとして保存します。
- その顔は、プロフィールの証拠、重複検知、顔検索の対象として登録されます。今後照合で一致したセッションを却下することが目的の場合は、ブロックリストの画面を使用してください。
- オフラインで認証済みの顧客の顔写真が手元にある場合。
- 不正対策データベースにある既知の不正行為者をブロックリストに事前登録したい場合。
プライバシーとデータ保持
- 顔エンベディングは画像ではなく数値ベクトルです。画像そのものは暗号化されたオブジェクトストレージに保存され、署名付きURLでアクセスします。顔エンベディングは生体データです。
- 保持期間はアプリケーションのデータ保持ポリシーに従います。保持された生体認証テンプレートには、より厳格で期限が定められた生体認証テンプレートの保持期間が適用されます。
- セッションを削除すると画像が削除され、デフォルトではエンベディングも削除されます。アプリケーションで生体認証テンプレートの保持を有効にしている場合、セッションを削除しても、画像を含まないテンプレートが有効期限に達するか削除されるまで保持されます。
- GDPR / CCPAに基づく忘れられる権利の請求には、その人物のセッションを
deletion_instruction: "privacy_erasure"で削除するか、ユーザーを削除してください。どちらの方法でも、保持されたテンプレートもすべて完全に削除されます。管理している顔ブロックリストのエントリは、削除するまで残ります。
次のステップ
顔検索
1:Nの顔検索の仕組み。
ライブネス検知
顔を捉えるライブネス検知。
ブロックリストAPI
顔をブロックリストにアップロードします。
生体認証テンプレート
セッション削除後に保持されるテンプレート。
ユーザーブロックリスト
ユーザーをブロックリストに登録する仕組み。