ケース管理 - ケースとライフサイクル

Case Managementは、Didit Consoleにおける調査の中核です。AMLのヒット、フラグが付いた認証、不審な取引はいずれもケースにでき、コンプライアンスチームは開始から解決まで、完全な監査ログを記録しながら対応できます。

---

​

ライフサイクル

ケースのステータスは、次の3つだけです。 ケースを解決するには、解決内容の指定が必要です。 すべてのケースには優先度(Low、Medium、High、デフォルトはMedium)と、任意の期日も設定されます。期日はSLAに基づく並べ替えと期限超過フラグに使われます。

​

ケースごとに対象は1つ

すべてのケースは、ちょうど1人のユーザーまたは1つの企業に紐付けられます。1つのケースで複数の対象者を混在させることはできません。また、ケースとは異なる対象者に属するセッション、企業セッション、取引を紐付けることもできず、紐付けようとすると明確なエラーが返されます。 これにより、各ケースページでは1つの対象に焦点を絞ることができます。対象者カード、リスク概要、書類、財務データはすべて、そのケースで調査している同じ人物または企業に関するものです。別のエンティティをレビューするには、別のケースを開いて(または作成して)ください。

​

Fraud Checkのソースコンテキスト

Fraud Checkセッションからケースを作成すると、そのチェックID、リクエストID、レビュアーが開いていたセクションが保持されます。 ソースカードには、ケース作成時点のセッションのアナリストステータスも記録されます。 ケースの判定とソースの判定は別々に管理されます。 APIクライアントは、ケース作成時にcheck_id、request_id、source_sectionを含むsource_contextを指定できます。 そのリクエストをlinksにsessionエントリとして含めてください。 チェックと紐付けるセッションは、選択したアプリケーションに属し、かつ互いに紐付いている必要があります。 APIはアナリストステータスを自ら読み取り、このコンテキストで呼び出し元が指定したステータス、推奨、ソース種別のフィールドは拒否します。

​

一覧

Case Managementの上部ナビゲーションでは、ケース、概要、割り当てを常に利用できます。 ケースのワークスペースには、オープン、ユーザー待ち、解決済み、すべてのステータスビューがあります。 デスクトップでケースを開くと、ケースのキューが詳細の横に表示されたままになります。 モバイルでは、パンくずリストを使ってキューに戻ります。 検索は、対象者の名前またはID、タグ、ケース番号、ケースタイトル、紐付けられたセッションID、紐付けられた取引IDに一致します。そのため、セッションまたは取引のUUIDを貼り付けると、該当するケースに直接移動できます。 フィルターチップ:ブループリント、作成日、ソース、担当者、タグに加え、フィルターを追加から優先度と期限を追加できます。 列:作成日(日付と作成者)、ケース詳細(タイトル)、ステータス、ブループリント、対象者(名前とID)、対象者タグ、担当者、優先度、期日。横スクロールと列の設定から、さらに多くの列を利用できます。

​

並べ替えとSLA

作成日(デフォルト)または期日で並べ替えます。期日で並べ替えると、期限超過のケースが先頭に表示されます。ケースがオープンまたはユーザー待ちのまま期日を過ぎると期限超過となり、赤い期限チップで表示されます。

​

保存済みビュー

ビューを保存で現在のフィルターと列の組み合わせを名前付きビューとして保存し、ビューを選択でビューを切り替え、フィルターをクリアでリセットします。ビューは個人ごとのもので、他のコンソールのテーブル設定と同じ方法で保持されます。

​

一括アクション

複数のケースを選択して、次の操作ができます。

• 割り当て先で担当者を指定する。選択したすべてのケースは同じブループリントである必要があり、そうでない場合は送信前にコンソールが警告します。
• ステータスを設定で、ユーザー待ち、再オープン、解決(解決内容と任意のメモを指定)に変更する。各ケースは個別に評価されるため、未完了のチェックリストや必須メモの欠落によってブロックされたケースは個別に報告され、バッチの残りが失敗することはありません。

​

エクスポート

一覧のメニューには2種類のCSVエクスポートがあり、レポートページから配信されます。

• 全ケースレポート:ケースごとに1行で、ステータス、解決内容、優先度、タグ、紐付けられた取引、最後に提出したFIU報告を含みます。
• SLAレポート:ケースごとの時間指標で、割り当てまでの時間、解決までの時間、期限超過、SLA達成のフラグを含みます。

​

対象者へのアクションと再試行

対象者カードでは、権限のあるレビュアーが対象者のステータス変更、タグの追加、内部メモの追加、対象者のブロックリストへの追加を行えます。 これらのアクションは、ケースの解決とは別のものです。 対象者へのアクションセクションには、リクエストされた各アクションが適用済みまたは失敗として記録され、そのレビュアーと時刻が示されます。 現在の対象者を確認したうえで、アクションを再試行を使用して失敗したアクションを再試行します。 適用済みのアクションは、そのリクエストを再試行しても再度実行されません。 APIクライアントは、ケースのentity-actions/エンドポイントへの各リクエストに一意のclient_referenceを送信してください。 接続エラー後にリクエストを再試行する場合は、同じリファレンスと入力を使用してください。 同じリファレンスで入力を変更すると409が返されます。 リファレンスを指定した場合はreceipt.statusを確認してください。200レスポンスに失敗したレシートが含まれることがあり、その場合はアクションが適用されていません。 失敗したリクエストを再試行するには、retry: trueを指定するか、そのaction-receipts/{receipt_uuid}/retry/エンドポイントを呼び出す必要があります。 履歴エンドポイントは1ページあたり最大20件のレシートを返し、追加の結果用にnext_offsetを返します。 client_referenceを省略している既存のAPIクライアントは、従来のレスポンス動作のまま変わりません。

​

タグ

関連する調査をまとめるには、ケースのヘッダーにある タグを追加 からケースにタグを追加します。一覧からタグでフィルターや検索を行うこともできます。タグの変更はケースのタイムラインに記録されます。

​

関連ページ

​

顧客へのメッセージ

Message customerを使うと、確認済みの連絡先に送る定型の依頼やレビュー状況の更新をプレビューできます。 配信状態、セキュアな返信、APIのワークフローについては、顧客へのメッセージを参照してください。

​

ディスカッションとピン留めメモ

ケースのステータスの横にあるディスカッションボタンをクリックすると、調査画面を離れずにメモを確認できます。 メモのメニューから、返信やピン留めができます。 ピン留めしたメモは先頭に表示され、返信には親メモの短い抜粋が表示されます。 ピン留めの変更はケースのアクティビティに記録され、ソース側の判定は変更されません。 削除を確定すると、メモと、返信に引用されたその抜粋が完全に削除されます。 返信自体は引き続き閲覧できます。 添付ファイルは、他のメモでまだ使用されていない限り削除されます。 APIクライアントは、メモを追加する際にclient_referenceとしてUUIDを指定できます。 内容を変更せずに再試行すると、通知を重複させることなく既存のメモが返されます。 同じ参照を異なる内容で再利用した場合や、削除済みのメモに対して再利用した場合は409が返されます。 同じケース内の削除されていないメモを参照するにはreply_toを指定し、is_pinnedはメモのPATCHエンドポイントで更新します。

​

既存の調査の確認

共通のケース作成ダイアログでは、選択したユーザー、企業、または紐付けられたソースについて既存の調査があるかを確認します。 既存のケースを開くと、そのレビューを続けられます。 クローズ済みのケースも表示されるため、開いて再オープンするかどうかを判断できます。 別の調査として作成するには、異なるインシデントとして扱う理由を入力してください。 入力した理由は新しいケースとともに保存され、その概要に表示されます。 送信時にコンソールは重複を再確認し、ダイアログを開いている間に他のレビュアーが作成したケースも対象に含めます。 API連携では、POST .../cases/duplicates/で重複を確認し、ケース作成時にreview_duplicates=trueを設定できます。 既存の調査が見つかった場合、separate_incident_reasonを指定しない限り、作成リクエストは409を返します。 重複確認エンドポイントは1ページあたり最大20件のケースを返し、続きの結果にはnext_offsetを使用します。 このオプションを指定しない既存のAPI連携では、現在の作成時の動作がそのまま維持されます。