메인 콘텐츠로 건너뛰기
Case Management는 Didit Console의 조사 허브입니다. AML 히트, 플래그가 지정된 인증, 의심 거래는 모두 케이스가 될 수 있으며, 컴플라이언스 팀은 이를 열기부터 해결까지 전체 감사 로그와 함께 처리합니다.

수명 주기

케이스는 정확히 세 가지 상태를 거칩니다: 케이스를 해결하려면 해결 유형이 필요합니다: 모든 케이스에는 우선순위(Low, Medium, High, 기본값 Medium)가 있으며, 선택 사항인 마감일은 SLA 정렬과 기한 초과 표시를 결정합니다.
Under review, On hold, Pending approval, Critical 심각도, 케이스 유형 축은 없습니다. 수명 주기는 케이스가 어떻게 생성되었는지와 관계없이 모든 케이스에서 분석, SLA, 권한이 모호하지 않도록 의도적으로 고정되어 있습니다.

케이스당 대상 하나

모든 케이스는 정확히 한 명의 사용자 또는 한 개의 기업에 연결됩니다. 한 케이스에서 대상을 섞을 수 없으며, 케이스의 대상과 다른 대상에 속한 세션, 기업 세션 또는 거래를 연결하려고 하면 명확한 오류가 반환됩니다. 이렇게 하면 모든 케이스 페이지가 집중된 상태를 유지합니다. 대상 카드, 위험 개요, 문서, 금융 데이터가 모두 조사 대상인 동일한 사람 또는 기업을 가리킵니다. 두 번째 대상을 검토하려면 별도의 케이스를 열거나 생성하십시오.

Fraud Check 출처 컨텍스트

Fraud Check 세션에서 케이스를 생성하면 해당 세션의 check ID, request ID, 검토자가 연 섹션이 보존됩니다. 출처 카드에는 케이스 생성 시점의 세션 분석가 상태도 기록됩니다. 케이스 결정과 출처 결정은 별도로 유지됩니다. API 클라이언트는 케이스를 생성할 때 check_id, request_id, source_section을 포함하는 source_context를 전달할 수 있습니다. 해당 요청을 links에 session 항목으로 포함하십시오. check와 연결된 세션은 선택한 애플리케이션에 속하며, 서로 일치해야 합니다. API는 분석가 상태를 직접 읽으며, 이 컨텍스트에서 호출자가 제공한 상태, 권장 사항, 출처 유형 필드는 거부합니다.

목록

케이스 관리의 상단 내비게이션에서는 케이스, 개요, 배정을 이용할 수 있습니다. 케이스 작업 공간은 열림, 사용자 대기, 해결됨, 전체 상태 보기를 제공합니다. 케이스를 열면 데스크톱에서 케이스 대기열이 상세 정보와 나란히 표시됩니다. 모바일에서는 이동 경로를 사용하여 대기열로 돌아가십시오. 검색은 대상 이름 또는 ID, 태그, 케이스 번호, 케이스 제목, 연결된 세션 ID, 연결된 거래 ID와 일치합니다. 따라서 세션 또는 거래 UUID를 붙여 넣으면 해당 케이스로 바로 이동할 수 있습니다. 필터 칩: 블루프린트, 생성일, 출처, 담당자, 태그, 그리고 우선순위와 마감을 위한 필터 추가. 열: 생성일(날짜 및 생성자), 케이스 세부 정보(제목), 상태, 블루프린트, 대상(이름 및 ID), 대상 태그, 담당자, 우선순위, 마감일이며, 가로 스크롤과 열 구성을 통해 더 많은 열을 볼 수 있습니다.

정렬 및 SLA

생성일(기본값) 또는 마감일로 정렬합니다. 마감일로 정렬하면 기한이 지난 케이스가 먼저 표시됩니다. 케이스가 여전히 열림 또는 사용자 대기 상태이고 마감일이 지나면 기한 초과로 간주되며, 빨간색 마감 칩으로 표시됩니다.

저장된 보기

현재 필터와 열 조합을 보기 저장으로 이름이 있는 보기로 저장하고, 보기 선택으로 보기 사이를 전환하며, 필터 초기화로 재설정합니다. 보기는 개인별로 저장되며, 콘솔의 다른 테이블 환경설정과 같은 방식으로 유지됩니다.

일괄 작업

여러 케이스를 선택하여 다음을 수행합니다:
  • 담당자에게 할당합니다. 선택한 모든 케이스는 같은 블루프린트를 공유해야 하며, 그렇지 않으면 콘솔이 제출 전에 경고합니다.
  • 상태 설정으로 사용자 대기, 다시 열기, 또는 해결(해결 유형과 선택 메모 포함)로 설정합니다. 각 케이스는 독립적으로 평가되므로, 미완료 체크리스트 또는 필수 메모 누락으로 차단된 케이스는 개별적으로 보고되며 나머지 일괄 작업은 실패하지 않습니다.

내보내기

목록 메뉴에서는 리포트 페이지를 통해 제공되는 두 가지 CSV 내보내기를 사용할 수 있습니다:
  • 전체 케이스 보고서: 케이스당 한 행으로, 상태, 해결 유형, 우선순위, 태그, 연결된 거래, 마지막으로 제출된 FIU 보고서가 포함됩니다.
  • SLA 보고서: 케이스별 시간 지표로, 배정까지 걸린 시간, 해결까지 걸린 시간, 기한 초과 여부, SLA 충족 여부 표시가 포함됩니다.

대상에 대한 작업 및 재시도

대상 카드에서 권한이 있는 검토자는 대상 상태를 변경하거나, 태그를 추가하거나, 내부 메모를 추가하거나, 대상을 차단 목록에 추가할 수 있습니다. 이러한 작업은 케이스 해결과 별개입니다. 대상에 대한 작업 섹션은 요청된 각 작업을 적용됨 또는 실패로 기록하고, 해당 검토자와 시각을 표시합니다. 현재 대상을 검토한 후 작업 다시 시도를 사용하여 실패한 작업을 다시 시도하십시오. 적용된 작업은 해당 요청을 다시 시도하더라도 다시 실행되지 않습니다. API 클라이언트는 케이스의 entity-actions/ endpoint에 요청할 때마다 고유한 client_reference를 보내야 합니다. 연결 오류 후 요청을 다시 시도할 때는 동일한 참조와 입력을 유지하십시오. 같은 참조에 입력이 변경되면 409가 반환됩니다. 참조가 제공된 경우 receipt.status를 확인하십시오. 200 응답에도 실패한 영수증이 포함될 수 있으며, 이는 작업이 적용되지 않았음을 의미합니다. 실패한 요청을 다시 시도하려면 retry: true를 설정하거나 action-receipts/{receipt_uuid}/retry/ endpoint를 호출해야 합니다. 기록 endpoint는 페이지당 최대 20개의 영수증을 반환하며, 추가 결과를 위해 next_offset을 제공합니다. client_reference를 생략하는 기존 API 클라이언트는 이전 응답 동작을 그대로 유지합니다.

태그

케이스 헤더에서 태그 추가를 사용하여 관련 조사를 묶거나, 목록에서 태그로 필터링하고 검색할 수 있습니다. 태그 변경 사항은 케이스 타임라인에 기록됩니다.

관련 페이지

케이스 생성

사용자, 기업, 세션, 거래, 자동 커넥터 등 모든 진입점입니다.

블루프린트

담당자 지정, 에스컬레이션, 이관, 케이스 페이지 콘텐츠를 구성합니다.

체크리스트

필수 조사 단계를 완료해야 케이스를 해결할 수 있도록 제한합니다.

4인 검토

민감한 해결 건에 대한 메이커/체커 승인입니다.

고객 메시지

고객에게 메시지 보내기를 사용하면 확인된 연락처에 보낼 미리 정해진 요청이나 검토 업데이트를 미리 볼 수 있습니다. 전송 상태, 보안 응답, API 워크플로에 대해서는 고객 메시지를 참조하세요.

토론 및 고정 노트

케이스 상태 옆의 토론 버튼을 클릭하면 조사를 계속 진행하면서 노트를 검토할 수 있습니다. 노트의 메뉴를 사용하여 답글을 달거나 노트를 고정할 수 있습니다. 고정된 노트가 가장 먼저 표시되며, 답글에는 상위 노트의 짧은 발췌문이 함께 표시됩니다. 고정 상태 변경 사항은 케이스 활동에 기록되며 소스의 결정에는 영향을 주지 않습니다. 삭제를 확인하면 노트와, 답글에 인용된 해당 노트의 발췌문이 영구적으로 제거됩니다. 답글 자체는 계속 남아 있습니다. 첨부 파일은 다른 노트에서 아직 사용 중인 경우를 제외하고 삭제됩니다. API 클라이언트는 노트를 추가할 때 client_reference UUID를 제공할 수 있습니다. 내용이 변경되지 않은 재시도는 알림을 중복으로 보내지 않고 기존 노트를 반환합니다. 변경된 내용에 대해서나 삭제된 노트에 대해 이 참조를 다시 사용하면 409를 반환합니다. 같은 케이스에 있는 삭제되지 않은 노트를 참조하려면 reply_to를 제공하고, is_pinned는 노트의 PATCH 엔드포인트를 통해 업데이트하세요.

기존 조사 확인

공유 케이스 생성 대화 상자는 선택한 사용자, 기업 또는 연결된 소스에 대해 기존 조사가 있는지 확인합니다. 기존 케이스를 열어 계속 검토하세요. 종료된 케이스도 계속 표시되므로, 열어 본 뒤 다시 열지 결정할 수 있습니다. 별도의 조사를 만들려면 이를 다른 사건으로 취급하는 이유를 입력하세요. 이유는 새 케이스와 함께 저장되며 개요에 표시됩니다. 콘솔은 제출할 때 중복을 다시 확인하며, 대화 상자가 열려 있는 동안 다른 검토자가 만든 케이스도 포함됩니다. API 통합에서는 POST .../cases/duplicates/를 검토하고 케이스 생성 시 review_duplicates=true를 설정할 수 있습니다. 기존 조사가 발견되면 separate_incident_reason이 제공되지 않는 한 생성 요청은 409를 반환합니다. 중복 검토 엔드포인트는 페이지당 최대 20개의 케이스를 반환하며, 더 많은 결과는 next_offset으로 확인합니다. 이 옵션을 생략하는 기존 API 통합은 현재의 케이스 생성 동작을 그대로 유지합니다.
마지막 수정일 2026년 11월 7일