メインコンテンツへスキップ
POST /v3/workflows/およびPATCH /v3/workflows/{settings_uuid}/では、features配列の各項目内で以下のconfigフィールドを使用します。
v3ワークフローAPIは、順序付きのfeatures配列から、ノードを直列につないだワークフローを構築します。機能は実際の実行順どおりに送信してください。
機能をどのエンジンで実行するか(Didit独自のエンジンか、サードパーティのプロバイダーか)は、以下のconfigフィールドでは指定しません。これはコンソールのMarketplaceで管理され、機能のconfigオブジェクトにprovider_keyとfallback_to_nativeが自動的に設定されます。

バリデーションルール

  • config.documents_allowedを省略した場合、またはnullか{}を指定した場合、OCRはサポートされているすべての国と書類タイプを対象とします。カスタムのdocuments_allowedオブジェクトを送信する場合は、有効な国と有効化された書類タイプをそれぞれ1つ以上含める必要があります。各書類設定では、sidesを1(表面のみ撮影)または2(表面と裏面を撮影)に設定できます。
  • QUESTIONNAIREにはconfig.questionnaire_uuidが必須です。
  • KYB_DOCUMENTSにはconfig.kyb_required_document_groupsが必須です。
  • SIGNATUREは、適格電子署名が利用可能になるまでsignature_level: "qes"をqes_not_availableで拒否します。また、ワークフローのsignature_availability.aesがfalseの間は、signature_level: "aes"の新しいステップをaes_not_availableで拒否します。署名対象の書類は、セッション作成時に存在している必要があります。signature_documents_sourceをworkflowに設定した場合、ステップにはコンソールでアップロードされた書類が必要です。書類のないステップは下書きのまま保存できますが、公開はできません。sessionに設定した場合は、すべての作成リクエストでsign.documentsを送信する必要があります。
  • シンプルなワークフローリクエストでは、FACE_MATCHはOCRの後に配置する必要があります。
  • NFCとDATABASE_VALIDATIONを同じワークフローに含める場合はOCRが必要です。AMLの前にはOCR、KYB_REGISTRY、DOCUMENT_AIのいずれかが必要です。前にDOCUMENT_AIしかない場合は、スクリーニング対象のfull_nameに値を入れられる必要があります。値の取得元は、すでにfull_nameというキーを持つ上流のDocument AIフィールド(自動的にマッピングされます)か、明示的なconfig.aml_field_sourcesエントリーのいずれかです(AMLを参照)。
  • KYB_DOCUMENTSやKYB_KEY_PEOPLEなどのKYBサブ機能を使用するには、ワークフロー内でそれより前にKYB_REGISTRYが必要です。
  • ワークフローは個人(KYC)ワークフローか企業(KYB)ワークフローのいずれかであり、両方を兼ねることはできません。KYB機能(KYB_REGISTRY、KYB_DOCUMENTS、KYB_KEY_PEOPLE)を使用するワークフローで組み合わせられるのは、AML、DOCUMENT_AI、QUESTIONNAIRE、PHONE_VERIFICATION、EMAIL_VERIFICATION、IP_ANALYSIS、SIGNATUREのみです。OCR、LIVENESS、FACE_MATCH、NFC、PROOF_OF_ADDRESS、DATABASE_VALIDATION、AGE_ESTIMATIONなどの個人専用機能は含めることができず、個人ワークフローにKYB機能を含めることもできません。企業ワークフローでは、DOCUMENT_AIはis_full_nameが指定されたフィールドを、個人ではなく検証済みの企業と照合します。企業の背後にいる人物を検証するには、別のKYCワークフローを作成し、kyb_ubo_verification_workflow、kyb_officer_verification_workflow、kyb_shareholder_verification_workflowのいずれかを使ってKYB_KEY_PEOPLEノードから参照します。
  • アクションフィールドには、以下の各フィールドで制限が明記されていない限り、DECLINE、REVIEW、NO_ACTIONのいずれかを使用します。
  • スコアおよびしきい値のフィールドは、より狭い範囲が記載されていない限り、0から100までの数値です。

共通のステータスルール

すべての機能で、任意のstatus_rules配列を指定できます。フィールドの条件に一致したときに機能のステータスを上書きするために使用します。
上の例は、「kyc.extra_fields.professionが最小スコア80でSoft. Engineerにあいまい一致した場合 → 機能のステータスをDeclinedに設定する」という意味です。 本人確認では、抽出されたextra_fieldsの値を対象にできます。たとえばkyc.extra_fields.profession、kyc.extra_fields.dl_class_code_b_fromやkyc.extra_fields.dl_class_code_b_toのような運転免許証の区分ごとの有効期間の開始日・終了日、kyc.extra_fields.dl_class_code_b_notes(英国の運転免許証の第12欄)のような区分ごとの制限・情報コードです。これらの値はOCR結果のextra_fieldsオブジェクトから取得されるもので、expected_detailsには含まれません。
dl_class_code_*_fromとdl_class_code_*_toは、常に有効なISO日付であるか、extra_fieldsに存在しないかのどちらかです。Diditが読み取れなかったOCRテキストを日付フィールドに返すことはありません。区分表のセルを読み取れない場合、そのフィールドは生の文字列として送信されるのではなく省略されます。そのため、フィールドが常に存在すると想定せず、is_empty演算子を使用して読み取れなかった区分の日付を振り分けてください。
日付フィールドでは、value_type: "relative_date"を使用し、値には{ "direction": "past" | "future", "amount": number, "unit": "days" | "months" | "years" }の形式のオブジェクトを指定します。たとえば、operator: "less_than"と{ "direction": "past", "amount": 3, "unit": "years" }を組み合わせると、今日から3年より前の日付に一致します。

特定のステップと比較する

グラフワークフローでは、同じ機能を複数回実行できます。たとえば、本人確認のステップを3つ配置する場合です。 value_type: "field"を使用する場合、値の末尾に@<node_id>を付けると、特定の1つのステップから値を読み取れます。 参照するノードは、ルールが設定されたステップに到達するすべての経路で、そのステップより必ず前に実行される機能ステップであるか、ルールが設定されたステップ自体である必要があります。 サフィックスのない値は、ルールが設定されたステップから読み取られます。
3つ目の本人確認ステップに設定されたこのルールは、「このステップのkyc.full_nameが、ステップocr_1で読み取られた氏名と最小スコア80であいまい一致した場合 → 機能のステータスをDeclinedに設定する」という意味です。 コンソールでは、変数ピッカーに対象となる各ステップがキャンバス上の番号で表示され、サフィックスは自動的に保存されます。

OCR / 本人確認

機能の値はOCRです。
書類ライブネスは、シグナルごとのアクションフィールドではなく、上記の6つのdocument_liveness_*しきい値で設定します。 portrait_replacement_action、printed_copy_action、 screen_capture_actionはアカウントレベルの設定であり、ワークフローの機能設定では受け付けられません。 APIは保存時に未知の設定キーを削除するため、ここで送信しても効果はありません。各シグナルには、 スコアが高いほど書類が本物である可能性が高いことを意味する0-100のスケールで、却下しきい値とレビューしきい値があります。
例:

国ごとのメソッド

methodsのキーはISO 3166-1 alpha-3の国コードです。各国には最大3つのメソッドオブジェクトを指定でき、省略したものにはデフォルトが適用されます。
最初の画面に書類を表示せず、ウォレットやルックアップが成功しなかった場合にのみ提示するには、document.fallback_onlyを設定します。この例ではフィンランドを使用しています。フィンランドではFinnish Trust Networkが最初に使われ、書類撮影はフォールバックです。また、フォールバック時に提示できる書類があるよう、フィンランドでもdocuments_allowedで書類タイプ(パスポートやIDカードなど)を有効にする必要があります。
上記の2つのルックアップは現在のカタログでどちらもavailableのため、この設定はそのまま保存できます。ウォレットブロックは意図的にオフにしています。本番環境で利用可能なウォレットはまだありません。そのためwallet.enabled: trueは拒否され、ルックアップの設定を含む保存全体が失敗します。カタログである国のウォレットがavailableになったら、その国に追加してください:
保存時にAPIが適用する検証:
  • 不明な国コード、国内の不明なキー、またはメソッド内の不明なキーは拒否されます。暗黙的に破棄されるものはありません。
  • どのメソッドも有効になっていない国は拒否されます。その国では誰も認証できないためです。
  • ウォレットまたはルックアップが書類撮影にフォールバックできるのは、その国で書類撮影が有効な場合のみです。document.enabledがfalseの国でfallback_to_documentを指定すると、フォールバック先がないため実行時に却下されます。
  • document.fallback_only: trueは、document.enabledがtrueで、かつその国の少なくとも1つのウォレットまたはIDルックアップが書類撮影にフォールバックする場合を除き、HTTP 400で拒否されます。
現在のステージング実装では、id_lookup.response_fieldsを比較出力、任意の性別、保持される登録簿ポートレートに適用します。必須の身元情報フィールドは引き続き検証記録の一部となります。これは、すべての中間プロバイダーペイロードが処理から除外されることを保証するものではありません。この変更の本番環境へのロールアウトは検証されていません。保持要件を満たすためにフィールド選択に依存する前に、対象の環境で動作を確認してください。
methodsを記述する前に、コンソールの国タブ、またはdidit_workflow_get_id_verification_methods_catalogMCPツールで機能カタログを確認してください。動作、対応範囲、請求については本人確認の方法を参照してください。

NFC / ePassport

機能の値:NFC。

ライブネス

機能の値: LIVENESS。

顔照合

機能の値: FACE_MATCH。

年齢推定

機能の値:AGE_ESTIMATION。

電話番号検証

機能の値: PHONE_VERIFICATION。 電話番号検証は、組織が初回のチャージを完了するまで無効です。
電話番号インテリジェンスによる情報付加は任意のアドオンです。phone_enrichment_enabledがtrueの場合、完了した各電話番号検証に電話番号インテリジェンスの情報が付加され、標準の電話番号検証の費用に加えてリクエスト1件あたり$0.05が請求されます。スコアに基づくアクションは、情報付加のスコアが取得できた時点で初めて有効になります。信頼指数、電話番号種別、番号ポータビリティに関するアクションは、情報付加が実行されるとすぐに適用されます。ソーシャルフットプリントチェックは、これとは別の2つ目のアドオンです。phone_social_enabledがtrueの場合、完了した各電話番号検証では、番号が登録されているオンラインプラットフォーム(メッセージング、ソーシャルメディア、Eコマース、ビジネス向けサービス)もレポートされ、リクエスト1件あたり$0.05が請求されます。phone_enrichment_enabledの有無にかかわらず有効にでき、2つのアドオンの料金と請求はそれぞれ独立しています。対象とするどのプラットフォームにも番号が見つからなかった照会結果も有効で課金対象の回答であり、phone_no_social_presence_actionをトリガーします。ワークフローのグラフで結果に応じて分岐するには、phone.social_profiles_registered(番号が登録されているプラットフォームの数)を使用してください。

メールアドレス認証

機能の値:EMAIL_VERIFICATION。
メールインテリジェンスによる情報付加は任意のアドオンです。email_enrichment_enabledがtrueの場合、完了した各メールアドレス認証にメールインテリジェンスの情報が付加され、通常のメールアドレス認証の費用に加えてリクエスト1件あたり$0.05が請求されます。スコアに基づくアクションは情報付加のスコアが取得できた時点で有効になり、漏洩に関するアクションは情報付加が実行された時点で適用されます。ソーシャルフットプリントチェックは、これとは別の2つ目のアドオンです。email_social_enabledがtrueの場合、完了した各メールアドレス認証では、アドレスが登録されているオンラインプラットフォーム(メールプロバイダー、ソーシャルメディア、プロフェッショナル、Eコマース、エンターテインメントの各サービス)もレポートされ、リクエスト1件あたり$0.05が請求されます。このアドオンはemail_enrichment_enabledの有無にかかわらず有効にでき、2つのアドオンの料金と請求はそれぞれ独立しています。対象とするどのプラットフォームにもアドレスが見つからなかった照会も有効な課金対象の結果であり、email_no_social_presence_actionをトリガーします。ワークフローのグラフで結果に応じて分岐するには、email.social_profiles_registered(アドレスが登録されているプラットフォームの数)を使用します。

データベース検証

機能の値: DATABASE_VALIDATION。 例:
database_validation_countriesがなければ、このステップは何も行いません。これを指定せずに保存されたDATABASE_VALIDATION 機能は受け付けられますが、その後は一切チェックを実行しません。そのため、必ず1つ以上のサービスIDを持つ国を 1つ以上送信してください。
ステップが実行できないサービスIDは、そのIDと理由を示す400で拒否され、何も保存されません。 これには、カタログにないID、別の国に属するID、まだ利用できないサービス、スタンドアロンのPOST /v3/database-validation/でのみ提供されるサービスが該当します。 それより前のどのステップからも入力が提供されないサービスも同様に拒否され、不足している入力が一覧で示されます。 保存済みのワークフローにすでに含まれているものの、実行できなくなったサービスは、ワークフローを再度保存した際に削除されます。 例えば、次のアルゼンチンのワークフローは、本人確認からDNI番号と性別を読み取り、セルフィーなしでRENAPERと照合します:
セルフィーをRENAPERが保有する写真とも照合するには、代わりにLIVENESSステップの後でarg_renaperを使用します。 顔照合の一致スコアとしきい値については、RENAPERを参照してください。

銀行口座認証

機能値: BANK_VERIFICATION。
銀行口座認証は、本番環境ではまだ有効になっていません。 有効になるまでは、このノードを含む本番環境のワークフローを保存しようとしても拒否されます。
ユーザーが銀行口座を認証し、銀行が報告する口座名義人を、ワークフローの前のステップで確立された本人情報と照合します。ユーザーは2つの方法のいずれかで認証します。銀行でサインインする銀行サインイン(open_banking)か、口座情報を入力して銀行が口座の名義を確認する口座照会(account_lookup)です。bank_method_orderと各国のmethodsで、国ごとにどの方法を提示し、どれを先にするかを選びます。銀行口座認証の方法を参照してください。このステップは証拠(名義人スコア、そのスコアを算出した照合、理由コード)を生成し、bank_*_actionキーがその証拠をステータスに変換します。 ノードがそもそも何かを行うかどうかは、2つの点で決まります。bank_countriesは許可リストのため、空のマップでは銀行は提示されず、チェックも実行されません。また、名義人には照合する対象が必要です。その前にOCR、DATABASE_VALIDATION、QUESTIONNAIREのいずれかのステップを置くか、セッション作成時にexpected_detailsを送信するか、bank_field_sourcesで自分でフィールドをマッピングしてください。いずれもない場合、所有権はunknownにしかならず、その扱いはbank_reference_identity_missing_actionで決まります。
銀行口座認証はまだ段階的に提供中のため、BANK_VERIFICATIONノードは、この機能が有効化されたアカウントでのみ受け付けられます。それ以外のアカウントでは保存が拒否され、その旨が表示されます。どのルートでこのステップを実行するかも、ここでは設定しません。それはコンソールのMarketplaceが自動で設定するprovider_keyとfallback_to_nativeの組み合わせです。

口座の接続

ユーザーが認証できない場合

ユーザーは常に銀行なしで続行でき、このステップで行き詰まることはありません。本人が銀行を認証できない場合を参照してください。 続行がセッションにとって何を意味するかは、ユーザーが続行した理由に応じてbank_unsupported_action、bank_attempts_exhausted_action、bank_skipped_actionのいずれかで決まります。ただし、それより前に評価された試行ですでにステップの判定が決まっている場合は除きます。判定アクションを参照してください。

名義人の照合

口座チェック

これらのキーは口座チェックにのみ適用されます。銀行サインインでは、独自の近似一致と独自のbank_max_attemptsがそのまま使われます。

財務データ

bank_expected_currenciesは、デフォルトのownership同意だけで動作します。ほかの3つのキーは実際の財務データを読み取るため、それぞれbank_scopesに対応する同意スコープが必要で、ない場合は保存が拒否されます。

保存される内容

判定アクション

ここにあるすべてのキーは、制限付きと記載されていない限りDECLINE、REVIEW、NO_ACTIONのいずれかを受け付け、省略した場合やnullを送信した場合は以下のデフォルトが適用されます。明確な所有の証拠以外がデフォルトで承認されることはなく、ユーザーに不利な実証可能な証拠がある場合にのみ却下されます。

その他の制御

これらのキーは任意です。各アクションキーはDECLINE、REVIEW、NO_ACTIONのいずれかを受け付けます。 銀行口座認証が有効で、選択したルートが指定した国をカバーしているアカウント向けのconfigオブジェクトの例:
このステップを機能させるのはbank_countriesであり、グローバルなリストではなく、 ノードが実行されるルートに照らしてチェックされます。そのルートで口座所有を確認できない国は 保存時に拒否され、エラーにその国名が示されます。国が受け入れられて実行時にスキップされると 思い込まず、エラーを確認してください。

AML

機能の値: AML。 KYCの個人スクリーニングには、次のフィールドを使用します。 KYBの企業スクリーニングには、次のフィールドを使用します。

Document AIステップが抽出したエンティティのスクリーニング

AMLステップは通常、スクリーニング対象をOCRステップ(個人)またはKYB_REGISTRYステップ(企業)から読み取ります。抽出ステップがDOCUMENT_AIのみのワークフロー(納税証明書や設立証書などの非定型書類)にはそのどちらもないため、各スクリーニング入力をどこから取得するかを指定する必要があります。 例: ワークフローのどこにも本人確認書類がない状態で、メキシコのacta constitutivaに記載された企業をスクリーニングする場合:
前にOCRステップもKYB_REGISTRYステップもない場合、AMLステップは full_nameを埋められる必要があります。氏名がなければプロバイダー検索は行えません。何もマッピングしないワークフローや、 上流のどのステップも抽出しないDocument AIキーをマッピングしたワークフローは、保存されて何もスクリーニングしないまま放置されるのではなく、保存時に拒否されます。 AMLの精度は、提供する識別子の数に直接左右されます。 氏名のみのスクリーニングこそが、大量の誤検知を生む原因です。

デバイス・IP分析

機能の値: IP_ANALYSIS。 例:
高い信頼度で復元されたデバイスを自動的に却下する前にモニタリングしたい場合は、recovered_device_actionをduplicated_device_actionとは別に使用してください。復元デバイスの一致は不正グループの検知を目的として設計されていますが、それでも自社のトラフィックに合わせて調整する必要があるため、これは導入段階で役立ちます。

位置情報検証

機能の値: GEOLOCATION。 本人が認証を行っている間にどこにいるかを、デバイスの位置または接続のIP所在地から確認し、許可エリアとブロックエリア、IP所在地、書類の住所と照合します。 ステップの動作については位置情報検証を、判定フィールドについてはそのレポートを参照してください。 書類の住所までの距離が必要な場合は、本人確認または住所証明の後に配置してください。距離は住所が登録されている場合にのみ測定されるためです。 geolocation_position_sourceが未設定の場合、IP所在地までの距離を測定するには、同じワークフロー内にデバイス・IP分析ステップが必要です。 すべてのキーは任意です。configが空のステップは、精度250m以内かつ120秒以内に取得されたデバイス位置を要求し、本人に3回の試行を与え、エリアルールは適用しません。 各検出結果には固有のアクションキーがあり、未設定のアクションキーには、選択したgeolocation_presetのデフォルトが適用されます。プリセットを選択していない場合は、以下に記載するキーごとのデフォルトが適用されます。 不確かな位置情報や拒否された位置情報のデフォルトはREVIEWであり、DECLINEになることはありません。権限の拒否や広い半径は不正の証拠ではないためです。 明示的に設定したアクションは、常にプリセットより優先されます。 リプレイされたチャレンジ(LOCATION_REPLAY_DETECTED)とデバイスアテステーションの失敗(LOCATION_INTEGRITY_FAILED)は常に却下となり、アクションキーはありません。

エリアの形状

geolocation_areasの各項目には、id(A-Z a-z 0-9 _ -からなる1〜64文字で、リスト内で一意)、任意のlabel(最大80文字)、allowedまたはblockedを指定するtype、形状を選択するkindがあります。 1つのリストに含められるエリアは最大50個で、is_geolocation_geofencing_enabledがtrueの間は少なくとも1つのallowedエリアが必要です。 geolocation_areasとgeolocation_geofencing_by_countryは同時に送信できません。また、geolocation_refusal_path: "end_session"を指定するには、geolocation_permission_denied_actionがREVIEWまたはDECLINEである必要があります。 境界が公開されていない国の地域など、一致する可能性のないエリアは、APIが保存せずに拒否します。 例:

住所証明

機能の値: PROOF_OF_ADDRESS。

アンケート

機能の値: QUESTIONNAIRE。

KYB登記

機能の値: KYB_REGISTRY。 kyb_registry_fields_configは、設定可能な各フィールドキーを{"enabled": bool, "required": bool}に対応付けます。enabled: falseはフィールドを非表示にし、enabled: true, required: falseは任意項目として表示し、enabled: true, required: trueは送信時に入力必須にします。company_name、country_code、regionは常に表示される必須項目で、設定できません。オブジェクトを省略した場合、またはnullか{}の場合はデフォルトが適用され、incorporation_dateのみが必須で、その他のフィールドはすべて任意になります。
設定可能なフィールドキー: registration_number、incorporation_date、legal_address、vat_number、alternative_names、tax_number、company_type、legal_entity_identifier、location_of_registration、nature_of_business、registered_capital_amount、registered_capital_currency、website、email、phone、control_scheme。エンドユーザー側の動作については設定可能な登記フォームフィールドを、vat_numberとtax_numberの確認方法についてはVATおよび納税者番号の検証を参照してください。

KYB書類

機能の値:KYB_DOCUMENTS。

KYB主要人物

機能の値:KYB_KEY_PEOPLE。

Document AI

機能の値:DOCUMENT_AI。 ユーザーに1件以上の書類を提出してもらい、定義した名前付きフィールドをビジョンモデルで抽出します。設定した各フィールドは分岐に使える値document_ai.<key>となり、ステップの結果はdocument_ai.statusです。 document_ai_documentsの各エントリは書類です。 書類のfieldsの各エントリはフィールドです。 例:

電子署名

機能の値:SIGNATURE。 本人確認を受けた人物、または企業の主要人物に、Simpleレベル(デフォルト)またはAdvanced(AES)で書類に署名してもらいます。署名者を検証するステップ(本人確認と、コード送信用のメールアドレス認証または電話番号検証)の後に配置してください。詳しくは電子署名を参照してください。 ワークフローの書類上のフィールドは、コンソールのテンプレートエディターで配置します。セッションの書類の場合は、フィールドをsign.documents[].fieldsで送信し、api.<key>フィールドの値をsign.field_valuesで送信します。詳しくはセッションの作成を参照してください。 セッションごとに書類を送信する場合の例:
最終更新日 2026年11月1日