新しいケイパビリティの追加方法(API)
情報
このガイドは、API(POST /processes/v1)経由で不正リスク分類(Trust Network)をすでに統合しており、契約に本人確認を追加するクライアントを対象としています。
本人確認の追加
このガイドでは、本人確認プロセスを強化するための意思決定エンジンの進化について説明します。
技術要件
他のインテグレーションとは異なり、このケイパビリティを有効にするにはAPIキーの更新が必要です。この変更を行わないと、新しい本人確認レスポンスを受け取ることができません。担当のUnico窓口よりご案内します。
大きな変更点:本人確認
主な改善点は、(不正レスポンスに加えて)本人の同一性を検証できるようになったことです。システムはプロセスを実行している人物が、実際に提出された書類の本人であるかどうかを検証するようになりました。
このケイパビリティが有効化される前に、チームが新しいレスポンスの解釈を正しく理解し、マッピングしておくことが極めて重要です。そうしないと、運用に影響が及ぶ可能性があります。
結果比較表
| 結果(Trustのみ) | 結果(Trust + IDUnico) | 意味と推奨アクション |
|---|---|---|
| N/A | APPROVED | 新規(理想的な状態)。 ユーザーは本人確認書類の本人であり、不正の証拠はありません。 |
INCONCLUSIVE | INCONCLUSIVE | ニュアンスの変化。 ユーザーは実在し、不正の証拠はありませんが、本人確認書類の本人であるという確証はありません。 |
REPROVED | REPROVED | 却下を推奨。 不正の兆候がある、またはシステムがユーザーは本人確認書類の本人ではないと確認 しました。 |
HIGH_RISK | HIGH_RISK | 強い不正の証拠が少なくとも1つあります。アクションはクライアントが判断します。 |
CRITICAL_RISK | CRITICAL_RISK | 重大な不正の証拠が少なくとも2つあります。却下を推奨します。 |
命名における主な変更点
承認フローにおいて、以下の3つの基本的な変更に対応できるようシステムを準備してください。
APPROVEDの登場 — これが新たな「理想」の状態です。このコードを受け取った場合、プロセスの同一性と安全性について完全な確証があります。INCONCLUSIVEの新しいニュアンス — 以前は主要な「green light(承認可)」でした。現在は、ユーザーが「実在」しており明白な不正はないものの、システムが本人確認書類の同一性と完全な確証を持って紐づけられなかったことを意味します。REPROVEDの重大性 — 複数要因による不正の兆候に加えて、この状態にはユーザーが本人確認書類の本人になりすましているケースも含まれるようになりました。