メインコンテンツへスキップ

概要

機能ごとのレポートはすべて、service-didit-verificationで定義されたV3シリアライザーの形式に従います。同じオブジェクトが3か所に現れるため、ここに示すスキーマがそれらすべてに共通する唯一の信頼できる情報源です。
  • GET /v3/session/{sessionId}/decision/:各機能は複数形の配列として返されます(id_verifications[]、nfc_verifications[]、liveness_checks[]、face_matches[]、poa_verifications[]、phone_verifications[]、email_verifications[]、aml_screenings[]、ip_analyses[]、database_validations[]、questionnaire_responses[]、signatures[]、bank_verifications[](銀行認証の方法を参照)、およびKYBの対応項目であるregistry_checks[]、document_verifications[]、key_people_checks[])。
  • Webhookペイロード(status.updated、data.updated):decisionエンベロープ内で同じ形式です。
  • スタンドアロンAPI:単一オブジェクトのレスポンス(顔検索、年齢推定、生体認証)も同じフィールドセットを使用します。
V3ではマルチインスタンスのワークフローが導入されました。すべての機能オブジェクトにはnode_idが含まれ、レポートを生成したワークフローグラフのノードにそのレポートを紐付けます。V2エンドポイント(単数形のkyc、face、amlなど)は後方互換性を維持していますが、最初のインスタンスのみを返します。

共通フィールド

すべてのレポートオブジェクトは次のフィールドを持ちます。 メディアフィールド(portrait_image、front_image、document_fileなど)は、有効期間が限られた事前署名付きURLです。URLを保存するのではなく、速やかにダウンロードしてください。例ではhttps://<media-host>/...と表記しています。

警告オブジェクト

すべてのwarnings[]配列で返されます。スキーマはlogs/serializers/log.py:8-65(LogV3Serializer)に基づきます。

レポートオブジェクト

残りのセクションでは、機能ごとのレポートオブジェクトを説明します。H3見出しのテキストは、他のドキュメントからディープリンクできるよう意図的に固定しています。

本人確認

ユーザーが提出したKYC/本人確認書類ごとに返されます。GET /v3/session/{sessionId}/decision/ではid_verifications[]として、V2のレスポンスではkycフィールド内に含まれます。ソース:kyc/serializers/kyc.py:383-414(IDVerificationV3Serializer。kyc/serializers/kyc.py:320-380のIDVerificationV2Serializerを拡張)。
書類以外の方式を使用した場合の同じオブジェクトです。変わるのは方式固有のキーのみです。書類の読み取りで入力される項目はすべて、代わりに登録簿のレコードまたはウォレットの属性から入力され、該当しないキーはnullになります。

NFC認証

ID書類に対して読み取られたチップごとに返されます。対象は、ICAO 9303のePassportまたはeIDチップ、あるいはJPKI経由で読み取った日本のマイナンバーカード(chip_protocol: "jpki")です。GET /v3/session/{sessionId}/decision/のnfc_verifications[]として表示されます(親KYCレコード1件につき1つ)。ソース:kyc/serializers/epassport.py:121-139(NFCV3Serializer。kyc/serializers/epassport.py:83-118のNFCV2Serializerを拡張)。

ライブネスチェック

ライブネスセッションごとに返されます。GET /v3/session/{sessionId}/decision/ではliveness_checks[]として含まれます。ソース: face/serializers/face.py:301-320(LivenessV3Serializer。face/serializers/face.py:216-298のLivenessV2Serializerを拡張)。

顔照合

顔照合の比較ごとに返されます(通常は、ユーザーのライブネス時の顔と書類の顔写真との比較)。GET /v3/session/{sessionId}/decision/ではface_matches[]として含まれます。ソース: face/serializers/face.py:367-389(FaceMatchV3Serializer。face/serializers/face.py:323-364のFaceMatchV2Serializerを拡張)。

顔検索

スタンドアロンの顔検索API(POST /v3/face-search/)から返されます。顔検索が/v3/session/{sessionId}/decision/で複数形の配列として現れることはありません。save_api_request=trueで保存した場合、そのセッションはfeatures[]内のFACE_SEARCHエントリと、保存されたmatchesを持つliveness_checks[]の項目として表示されます。ソース: apis/serializers/face_search.py:8-79(FaceSearchDetailsSerializerをラップするFaceSearchResponseSerializer)。マッチの辞書はface/utils/utils.py:869-884で構築されます。 トップレベルのレスポンス: face_searchオブジェクト:

顔検索のマッチオブジェクト

AMLスクリーニング

スクリーニング対象のエンティティごとに返されます。KYCとKYBの両方のセッションで、GET /v3/session/{sessionId}/decision/のaml_screenings[]として表示されます。ソース: aml/serializers/aml.py:63-85(AMLV3Serializer。aml/serializers/aml.py:28-60のAMLV2Serializerを拡張)。

IP分析

取得されたネットワークロケーションごとに返されます。KYCセッションとKYBセッションの両方で、GET /v3/session/{sessionId}/decision/のip_analyses[]として含まれます。ソース:kyc/serializers/location.py:196-243(IPAnalysisSerializerV3)。

位置情報検証

位置情報検証ステップごとに返されます。GET /v3/session/{sessionId}/decision/のgeolocation_checks[]として含まれ、ステップごとに1項目で、そのステップで採用された試行が入ります。geolocation_attempts[]には、すべてのステップのすべての試行が古い順に列挙されます。このステップを含まないワークフローでは、どちらもnullです。ソース:GeolocationDecisionSerializer。 すべてのフィールドと例は位置情報検証レポートに記載されています。

住所証明

提出された住所書類ごとに返されます。GET /v3/session/{sessionId}/decision/ではpoa_verifications[]として表示されます。ソース:poa/serializers/poa.py:212-227(POAV3Serializer。poa/serializers/poa.py:173-209のPOAV2Serializerを拡張)。

電話番号検証

電話番号検証の試行ごとに返されます。KYCセッションとKYBセッションの両方で、GET /v3/session/{sessionId}/decision/内のphone_verifications[]として表示されます。ソース:phone/serializers/phone.py:251-266(PhoneV3Serializer。phone/serializers/phone.py:103-248のPhoneV2Serializerを拡張)。

メールアドレス認証

メールアドレス認証の試行ごとに返されます。KYCセッションとKYBセッションの両方で、GET /v3/session/{sessionId}/decision/内のemail_verifications[]として表示されます。ソース:email_verification/serializers/email.py:149-164(EmailV3Serializer。email_verification/serializers/email.py:38-146のEmailV2Serializerを拡張)。

データベース検証

ユーザーが送信したデータに対して実行されたデータベース照会ごとに返されます。GET /v3/session/{sessionId}/decision/内のdatabase_validations[]として表示されます。ソース:database_validation/serializers/database_validation.py:21-142(DatabaseValidationV3Serializer。DatabaseValidationV2Serializerを拡張)。

アンケートの回答

アンケートの提出ごとに返されます。KYCセッションとKYBセッションの両方で、GET /v3/session/{sessionId}/decision/のquestionnaire_responses[]として含まれます。ソース: questionnaires/serializers/questionnaire.py:591-597(QuestionnaireResponseV3Serializer。questionnaires/serializers/questionnaire.py:520-588のQuestionnaireResponseSerializerを継承)。

電子署名

電子署名ステップの署名者ごとに返されます。KYCセッションとKYBセッションの両方で、ワークフローにこのステップがある場合に限り、GET /v3/session/{sessionId}/decision/のsignatures[]として含まれます。他のレポートオブジェクトとは異なり、statusは署名の段階を表し、結果はverdictに入ります。また、warnings[]の各アイテムは警告オブジェクトではなく{ code, node_id }です。 電子署名レポートに、完全な例とすべてのネストされたフィールドが記載されています。

年齢推定

スタンドアロンのAge Estimation API(POST /v3/age-estimation/)が返します。レスポンスは、age_estimationエンベロープの下にLiveness checkの構造の一部(status、method、score、age_estimation、warnings)を含み、さらにスタンドアロン専用のuser_image顔検出ブロックを含みます。reference_image、video_url、matches、face_quality、face_luminanceは含みません。ワークフローのセッションでは個別の配列はなく、推定年齢はGET /v3/session/{sessionId}/decision/のliveness_checks[].age_estimationとして返されます。ソース:apis/serializers/age_estimation.py:50-55(AgeEstimationResponseSerializer)。エンベロープはapis/views/age_estimation.py:138-174で組み立てられます。

生体認証

生体認証は、標準のKYCで使われるものと同じLiveness + Face Matchパイプラインを実行しますが、新たにOCRで読み取った書類の顔写真ではなく、既存ユーザーの参照画像と撮影した顔を比較するように設定されています。専用のシリアライザーはなく、GET /v3/session/{sessionId}/decision/は標準のLiveness checkオブジェクトとFace matchオブジェクトをliveness_checks[]とface_matches[]の下に返します。セッションのワークフローはworkflow_type = "biometric_authentication"(WorkflowTypeChoices、common/config/choices.py:636)で設定されます。

KYB登記

KYBワークフローで、登記情報により確認された企業ごとに返されます。企業セッションではGET /v3/session/{sessionId}/decision/のregistry_checks[]として含まれます。出典: kyb/serializers/kyb.py:939-964(RegistryCheckV3Serializer)。

Companyオブジェクト

出典: kyb/serializers/kyb.py:220-321(KYBCompanyResponseSerializer)。

KYB書類

KYBの補足書類を収集するノードごとに返されます。企業セッションではGET /v3/session/{sessionId}/decision/のdocument_verifications[]として含まれ、node_idごとに1件のエントリがあり、items[]にアップロードされた各書類が列挙されます。出典: kyb/serializers/kyb.py:1053-1068(DocumentVerificationV3Serializer)。各項目はkyb/serializers/kyb.py:811-851(KYBDocumentResponseSerializer)に従います。

KYB書類アイテムオブジェクト

KYB主要人物

KYBワークフロー内の主要人物ノードごとに返されます。企業のセッションでは、GET /v3/session/{sessionId}/decision/のkey_people_checks[]として表示されます。ソース: kyb/serializers/kyb.py:967-1050(KeyPeopleCheckV3Serializer)。

判定レベルのフィールド

これらのキーは、GET /v3/session/{sessionId}/decision/では機能の配列と同じ階層に、Webhookではdecisionの中に含まれます。 読み取り方法についてはセッションの取得を参照してください。

生体情報の利用同意

ユーザー認証のすべての判定とセッションのWebhookには、単一のbiometric_consentオブジェクト(配列ではありません)が含まれます。このオブジェクトは、セッションで生体情報の明示的な同意が必要だったかどうか、その理由、および回答の証跡を示します。セッションが一度も評価されなかった場合(顔撮影を含まないワークフローなど)はnullになります。ソース: BiometricConsentDecisionSerializer(sessions/serializers/biometric_consent.py)。このステップが表示される条件と各ケースの意味については、生体情報の利用同意で説明しています。 値が記録されていないフィールドはnullになり、空文字列になることはありません。 イリノイ州のセッションで、4.10.0未満のネイティブSDKがステップを経ずにセルフィーを撮影した例:
米国外に出口があるVPNを使用している本人が、ホスト型フローで同意した例:

ステータス列挙値リファレンス

statusというフィールド名は、関連する2種類の値で共通して使用されます。このページの機能ごとのレポートオブジェクトはすべて機能レベルの列挙値を使用し、親セッションのトップレベルのstatusはより範囲の広いセッション列挙値を使用します。

機能レベルのステータス

すべてのレポートオブジェクトのstatusフィールドで使用されます。ソース: common/config/choices.py:343-348(FeatureStatusChoices)。 電話番号検証、メールアドレス認証、本人確認では、ステップがタイムアウトした場合にExpiredが返されることもあります(PhoneStatusChoicesはcommon/config/choices.py:377-382、EmailStatusChoicesはcommon/config/choices.py:434-439)。

セッションレベルのステータス

親セッションのトップレベルのstatusで使用されます。ソース: common/config/choices.py:106-117(StatusChoices)。
セッションの終端ステータスはApproved、Declined、In Review、Expired、Kyc Expired、Abandonedです。個々の機能がIn Reviewのままでも、セッション全体の判定が確定することがあります。
最終更新日 2026年11月1日