vendor_dataは、各セッションと取引をユーザーまたは企業エンティティに紐付けるために指定する識別子です。エンティティの集約において最も重要なフィールドであり、正しく設定すれば、その後のすべての機能(プロフィール履歴、トランザクションモニタリング、ブロックリストの適用、継続的なAMLモニタリング)がスムーズに動作します。
概要
vendor_dataは、お客様が任意に決める文字列です。Diditはこれを不透明な識別子として扱い、内容を解釈しません。代表的な値は次のとおりです。
紐付けの仕組み
vendor_dataの値を指定してセッションまたは取引を送信すると、次のように処理されます。
- Diditは、お客様のアプリケーション内でその
vendor_dataを持つエンティティを検索します。 - エンティティが存在する場合、新しいオブジェクトはそのエンティティに紐付けられます。
- エンティティが存在しない場合、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を指定してください。
エンティティを事前に作成してからセッションを実行する例
GET /v3/users/user-42/を呼び出すと、セッション数、承認済み/却下の件数、紐付けられた取引、最新のプロフィールデータを確認できます。
外部IDの移行
既存のKYCベンダーからDiditに移行する場合は、初日から既存の固定ユーザーIDをvendor_dataとして渡してください。これにより、次のことが容易になります。
- Diditのデータを社内データベースと照合する。
- セッションを実行する前に、コンソールのCSVインポートで過去のユーザーを一括登録する。
- 後から取引モニタリングをDiditに移行する際に、関係性を維持する。
ルール、規約、ベストプラクティス
次のステップ
ユーザーの概要
ユーザーエンティティと操作について詳しく説明します。
企業の概要
企業エンティティと操作について詳しく説明します。
セッションの作成
vendor_dataに対する認証を開始します。
取引の作成
エンティティに紐付けた取引を送信します。