> ## 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.

# AMLR 컴플라이언스 가이드: EU 2024/1624 자금세탁방지 API

> Didit 워크플로, API endpoint, webhook을 통해 EU 자금세탁방지 규정(AMLR)의 각 규제 요건을 충족하고 구현하는 방법을 확인해 보세요.

EU 자금세탁방지규정(AMLR, Regulation (EU) 2024/1624)은 고객확인(CDD) 규정을 직접 적용 가능한 단일 법률 문서로 통합했습니다. 이는 암호화폐 서비스 제공업체(CASP)를 포함한 신용 및 금융 기관, 도박 서비스 제공업체 및 제3조에 열거된 기타 의무 대상 기관을 구속합니다. 본 규정은 2024년 7월 9일에 발효되었으며 2027년 7월 10일부터 적용됩니다. 그전까지는 현행 지침을 국내법으로 전환한 각국의 법률이 계속 적용됩니다.

이 페이지는 이를 구축해야 하는 개발자와 컴플라이언스 엔지니어를 위한 가이드입니다. 각 섹션에서는 규정이 요구하는 사항과 해당 조항을 명시하고, 각 부분에 활용할 수 있는 Didit 워크플로 단계, API endpoint 또는 webhook을 안내합니다. 비즈니스 개요는 [AMLR 솔루션 페이지](https://didit.me/solutions/amlr)를 참고하십시오.

최종 검토일: 2026년 10월 2일.

> [!WARNING]
>
> **Didit은 검증 및 증빙 자료를 제공합니다. 의무 대상 기관은 여전히 귀사입니다.** 고객의 위험 프로필을 결정하고 온보딩 여부를 판단하는 주체는 귀사이며, 외부 위탁(아웃소싱)한 모든 업무에 대한 최종 책임 또한 귀사에 있습니다(제18조). Didit을 사용한다고 해서 귀사가 AMLR을 자동으로 준수하게 되는 것은 아닙니다. 이 페이지의 내용은 법률 자문이 아니므로, 각 규정이 귀사 비즈니스에 어떻게 적용되는지는 법률 고문 및 감독 기관을 통해 확인하십시오.

## AMLR 주요 요구사항 한눈에 보기

| 의무 사항 | 조항 | Didit 내 해당 기능 |
| - | - | - |
| 고객확인 트리거 발생 시점 파악 | 제19조 | 자체 라우팅 로직 후 트리거별 세션 생성. [고객확인 적용 시점](#고객확인-적용-시점) 참고 |
| 고객 신원 파악 및 신원 검증 | 제20조 제1항 (a)호, 제22조 | 디지털 ID 지갑 또는 문서 캡처를 통한 신분증 인증. [개인 신원 파악 및 검증](#사람-식별-및-검증) 참고 |
| 실소유자 파악 및 소유 구조 이해 | 제20조 제1항 (b)호, 제51조\~제53조 | 기업 확인(KYB) 워크플로. [기업 및 실소유자 확인](#기업-및-실소유자-확인) 참고 |
| 제재 및 정치적 주요 인물(PEP) 확인 | 제20조 제1항 (d) 및 (g)호, 제42조 | AML 스크리닝. [제재 대상 및 PEP 스크리닝](#제재-및-pep-스크리닝) 참고 |
| 거래 관계 모니터링 및 고객 데이터 최신 유지 | 제26조 | 지속적인 AML 모니터링 및 문서 만료 관리. [지속적인 모니터링 및 갱신](#지속적인-모니터링-및-정보-갱신) 참고 |
| 거래 관계 목적 및 필요한 경우 자금 출처 파악 | 제25조 | 설문지. [관계 목적 및 자금 출처](#자금의-목적-및-출처) 참고 |
| 거래 모니터링 및 의심 거래 보고 | 제26조 제1항, 제69조 | 거래 모니터링 및 케이스 관리. [거래 모니터링 및 보고](#거래-모니터링-및-보고) 참고 |
| 5년간 기록 보존 후 개인정보 삭제 | 제77조 | 보존 기간 설정, 내보내기 및 요청 기반 삭제. [기록 보존 및 삭제](#기록-보관-및-삭제) 참고 |
| 자동화된 결정에 인적 개입 포함 | 제76조 제5항 | 수동 검토 및 상태 업데이트. [자동화된 결정에 대한 인적 검토](#자동화된-결정에-대한-사람의-검토) 참고 |
| 위탁 업무 관리 및 거버넌스 | 제18조 | 자체 위탁 등록부 관리. [외부 위탁(아웃소싱)](#아웃소싱) 참고 |

## 엔드투엔드 흐름

백엔드에서 세션을 생성하면 사용자가 워크플로를 완료하고, Didit이 결과를 알리면 전체 결정을 조회합니다. 온보딩 결정 권한은 귀사 팀에 있습니다. 모니터링은 온보딩 이후에도 계속됩니다.

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant User as Your customer
    participant You as Your backend
    participant Didit as Didit API
    participant Team as Your compliance team

    You->>Didit: POST /v3/session/ (workflow_id, vendor_data)
    Didit-->>You: session_id and url
    You->>User: Redirect to url
    User->>Didit: Completes the workflow
    Didit--)You: status.updated webhook
    You->>Didit: GET /v3/session/{sessionId}/decision/
    Didit-->>You: Decision with the result of every check
    You->>Team: Queue the case for a decision
    Note over You,Team: Risk profile and onboarding decision are yours (Article 18)
    Team->>Didit: PATCH /v3/session/{sessionId}/update-status/
    You->>Didit: POST /v3/users/aml-monitoring/
    Didit--)You: status.updated and data.updated on each change
```

## 고객확인 적용 시점

제19조에서는 고객확인(CDD)을 적용해야 하는 시점을 다음과 같이 규정합니다: 거래 관계를 수립할 때, 한 번의 거래 또는 연계된 거래에서 최소 EUR 10,000 이상의 일회성 거래가 발생할 때, 금액에 상관없이 자금세탁 또는 테러 자금 조달이 의심될 때, 이미 보유하고 있는 신원 확인 데이터에 의문이 있을 때입니다. 일부 부문에는 더 낮은 기준 금액이 적용됩니다: 일회성 자금 이체 및 CASP의 경우 EUR 1,000, 일회성 현금 거래(최소 신원 파악 및 검증)의 경우 EUR 3,000, 도박의 경우 EUR 2,000입니다. CASP는 EUR 1,000 미만의 일회성 거래에 대해서도 최소한 고객의 신원을 파악하고 검증해야 합니다.

Didit은 트리거 적용 여부를 자체적으로 결정하지 않습니다. 자체 코드에서 거래 유형과 금액에 따라 라우팅한 후 이에 맞는 워크플로를 시작해야 합니다.

| 요구사항 | Didit 기능 | Endpoint 또는 설정 |
| - | - | - |
| 새로운 사업 관계 수립 시 고객확인 시작(제19조 제1항 (a)호) | 온보딩 워크플로의 인증 세션 | [`POST /v3/session/`](https://docs.didit.me/ko/sessions-api/create-session) |
| 일회성 거래가 임계값에 도달하거나 초과할 때 고객확인 시작(제19조 제1항 (b)호, 제19조 제2항\~제5항) | 해당 트리거를 위해 선택한 워크플로의 인증 세션 | 일치하는 `workflow_id`를 지정한 [`POST /v3/session/`](https://docs.didit.me/ko/sessions-api/create-session) |
| 기준을 합산 초과하는 연계 거래 감지 | 거래 모니터링의 속도 규칙 | [`POST /v3/transactions/`](https://docs.didit.me/ko/transaction-monitoring/transactions), [규칙](https://docs.didit.me/ko/transaction-monitoring/rules.md) |
| 플래그가 지정된 거래가 정산되기 전에 고객에게 인증 요청 | 규칙 작업을 통해 거래를 `AWAITING_USER` 상태로 변경하고 연결된 인증 세션 생성 | [거래 상태](https://docs.didit.me/ko/transaction-monitoring/statuses.md) |

백엔드를 위한 최소한의 라우팅 구현 예시입니다. 제19조의 모든 트리거(예: 법인 설립 참여)를 다루지는 않으며, 귀사에 적용되는 부문별 규정에 따라 다를 수 있습니다.

```python theme={null}
# Illustrative only. The figures are the Article 19 thresholds in EUR.
def due_diligence_for(event) -> str:
    """Return "full_cdd", "identify_and_verify" or "none"."""
    if event.new_business_relationship or event.suspicion or event.doubts_about_identity_data:
        return "full_cdd"

    amount = event.linked_total_eur  # one operation, or linked transactions added together

    if event.sector == "casp":
        return "full_cdd" if amount >= 1_000 else "identify_and_verify"
    if event.is_transfer_of_funds and amount >= 1_000:
        return "full_cdd"
    if event.sector == "gambling" and amount >= 2_000:
        return "full_cdd"
    if amount >= 10_000:
        return "full_cdd"
    if event.is_cash and amount >= 3_000:
        return "identify_and_verify"
    return "none"


WORKFLOWS = {
    "full_cdd": "YOUR_FULL_CDD_WORKFLOW_ID",
    "identify_and_verify": "YOUR_ID_ONLY_WORKFLOW_ID",
}
```

## 사람 식별 및 검증

제22조 제1항에는 자연인에 대해 보유해야 하는 데이터가 명시되어 있습니다. 즉, 모든 이름과 성, 출생지 및 생년월일 전체, 국적, 해당되는 경우 국가 식별 번호, 통상적인 거주지, 그리고 가능한 경우 납세자 번호입니다. 그런 다음 제22조 제6항에서는 신원 확인 수단으로 두 가지를 명시합니다. 신분증, 여권 또는 이에 준하는 서류이거나, 관련 적격 신뢰 서비스와 함께 eIDAS 보증 수준 "상당함(substantial)" 또는 "높음(high)"을 충족하는 전자 신원 확인(eID)입니다.

### 결정에 대한 데이터 포인트

[`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/ko/sessions-api/retrieve-session)에서 반환되는 결정에는 `id_verifications[]`에 신원 확인 건당 하나의 항목이 포함됩니다.

| 제22조 제1항 (a)호 데이터 포인트 | `id_verifications[]`의 필드 | 참고 사항 |
| - | - | - |
| 모든 이름과 성 | `first_name`, `last_name`, `full_name` | 문서에 표시된 형태 또는 지갑에서 반환된 형태 그대로 표시됨 |
| 출생지 및 생년월일 전체 | `place_of_birth`, `date_of_birth` | 출생지는 문서에 기재되어 있는 경우에 제공됨 |
| 국적 | `nationality` | 고객이 신고한 추가 국적은 자체 시스템에 기록 |
| 국가 식별 번호(해당되는 경우) | `personal_number` | 이 필드에 들어가는 내용은 문서에 따라 다름. [신분증 인증 보고서](https://docs.didit.me/ko/core-technology/id-verification/report-id-verification.md) 참조 |
| 통상적인 거주지 | `address`, `formatted_address`, `parsed_address` | 여권에는 주소가 기재되어 있는 경우가 드뭅니다. 문서에 주소가 없는 경우 [주소 증명](https://docs.didit.me/ko/core-technology/proof-of-address/overview.md) 또는 [데이터베이스 검증](https://docs.didit.me/ko/core-technology/database-validation/overview.md)을 추가하십시오 |
| 납세자 번호(가능한 경우) | `extra_fields.tax_number` | 문서에 기재되어 있는 경우에만 해당. 그렇지 않은 경우 [설문지](https://docs.didit.me/ko/core-technology/questionnaires/overview.md)로 수집 |

### 두 가지 경로

| 요구사항 | Didit 기능 | endpoint 또는 설정 |
| - | - | - |
| 전자 신원 확인으로 검증(제22조 제6항 (b)호) | [디지털 ID 지갑](https://docs.didit.me/ko/core-technology/id-verification/digital-id-wallets.md). 프로덕션 환경에서 사용 가능: MitID(덴마크), BankID Sweden, Finnish Trust Network(핀란드), Smart-ID(에스토니아, 라트비아, 리투아니아, 벨기에) 및 Mobile-ID(에스토니아, 리투아니아). 유럽 디지털 신원(EUDI) 지갑: **출시 예정** | [신분증 인증 단계](https://docs.didit.me/ko/console/id-verification-methods.md)에서 국가별로 방법을 구성하십시오. 결과에는 `verification_method` 및 `wallet_provider`가 보고됩니다 |
| 신분증으로 검증(제22조 제6항 (a)호) | 진위 여부 확인을 포함한 [문서 촬영](https://docs.didit.me/ko/core-technology/id-verification/overview.md), 전자여권 및 전자 신분증을 위한 [NFC 칩 판독](https://docs.didit.me/ko/core-technology/nfc-verification/overview.md). 원격 사용의 경우 아래 기술 표준 초안을 확인하십시오 | 워크플로 내의 신분증 인증 및 NFC 단계 |
| 문서를 제시하는 사람이 해당 서류의 명의인인지 확인 | [라이브니스 감지](https://docs.didit.me/ko/core-technology/liveness/overview.md) 및 문서 초상과의 [얼굴 대조](https://docs.didit.me/ko/core-technology/face-match/overview.md) | 라이브니스 감지 및 얼굴 대조 단계. 결과는 `liveness_checks[]` 및 `face_matches[]`에 기록됨 |
| 추후 검토할 수 있는 증적 보관 | 이미지, 추출된 데이터 및 타임스탬프가 포함된 세션 기록 | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/ko/sessions-api/generate-pdf), [내보내기](https://docs.didit.me/ko/console/export-pdf-csv.md) |

각 지갑이 보고하는 보증 수준은 [디지털 ID 지갑](https://docs.didit.me/ko/core-technology/id-verification/digital-id-wallets.md) 페이지에 나열되어 있습니다. 특정 제도가 귀사의 사용 사례에 대해 제22조 제6항 (b)호를 충족하는지 여부는 귀사에서 직접 평가해야 합니다. Didit은 고객이 해당 지갑을 사용할 수 있도록 지원하는 연동 수단이며, Didit 자체가 적격 신뢰 서비스 제공자나 eID 제도는 아닙니다.

### 원격 검증에 관한 규정 기술 표준 초안의 내용

제28조 제1항에 따른 고객 확인(CDD)에 관한 규정 기술 표준(RTS)은 유럽 자금세탁방지청(AMLA)에서 작성합니다. AMLA의 최종 보고서는 2026년 9월 30일 자로 작성되었으며 2026년 10월 1일에 발표되었습니다. **이는 유럽 집행위원회에 제출된 최종 초안입니다. 아직 채택되지 않았으며 법률로서의 효력을 갖지 않습니다.** 집행위원회에서 이를 변경할 수 있으며, 초안에서는 발효 후 6개월 뒤부터 적용할 것을 제안하고 있습니다.

해당 초안은 제22조 제6항의 두 가지 수단을 기본 방식으로 취급합니다. 신분증을 활용한 원격 검증은 대면으로 신분증을 제시할 것으로 합리적으로 기대할 수 없고 자격을 갖춘 eID에 접근할 수 없는 경우를 위한 대체 방안입니다(초안 제7조 제1항). 대체 방안을 사용하는 경우, 초안에서는 그 이유를 정당화할 수 있어야 하며 해당 솔루션에 안전장치가 마련되어 있음을 감독 당국에 입증할 것을 요구합니다(초안 제7조 제2항 및 제3항). 초안은 기술 중립적이며 특정 기술을 명시하지 않습니다.

초안의 안전장치가 Didit 세션에 기록되는 내용과 일치하는 방식은 다음과 같습니다.

| 초안의 안전장치(제7조 제2항) | Didit에서 활용할 수 있는 기능 |
| - | - |
| 문서를 제시하는 사람이 문서 명의인인지 통제 | 세션의 라이브니스 감지 및 얼굴 대조 결과 |
| 신원을 식별하기에 충분한 품질의 이미지, 동영상 및 데이터 | 절차 진행 중 촬영 품질 확인 및 보고서 경고 표시 |
| 신원이나 절차의 무결성에 의심이 있는 경우 중단 | 경고 표시 및 세션 상태 `"Declined"` 또는 `"In Review"` 지정 |
| 사본을 보관하고 타임스탬프를 적용하여 추후 검증에 활용 가능하도록 유지 | 세션 기록, PDF 보고서 및 귀사의 [데이터 보존 설정](#기록-보관-및-삭제) |

고객이 eID 대신 신분증 방식을 거친 사유는 귀사에서 직접 기록해야 합니다. 자체 시스템에 저장하거나 세션 생성 시 `metadata`로 첨부하십시오.

## 기업 및 실소유자 확인

법인의 경우 제22조 제1항 (b)호에 따라 법적 형태 및 명칭, 등록 사무소 주소, 법정 대리인, 그리고 이용 가능한 경우 등록번호, 납세자 번호 및 법인 식별자(LEI)가 요구됩니다. 또한 소유 구조 및 지배 구조를 이해할 수 있도록 실소유자를 식별하고 이들을 확인하기 위한 합리적인 조치를 취해야 합니다(제20조 제1항 (b)호). 실소유자는 주식, 의결권 또는 기타 소유 지분의 "25% 이상"을 직접 또는 간접적으로 소유한 자연인(제52조 제1항)이거나, 소유권 또는 기타 수단을 통해 법인을 지배하는 자연인(제51조 및 제53조)을 의미합니다. 지배력은 소유권과 병행하여 평가됩니다.

| 요구사항 | Didit 기능 | endpoint 또는 설정 |
| - | - | - |
| 법인 식별 및 법인 등기부 대조 확인 | Lite, Shareholders 또는 UBOs 등급에서 법인 등기부 조회를 지원하는 [기업 확인](https://docs.didit.me/ko/business-verification/overview.md)(KYB). 등급 제공 여부는 국가별로 상이함 | KYB `workflow_id`를 사용하는 [`POST /v3/session/`](https://docs.didit.me/ko/sessions-api/create-session). [지원 국가](https://docs.didit.me/ko/business-verification/supported-countries.md) 참조 |
| 25% 이상의 실소유자(UBO) 식별 | 이용 가능한 경우 법인 등기부의 [소유 구조](https://docs.didit.me/ko/business-verification/ownership.md)를 활용하고, 회사 대리인이 이를 확인 및 보완 | KYB 워크플로의 **Workflows** 내 UBO 임계값. 결과는 `key_people_checks[]`에 반영됨 |
| 소유자, 이사 및 대리인의 신원 확인 | 연결된 신원 확인: 각 [주요 인물](https://docs.didit.me/ko/business-verification/key-people.md)은 역할별로 선택한 워크플로에서 하위 인증 세션을 진행함 | KYB 워크플로의 **Key People** 하위 역할별 설정 |
| 법인 등기부 보유 내용과 고객 신고 내용 비교(제22조 제7항, 제24조) | 법인 등기부 및 제출된 당사자 정보가 나란히 표시됨 | 결정 내 `key_people_checks[].registry` 및 `key_people_checks[].submitted` |
| 기업, 소유자 및 지배자 스크리닝 | 기업 및 개인 [AML 스크리닝](https://docs.didit.me/ko/business-verification/aml.md) | KYB 워크플로의 AML 단계 |

설계 시 고려해야 할 4가지 사항:

* **임계값은 직접 설정합니다.** AMLR 규정 수치는 "25% 초과"가 아니라 "25% 이상"입니다. 워크플로의 UBO 임계값은 설정 가능하므로, 이에 맞춰 설정하고 자체 정책이 더 엄격하다면 검토하십시오.
* **등기부 확인만으로는 충분하지 않습니다.** 제22조 제7항에 따르면 실소유자 확인 외에도 중앙 등록부를 조회해야 합니다. 등록부와의 불일치 사항을 14일 이내에(달력일 기준) 보고하는 절차(제24조)는 귀사에서 직접 수행해야 합니다.
* **등기부 조회 결과가 비어 있다고 해서 회사에 소유자가 없다는 증거는 아닙니다.** 특정 기업이나 국가의 경우 등기부에 소유권 기록이 없을 수 있습니다. 실소유자를 식별할 수 없는 경우, 제22조 제2항에 따라 해당 사실을 기록하고 대신 고위 경영진을 식별 및 확인해야 합니다.
* **등기부 모니터링은 출시 예정입니다.** 등기부 변경 사항에 대한 지속적인 모니터링은 아직 지원되지 않습니다. 해당 기능이 제공되기 전까지는 자체 갱신 주기에 맞춰 기업 확인을 재실행하십시오.

## 제재 및 PEP 스크리닝

고객 또는 실소유자가 표적 금융 제재 대상인지, 그리고 제재 대상자가 법인 고객을 지배하거나 지분을 50% 초과하여 보유하고 있는지 확인해야 합니다(제20조 제1항 (d)호). AMLR에서 표적 금융 제재는 EU 제재를 의미합니다. 또한 고객 또는 실소유자가 정치적 주요 인물(PEP), 그 가족 또는 가까운 관계자인지 여부를 확인해야 합니다(제20조 제1항 (g)호). PEP의 경우 제42조에 따라 고위 경영진 승인, 재산 출처 및 자금 출처 확인 조치, 강화된 지속적인 모니터링이 추가로 요구됩니다.

| 요구사항 | Didit 기능 | endpoint 또는 설정 |
| - | - | - |
| 온보딩 시 스크리닝 | 제재, PEP 및 감시 목록에 대조하는 워크플로 내 [AML 스크리닝](https://docs.didit.me/ko/core-technology/aml-screening/overview.md) 단계 | 워크플로 내 AML 단계 및 해당 임계값. 결과는 `aml_screenings[]`에 반영됨 |
| 호스팅 플로우 없이 스크리닝 | 개인 또는 기업에 대한 단독 스크리닝 | [`POST /v3/aml/`](https://docs.didit.me/ko/standalone-apis/aml-screening) |
| 어떤 목록이 포함되는지 확인 | EU 통합 금융 제재 목록을 포함하는 [감시 목록 데이터베이스](https://docs.didit.me/ko/core-technology/aml-screening/watchlist-database-aml-screening.md) | 레퍼런스 페이지 |
| 각 적발 건에 대한 결정 기록 | 적발 건별 `review_status`를 통한 적발 검토 | [`PATCH /v3/session/{sessionId}/update-aml-hit-status/`](https://docs.didit.me/ko/sessions-api/update-aml-hit-status) |
| PEP 및 제재 일치 건을 담당자에게 전달 | 세션을 `"In Review"` 상태로 전환하는 임계값 | 워크플로 내 AML 임계값 설정 후 [수동 검토](https://docs.didit.me/ko/console/manual-review.md) 진행 |

```bash theme={null}
curl -X POST 'https://verification.didit.me/v3/aml/' \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "full_name": "Javier Ejemplo Modelo",
    "entity_type": "person",
    "date_of_birth": "1974-01-01",
    "nationality": "ES",
    "vendor_data": "user-1234"
  }'
```

적발 건을 `Confirmed Match` 또는 `False Positive`로 기록하면 `data.updated` webhook이 발생하지만, 그 자체로 세션 결정이 변경되지는 않습니다. PEP 관계에 대한 고위 경영진 승인은 자체 프로세스에 따라 진행해야 합니다. 즉, 세션을 검토 대상으로 라우팅하고 승인한 사람을 기록하십시오.

## 지속적인 모니터링 및 정보 갱신

AMLR 제26조는 거래 관계에 대한 지속적인 모니터링과 고객 정보의 최신 상태 유지를 요구합니다. 정보 갱신 주기는 고위험 고객의 경우 1년, 그 외 모든 고객의 경우 5년을 초과할 수 없으며(제26조 제2항), 고객의 상황이 변경되거나 관련 사실을 알게 된 경우에도 정보를 갱신해야 합니다(제26조 제3항). 제재 확인은 정기적으로 반복되어야 하며, 신용기관 및 금융기관은 신규 제재 지정이 발생할 때마다 확인을 수행해야 합니다(제26조 제4항).

| 요구사항 | Didit 기능 | endpoint 또는 설정 |
| - | - | - |
| 고객 대상 제재 및 PEP 목록 재스크리닝 | 매일 재스크리닝을 수행하는 [지속적인 AML 모니터링](https://docs.didit.me/ko/core-technology/aml-screening/continuous-monitoring-aml-screening.md) | AML 단계에서 활성화하거나, [`POST /v3/users/aml-monitoring/`](https://docs.didit.me/ko/management-api/aml-monitoring/toggle-users)을 통해 프로필별로 활성화 |
| 기업 대상 재스크리닝 | 기업 프로필 대상 지속적인 AML 모니터링 | [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/ko/management-api/aml-monitoring/toggle-businesses) |
| 재스크리닝으로 결과가 변경되었을 때 알림 수신 | 세션 기반 webhook | 상태가 변경될 때(예: `"In Review"`) 전송되는 `status.updated` 및 `data.updated`. payload에는 `trigger: "ongoing_monitoring"`이 포함됨 |
| 변경 사항이 없을 때도 모니터링이 실행되었음을 증명 | 최근 스크리닝 일시 및 스크리닝 이력 | AML 보고서의 `last_ongoing_screening_at` 및 스크리닝 이력 내보내기 |
| 만료된 신분증 감지 | [문서 모니터링](https://docs.didit.me/ko/core-technology/id-verification/document-monitoring-id-verification.md) | 세션 상태가 `"Approved"`에서 `"Kyc Expired"`로 변경되고 `status.updated` webhook이 트리거됨 |

```bash theme={null}
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'
```

모니터링 활성화 여부를 전환할 때는 별도의 webhook이 발생하지 않습니다. 모니터링이 활성화되면 재스크리닝 시 일반적인 `status.updated` 및 `data.updated` 이벤트가 발생합니다.

### 자체 시스템에서 1년 및 5년 갱신 예약

정보 갱신 주기는 직접 지정한 위험 등급에 따라 결정되며, 이 결정은 외부에 위탁할 수 없습니다. Didit은 고객의 위험 등급을 보관하지 않으며, 정기적인 갱신 일정을 대신 예약하지 않습니다.

**1. 위험 등급 및 최근 갱신 일자 저장**

Didit으로 전송하는 `vendor_data`와 함께 고객 레코드에 이 정보를 보관합니다.

**2. 예약 작업 실행**

최근 갱신 일자가 설정한 주기보다 오래된 고객을 선택합니다. 고위험 고객은 최대 1년, 나머지 고객은 최대 5년입니다. 이 기간은 최대 기한이므로 더 짧은 주기를 선택할 수도 있습니다.

**3. 새 세션 생성**

동일한 `vendor_data`와 갱신 워크플로를 사용하여 [`POST /v3/session/`](https://docs.didit.me/ko/sessions-api/create-session)을 호출한 다음, 고객에게 `url`을 전송합니다.

**4. 이벤트 발생 시 대응**

`"Kyc Expired"`, 세션을 `"In Review"` 상태로 변경하는 모니터링 webhook, 고객이 직접 알린 변경 사항 등을 즉시 조기 갱신을 진행하기 위한 트리거로 처리합니다.

## 자금의 목적 및 출처

거래 관계를 맺거나 일회성 거래를 수행하기 전에, AMLR 제25조에 따라 해당 거래 또는 거래 관계의 목적과 의도된 성격을 파악해야 합니다. 필요한 경우 거래의 목적과 경제적 타당성, 예상 거래 규모, 자금 출처, 자금의 목적지, 고객의 사업 활동 또는 직업에 대한 정보를 확보해야 합니다. "필요한 경우"란 위험에 비례하여 범위를 정함을 의미합니다. 강화된 실사(EDD) 시에는 재산 출처가 추가될 수 있습니다(제34조 제4항).

| 요구사항 | Didit 기능 | endpoint 또는 설정 |
| - | - | - |
| 목적 및 예상 활동 수집 | Purpose of Account 템플릿을 활용한 [설문지](https://docs.didit.me/ko/core-technology/questionnaires/overview.md) | 워크플로의 설문지 단계 |
| 증빙 문서를 포함한 자금 출처 수집 | 파일 업로드 기능이 포함된 Source of Funds 템플릿 | 워크플로의 설문지 단계 |
| 직업 및 직장 정보 수집 | Employment Details 템플릿 | 워크플로의 설문지 단계 |
| 담당자가 모든 응답을 직접 검토하도록 설정 | 항상 `"In Review"` 결과가 나오도록 설정된 설문지 | 설문지의 수동 검토 설정 |

템플릿은 기본 시작점입니다. 자체 위험 평가에 맞게 질문을 수정하고, 응답 내용을 세션에 함께 보관하여 신분증 인증과 동일한 레코드에서 관리합니다.

## 거래 모니터링 및 보고

지속적인 모니터링은 고객에 대해 파악하고 있는 정보와 일치하는지 확인하기 위해 거래 관계 중에 수행되는 거래까지 포괄합니다(제26조 제1항). 자금이 범죄 행위의 수익이거나 테러 자금 조달과 관련되어 있음을 알게 되거나 의심되는 경우, 또는 이를 의심할 합당한 근거가 있는 경우에는 제69조에 따라 관할 금융정보분석원(FIU)에 보고해야 합니다.

| 요구사항 | Didit 기능 | endpoint 또는 설정 |
| - | - | - |
| 평가를 위한 개별 거래 제출 | 법정화폐 및 가상자산을 지원하는 [거래 모니터링](https://docs.didit.me/ko/transaction-monitoring/overview.md) | [`POST /v3/transactions/`](https://docs.didit.me/ko/transaction-monitoring/transactions) |
| 승인한 탐지 기준 적용 | 사전 설정된 규칙 번들 및 맞춤형 [규칙](https://docs.didit.me/ko/transaction-monitoring/rules.md)(각 규칙별 제어 모드 설정 가능) | 콘솔의 규칙 메뉴 또는 규칙 API |
| 판정 결과 수신 | Webhook | `transaction.created` 및 `transaction.status.updated` |
| 조사 수행 | 모든 작업의 타임라인을 제공하는 [알림](https://docs.didit.me/ko/transaction-monitoring/alerts.md) 및 [케이스](https://docs.didit.me/ko/transaction-monitoring/cases.md) | 콘솔의 케이스 관리 |
| 보고서 준비 | 케이스 데이터를 활용한 [FIU 보고서 준비](https://docs.didit.me/ko/console/case-management/fiu-reports.md) | 케이스 상세 페이지의 **FIU 보고서** 탭 |

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "finance0001",
    "transaction_category": "finance",
    "transaction_details": {
      "direction": "outbound",
      "amount": "1200.00",
      "currency": "EUR"
    },
    "subject": { "entity_type": "person", "vendor_data": "user-123", "full_name": "John Doe" },
    "counterparty": { "entity_type": "person", "full_name": "Jane Doe" }
  }'
```

유의해야 할 두 가지 제한 사항:

* **탐지 기준은 직접 승인해야 합니다.** 의심스럽거나 비정상적인 거래를 탐지하기 위한 기준의 승인은 외부에 위탁할 수 없습니다(제18조 제3항 (f)호). 적용하려는 각 규칙을 검토하고 해당 승인 사실을 자체 정책에 기록해야 합니다.
* **보고서는 직접 제출해야 합니다.** Didit은 케이스를 기반으로 보고서 파일을 생성해 주지만, FIU에 아무것도 제출하지 않습니다. 제출은 관할 FIU의 공식 접수 창구를 통해 기업의 컴플라이언스 담당자가 직접 진행해야 합니다.

## 기록 보관 및 삭제

제77조는 기록 보관 의무를 규정합니다. 고객 확인을 위해 수집한 문서와 정보, 의심 평가 기록 및 거래 기록을 5년간 보관해야 합니다. 이 기간은 비즈니스 관계가 종료된 시점, 일회성 거래가 실행된 시점 또는 관계 체결을 거절한 시점부터 시작됩니다(제77조 제3항). 다른 법률이 적용되거나 당국이 특정 기록의 장기 보관을 요청하지 않는 한, 5년이 만료되면 해당 개인정보를 삭제해야 합니다.

기간 산정의 기준은 여러분의 시스템 내 이벤트(비즈니스 관계의 종료)로부터 시작됩니다. Didit은 해당 날짜를 알 수 없으므로, 설정하는 데이터 보존 기간과 요청하는 삭제 작업은 귀사의 결정에 따릅니다.

| 요구사항 | Didit 기능 | Endpoint 또는 설정 |
| - | - | - |
| 의무 기간 동안 세션 기록 보관 | [데이터 보존 설정](https://docs.didit.me/ko/console/data-retention.md): 1개월에서 10년까지의 기간 또는 무제한 | **Business Console → App Settings → Data retention** |
| 5년 기간 만료 시 삭제 | 세션 온디맨드 삭제 | [`DELETE /v3/session/{sessionId}/delete/`](https://docs.didit.me/ko/sessions-api/delete-session) |
| 감독관 또는 감사인에게 파일 제출 | 세션 및 사용자별 PDF 보고서, 대량 CSV 내보내기 | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/ko/sessions-api/generate-pdf), [내보내기](https://docs.didit.me/ko/console/export-pdf-csv.md) |
| 스크리닝 증거 보관 | 세션별 스크리닝 이력 내보내기 | [지속적인 모니터링 증거](https://docs.didit.me/ko/core-technology/aml-screening/continuous-monitoring-aml-screening.md#모니터링-실행-입증) |

**1. 일찍 만료되지 않는 데이터 보존 기간 선택**

세션은 보존 기간이 만료되면 삭제됩니다. 고객 관계 유지 기간에 5년을 더한 기간을 포괄하는 보존 기간을 선택하거나, 무제한으로 설정한 후 필요에 따라 온디맨드로 삭제하십시오.

**2. 비즈니스 관계 종료 기록**

종료, 거래 또는 거절 날짜를 자체 시스템에 저장하십시오. 해당 날짜부터 5년 기간이 시작됩니다.

**3. 기간 만료 시 삭제**

해당 고객의 각 세션에 대해 `DELETE /v3/session/{sessionId}/delete/`를 호출하십시오. 삭제는 되돌릴 수 없으며 미디어 URL이 더 이상 작동하지 않습니다.

> [!WARNING]
>
> **감사 로그와 스크리닝 이력 자체만으로는 5년 보관 의무를 완전히 충족하지 못합니다.** 감사 로그는 [요금제](https://docs.didit.me/ko/console/audit-logs.md#데이터-보존)에 따라 30일에서 3년 동안 이용할 수 있으며, 스크리닝 이력 실행 내역은 기본적으로 2년간 이용 가능합니다. 귀사의 기록 보관 정책이 이에 의존한다면, 해당 기간이 만료되기 전에 자체 기록 보관소로 내보내십시오. 제77조에 대응하는 것은 귀사의 데이터 보존 설정에 따른 세션 기록입니다.

## 자동화된 결정에 대한 사람의 검토

제76조 제5항에 따라 프로파일링 및 AI 시스템을 포함한 자동화된 프로세스를 통해 도출된 결정을 채택할 수 있으나, 여기에는 세 가지 조건이 적용됩니다. 데이터는 고객 확인 데이터로 제한되어야 합니다. 비즈니스 관계의 체결, 거절 또는 유지, 일회성 거래의 실행 또는 거절, 고객 확인 범위 변경에 관한 모든 결정은 실질적인 사람의 개입을 거쳐야 합니다. 그리고 고객은 해당 결정에 대한 설명을 받고 이의를 제기할 수 있어야 합니다.

| 요구사항 | Didit 기능 | Endpoint 또는 설정 |
| - | - | - |
| 담당자에게 케이스 전달 | `"In Review"`로 종료되는 워크플로 임계값 및 분기 | [워크플로](https://docs.didit.me/ko/console/workflows.md) |
| 증거 검토 및 결정 | 거절 사유 및 검토 메모를 포함한 [수동 검토](https://docs.didit.me/ko/console/manual-review.md) | 콘솔 또는 [`PATCH /v3/session/{sessionId}/update-status/`](https://docs.didit.me/ko/sessions-api/update-status) |
| 2차 검토자 지정 필수화 | 케이스 블루프린트에 대한 [상호 검토(Four-eyes review)](https://docs.didit.me/ko/console/case-management/four-eyes.md): 다른 담당자가 처리 결과를 승인하거나 거부 | 콘솔의 케이스 관리 |
| 결과 설명 | 세션의 검사별 결과, 경고 및 검토자 코멘트 | [`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/ko/sessions-api/retrieve-session) |

```bash theme={null}
curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../update-status/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "new_status": "Approved",
    "comment": "Cleared after manual review by compliance team"
  }'
```

`"Approved"` 또는 `"Declined"` 세션 상태는 설정된 검사의 결과물입니다. 이는 제18조 제3항에 따라 최종적으로 귀사가 내려야 하는 온보딩 결정의 입력 자료가 됩니다. 법률 고문과 상의하여 사람의 개입이 필요한 단계를 결정한 다음, 해당 단계를 워크플로 및 자체 백오피스에 구축하십시오.

## 아웃소싱

제18조에 따라 AMLR에서 비롯된 업무를 서비스 제공업체에 아웃소싱할 수 있습니다. 단, 제공업체가 업무를 시작하기 전에 감독 당국에 통지해야 하고(제18조제1항), 아웃소싱된 업무에 대해 전적인 책임을 져야 하며(제18조제2항), 서면 계약에 조건을 명시하고 제공업체에 대해 정기적인 통제를 수행해야 합니다(제18조제4항). 또한 규정에 따르면 요구사항을 직접 이행하면서 타사 소프트웨어를 사용하거나 데이터베이스 또는 스크리닝 서비스에 접근하는 것은 아웃소싱에 해당하지 않습니다(전문 47항). Didit 이용이 어느 쪽에 해당하는지는 사용 방식에 따라 달라집니다. 아웃소싱에 관한 AMLA 가이드라인은 2027년 7월 10일까지 발표될 예정입니다.

다음 6가지 업무는 어떤 경우에도 아웃소싱할 수 없습니다(제18조제3항). 이 업무들은 조직 내에서 직접 수행해야 합니다.

1. 전사적 위험 평가의 제안 및 승인
2. 내부 정책, 절차 및 통제의 승인
3. 고객에게 부여할 위험 프로필에 대한 결정
4. 사업 관계를 맺거나 비정기적 거래를 수행하기로 하는 결정
5. 의심스러운 활동 보고 및 임계값에 따른 보고를 FIU에 제출
6. 의심스럽거나 비정상적인 거래 및 활동을 탐지하기 위한 기준의 승인

이를 제외한 관련 업무는 위탁할 수 있습니다. 신원 데이터 수집, 문서 인증 또는 eID 인증 실행, 실소유자 데이터 수집 및 등기부 조회, 제재 및 PEP 목록 스크리닝, 승인된 기준에 따른 거래 모니터링 실행, 알림 및 증빙 자료 준비 등이 여기에 포함됩니다.

Didit과 관련하여 아웃소싱 대장에 기록해야 할 항목은 다음과 같습니다.

| 항목 | 기록할 내용 | 확인 위치 |
| - | - | - |
| 서면 계약(제18조제4항) | Didit과의 계약 및 데이터 처리 계약(DPA) | DPA 및 기술적·조직적 조치는 Didit 담당자에게 문의하십시오 |
| 위탁된 업무 | 실행하는 각 워크플로의 검사 항목(워크플로 버전별) | [워크플로](https://docs.didit.me/ko/console/workflows.md). 세션과 webhook에 `workflow_id` 및 `workflow_version`이 전달됩니다 |
| 직접 수행하는 업무 | 위 6가지 업무와 조직 내 담당자 | 자체 내부 정책 |
| 제공업체 적격성(제18조제4항) | 인증 및 증명 | [인증](https://docs.didit.me/ko/getting-started/certifications.md) |
| 데이터 보관 위치 | 데이터는 기본적으로 EU 내에서 처리 및 저장됩니다. Enterprise 요금제에서는 해당 국가 내 처리를 지원합니다 | [데이터 보존](https://docs.didit.me/ko/console/data-retention.md#역할-및-처리-위치) |
| 정기적 통제(제18조제4항) | 업무의 중요도에 부합하는 주기로 실시한 세션 표본 추출, 내보내기 및 검토 추적 기록 | [내보내기](https://docs.didit.me/ko/console/export-pdf-csv.md), [감사 로그](https://docs.didit.me/ko/console/audit-logs.md) |
| 감독 당국 통지(제18조제1항) | 서비스 개시 전 감독 당국에 통지한 일자 | 자체 진행 단계. 통지가 감독 당국이 해당 약정을 수락한다는 의미는 아닙니다 |

## 참조 워크플로

자연인 온보딩 워크플로의 기준 구성입니다. 위험 평가에 맞게 조정하여 사용하십시오.

**1. 워크플로 생성**

Business Console에서 **Workflows**를 열고 고객 확인(KYC) 워크플로를 생성합니다. 국가별 또는 결과별 분기가 필요한 경우 비주얼 빌더를 사용하십시오.

**2. 국가별 신원 확인 방식 선택**

**신분증 인증** 단계에서 지원 대상 국가에 사용 가능한 디지털 ID 지갑을 활성화하고, 그 외 사용자를 위한 경로로 문서 촬영을 설정합니다. 자세한 내용은 [신분증 인증 방법](https://docs.didit.me/ko/console/id-verification-methods.md)을 참조하십시오.

**3. 문서와 사용자 매칭**

문서 경로의 경우 **라이브니스 감지** 및 **얼굴 대조**를 추가하고, 문서에 칩이 있는 경우 **NFC**를 추가합니다.

**4. 주소 확인 추가**

신분증에 주소가 기재되지 않은 고객을 위해 **주소 증명**을 추가합니다.

**5. 스크리닝 및 모니터링**

**AML 스크리닝**을 추가하고 일치 항목을 검토로 보낼 임계값을 설정한 뒤 지속적인 모니터링을 활성화합니다.

**6. 계좌 목적 및 자금 출처 질문**

계좌 목적 및 자금 출처 템플릿에서 **설문지**를 추가합니다.

**7. webhook 구독**

`status.updated` 및 `data.updated`를 구독하는 webhook 대상을 생성합니다. 자세한 내용은 [Webhooks](https://docs.didit.me/ko/integration/webhooks.md)를 참조하십시오.

**8. 워크플로 게시 및 워크플로 ID 복사**

워크플로를 게시하고 세션을 생성할 때 해당 `workflow_id`를 사용합니다.

세션을 생성합니다.

```bash theme={null}
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "YOUR_KYC_WORKFLOW_ID",
    "vendor_data": "user-42",
    "callback": "https://yourapp.com/callback"
  }'
```

응답(`201 Created`):

```json theme={null}
{
  "session_id": "4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a",
  "session_kind": "user",
  "session_number": 1024,
  "session_token": "...",
  "url": "https://verify.didit.me/session/...",
  "status": "Not Started",
  "workflow_id": "YOUR_KYC_WORKFLOW_ID",
  "vendor_data": "user-42"
}
```

고객을 `url`로 리디렉션합니다. 세션에 대한 결정이 내려지면 Didit이 `status.updated` webhook을 전송합니다. 예시 발췌본은 다음과 같습니다.

```json theme={null}
{
  "event_id": "9c0c8b8a-1111-4222-9333-444444444444",
  "webhook_type": "status.updated",
  "timestamp": 1774970000,
  "created_at": 1774969994,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "session_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "status": "In Review",
  "workflow_id": "66666666-7777-8888-9999-000000000000",
  "workflow_version": 4,
  "vendor_data": "user_42",
  "decision": { "...": "see /sessions-api/retrieve-session" }
}
```

서명을 검증하고, `event_id`를 멱등성 키로 사용하고, `status`를 대소문자를 구분하여 정확한 문자열로 비교합니다. 사용 가능한 값은 [인증 상태](https://docs.didit.me/ko/integration/verification-statuses.md)에 나와 있습니다. 그런 다음 `GET /v3/session/{sessionId}/decision/`으로 전체 결정을 조회하여 온보딩 결정을 내리는 담당자 또는 프로세스에 전달합니다.

## 일정

| 일자 | 주요 내용 |
| - | - |
| 2024년 6월 19일 | AMLR, 즉 규정 (EU) 2024/1624가 관보(Official Journal)에 게재됨 |
| 2024년 7월 9일 | AMLR 발효 |
| 2026년 9월 30일 | AMLA가 고객 확인 제도 기준 초안에 대한 최종 보고서 일정을 정함(2026년 10월 1일 발표). 집행위원회에 제출되었으며 채택되지는 않음 |
| 2027년 7월 10일 | AMLR 적용. 회원국의 제6차 자금세탁방지 지침(Directive (EU) 2024/1640) 국내법 전환 기한. 아웃소싱에 관한 AMLA 가이드라인 발표 기한 |
| 2028년 | AMLA가 선별된 금융 기관에 대한 직접 감독 시작. 1차 감독 대상은 최대 40개 기관으로 제한됨 |
| 2029년 7월 10일 | 축구 에이전트 및 프로 축구 클럽에 AMLR 적용 |

## FAQ

> [accordion] AMLR은 언제부터 적용되나요?
>
> AMLR은 2024년 7월 9일에 발효되었으며 2027년 7월 10일부터 적용됩니다. 축구 에이전트 및 프로 축구 클럽의 경우 2029년 7월 10일부터 적용됩니다. 2027년 7월 10일까지는 현행 지침을 국내법으로 전환한 각국의 국내법이 적용됩니다.

> [accordion] AMLR, AMLD6, AMLA의 차이점은 무엇인가요?
>
> AMLR은 Regulation (EU) 2024/1624입니다. 의무 대상 기관에 대한 규정을 담고 있으며 국내법 전환 절차 없이 직접 적용됩니다. AMLD6은 Directive (EU) 2024/1640입니다. 회원국을 대상으로 감독 기관, 등록부 및 처벌을 규정하며, 2027년 7월 10일까지 국내법 전환이 완료되어야 합니다. AMLA는 Regulation (EU) 2024/1620에 의해 설립되고 프랑크푸르트에 본부를 둔 자금세탁방지기구입니다. 기술 표준 및 지침의 초안을 작성하며 2028년부터 선정된 금융 기관 그룹을 직접 감독하게 됩니다.

> [accordion] 신분증을 사용한 원격 인증이 계속 허용되나요?
>
> 네, 특정 조건 하에 허용됩니다. 제22조(6)항은 신분증 또는 상당한 또는 높은 보증 수준의 eID라는 두 가지 수단을 명시합니다. 2026년 9월 30일자 AMLA 최종 기술 표준 초안에서는 대면으로 신분증을 제시하기를 합리적으로 기대할 수 없고 적격 eID에 접근할 수 없는 경우의 대안으로 신분증을 사용한 원격 인증을 유지하고 있습니다. 이를 사용하는 이유를 정당화하고 안전장치를 제시할 수 있어야 합니다. 초안에는 특정 기술이 명시되어 있지 않으며 아직 법으로 확정되지 않았습니다.

> [accordion] 기술 표준은 최종 확정되었나요?
>
> 아닙니다. AMLA는 2026년 9월 30일에 초안을 확정하여 유럽 집행위원회에 제출했습니다. 집행위원회가 이를 채택하고 관보에 게재되어야만 구속력을 가지며, 집행위원회가 이를 수정할 수 있습니다. 초안은 발효 후 6개월 뒤부터 적용되도록 제안하고 있으므로 아직 구체적인 날짜는 정해지지 않았습니다.

> [accordion] EUDI Wallet을 반드시 수용해야 하나요? 그리고 Didit은 이를 지원하나요?
>
> AMLR 자체는 eID를 두 가지 인증 수단 중 하나로 나열하고 있을 뿐입니다. 모든 의무 대상 기관에 EUDI Wallet 수용을 명령하지는 않습니다. 수용 의무는 eIDAS 규정에 명시되어 있습니다. 온라인 식별을 위해 강력한 사용자 인증을 사용해야 하는 민간 신뢰 당사자는 이행 입법 발효 후 36개월 이내에 사용자의 요청에 따라 지갑을 수용해야 하며, 마이크로 및 소기업은 면제됩니다. 이것이 귀사의 온보딩에 적용되는지 여부는 법률 자문팀에 문의해야 합니다. Didit에서 EUDI Wallet은 **출시 예정**입니다. 현재 프로덕션 환경에서 사용할 수 있는 지갑은 MitID, BankID Sweden, Finnish Trust Network, Smart-ID, Mobile-ID입니다.

> [accordion] 실소유자 기준은 25%인가요, 15%인가요?
>
> 지분, 의결권 또는 기타 소유권 지분의 "25% 이상"이며(제52조(1)항), 지배력도 함께 평가됩니다. 제52조(2)항에 따라 집행위원회는 위임 입법을 통해 고위험 범주의 기관에 대해 최대 15%까지 더 낮은 임계값을 설정할 수 있습니다. 현재 그러한 위임 입법은 존재하지 않습니다. Didit에서 UBO 임계값은 KYB 워크플로의 설정입니다.

> [accordion] 1년 및 5년 주기 갱신은 어떻게 구현하나요?
>
> 고객의 위험 등급과 최종 업데이트 날짜를 자체 시스템에 저장하고, 설정한 주기보다 오래된 고객을 선별하는 예약 작업을 실행한 후 동일한 `vendor_data`와 함께 `POST /v3/session/`으로 새 세션을 생성합니다. `"Kyc Expired"` 상태, 모니터링 webhook 또는 고객이 신고한 변경 사항 등의 이벤트 트리거를 추가합니다. 제26조(2)항의 1년 및 5년 수치는 최대 기간입니다.

> [accordion] 어떤 업무를 위탁할 수 있나요?
>
> 신원 데이터 수집, 인증 실행, 등기부 조회, 스크리닝, 승인한 기준에 따른 거래 모니터링 실행 등의 작업을 위탁할 수 있습니다. 전사적 위험 평가 승인, 내부 정책 승인, 고객 위험 프로필 결정, 온보딩 결정, 금융정보분석원(FIU) 보고, 탐지 기준 승인의 6가지 작업은 위탁할 수 없습니다. 위탁한 업무에 대해서도 전적인 책임은 귀사에 귀속됩니다(제18조(2)항).

> [accordion] 5년 보존 규정에 맞는 데이터 보존 기간은 어떻게 설정하나요?
>
> 5년의 기산점은 고객이 인증된 시점이 아니라 거래 관계가 종료된 시점입니다. **Business Console → App Settings → Data retention**에서 거래 관계 기간에 5년을 더한 기간을 포괄할 수 있을 만큼 충분히 긴 기간을 선택하거나 무제한으로 둡니다. 자체 시스템에서 종료 날짜를 추적하고 해당 기간이 만료되면 `DELETE /v3/session/{sessionId}/delete/`를 호출합니다. 기록 보존 정책이 감사 로그와 스크리닝 내역에 의존하는 경우 이를 내보내십시오.

> [accordion] Didit을 사용하면 AMLR 규정을 준수하게 되나요?
>
> 아닙니다. 컴플라이언스는 귀사의 위험 평가, 정책, 결정 및 통제 조치 등 자체 프로그램의 속성입니다. Didit은 프로그램의 이러한 부분이 작동하는 데 필요한 검사, 모니터링 및 증빙 자료를 제공합니다. 공급업체나 도구에 대한 별도의 AMLR 인증이나 승인은 존재하지 않습니다.

## 관련 리소스

> [card] [AMLR 솔루션 개요](https://didit.me/solutions/amlr)
>
> 비즈니스 관점: AMLR 적용 대상 및 Didit의 역할.

> [card] [신분증 인증 방법](https://docs.didit.me/ko/core-technology/id-verification/verification-methods.md)
>
> 문서 캡처, 비문서 조회 및 디지털 ID 지갑.

> [card] [디지털 ID 지갑](https://docs.didit.me/ko/core-technology/id-verification/digital-id-wallets.md)
>
> 지갑별 가용성 및 보증 수준.

> [card] [기업 확인(KYB)](https://docs.didit.me/ko/business-verification/overview.md)
>
> 법인 등기부 조회, 소유 구조 및 주요 인물.

> [card] [AML 스크리닝](https://docs.didit.me/ko/core-technology/aml-screening/overview.md)
>
> 제재, PEP 및 감시 목록 스크리닝과 지속적인 모니터링.

> [card] [거래 모니터링](https://docs.didit.me/ko/transaction-monitoring/overview.md)
>
> 규칙, 알림, 케이스 및 FIU 보고서 준비.

> [card] [설문지](https://docs.didit.me/ko/core-technology/questionnaires/overview.md)
>
> 거래 관계 목적 및 자금 출처 템플릿.

> [card] [데이터 보존](https://docs.didit.me/ko/console/data-retention.md)
>
> 보존 기간 및 요청 시 삭제.

> [card] [Webhook](https://docs.didit.me/ko/integration/webhooks.md)
>
> 이벤트 유형, payload 및 서명 검증.

> [card] [요금](https://docs.didit.me/ko/getting-started/pricing.md)
>
> 검사 건당 결제. 각 기능의 현재 가격을 확인하세요.


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