시작하기
연동 / SDK
사용자 인증
기업 확인
거래 모니터링
변경 내역규칙은 비즈니스 콘솔, 관리 API, Didit MCP에서 관리할 수 있습니다. 컴플라이언스 팀의 담당자가 모든 변경 사항을 검토해야 하면 콘솔을 사용하십시오. 규칙을 프로그래밍 방식으로 만들고 조정할 때, 예를 들어 다른 제공업체의 규칙 세트를 마이그레이션할 때는 API 또는 MCP를 사용하십시오. API 참조와 API 및 MCP로 규칙 관리 가이드를 참고하십시오. 규칙은
POST /v3/transactions/로 제출된 모든 거래에 대해 평가되며, 결과는 거래의 rule_runs[] 배열에 나타납니다(응답 스키마 참조).기본 제공 규칙 번들
Didit은 일반적인 규제 유형을 다루는 사전 구성된 규칙 라이브러리를 제공합니다. 라이브러리에서 원하는 프리셋(또는 번들 전체)을 콘솔, 설치 API 또는 MCP 도구를 통해 설치하고, 설치한 각 프리셋의 모드를 관리하십시오. 임계값과 액션이 포함된 모든 프리셋 규칙의 전체 목록은 규칙 라이브러리를 참고하십시오.규칙 출처
모든 규칙에는 누가 관리하는지를 나타내는source가 있습니다.
규칙 구조
각 규칙은 다음으로 구성됩니다.작업
규칙이 거래와 일치하면 하나 이상의 작업이 실행됩니다. 각 규칙에는 여러 작업을 설정할 수 있으며, 이 작업들은 모두 함께 적용됩니다.
대부분의 사전 설정 규칙은 점수 추가와 상태 변경을 함께 사용합니다. 예를 들어 제재 대상 거래 상대방 규칙은 점수에 90점을 추가하며, 동시에 거래를 즉시 거부합니다.
사용자 인증 요구 (AWAITING_USER)
상태 변경 → AWAITING_USER 작업은 상태만 설정하는 것이 아닙니다. 규칙이 실행되는 즉시 Didit이 거래 주체(같은 vendor_data)를 위한 호스팅 인증 세션을 자동으로 생성합니다.
이 세션은 생성 응답과 이후의 모든 조회에서 거래의 action_required 블록(및 remediation 객체)으로 반환되며, 두 거래 webhook 모두에 포함됩니다. 따라서 사용자를 즉시 리디렉션할 수 있습니다. 필수 사용자 작업을 참조하십시오.
사용자 지정 규칙은 작업 자체에 워크플로를 지정해야 합니다(workflow_id). 콘솔 규칙 빌더와 규칙 API 모두 이를 요구합니다.
기본 제공 라이브러리 규칙에는 워크플로가 포함되지 않으며, 이 경우 세션 워크플로는 다음 순서로 결정됩니다.
- 거래 설정에서 구성한 보완 워크플로
- 해당 주체가 승인된 인증을 통해 저장된 기준 얼굴을 이미 보유한 경우 애플리케이션의 생체 인증 워크플로
- 애플리케이션의 기본 워크플로
AWAITING_USER 라이브러리 규칙은 별도 설정 없이도 항상 실행 가능한 세션을 생성합니다. 이미 인증을 마친 사용자에게는 생체 인증 단계가, 그 외의 사용자에게는 전체 인증이 적용됩니다.
Travel Rule 거래는 이 자동 대체 방식에서 제외됩니다. 이들의 AWAITING_USER 대기는 지갑 소유권 증명을 위한 것이며, 이는 별도의 흐름을 따릅니다.
고위험 거래에 가장 적합한 선택은 생체 인증 워크플로입니다. 주체가 이미 KYC를 마친 사용자이므로, Didit은 온보딩 과정에서 확보한 기준 얼굴(승인된 라이브니스 셀피, 여권 칩 사진 또는 신분증 초상)을 재사용합니다. 사용자는 실시간 셀피 한 장만 촬영하면 되며, Didit은 라이브니스 검사와 계정을 개설한 사용자의 신원에 대한 1:1 얼굴 대조를 수행합니다. 도용된 자격 증명, 탈취된 OTP, SIM 스왑 공격은 모두 이 단계에서 실패합니다.
전체 안내는 고액 출금을 위한 단계별 생체 인증을 참조하십시오.
세션에서 결정이 내려지면 거래는 그 결과를 자동으로 따르고, transaction.status.updated webhook이 발생합니다. 승인된 세션은 거래를 승인하고(decision_reason_code: user_action_approved), 거부된 세션은 거래를 거부하며(user_action_declined), 검토로 끝난 세션은 거래를 IN_REVIEW로 보냅니다(user_action_in_review).
만료되었거나 중단된 세션은 거래를 AWAITING_USER 상태로 유지합니다.
KYB를 제외한 모든 워크플로 유형을 보완 작업으로 사용할 수 있습니다.
생체 인증 워크플로(및 얼굴 대조가 신분증 인증보다 먼저 실행되는 워크플로)에는 추가로 주체의 저장된 기준 얼굴이 필요합니다. 승인된 라이브니스 셀피, 여권 칩 사진, 신분증 초상 또는 수동으로 등록된 프로필 얼굴이 이에 해당합니다.
기준 얼굴이 없으면 대신 애플리케이션의 기본 워크플로를 완료하도록 요청하며, 이 과정에서 얼굴도 등록되어 다음번에 사용됩니다. 거래의 노트에는 이러한 대체 처리가 기록됩니다.
적합한 기본 워크플로도 없을 때에만 세션이 건너뛰어지며, 그 이유를 설명하는 노트가 남습니다.
점수 산정
거래가 하나 이상의 규칙과 일치하면 점수가 합산됩니다.- 각 규칙 일치는
add_score작업을 통해 거래의 전체 위험 점수에 기여합니다 - 최종 점수는 애플리케이션의 점수 임계값에 따라 거래 상태를 결정합니다
- 규칙에
change_status작업이 있으면 해당 상태가 직접 적용되며,DECLINED가 항상 우선합니다
커스텀 규칙 생성
커스텀 규칙은 비즈니스 콘솔에서 만들거나 관리 API를 통해 만들 수 있습니다. 관리 API는 Didit MCP나 MCP에 연결된 모든 AI 어시스턴트에서도 사용할 수 있습니다.- 콘솔
- API
- 콘솔에서 거래 > 규칙으로 이동합니다
- 규칙 생성을 클릭합니다
- 규칙 제목, 설명, 카테고리를 정의합니다
- 모드를 설정합니다. 실시간으로 실행하려면
Active, 거래에 영향을 주지 않고 평가만 하려면Test를 선택합니다 - 평가 모드를 선택합니다.
All(모든 조건이 일치해야 함) 또는Any(하나 이상 일치) 중 하나입니다 - 범위를 설정합니다. 규칙이 적용될 거래 유형 또는 방향을 지정합니다
- 조건을 추가합니다. 금액 임계값, 국가 코드, 커스텀 속성 확인 같은 필드 비교가 여기에 해당합니다
- 선택 사항으로 집계를 추가합니다. 시간 윈도우에 걸친 벨로시티 검사(건수, 합계, 고유 값 개수 등)를 설정할 수 있습니다
- 하나 이상의 작업을 정의합니다. 점수 추가, 상태 변경, 태그 추가, 메모 추가, 목록에 추가, 케이스 열기 중에서 선택할 수 있습니다
- 저장한 뒤 규칙을 활성화합니다
Active 모드의 규칙은 모든 새 거래에 즉시 적용됩니다. 제목은 애플리케이션마다 고유해야 합니다.
백테스팅
규칙을 활성화하기 전에 과거 데이터를 기준으로 검증할 수 있습니다.- 규칙을 Test 모드로 설정합니다. 이 규칙은 모든 새 거래에 대해 평가되지만, 결과는 거래의 상태나 점수에 영향을 주지 않습니다. 실행 통계(일치 건수, 영향을 받은 개체)가 누적되므로 실제 적용 전에 영향을 평가할 수 있습니다.
- 백테스트 기능을 사용합니다. 콘솔에서 하거나
POST /v3/transactions/rules/backtest/를 통해 실행할 수 있습니다. 이 기능은 지정한 기간의 거래를 대상으로 규칙의 조건과 집계를 소급 평가합니다. 백테스트는 평가된 거래 수, 일치한 거래 수, 영향을 받은 개체를 반환하며, 과거 데이터는 수정하지 않습니다. 활성화할 규칙과 같은conditions,aggregation,evaluation_mode그리고scope를 보내야 합니다. 범위를 생략하면 제한이 없다는 뜻이므로, 저장된 규칙이 건너뛰는 거래까지 백테스트가 포함하게 됩니다.
벨로시티 윈도우(집계)
벨로시티 규칙은 일정 기간에 걸쳐 과거 거래 데이터를 집계해, 단일 거래 검사로는 놓칠 수 있는 패턴을 찾아냅니다.
각 집계는 다음을 지정합니다.
- 시간 윈도우:
<N>m(분),<N>h(시간),<N>d(일). 예:30m,6h,7d,30d. 주의:m은 분이며, 개월이 아닙니다. - 필터: 포함할 과거 거래를 좁힙니다. 키는 필드 카탈로그의 필드 경로입니다. 특수 값
"__current__"는 평가 중인 거래의 같은 필드 값으로 해석됩니다(예:"subject_vendor_data": "__current__"는 윈도우를 같은 대상으로 한정합니다). 리스트 값은 멤버십을 의미합니다. 필터는 동등 비교 또는 멤버십 비교만 지원합니다.lt나gte필터는 없으므로, 10,000 미만 거래와 같은 범위는 필터로 표현할 수 없습니다. 범위는 지표에 설정하세요(max가 10,000 미만,min이 1,000 초과). 또한 조건은 평가 중인 거래를 제한하며, 윈도우를 제한하지 않는다는 점을 기억하세요. - 연산자와 임계값:
value에 대해eq,ne,gt,gte,lt,lte중 하나를 사용합니다(예: 건수 >= 20).
패턴 예시
필드 카탈로그
조건과 집계 필터는 경로로 거래 필드를 참조합니다.조건 연산자
규칙 조건에서는 다음 비교 연산자를 사용할 수 있습니다.
그 밖의 모든 연산자는 비어 있지 않은
value가 필요하며, 없으면 API가 400을 응답합니다.
contains, not_contains, regex는 목록이나 객체가 아닌 단일 문자열을 받습니다. contains_any는 문자열 목록을 받습니다.
조건 값 유형
조건에 선택 사항인value_type을 지정하면 value를 해석하는 방식이 바뀝니다.
그룹 조건
그룹화되지 않은 조건 목록은 규칙의evaluation_mode(ALL/ANY)에 따라 결합됩니다. 복합 논리가 필요하면 조건에 group_index를 지정하십시오. 같은 인덱스를 가진 조건들이 하나의 그룹을 이룹니다. group_logic(AND/OR, 기본값 AND)은 그룹 내 조건을 결합하고, 첫 번째 조건의 groups_logic(AND/OR, 기본값 OR)은 그룹 결과를 결합합니다. 어떤 조건에든 group_index가 있으면 그룹 평가가 evaluation_mode를 대체합니다.
사용자 지정 속성 참조
POST /v3/transactions/의 custom_properties 객체에 제출된 모든 키는 거래에 custom_values로 저장되며, 필드 경로 custom_values.<key>로 조건에서 사용할 수 있습니다. 예를 들어 "custom_properties": {"channel": "mobile_app"}로 제출된 거래는 custom_values.channel eq "mobile_app" 조건과 일치합니다. 위의 모든 연산자는 사용자 지정 속성에도 동작하며, 다른 필드와 비교하거나 속도 필터에 사용할 수도 있습니다.
Console 규칙 빌더에서는 최근 수집된 거래에서 확인된 키가 조건 필드 선택기의 사용자 지정 속성 아래에 자동으로 나타납니다. 어떤 거래에도 해당 키가 포함되기 전에 키를 미리 참조할 수도 있습니다. 같은 그룹에서 사용자 지정 속성 입력을 선택한 후, 연동에서 보내는 키를 정확히 입력하십시오. 키는 대소문자를 구분합니다. 해당 키를 가진 거래가 도착하기 전까지 규칙은 단순히 일치하지 않는 것으로 평가됩니다.
차단 목록에 의한 자동 거부
규칙을 평가하기 전에 Didit는 거래의 항목들을 애플리케이션의 차단 목록과 대조합니다. 어느 하나라도 일치하면 거래는 즉시 거부되며, 규칙은 평가되지 않습니다. 다음 항목들이 검사됩니다.
차단 목록과 일치하는 경우:
- 거래 상태가
DECLINED로 설정됩니다. - 결정 사유가
blocklisted로 설정됩니다. - 감사 추적을 위해 활동 기록이 생성됩니다.
차단 목록 검사는 규칙 평가보다 먼저 실행됩니다. 차단 목록에 있는 항목은 규칙 구성이나 점수 임계값과 관계없이 항상 거부됩니다.
거래 스크리닝
Didit는 외부 AML 및 블록체인 분석 제공업체와 연동하여 거래에 위험 정보를 보강합니다. 거래가 제출되면 시스템은 다음을 수행할 수 있습니다.- 거래 상대방을 스크리닝하여 글로벌 제재 및 감시 목록 데이터베이스와 대조합니다.
- 지갑 주소를 평가합니다(가상자산 거래의 경우). 믹서 노출, 제재 대상 기관과의 연결, 고위험 서비스와의 상호작용을 포함한 블록체인 인텔리전스 데이터를 기준으로 평가합니다.
- 신청자의 AML 상태를 확인합니다. 거래에 연결된 사용자를 최신 AML 스크리닝 결과와 대조합니다.
다음 단계
거래 제출
규칙 평가를 위해 거래가 구조화되는 방식을 설명합니다.
암호화폐 스크리닝
암호화폐 스크리닝 결과와 사전 설정 규칙이 이를 활용하는 방식을 설명합니다.
설정
점수 임계값과 해결 워크플로를 구성합니다.
API 레퍼런스
거래 생성 API endpoint입니다.