メインコンテンツへスキップ
vendor_dataは、各セッションと取引をユーザーまたは企業エンティティに紐付けるために指定する識別子です。エンティティの集約において最も重要なフィールドであり、正しく設定すれば、その後のすべての機能(プロフィール履歴、トランザクションモニタリング、ブロックリストの適用、継続的なAMLモニタリング)がスムーズに動作します。

概要

vendor_dataは、お客様が任意に決める文字列です。Diditはこれを不透明な識別子として扱い、内容を解釈しません。代表的な値は次のとおりです。
個人情報(メールアドレス、電話番号、加工していない納税者番号)をvendor_dataに直接入れないでください。ハッシュ化するか、プレフィックスを付けてください。vendor_dataはWebhookのペイロードに含まれ、エンティティが存在する限り無期限に保存されます。

紐付けの仕組み

vendor_dataの値を指定してセッションまたは取引を送信すると、次のように処理されます。
  1. Diditは、お客様のアプリケーション内でそのvendor_dataを持つエンティティを検索します。
  2. エンティティが存在する場合、新しいオブジェクトはそのエンティティに紐付けられます。
  3. エンティティが存在しない場合、Diditはエンティティを(status: ACTIVEとして)作成し、新しいオブジェクトを紐付けます。
これは次の場合に当てはまります。
  • POST /v3/session/:KYCおよび法人確認 (KYB) のセッション
  • POST /v3/transactions/:取引(申請者と取引相手の両方)
  • 取引ペイロード内のapplicant.vendor_data/counterparty.vendor_dataフィールド

一意性とスコープ

vendor_dataはアプリケーションごとに一意であり、Didit全体で一意なわけではありません。 そのため、ステージング用アプリと本番環境用アプリで同じvendor_dataを使っても衝突しません。また、ユーザーuser-42と企業user-42を同時に持っても衝突しません(ただし、わかりやすさのために推奨されません)。

vendor_dataを省略した場合

vendor_dataを指定せずにセッションを作成することもできます。その場合は次のようになります。
  • そのセッションに対してエンティティは作成されません。
  • セッションはどこにも属さず、どのユーザーまたは企業のプロフィールにも表示されません。
  • 後からそのセッションをvendor_dataで検索することはできず、session_idでのみ検索できます。
この方法は、エンティティの集約が不要な匿名または単発の認証にのみ使用してください。再検証、取引、継続的なモニタリングを伴う連携では、必ずvendor_dataを指定してください。

エンティティを事前に作成してからセッションを実行する例

3つの呼び出しはすべて同じユーザーエンティティに紐付けられます。後からGET /v3/users/user-42/を呼び出すと、セッション数、承認済み/却下の件数、紐付けられた取引、最新のプロフィールデータを確認できます。

外部IDの移行

既存のKYCベンダーからDiditに移行する場合は、初日から既存の固定ユーザーIDをvendor_dataとして渡してください。これにより、次のことが容易になります。
  • Diditのデータを社内データベースと照合する。
  • セッションを実行する前に、コンソールのCSVインポートで過去のユーザーを一括登録する。
  • 後から取引モニタリングをDiditに移行する際に、関係性を維持する。

ルール、規約、ベストプラクティス

次のステップ

ユーザーの概要

ユーザーエンティティと操作について詳しく説明します。

企業の概要

企業エンティティと操作について詳しく説明します。

セッションの作成

vendor_dataに対する認証を開始します。

取引の作成

エンティティに紐付けた取引を送信します。
最終更新日 2026年11月1日