database_validations[]の各エントリーは、1件の完全なデータベース検証レポートです。これは、1つの発行国に対してデータベース検証ノードを1回実行した結果にあたります。サービスごとの登録機関の照合結果は、そのエントリー内のvalidations[]サブ配列に格納されます。このページでは、各サービスが返す照合結果、登録機関のソースデータ、生体認証スコアを解析できるよう、JSONの構造を説明します。

概要
データベース検証レポートは、ワークフローのノードがデータベース検証機能を実行するたびに生成されます。database_validations[]配列の各エントリーは、1つの発行国に対する1回のノード実行を表します。ノードがその国で複数のサービスを実行する場合(例: ブラジルのCPFとCNH)、各サービスはエントリーのvalidations[]サブ配列内の個別の項目として表示されます。各レポートには次の情報が含まれます。
- 機能全体の
status。FeatureStatusChoicesの値(Not Finished、Approved、Declined、In Review)です。 - 集約された
match_type(full_match、partial_match、no_match、または利用可能な結果を返したサービスがない場合はnull)。照合方式に従って複数のサービスの結果を集約した値です。 issuing_state(ISO 3166-1 alpha-3)と、そこから導出されるvalidation_type(one_by_one、two_by_two、またはnot_enabled。nullになることはありません)。screened_dataブロック。登録機関に送信された、ユーザーが提供したデータです。validations[]配列。結果を返したサービスごとに1件のエントリーがあり、カタログのservice_id/service_name、ベンダーに依存しないoutcome_code、任意のoutcome_detail、フィールドごとのvalidationマップ、登録機関のレスポンスから抽出して整形したsource_dataを含みます。errors[]配列。照会が失敗した場合やスキップされた場合の、サービスごとのエラーです。エラーがない場合、このキーは完全に省略されます。warnings[]配列。検証中に発生したリスクイベントです(データベース検証の警告を参照)。node_id。レポートを生成したワークフローのグラフノードを識別します(V3セッションのみ)。
APIレスポンスでの表示位置
このレポートは、GET /v3/session/{sessionId}/decision/のdatabase_validations[]として表示されます。常にJSON配列であり、単一のオブジェクトになることはありません。配列には、ワークフローのグラフ内にあるデータベース検証ノードごとに1件のエントリーが含まれます。さらに、各エントリーのvalidations[]サブ配列には、結果を返したレジストリサービスごとに1件の項目が含まれます。
nullの場合は、データベース検証のステップがまだ実行されていないことを意味します。
スキーマ
フィールドごとの正式なスキーマはデータモデルページに掲載しています。このスキーマはDatabaseValidationV3Serializerによって生成されます。
ステータス値
statusは機能レベルの標準列挙型を使用します(ステータス列挙型を参照)。詳しくはステータス列挙型リファレンスを参照してください。この列挙型にはResub Requestedも定義されていますが、実際にはデータベース検証で生成されることはありません。
ノードごとのカスタムステータスルールは、この基本ステータスに上乗せして適用されます。設定可能なアクションとそのデフォルトについては、データベース検証の警告を参照してください。
結果コード
validations[]の各エントリには、ベンダーに依存しないoutcome_codeが含まれます。値はMATCH、PARTIAL_MATCH、NO_MATCH、DOCUMENT_NOT_FOUND、INVALID_DOCUMENT_FORMAT、INVALID_INPUT、MINOR_BLOCKED、DECEASED、BIOMETRIC_NO_MATCH、BIOMETRIC_IMAGE_UNUSABLE、INCONCLUSIVE、DOCUMENT_SUPERSEDED、REGISTRY_UNAVAILABLE、REGISTRY_ERRORのいずれかです。次の違いに注意してください。NO_MATCHは登録機関がデータを確定的に確認しなかったことを意味し、INCONCLUSIVEは登録機関がどちらとも判断できなかったことを意味します(却下ではなくレビューに回してください)。またBIOMETRIC_IMAGE_UNUSABLEはセルフィーの技術的な問題(再撮影が必要)であり、確定的なBIOMETRIC_NO_MATCHとは異なります。分類の全体像と推奨される対応については、結果コードページを参照してください。
サービスごとに1エントリ
validations[]配列には、結果ペイロードを生成したサービスごとに1つの項目(validationマップ、source_data、outcome_code、またはoutcome_detail)が含まれます。ワークフローが同じ国で複数のサービスを実行する場合(例: ブラジルのCPFとブラジルのCNH)、それぞれが独自のservice_id、outcome_code、source_dataを持つ別々の項目として表示されます。集約値のmatch_typeはすべてのサービスを集計したものです(いずれかが完全一致ならfull_match、そうでなくいずれかが部分一致ならpartial_match、それ以外はno_match)。validation_typeは完全一致した異なるサービスの数から導出されます。詳しくは照合方式を参照してください。
署名付き画像URL
source_data(photo、signature)およびscreened_data(selfie、cnh_qr_code_image、document_image)の画像フィールドは、有効期限のある署名付きURLとして返されます。更新するには判定エンドポイントを再度呼び出してください。上流から受け取った生のペイロードは、意図的にAPI経由では公開していません。
例
承認済み: ブラジルCPFステータス確認 (Receita Federal)
承認済み: アルゼンチンDNI生体認証 (RENAPER)
アルゼンチンでは、RENAPERによる生体認証の顔照合を用いて検証します。レスポンスにはface_match_scoreと、登録機関から返される追加の本人情報フィールドが含まれます。
レビュー中: 登録機関による検証を実行できなかった場合
どのサービスからも有効な結果が返されない場合(必須フィールドの欠落や形式不正、または登録機関に到達できない場合)、match_typeはnullのまま、validation_typeはnot_enabledとなり、COULD_NOT_PERFORM_DATABASE_VALIDATION警告が発行され、データが修正されるまで、この機能のステータスはIn Reviewになります。スキップされたサービスには料金は発生しません。
関連情報
- データベース検証の概要: APIのエンドツーエンドの仕組みと対応する登録機関。
- 照合方式: 1×1 / 2×2の結果(
validation_type: one_by_one/two_by_two)の導出方法。 - 結果コード: 国別の詳細コードを含む、結果ごとの分類の全体像。
- 対応国とサービス: 稼働中のすべての登録機関、必須フィールド、呼び出しごとの料金。
- データベース検証の警告: サービスを実行できない場合に表示される内容。
- データモデル: データベース検証: フィールドごとの正式なスキーマ。