はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴国ごとの本人確認方法
本人確認でCountries and allowed ID methodsを開くと、国ごとに書類の撮影、書類不要の照会、デジタルIDウォレットを設定できます。 Additional settingsには、書類のサブタイプ、照会の試行回数、フォールバックルールがあります。 書類不要の照会には、組織のデータベース検証サービスの料金が適用されます。 完了した試行はそれぞれ個別に課金され、部分一致や一致なしの場合も含まれます。完了した試行が2回あれば、課金も2回です。 形式エラーや、回答を返さないプロバイダー障害は課金されません。 1回の試行に複数のデータベースサービスが回答した場合は、該当する各サービスの料金が合算されます。 デフォルトはフォールバック前に1回の試行で、1回から5回まで設定できます。 完了した照会が書類にフォールバックした場合、書類の撮影は追加で課金されます。 本番環境のアプリケーションでは、本番環境で利用可能なウォレットのみを有効にできます。 リリース待ちのウォレットは無効のままです。 サンドボックスのアプリケーションでは、カタログ内のすべてのウォレットをシミュレーション結果でテストできます。サンドボックスで利用可能であっても、本番環境で利用可能であることを示すものではありません。 照会とウォレットの失敗シナリオについては、サンドボックスでのテストを参照してください。ワークフローのバージョン管理
ワークフローはドラフト/公開のバージョン管理に対応しています。そのため、稼働中のセッションに影響を与えることなく、ワークフローを安全に改善できます。- ドラフトバージョンは完全に編集可能です。ノードの追加、削除、再構成を自由に行えます
- ドラフトを公開すると、新しいセッションで使用される変更不可のバージョンが作成されます
- 以前のバージョンは保持されるため、過去のどのセッションで使用された設定も正確に確認できます
- セッションは常に作成時の特定のバージョンを参照するため、更新を公開した後も一貫性が保たれます
ワークフローを構築する2つの方法
Didit では、検証ワークフローの作成方法として2つの異なるアプローチを用意しており、ニーズに合った複雑さを選べます。
1. シンプルモード: テンプレートベースのビルダー
シンプルモードは、すぐに始めたい場合に最適です。あらかじめ用意されたテンプレートを選び、必要な機能のオン/オフを切り替えるだけで準備が整います。
- 迅速なセットアップと導入
- 標準的な検証フロー
- 本人確認を初めて導入するチーム
- 一般的なパターンに当てはまるユースケース
- ワークフローテンプレートを選択します(KYC、年齢確認など)
- 機能のオン/オフを切り替えます(ライブネス、顔照合、AMLなど)
- 各機能の基本設定を構成します
- 公開して検証を開始します
2. 詳細モード: ビジュアルグラフビルダー
詳細モードでは、Didit のオーケストレーションエンジンの機能をすべて利用できます。ドラッグ&ドロップできるノード、分岐、カスタムロジックを備えたビジュアルグラフエディターを使って、複雑な条件付きの検証フローを構築できます。
- 複数の経路を持つ複雑な検証ジャーニー
- ユーザーデータや検証結果に基づく条件付きロジック
- 独自のビジネスルールと分岐
- エンタープライズレベルのコンプライアンス要件
- ビジュアルノードエディター: 無限キャンバス上でノードをドラッグ、ドロップし、接続できます
- スマート接続: ノードのハンドルから空いているスペースへドラッグすると、新しいノードを即座に作成して接続できます
- 条件分岐: 抽出されたデータ、検証ステータス、国、書類タイプ、書類サブタイプ、発行日、年齢、WebhookのJSONレスポンスのパス、またはカスタムルールに基づいてユーザーを振り分けます
- アクションの自動化: フローの結果に応じて、タグの追加、メタデータの設定、手動レビューへの振り分けを行います
- キーボードショートカット: 元に戻す(Ctrl/Cmd+Z)、やり直す(Ctrl/Cmd+Shift+Z)、削除(Delete/Backspace)
- ズームとパン: スクロールでのズームやドラッグでのパンにより、複雑なフローを操作できます
グラフビルダーのノードタイプ
機能ノードのカテゴリー
ユーザー操作を伴う機能(ワークフローの開始点にできます):- 本人確認(OCR)
- ライブネス検知
- 顔照合
- 年齢推定
- 電話番号検証
- メールアドレス認証
- アンケート
- 住所証明
- Document AI
- NFC / ePassport
- AMLスクリーニング(前段に本人確認、KYB Registry、またはDocument AIのステップが必要です。スクリーニング対象エンティティを参照してください)
- データベース検証(先にOCRが必要です)
- デバイス・IP分析
注: バックエンド専用の機能はビルダー内で専用のインジケーターで示され、依存関係が満たされるとユーザー操作なしで自動的に実行されます。各機能ノードの最初の設定タブは検証エンジンの項目から始まります。Didit独自のエンジンでチェックを実行するか、Marketplaceから接続したサードパーティのプロバイダーに切り替えることができます。そのプロバイダーが利用できない場合は、自動的にDiditにフォールバックします。
スクリーニング対象エンティティ
AMLスクリーニングは通常、スクリーニング対象を直前のステップから取得します。本人確認ステップが書類から読み取った人物、またはKYB Registryステップが返した企業です。しかし、どちらも含まないフローもあります。税務証明書や公証済みの設立証書など、標準化されていない書類を扱う、Document AIだけで構築されたフローは、氏名、生年月日、書類番号、国をすでに保持していますが、それらは独自のフィールドキーの下に格納されています。 AMLノードの詳細タブで、これらのキーをスクリーニングに割り当てます。- エンティティタイプ: 個人をスクリーニングするか、アップロードされた書類に記載された企業をスクリーニングするかを選びます。企業ノードは人物ではなく企業の記録を検索します。
- フィールドの取得元: 4つのスクリーニング入力(氏名、生年月日、国、書類番号)のそれぞれを、Document AIのフィールド、アンケートの回答、またはセッション作成時に送信する値(
expected_details/metadata)に対応付けます。すでにfull_nameという名前を付けたDocument AIのフィールドは自動的に取り込まれます。 - 不完全なスクリーニングデータ: 完全な身元情報がそろっていない状態でスクリーニングが実行された場合の動作です。デフォルトはレビューです。No actionを選ぶのは、フローが意図的に氏名しか保持していない場合に限ってください。
分岐条件がセッションデータを読み取る仕組み
条件が読み取るレコード。 分岐条件は、その条件の作成元となった機能ノードに紐づいており、そのノードの結果を読み取ります。1つのノードが複数のレコードを生成した場合、条件は最新のレコードを読み取ります。これが最も重要になるのはデバイスとIP分析です。Diditはセッションが開かれたデバイスとIPアドレスごとに1件の観測を記録するため、セッションの途中でスマートフォンやネットワークを切り替えたユーザーは、同じノードに複数のレコードを残します。その場合、IP COUNTRY is in [...]のようなルールは最新の観測に対して評価されます。これは、セッションのデバイスとIP分析パネルの先頭に表示されるレコード、および判定ペイロードのip_analyses配列の先頭にあるレコードと同じです。複数の観測を持つセッションにはMULTIPLE_DEVICES_IN_SESSION警告も付与されます。これは、分岐の結果だけでなく一覧全体を確認すべきであることを示すシグナルです。
国の値。 国の条件は、表記ではなく国そのものに基づいて照合されます。フィールドピッカーから国を選択すると、Diditが比較の両側を正規化するため、ISO 3166-1 alpha-3(UKR)で記述したルールでも、alpha-2(UA)として取得された値に一致します。
値の欠落、空の値、否定の比較。 値がまったくないフィールド(書類に記載がない、メタデータのキーが送信されていない、機能が実行されなかった)は、is emptyとequals not_definedにのみ一致します。それ以外の比較(equals、contains、greater than、さらにnot equalsとnot inも含む)はすべて一致せず、分岐ノードは次の分岐に進みます。空文字列を保持するフィールドは値であり、欠落したフィールドではありません。"metadata": {"credential_state": ""}で作成されたセッションはmetadata.credential_state equals ILを満たしませんが、not equals IL、not in [IL, MA, NJ]、equals ""は満たします(is emptyはどちらのケースにも一致します)。したがって、否定の比較で承認する分岐は、州が空で送信されたセッションを承認しますが、キーが省略された同じセッションはフォールバックに進みます。not equalsやnot inでルーティングする場合は、同じ分岐にmetadata.<key> is not emptyを追加し(AND条件)、どちらのケースも値が存在しない場合の行き先に到達するようにしてください。分岐は順番に評価され、最初に一致したものが採用されます。フォールバック分岐(条件のない分岐)は、他のどの分岐にも一致しなかった場合にのみ採用されます。そのため、すべての分岐ノードに、想定外の値を到達させたい場所で終わるフォールバックを設定してください。どの機能にも警告がないのにレビュー中になったセッションは、チェックではなく、グラフ内のステータスノードによってそこにルーティングされたものです。通常の原因は分岐ノードのフォールバック分岐です。
セッションメタデータ。 セッション作成時にmetadataで送信した値は、すべての分岐でmetadata.<key>として利用でき、固定値または別のセッションフィールドと比較できます(例: metadata.min_age <= Age)。数値は数値として比較されるため、18と"18"は同じように動作します。
サンドボックス/テストモード。 分岐条件、メタデータ、ステータスノードは、サンドボックスでも本番環境とまったく同じように動作し、サンドボックスがそれ自体でセッションをレビューに回すことはありません。違いは書類です。サンドボックスのセッションには米国の州/地域を持たない架空の書類が含まれるため、そこではRegion条件が一致しません。州に依存するフローをテストする方法については、架空の書類に含まれない項目を参照してください。
再提出。 分岐ノードは、再提出を含むすべての試行で評価されます。特定のステップについてセッションを差し戻すと、それらのステップの間に配置された分岐とアクションは、ユーザーがステップを再度完了する際に、新規の試行のデータに対して再び実行されます。したがって、試行の間に制限対象の法域へ移ったユーザーは、その法域を対象とする分岐によってルーティングされ、却下の結果で終わる分岐は、再提出されたセッションをそこで終了させます。
セッションがどの分岐を通ったかを確認する。 セッションの実行中にワークフローが行うすべての分岐判定と、セッションが到達するすべての結果ノードは、セッションのイベントタイムライン(Consoleのセッション詳細 > Events、およびGET /v3/session/{id}/decision/?include=events)に記録されます。Workflow routingの行には、分岐ノード、一致した条件、セッションが進んだ先のノードが示されます。または、一致した条件がなく、そのノードのフォールバックエッジが採用されたことが示されます。Workflow outcomeの行には、セッションのステータスを設定したステータスノードが示されます。どの機能もフラグを立てていないのにワークフローがセッションをレビュー中に送った場合、これらの行には、フォールバックエッジとその先の結果ノードを含め、セッションが通った経路が表示されます。後から行われた手動の判定によって、これらのワークフローイベントが書き換えられることはありません。入力の欠落は考えられる原因の1つです。metadata.*の値が存在することを要求する条件は、セッション作成時にキーが省略された場合には一致しません。is_emptyやnot_definedを指定したequalsのように、入力の欠落を明示的にテストする条件は、同じ欠落したキーに一致する可能性があります。フォールバックエッジは、else分岐を含め、どの分岐にも一致しなかった場合にのみ採用され、デフォルト出力に接続されたノードへ進みます。イベントのペイロードについては、セッションイベントを参照してください。
ワークフローテンプレート: 構築の出発点
テンプレートは固定された種類ではなく、一般的なユースケース向けに設計されたスマートな事前設定済みの出発点です。シンプルモードではそのまま使用でき、アドバンスドモードでは自由にカスタマイズできる土台になります。
利用可能なテンプレート
1. KYCワークフロー
新規ユーザーのオンボーディングと、本人確認 (KYC) コンプライアンスへの完全な対応を実現する包括的なソリューションです。- 開始ステップ：中核となる本人確認書類の検証。
- よく追加される機能：
[+]ライブネス検知：ユーザーがその場に実在することを確認し、なりすましを防止します。[+]顔照合1:1：ユーザーのセルフィーと身分証明書の写真を生体情報で照合します。[+]AMLスクリーニング：ユーザーをグローバルな制裁リスト、PEPリスト、ネガティブメディアリストと照合します。[+]NFC認証：電子パスポートや電子IDのチップを読み取り、政府機関レベルのセキュリティを追加します。[+]住所証明 (PoA)：ユーザーの居住地住所を検証します。[+]電話番号検証：追加の要素として電話番号の所有を確認します。[+]メールアドレス認証：追加の要素としてメールアドレスの所有を確認します。[+]データベース検証：政府の公式データベースや信用情報データベースと照合します。[+]アンケート：カスタマイズ可能なフォームで、構造化された申告と裏付け書類を収集します。[+]デバイス・IP分析：位置情報と接続のリスクを分析します。
2. アダプティブ年齢確認ワークフロー
年齢制限のあるサービス向けの、負担が少なくプライバシーに配慮したフローです。- 開始ステップ：セルフィーによる年齢推定。
- 主なロジック：
- 推定年齢がしきい値を明らかに上回る場合 (例: 18+のサービスで推定25+)、ユーザーは即座に通過します。
- 推定年齢がしきい値を下回る、または「バッファゾーン」内にある場合 (例: 推定16-20歳)、正確な生年月日を確認するために完全な本人確認書類の検証へのフォールバックを自動的にトリガーするようワークフローを設定できます。
- よく追加される機能：
[+]デバイス・IP分析：地理的な位置に基づいてアクセスを制限します。
3. 生体認証ワークフロー
書類を再度求めることなく、再訪ユーザーを迅速かつ安全に再検証する方法です。- 開始ステップ：ユーザーがその場にいることを確認するライブネス検知チェック。
- 中核となるロジック：
- システムは、新しく撮影したライブセルフィーと、ユーザーの最初の承認済みKYC認証で得られた信頼できる生体認証テンプレートとの間で顔照合を行います。
- 同じ
vendor_dataのもとでユーザーの顔がすでに保存されている場合 (承認済みのライブネス顔画像、電子パスポートの写真、身分証明書の顔写真、または登録済みのプロフィール顔画像)、セッション作成時にportrait_imageを省略でき、Diditが保存済みの顔を自動的に再利用します。それ以外の場合はportrait_image(Base64エンコードされた画像、最大2MB) を渡してください。どちらもない場合、セッションの作成は400で失敗します。
- よく追加される機能：
[+]電話番号検証：住所を検証済みの電話番号に紐付けます。[+]メールアドレス認証：追加の要素としてメールアドレスの所有を確認します。[+]デバイス・IP分析：新しい場所からの不審なログイン試行を検知します。
4. 住所確認ワークフロー
住所証明 (PoA) が主な要件である場合の専用フローです。- 開始ステップ：ユーザーによる住所証明書類 (例: 公共料金の請求書、銀行取引明細書) の提出。
- 中核となるロジック：AIが書類から氏名と住所を抽出し、検証します。
- よく追加される機能：
[+]電話番号検証：住所を検証済みの電話番号に紐付けます。[+]メールアドレス認証：追加の要素としてメールアドレスの所有を確認します。[+]デバイス・IP分析：書類上の住所とユーザーの現在の位置情報を比較し、確実性を高めます。
5. アンケート認証ワークフロー
カスタマイズ可能なフォームで構造化された申告と裏付け書類を収集することが主な目的である場合の専用フローです。- 開始ステップ：アンケート。
- 中核となるロジック：システムが、設定済みのアンケート (セクション、翻訳済みコンテンツ、必須フィールド、アップロード) を表示します。
- よく追加される機能：
[+]デバイス・IP分析：アンケートの回答に位置情報と接続のコンテキストを追加します。
完全なカスタマイズ ワークフロー内の各機能は、要件に正確に合わせて固有のパラメーターでさらにカスタマイズできます。ビルダーで各チェックの設定を確認してください。
婚姻状況に基づいてルールを構築する
Advanced Modeでは、OCRフィールドkyc.marital_statusを条件分岐やカスタムステータスルールで使用できます。ルールが自由入力のテキストではなくサポートされている列挙値を使うよう、値はフィールドピッカーから選択してください。書類に婚姻状況が記載されていない場合、値は空になり、フォールバックの分岐が適用されます。
ワークフローコパイロットでは、Database Validationステップの作成と設定を1回の操作で行うこともできます。このチェックの追加を依頼する際は、必要な国を指定してください。コンソールが国ごとにサポートされているサービスを特定し、保存された設定をキャンバス上に表示します。
シンプルモードとアドバンストモードの比較
連携の流れ
オーケストレーションされたワークフローの連携は簡単です。サーバーがDiditでセッションを作成し、固有のURLを受け取って、ユーザーをそのURLにリダイレクトします。残りの処理はDiditが行い、結果をWebhookでサーバーに通知します。主なユースケース
| ユースケース | 推奨テンプレート | 推奨モード | 推奨機能 |
|---|---|---|---|
| 基本的な本人確認 | KYC | シンプル | ライブネス検知、顔照合 |
| 高セキュリティのオンボーディング | KYC | アドバンスト | NFC認証、ライブネス検知、顔照合、AMLスクリーニング、電話番号検証 |
| 年齢制限のあるコンテンツ/サービス | 適応型年齢確認 | シンプル | 本人確認へのフォールバック |
| 再訪ユーザーの認証 | 生体認証 | シンプル | デバイス・IP分析 |
| 住所の確認 | 住所証明 | シンプル | 電話番号検証 |
| 金融サービスのオンボーディング | KYC | アドバンスト | ライブネス検知、顔照合、住所証明、AMLスクリーニング、データベース検証 |
| 地域ごとのコンプライアンス | KYC | アドバンスト | 国による条件付きルーティング、地域ごとに異なるチェック |
| リスクに基づく認証 | KYC | アドバンスト | リスクスコアに基づく条件分岐、エスカレーションパス |
はじめに
- Diditを初めて使う場合は、シンプルモードと既製のテンプレートから始めてください
- カスタマイズが必要な場合は、アドバンストモードに切り替えて条件付きロジックを追加してください
カスタムのワークフロー設定についてのご相談や、お客様固有の要件に最適な構成についてのアドバイスは、営業チームまでお問い合わせください。