AWAITING_USER: フラグ付きトランザクションの自動修復 (JA)

トランザクション監視において最も難しいのは、不審な支払いを捕捉することではなく、その後の対応です。即座に拒否すれば、完全に正当な顧客をブロックしてしまう可能性があります。承認すれば、フラグを立てたリスクを受け入れたことになります。ほとんどのチームはこれを手動キューで解決しています。アナリストがユーザーにメールを送り、書類が届くのを何日も待ち、その間ずっとトランザクションは凍結されたままになります。

DiditのTransaction Monitoring APIには、このギャップを埋めるために特別に構築された4番目のステータスAWAITING_USERがあります。承認か拒否かという二者択一ではなく、フラグ付きトランザクションを一時停止し、ユーザーに特定の行動（本人確認の再実施、資金証明の提出など）を要求し、ユーザーがそれをクリアした瞬間に自動的に再開できます。摩擦はリスクがある場所にのみ発生し、他のすべてと同様にトランザクションあたり0.02ドルの費用がかかります。

このガイドでは、AWAITING_USERパスがどのように機能し、それをフローに組み込む方法について説明します。

主なポイント

• AWAITING_USERは、APPROVED、IN_REVIEW、DECLINEDと並ぶ4つのトランザクションステータスの1つです。そのため、修復は回避策ではなく、第一級の成果物として扱われます。
• フラグ付きトランザクションは失敗する代わりに一時停止し、ユーザーからのステップアップアクションを要求し、そのアクションがクリアされると自動的に再開されます。
• ステップアップは、再KYC、資金証明のアップロード、または統合された/v3/ APIで生成されるあらゆる検証ステップが可能です。
• Webhooksがループを駆動します — transaction.status.updatedは、トランザクションがAWAITING_USERに入るときと出るときに発生します。
• ケース管理にも同じステータスが存在します。そのため、アナリストはアラートをAWAITING_USERに移動し、ユーザーがそれをクリアできるようにすることができます。
• トランザクションあたり0.02ドル、最低料金はありません。修復中に生成される再KYCまたはAMLチェックは、それぞれの公開料金で請求されます。

AWAITING_USERの機能

ルールが発動すると、エンジンはステータスを割り当てます。4つのうち3つは見慣れたものです。APPROVEDはトランザクションを許可し、IN_REVIEWはアナリスト向けのアラートを開き、DECLINEDはトランザクションをブロックします。4番目のAWAITING_USERは異なる動作をします。トランザクションを中断し、解決される前にユーザーが何かをする必要があることを示します。

具体的には、高額または高頻度のルールがトリガーされた場合、エンジンはAWAITING_USERを返し、アプリケーションはユーザーに要求されたステップ（新しいライブネスチェック、書類のアップロード、資金源の申告など）を完了するように促し、検証セッションはプラットフォームにフィードバックされます。ステップがクリアされると、トランザクションは再評価され、APPROVEDに移行します（または、新しい証拠によって状況が悪化する場合はエスカレートします）。アナリストが監視する必要はありません。

なぜ重要なのか

ハードデクラインはコストがかかります。すべての誤検知によるブロックは、不満を抱いた正当な顧客、サポートチケット、そして多くの場合、アカウントの解約につながります。しかし、フラグ付きの支払いを通過させると、企業は執行措置を受けることになります。従来の解決策である手動の修復キューは、コストを別のコスト（アナリストの時間、遅い対応、何日も凍結されたトランザクション）に置き換えるだけです。

AWAITING_USERはそのトレードオフを解消します。ユーザーは、自身のトランザクションが待機しているため、それをクリアする動機があるまさにその瞬間、摩擦のポイントで作業を行います。リスクを捕捉し、顧客を維持し、書類を追いかけるためにアナリストに費用を払う必要はありません。これは、顧客を失うコンプライアンス管理と、静かにその役割を果たすコンプライアンス管理の違いです。

技術詳細

エンジンが修復にルーティングするトランザクションは、AWAITING_USERステータスと、それをトリガーしたルールを伴って返されます。

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "High-value transfer — first 30 days", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

これに対し、ユーザーにプロンプトを表示し、統合された/v3/ APIで検証ステップを生成します。ステップが完了すると、トランザクションが進行したことをWebhookが通知します。

# webhook payload: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

Webhooks。 transaction.createdとtransaction.status.updatedを購読します。status-updatedイベントは、トランザクションがAWAITING_USERに入るときと出るときの両方で発生するため、ポーリングなしで台帳とUIを同期できます。

価格。 トランザクションあたり0.02ドルです。修復ステップ自体は、それぞれの公開料金で請求されます。再KYCはユーザー検証料金で、フラグ付きの当事者に対するAMLチェックは0.20ドルです。

修復ループ、ステップバイステップ

1. ルールをトリガーする。 新しいアカウントからの最初の高額送金など、ポリシーで拒否ではなく修復すべきとされているしきい値をトランザクションが超える。
2. 失敗ではなく一時停止。 エンジンはDECLINEDではなくAWAITING_USERを返し、必要なアクションが添付される。
3. ユーザーに促す。 アプリケーションはステップアップ（ライブネスの再チェック、書類のアップロード、資金源の申告）を表示し、検証セッションを生成する。
4. ユーザーがクリアする。 ユーザーは、すでにいたフロー内でステップを完了する。
5. 自動的に再開する。 トランザクションは新しい証拠で再評価され、APPROVEDに移行する — または、証拠によってリスクが高まる場合はIN_REVIEW/DECLINEDにエスカレートする。いずれの場合も、transaction.status.updated webhookがバックエンドに通知する。

ケース管理にも同じAWAITING_USER状態が存在するため、IN_REVIEWアラートを処理しているアナリストも、自分で解決する代わりにユーザーにアラートを返送することができます。アラートはOPEN → INVESTIGATING → AWAITING_USERと遷移し、ユーザーが応答すると解決されます。

ユースケース

• フィンテック — 新しくオンボーディングされたアカウントからの最初の高額送金が、顧客をブロックする代わりに資金証明のために一時停止する。
• 暗号通貨 — リスクの高いウォレットへのアウトバウンド送金が、決済前に資金源の申告のために一時停止する。
• 融資 — 合成IDシグナルをトリガーする支払い disbursement が、再KYCライブネスチェックのために一時停止する。
• マーケットプレイス — 速度ルールをトリガーする販売者への支払いが、資金が解放される前に再検証のために一時停止する。
• iGaming — 入金速度の急増が、ステップアップチェックのために一時停止し、責任あるゲーミングの接点としても機能する。

Diditとの連携方法

1. 修復ポリシーを決定する。 ビジネスコンソールで、どのルールがDECLINEDではなくAWAITING_USERにルーティングされるか、そしてそれぞれがどのステップアップアクションを要求するかを設定します。
2. トランザクションを送信する。 資金が移動するたびにPOST /v3/transactions/を使用し、安定したtransaction_idとvendor_dataでそれぞれをユーザーにリンクします。
3. 一時停止を処理する。 トランザクションがAWAITING_USERを返した場合、ユーザーにプロンプトを表示し、/v3/ APIで検証ステップを生成します。
4. 再開をリッスンする。 ユーザーがステップをクリアした後、transaction.status.updatedに反応してトランザクションをリリースまたは保留します。

すべてが統合された/v3/ API上にあるため、フラグ付きトランザクションが生成する修復KYCは、ユーザーをオンボーディングする際に使用するKYCと同じです。つまり、エンドツーエンドで1つのIDおよび不正防止プラットフォームを使用します。

よくある質問

AWAITING_USERとは何ですか？

4つのトランザクションステータスの1つです。不正が疑われる取引を即座に拒否する代わりに、一時停止して本人確認の再実施や資金証明などのユーザーアクションを要求し、ユーザーがそれをクリアすると自動的に再開されます。

トランザクションは自動的に再開されますか？

はい。要求されたステップがクリアされると、トランザクションは再評価され、自動的にAPPROVEDに移行します。または、新しい証拠によってリスクが高まる場合はエスカレートします。変更があった場合はtransaction.status.updated webhookが発火します。

ステップアップは何ができますか？

統合された/v3/ API上のあらゆる検証ステップが可能です。再KYCライブネスチェック、書類の再検証、AMLチェック、または資金証明のアップロードなどです。

アナリストが関与する必要がありますか？

いいえ。自動修復ループはアナリストなしで実行されます。ただし、ケース管理にも同じAWAITING_USER状態が存在するため、アナリストは必要に応じてアラートをユーザーに返送することもできます。

費用はいくらですか？

トランザクションあたり0.02ドルです。修復ステップはそれぞれの料金で請求されます。再KYCはユーザー検証料金で、AMLチェックは0.20ドルです。

今すぐ始めますか？

ドキュメントのトランザクション監視概要を読み、トランザクション監視製品ページでプラットフォームの他の部分とどのように適合するかを確認し、料金ページで透明性の高い通話ごとの料金を確認してください。準備ができたら、無料で開始してください。毎月500回の無料KYCチェックと、0.02ドル/通話のトランザクション監視が利用できます。