> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# 거래 모니터링 규칙 및 점수 산정: 속도 및 조건

> 조건, 속도 윈도우, 자동 작업으로 KYT 규칙을 구성하세요. 사전 설정 번들 또는 직접 설정 가능. Didit에서 월 1,000건 포함, 이후 건당 $0.001.

Didit에 제출되는 모든 거래는 애플리케이션의 활성 규칙 전체와 대조하여 평가됩니다. 규칙은 거래의 최종 상태와 점수를 결정하는 조건, 빈도 검사, 작업을 정의합니다.

이 장은 Didit Academy 사기 방지 규칙 엔진 강의에서 규칙을 만드는 단계부터 이어집니다.

규칙 엔진 Academy 강의에서는 7:54부터 규칙을 직접 만듭니다. 트리거, 조건, 액션, 점수 산정을 설정한 뒤 배포 전에 백테스트를 진행합니다.

[규칙 만들기 — Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> 규칙은 **비즈니스 콘솔**, **관리 API**, **Didit MCP**에서 관리할 수 있습니다. 컴플라이언스 팀의 담당자가 모든 변경 사항을 검토해야 하면 콘솔을 사용하십시오. 규칙을 프로그래밍 방식으로 만들고 조정할 때, 예를 들어 다른 제공업체의 규칙 세트를 마이그레이션할 때는 API 또는 MCP를 사용하십시오. [API 참조](https://docs.didit.me/ko/management-api/transactions/rules-list.md)와 [API 및 MCP로 규칙 관리 가이드](https://docs.didit.me/ko/transaction-monitoring/rules-api.md)를 참고하십시오. 규칙은 [`POST /v3/transactions/`](https://docs.didit.me/ko/management-api/transactions/create)로 제출된 모든 거래에 대해 평가되며, 결과는 거래의 `rule_runs[]` 배열에 나타납니다([응답 스키마](https://docs.didit.me/ko/transaction-monitoring/response-schema.md) 참조).

## 기본 제공 규칙 번들

Didit은 일반적인 규제 유형을 다루는 사전 구성된 규칙 라이브러리를 제공합니다. 라이브러리에서 원하는 프리셋(또는 번들 전체)을 콘솔, [설치 API](https://docs.didit.me/ko/management-api/transactions/rules-install.md) 또는 MCP 도구를 통해 설치하고, 설치한 각 프리셋의 모드를 관리하십시오. 임계값과 액션이 포함된 모든 프리셋 규칙의 전체 목록은 [규칙 라이브러리](https://docs.didit.me/ko/transaction-monitoring/rules-library.md)를 참고하십시오.

| 번들 | 예시 |
| - | - |
| **금융** | 구조화 거래 탐지(인바운드/아웃바운드), 보고 임계값을 초과하는 대규모 단일 거래 |
| **AML/CTF** | 누적 거래량 한도, 빠른 입출금 이동, 제재 대상 거래 상대방 대조, 의심스러운 결제 참조 키워드 |
| **이상 탐지** | 높은 인바운드/아웃바운드 빈도, 12+개월 동안 비활성 상태였던 휴면 계정의 재활성화 |
| **FATF** | 거래 상대방과 주체 IP의 고위험 관할권 노출 |
| **디바이스 인텔리전스** | 동일한 디바이스 지문에서 반복된 보너스 캠페인 이용, 동일한 주체에 대한 여러 디바이스 지문 |
| **사기 예방** | 서로 다른 주체 간 공유 디바이스 지문을 통한 다중 계정 |
| **암호화폐 모니터링** | 믹서 또는 난독화 서비스 노출, 고위험 주소(다크넷, 제재 대상, 도난 자금) |
| **암호화폐 스크리닝** | 고위험 자금 출처 노출(>30%), 다수의 위험한 거래 상대방, 테러 자금 조달 및 아동 착취 자동 거부, 스크리닝 대기 보류, 중간 수준 지갑 위험 점수 표시 |
| **책임 게이밍** | 짧은 기간 내 급격한 입금 집중 |
| **전자상거래** | 전자상거래 특유의 거래 패턴 |

## 규칙 출처

모든 규칙에는 누가 관리하는지를 나타내는 `source`가 있습니다.

| 출처 | 설명 |
| - | - |
| **프리셋** | Didit의 기본 제공 라이브러리에서 설치된 규칙입니다. 설치할 프리셋(또는 번들 전체)을 직접 선택하고, 설치된 각 프리셋의 모드(`Active`, `Test`, `Disabled`)를 관리합니다. 조건과 임계값은 고정되어 있으며, 사용자 지정 규칙을 만들어 재정의할 수 있습니다. 삭제가 아니라 설치 해제로 제거됩니다. |
| **사용자 지정** | 팀이 비즈니스 콘솔에서 만든 규칙입니다. 사용자 지정 규칙은 완전히 제어할 수 있으며, 필요에 따라 만들고, 편집하고, 삭제할 수 있습니다. |

## 규칙 구조

각 규칙은 다음으로 구성됩니다.

| 구성 요소 | 설명 |
| - | - |
| **제목 및 설명** | 사람이 읽을 수 있는 이름과 규칙이 탐지하는 내용에 대한 설명 |
| **카테고리** | 논리적 그룹(예: `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) |
| **모드** | `Active`(실시간 평가), `Disabled`(건너뜀), `Test`(평가하지만 결과가 거래에 영향을 주지 않음) |
| **평가 모드** | `All`(모든 조건이 일치해야 함) 또는 `Any`(최소 하나의 조건이 일치해야 함) |
| **범위** | 규칙이 적용될 거래를 제한합니다. 키: `transaction_types`, `directions`(`INBOUND`/`OUTBOUND`), `action_types`. 비어 있거나 없으면 제한이 없습니다. |
| **조건** | 필드 단위 검사입니다. 거래 필드를 `eq`, `lt`, `gte`, `in`, `contains_any`, `exists` 같은 연산자로 값과 비교합니다. |
| **집계** | 빈도 측정 기간입니다. 일정 기간 동안의 과거 거래를 집계합니다(예: 1시간, 7일, 30일 동안의 건수, 합계 또는 고유 건수). |
| **작업** | 규칙이 일치할 때 일어나는 일입니다(아래 참조). |

## 작업

규칙이 거래와 일치하면 하나 이상의 작업이 실행됩니다. 각 규칙에는 여러 작업을 설정할 수 있으며, 이 작업들은 모두 함께 적용됩니다.

| 작업 | `type` | 키 | 설명 |
| - | - | - | - |
| **점수 추가** | `add_score` | `value` (정수, 음수 가능) | 거래의 위험 점수에 점수를 더합니다. 일치한 모든 규칙의 누적 점수에 따라 거래가 검토 임계값 또는 거부 임계값을 넘는지가 결정됩니다. |
| **상태 변경** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, 별칭 `status`), `workflow_id` (별칭 `remediation_workflow_id`) | 점수와 관계없이 거래 상태를 직접 설정합니다. `value`가 `AWAITING_USER`이면 `workflow_id`가 필수이며, 생략하면 `400`이 반환됩니다. |
| **태그 추가** | `add_tags` | `tag_uuid` 또는 `tag_name` (둘 중 하나), `tag_color` | 분류와 필터링을 위해 거래에 태그를 지정합니다. 기존 태그의 `tag_uuid`를 쓰거나, 처음 사용할 때 생성되는 `tag_name`을 지정할 수 있습니다(대문자로 저장됨). `tag_color`는 새로 생성되는 태그의 16진수 색상을 설정합니다. |
| **노트 추가** | `add_note` | `note` (별칭 `value`) | 분석가가 맥락을 파악할 수 있도록 거래에 자동 생성된 텍스트 노트를 첨부합니다. |
| **목록에 추가** | `add_to_list` | `list_id` | 거래 주체의 `vendor_data`를 차단 목록, 허용 목록 또는 사용자 지정 목록에 추가합니다. |
| **케이스 열기** | `open_case` | `blueprint` (케이스 블루프린트 UUID, 선택 사항), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (불리언) | 조사 케이스를 열거나 기존 케이스에 추가합니다. 규칙당 첫 번째 `open_case` 작업만 적용됩니다. |

대부분의 사전 설정 규칙은 **점수 추가**와 **상태 변경**을 함께 사용합니다. 예를 들어 제재 대상 거래 상대방 규칙은 점수에 90점을 추가하며, *동시에* 거래를 즉시 거부합니다.

### 사용자 인증 요구 (`AWAITING_USER`)

**상태 변경 → `AWAITING_USER`** 작업은 상태만 설정하는 것이 아닙니다. 규칙이 실행되는 즉시 Didit이 거래 주체(같은 `vendor_data`)를 위한 호스팅 인증 세션을 자동으로 생성합니다.
이 세션은 생성 응답과 이후의 모든 조회에서 거래의 `action_required` 블록(및 `remediation` 객체)으로 반환되며, 두 거래 webhook 모두에 포함됩니다. 따라서 사용자를 즉시 리디렉션할 수 있습니다. [필수 사용자 작업](https://docs.didit.me/ko/transaction-monitoring/sdk-transaction-submission.md#필수-사용자-작업)을 참조하십시오.

사용자 지정 규칙은 작업 자체에 워크플로를 지정해야 합니다(`workflow_id`). 콘솔 규칙 빌더와 규칙 API 모두 이를 요구합니다.
기본 제공 라이브러리 규칙에는 워크플로가 포함되지 않으며, 이 경우 세션 워크플로는 다음 순서로 결정됩니다.

1. [거래 설정](https://docs.didit.me/ko/transaction-monitoring/settings.md#보완-워크플로)에서 구성한 **보완 워크플로**
2. 해당 주체가 승인된 인증을 통해 저장된 기준 얼굴을 이미 보유한 경우 애플리케이션의 **생체 인증** 워크플로
3. 애플리케이션의 기본 워크플로

따라서 `AWAITING_USER` 라이브러리 규칙은 별도 설정 없이도 항상 실행 가능한 세션을 생성합니다. 이미 인증을 마친 사용자에게는 생체 인증 단계가, 그 외의 사용자에게는 전체 인증이 적용됩니다.
Travel Rule 거래는 이 자동 대체 방식에서 제외됩니다. 이들의 `AWAITING_USER` 대기는 지갑 소유권 증명을 위한 것이며, 이는 [별도의 흐름](https://docs.didit.me/ko/transaction-monitoring/wallet-ownership-widget.md)을 따릅니다.

고위험 거래에 가장 적합한 선택은 **생체 인증** 워크플로입니다. 주체가 이미 KYC를 마친 사용자이므로, Didit은 온보딩 과정에서 확보한 기준 얼굴(승인된 라이브니스 셀피, 여권 칩 사진 또는 신분증 초상)을 재사용합니다. 사용자는 실시간 셀피 한 장만 촬영하면 되며, Didit은 라이브니스 검사와 계정을 개설한 사용자의 신원에 대한 1:1 얼굴 대조를 수행합니다. 도용된 자격 증명, 탈취된 OTP, SIM 스왑 공격은 모두 이 단계에서 실패합니다.
전체 안내는 [고액 출금을 위한 단계별 생체 인증](https://docs.didit.me/ko/transaction-monitoring/sdk-transaction-submission.md#예시-고액-출금-시-추가-생체-인증)을 참조하십시오.

세션에서 결정이 내려지면 거래는 그 결과를 자동으로 따르고, `transaction.status.updated` webhook이 발생합니다. 승인된 세션은 거래를 승인하고(`decision_reason_code: user_action_approved`), 거부된 세션은 거래를 거부하며(`user_action_declined`), 검토로 끝난 세션은 거래를 `IN_REVIEW`로 보냅니다(`user_action_in_review`).
만료되었거나 중단된 세션은 거래를 `AWAITING_USER` 상태로 유지합니다.

> [!NOTE]
>
> KYB를 제외한 모든 워크플로 유형을 보완 작업으로 사용할 수 있습니다.
> 생체 인증 워크플로(및 얼굴 대조가 신분증 인증보다 먼저 실행되는 워크플로)에는 추가로 주체의 저장된 기준 얼굴이 필요합니다. 승인된 라이브니스 셀피, 여권 칩 사진, 신분증 초상 또는 수동으로 등록된 프로필 얼굴이 이에 해당합니다.
> 기준 얼굴이 없으면 대신 애플리케이션의 기본 워크플로를 완료하도록 요청하며, 이 과정에서 얼굴도 등록되어 다음번에 사용됩니다. 거래의 노트에는 이러한 대체 처리가 기록됩니다.
> 적합한 기본 워크플로도 없을 때에만 세션이 건너뛰어지며, 그 이유를 설명하는 노트가 남습니다.

## 점수 산정

거래가 하나 이상의 규칙과 일치하면 점수가 합산됩니다.

1. 각 규칙 일치는 `add_score` 작업을 통해 거래의 전체 **위험 점수**에 기여합니다
2. 최종 점수는 애플리케이션의 **점수 임계값**에 따라 거래 상태를 결정합니다
3. 규칙에 `change_status` 작업이 있으면 해당 상태가 직접 적용되며, `DECLINED`가 항상 우선합니다

기본 점수 임계값(콘솔에서 구성 가능):

| 설정 | 기본값 | 설명 |
| - | - | - |
| **검토 임계값** | 75 | 이 값 이상의 점수는 `IN_REVIEW`를 발생시킵니다 |
| **거부 임계값** | 500 | 이 값 이상의 점수는 `DECLINED`를 발생시킵니다. 기본값(`500`)은 점수로 거래를 거부하지 않습니다 |

## 커스텀 규칙 생성

커스텀 규칙은 **비즈니스 콘솔**에서 만들거나 **관리 API**를 통해 만들 수 있습니다. 관리 API는 [Didit MCP](https://docs.didit.me/ko/integration/mcp/tools.md)나 MCP에 연결된 모든 AI 어시스턴트에서도 사용할 수 있습니다.

> [tab] 콘솔
>
> 1. 콘솔에서 **거래** > **규칙**으로 이동합니다
> 2. **규칙 생성**을 클릭합니다
> 3. 규칙 제목, 설명, 카테고리를 정의합니다
> 4. **모드**를 설정합니다. 실시간으로 실행하려면 `Active`, 거래에 영향을 주지 않고 평가만 하려면 `Test`를 선택합니다
> 5. **평가 모드**를 선택합니다. `All`(모든 조건이 일치해야 함) 또는 `Any`(하나 이상 일치) 중 하나입니다
> 6. **범위**를 설정합니다. 규칙이 적용될 거래 유형 또는 방향을 지정합니다
> 7. **조건**을 추가합니다. 금액 임계값, 국가 코드, 커스텀 속성 확인 같은 필드 비교가 여기에 해당합니다
> 8. 선택 사항으로 **집계**를 추가합니다. 시간 윈도우에 걸친 벨로시티 검사(건수, 합계, 고유 값 개수 등)를 설정할 수 있습니다
> 9. 하나 이상의 **작업**을 정의합니다. 점수 추가, 상태 변경, 태그 추가, 메모 추가, 목록에 추가, 케이스 열기 중에서 선택할 수 있습니다
> 10. 저장한 뒤 규칙을 활성화합니다

> [tab] API
>
> 같은 필드(`title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`)를 사용해 [`POST /v3/transactions/rules/`](https://docs.didit.me/ko/management-api/transactions/rules-create)를 호출합니다. 필드, 연산자, 작업에 대한 전체 참조는 이 페이지에 있습니다. [API와 MCP로 규칙 관리하기](https://docs.didit.me/ko/transaction-monitoring/rules-api.md)에서는 권장 워크플로인 생성, 백테스트, 활성화 순서를 설명하며, 다른 제공업체의 CSV 내보내기에서 규칙 세트를 마이그레이션하는 방법도 다룹니다.

`Active` 모드의 규칙은 모든 새 거래에 즉시 적용됩니다. 제목은 애플리케이션마다 고유해야 합니다.

## 백테스팅

규칙을 활성화하기 전에 과거 데이터를 기준으로 검증할 수 있습니다.

* 규칙을 **Test** 모드로 설정합니다. 이 규칙은 모든 새 거래에 대해 평가되지만, 결과는 거래의 상태나 점수에 영향을 주지 않습니다. 실행 통계(일치 건수, 영향을 받은 개체)가 누적되므로 실제 적용 전에 영향을 평가할 수 있습니다.
* **백테스트** 기능을 사용합니다. 콘솔에서 하거나 [`POST /v3/transactions/rules/backtest/`](https://docs.didit.me/ko/management-api/transactions/rules-backtest)를 통해 실행할 수 있습니다. 이 기능은 지정한 기간의 거래를 대상으로 규칙의 조건과 집계를 소급 평가합니다. 백테스트는 평가된 거래 수, 일치한 거래 수, 영향을 받은 개체를 반환하며, 과거 데이터는 수정하지 않습니다. 활성화할 규칙과 같은 `conditions`, `aggregation`, `evaluation_mode`**그리고** `scope`를 보내야 합니다. 범위를 생략하면 제한이 없다는 뜻이므로, 저장된 규칙이 건너뛰는 거래까지 백테스트가 포함하게 됩니다.

## 벨로시티 윈도우(집계)

벨로시티 규칙은 일정 기간에 걸쳐 과거 거래 데이터를 집계해, 단일 거래 검사로는 놓칠 수 있는 패턴을 찾아냅니다.

| 지표 | 설명 |
| - | - |
| `count` | 윈도우 내에서 필터와 일치하는 거래 수 |
| `sum` | 윈도우 내 숫자형 `field`(예: `preferred_currency_amount`)의 합계 |
| `max` / `min` / `avg` | 윈도우 내 숫자형 `field`의 최댓값, 최솟값 또는 평균값 |
| `distinct_count` | 윈도우 내 `field`의 고유 값 개수(예: 고유 기기 지문). `unique_count`도 허용되는 별칭입니다 |

각 집계는 다음을 지정합니다.

* **시간 윈도우**: `<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).

### 패턴 예시

| 패턴 | 작동 방식 |
| - | - |
| **구조화 거래(스트럭처링)** | 같은 대상의 30일 거래 건수가 >= 20이고, 같은 윈도우에서 `max` 금액이 \$10,000 미만 |
| **높은 빈도** | 같은 대상의 7일 내 수신 거래 건수가 >= 20 |
| **빠른 입출금** | 현재 거래가 발신 거래이고, 같은 대상의 6시간 내 수신 거래 건수가 >= 1 |
| **다중 계정** | 7일 내에 같은 기기 지문을 공유하는 고유한 대상의 수가 >= 3 |
| **휴면 상태 재활성화** | 대상의 이전 거래 이후 경과 일수가 >= 365이고, 금액이 >= \$1,000 |

## 필드 카탈로그

조건과 집계 필터는 경로로 거래 필드를 참조합니다.

| 필드 | 설명 |
| - | - |
| `amount`, `currency` | 거래 금액과 통화 코드입니다 |
| `preferred_currency_amount`, `default_currency_code` | 애플리케이션의 선호 통화로 환산한 금액입니다(`amount_in_default_currency`로 대체됩니다) |
| `direction` | `INBOUND` 또는 `OUTBOUND`입니다 |
| `action_type` | 귀사의 작업 유형입니다. 예: `withdrawal`, `deposit`, `bet` |
| `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` 중 하나입니다 |
| `payment_details` | 자유 형식의 결제 참조 정보입니다(키워드 규칙에서 `contains_any`의 대상입니다) |
| `score`, `severity` | 거래의 현재 위험 점수와 심각도입니다 |
| `subject_vendor_data`, `counterparty_vendor_data` | 두 당사자에 대해 귀사가 사용하는 식별자입니다 |
| `subject_country`, `counterparty_country` | 당사자의 국가 코드입니다(ISO-2와 ISO-3 모두 허용되며, 비교 전에 정규화됩니다) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | 기기 핑거프린트 또는 영구 기기 ID입니다 |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | 기기 컨텍스트 세부 정보입니다(`counterparty_browser_family`도 사용할 수 있습니다) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | 네트워크 컨텍스트입니다 |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | 주체 측 결제 수단입니다(`counterparty_payment_method_*`에도 같은 네 필드가 있습니다) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | Travel Rule 확인 상태입니다 |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | Travel Rule 교환이 연결된 상대방 VASP에 대해 귀사가 알고 있는 정보입니다. 해당 VASP에 대한 귀사의 결정(`APPROVED`, `RESTRICTED`, `BLOCKED`), 위험 수준(`LOW`, `MEDIUM`, `HIGH`이며, 귀사의 상대방 스크리닝에 플래그가 지정된 동안에는 `HIGH`입니다), 국가, 응답성(`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`)입니다. [Travel Rule 상대방 실사](https://docs.didit.me/ko/transaction-monitoring/travel-rule.md#규칙-필드와-프리셋)를 참조하십시오 |
| `subject_days_since_previous_transaction` | 이 주체가 같은 유형의 거래를 이전에 수행한 후 경과한 일수입니다(휴면 규칙용) |
| `tags` | 거래의 태그 이름입니다 |
| `custom_values.<key>` | 거래 생성 시 `custom_properties`에 제출한 모든 키입니다 |

## 조건 연산자

규칙 조건에서는 다음 비교 연산자를 사용할 수 있습니다.

| 연산자 | 설명 | 예시 |
| - | - | - |
| `eq` / `ne` | 같음 / 같지 않음 | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | 숫자 및 날짜 비교입니다. 어느 한쪽 값이 없으면 절대 일치하지 않습니다. | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | 목록에 포함되는지 여부입니다(단일 스칼라 값도 허용됩니다). | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | 문자열 값에 대해 대소문자를 구분하지 않고 부분 문자열을 검사합니다. | `payment_details contains "refund"` |
| `contains_any` | 문자열 목록 중 하나라도 필드에 대소문자를 구분하지 않고 부분 문자열로 포함되면 일치합니다. | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | 값 패턴이 필드와 일치합니다. | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | 퍼지 문자열 유사도를 비교합니다. 조건에 `score` 임계값(0-100)이 필요합니다. | `counterparty_name fuzzy_match "Acme Corp"`이며 `score: 85`로 설정합니다 |
| `exists` / `is_not_empty` / `is_not_null` | 필드가 존재합니다(별칭이며 `value`는 무시됩니다). | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | 필드가 없거나 비어 있습니다(별칭이며 `value`는 무시됩니다). | `subject_ip_address is_empty` |

그 밖의 모든 연산자는 비어 있지 않은 `value`가 필요하며, 없으면 API가 `400`을 응답합니다.
`contains`, `not_contains`, `regex`는 목록이나 객체가 아닌 단일 문자열을 받습니다. `contains_any`는 문자열 목록을 받습니다.

### 조건 값 유형

조건에 선택 사항인 `value_type`을 지정하면 `value`를 해석하는 방식이 바뀝니다.

| `value_type` | 의미 |
| - | - |
| `list` | `value`는 목록 UUID입니다. 차단 목록/허용 목록/사용자 지정 목록의 항목이 비교 값이 되므로, 규칙이 "내 사용자 지정 감시 목록에 있는 거래 상대방"과 일치하도록 설정할 수 있습니다. |
| `field` | `value`는 다른 필드 경로입니다. 조건이 두 거래 필드를 비교합니다(예: `subject_payment_method_account_id ne counterparty_payment_method_account_id`). |
| `relative_date` | `value`는 상대 날짜입니다(예: `{"direction": "past", "unit": "days", "amount": 30}`). `txn_date`와 같은 날짜 필드에 사용합니다. |

### 그룹 조건

그룹화되지 않은 조건 목록은 규칙의 `evaluation_mode`(`ALL`/`ANY`)에 따라 결합됩니다. 복합 논리가 필요하면 조건에 `group_index`를 지정하십시오. 같은 인덱스를 가진 조건들이 하나의 그룹을 이룹니다. `group_logic`(`AND`/`OR`, 기본값 `AND`)은 그룹 내 조건을 결합하고, 첫 번째 조건의 `groups_logic`(`AND`/`OR`, 기본값 `OR`)은 그룹 결과를 결합합니다. 어떤 조건에든 `group_index`가 있으면 그룹 평가가 `evaluation_mode`를 대체합니다.

### 사용자 지정 속성 참조

[`POST /v3/transactions/`](https://docs.didit.me/ko/transaction-monitoring/transactions)의 `custom_properties` 객체에 제출된 모든 키는 거래에 `custom_values`로 저장되며, 필드 경로 `custom_values.<key>`로 조건에서 사용할 수 있습니다. 예를 들어 `"custom_properties": {"channel": "mobile_app"}`로 제출된 거래는 `custom_values.channel eq "mobile_app"` 조건과 일치합니다. 위의 모든 연산자는 사용자 지정 속성에도 동작하며, 다른 필드와 비교하거나 속도 필터에 사용할 수도 있습니다.

Console 규칙 빌더에서는 최근 수집된 거래에서 확인된 키가 조건 필드 선택기의 **사용자 지정 속성** 아래에 자동으로 나타납니다. 어떤 거래에도 해당 키가 포함되기 전에 키를 미리 참조할 수도 있습니다. 같은 그룹에서 **사용자 지정 속성 입력**을 선택한 후, 연동에서 보내는 키를 정확히 입력하십시오. 키는 대소문자를 구분합니다. 해당 키를 가진 거래가 도착하기 전까지 규칙은 단순히 일치하지 않는 것으로 평가됩니다.

## 차단 목록에 의한 자동 거부

규칙을 평가하기 전에 Didit는 거래의 항목들을 애플리케이션의 차단 목록과 대조합니다. **어느 하나라도** 일치하면 거래는 **즉시 거부**되며, 규칙은 평가되지 않습니다.

다음 항목들이 검사됩니다.

| 항목 | 차단 목록 유형 | 검사 대상 |
| - | - | - |
| **사용자(신청자)** | 사용자 차단 목록 | 신청자의 `vendor_data` 식별자 |
| **기업** | 기업 차단 목록 | 기업의 `vendor_data` 식별자 |
| **지갑 주소** | 지갑 주소 차단 목록 | 가상자산 지갑 결제 수단의 `account_id` |
| **은행 계좌** | 은행 계좌 차단 목록 | 은행 송금 결제 수단의 `account_id` |
| **IP 주소** | IP 주소 차단 목록 | 당사자 기기 컨텍스트의 IP 주소(CIDR 범위 지원) |
| **기기 지문** | 기기 지문 차단 목록 | 기기 지문 또는 영구 기기 ID |

차단 목록과 일치하는 경우:

* 거래 상태가 `DECLINED`로 설정됩니다.
* 결정 사유가 `blocklisted`로 설정됩니다.
* 감사 추적을 위해 활동 기록이 생성됩니다.

> [!NOTE]
>
> 차단 목록 검사는 규칙 평가보다 먼저 실행됩니다. 차단 목록에 있는 항목은 규칙 구성이나 점수 임계값과 관계없이 항상 거부됩니다.

## 거래 스크리닝

Didit는 외부 AML 및 블록체인 분석 제공업체와 연동하여 거래에 위험 정보를 보강합니다. 거래가 제출되면 시스템은 다음을 수행할 수 있습니다.

* **거래 상대방을 스크리닝**하여 글로벌 제재 및 감시 목록 데이터베이스와 대조합니다.
* **지갑 주소를 평가**합니다(가상자산 거래의 경우). 믹서 노출, 제재 대상 기관과의 연결, 고위험 서비스와의 상호작용을 포함한 블록체인 인텔리전스 데이터를 기준으로 평가합니다.
* **신청자의 AML 상태를 확인**합니다. 거래에 연결된 사용자를 최신 AML 스크리닝 결과와 대조합니다.

스크리닝 결과는 거래에 첨부되며 규칙 엔진의 점수 산정에 반영됩니다. 거래 상대방이나 지갑이 제재 목록과 일치하면 해당 규칙이 거래를 자동으로 플래그 지정하거나 거부합니다.

## 다음 단계

> [card] [거래 제출](https://docs.didit.me/ko/transaction-monitoring/transactions.md)
>
> 규칙 평가를 위해 거래가 구조화되는 방식을 설명합니다.

> [card] [암호화폐 스크리닝](https://docs.didit.me/ko/transaction-monitoring/aml-screening.md)
>
> 암호화폐 스크리닝 결과와 사전 설정 규칙이 이를 활용하는 방식을 설명합니다.

> [card] [설정](https://docs.didit.me/ko/transaction-monitoring/settings.md)
>
> 점수 임계값과 해결 워크플로를 구성합니다.

> [card] [API 레퍼런스](https://docs.didit.me/ko/management-api/transactions/create.md)
>
> 거래 생성 API endpoint입니다.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.