v0.6
AML/KYT 외부 연동 인터페이스 및 Travel Rule 대응 설계¶
1. 개요¶
1.1. 설계 목적¶
본 문서는 고객(VASP/금융기관)이 AML/의심거래 보고 의무(CORE-07)와 Travel Rule(REG-KR-07) 요건을 충족할 수 있도록, Zone 1(대시보드)에서 Chainalysis/Elliptic 등 AML/KYT 서비스와 연동하고 IVMS101 Travel Rule 메시지를 생성/수신하는 인터페이스를 설계한다.
핵심 원칙: 에어갭 원칙 엄격 준수 - 모든 외부 API 호출은 Zone 1(대시보드)에서만 발생 - Zone 2(오프라인 앱)/Zone 3(SE)에서는 외부 네트워크 접속 불가 - Zone 2/3에는 AML 조회 결과의 요약 정보(risk_level + alert_count)만 QR로 전달 - SE 내부 AML/KYT 직접 검증은 절대 불가 (에어갭 + SE 리소스 제한)
1.2. 규제 근거¶
| 요건 | 근거 | 본 문서 대응 |
|---|---|---|
| COMP-03 | AML/KYT 대시보드 연동 인터페이스 + Travel Rule 대응 | AMLProvider + TravelRuleProvider 추상화 |
| CORE-07 | AML/의심거래 보고 | STR/CTR 자동 보고서 생성 |
| REG-KR-03 | 의심거래보고/고액거래보고 | FIU 제출 포맷 STR/CTR |
| REG-KR-07 | Travel Rule (100만원 이상) | IVMS101 메시지 생성/수신 |
| REG-SG-02 | MAS PSN02 AML/CFT | AML/CFT 기록 5년 보존 |
1.3. Zone 배치 원칙¶
| 구성 요소 | Zone | 역할 | 에어갭 준수 |
|---|---|---|---|
| AML/KYT 연동 API 클라이언트 | Zone 1 | Chainalysis/Elliptic REST API 호출 | Zone 1 only (외부 네트워크) |
| Travel Rule 메시지 송수신 | Zone 1 | TRISA/OpenVASP 프로토콜 통신 | Zone 1 only (외부 네트워크) |
| STR/CTR 보고서 생성기 | Zone 1 | 보고서 초안 생성 + 제출 | Zone 1 only |
| AML 결과 요약 전달 | Zone 1 -> Zone 2 | risk_level + alert_count QR 전달 | 요약 정보만 (에어갭 준수) |
| 서명 정책 간접 반영 | Zone 3 (SE) | 금액 한도/화이트리스트 규칙 | SE 정책 엔진으로 간접 반영 |
1.4. Out of Scope¶
- SE 내부 AML/KYT 직접 검증: SE 리소스(NVM ~16KB, 계산 능력) 불가. 에어갭에서 온라인 DB 참조 불가
- 실시간 블록체인 모니터링: Zone 1 대시보드의 배치 조회로 대체
- 자체 AML 스코어링 엔진: 외부 전문 서비스(Chainalysis/Elliptic) 연동으로 대체
1.5. 선행 산출물 연결점¶
| 산출물 | 연결 방식 |
|---|---|
regulatory-clause-extraction.md (Phase 29) |
REG-KR-03, REG-KR-07, REG-SG-02, CORE-07 요건 정의 |
feature-implications-mapping.md (Phase 29) |
STR/CTR + Travel Rule 피처 배치 |
audit-log-record-schema.md (Phase 30) |
EventType 확장, AMLCheckPayload/TravelRulePayload 추가 |
audit-sync-integrity-chain.md (Phase 30) |
AuditSyncPayload로 AML 결과 요약 Zone 2 전달 |
jurisdiction-policy-profiles.md (Phase 31) |
한국 프로파일 travel_rule_threshold = 1,000,000 KRW |
2. AML/KYT 연동 아키텍처¶
2.1. 연동 대상 서비스¶
| 서비스 | 제공사 | 주요 기능 | API 방식 | 선택 사유 |
|---|---|---|---|---|
| Chainalysis KYT | Chainalysis | 실시간 트랜잭션 모니터링, 주소 위험도 분석 | REST API v2 | 글로벌 시장 점유율 1위, 한국 VASP 다수 사용 |
| Elliptic Lens | Elliptic | 지갑 위험도 분석, 제재 리스트 스크리닝 | REST API | EU 시장 강점, MiCA 대응 |
| Crystal Blockchain | Crystal | 블록체인 분석, 자금 추적 | REST API | 비용 효율, 신규 시장 진출 시 대안 |
2.2. AMLProvider 공통 추상화 레이어¶
벤더 독립적인 공통 인터페이스를 설계하여 서비스 교체/병행 사용이 가능하게 한다.
AMLProvider:
# 인터페이스 정의 (벤더 독립)
interface:
screen_address(request: AMLScreeningRequest) -> AMLScreeningResponse
screen_transaction(request: TxScreeningRequest) -> TxScreeningResponse
get_risk_profile(address: string, chain: string) -> RiskProfile
check_sanctions(address: string) -> SanctionsCheckResult
get_provider_status() -> ProviderStatus
AMLScreeningRequest:
request_id: string # UUID v7
address: string # 대상 블록체인 주소
chain: string # 체인 식별자 (BTC/ETH/USDT 등)
direction: Direction # inbound / outbound
amount: decimal # 거래 금액
currency: string # 통화 코드
counterparty_address: string? # 상대방 주소 (있는 경우)
requested_at: datetime # 요청 시점
requester: string # 요청자 (Operator/System)
Direction:
- INBOUND # 입금 (수신)
- OUTBOUND # 출금 (송신)
AMLScreeningResponse:
response_id: string # UUID v7
request_id: string # 원본 요청 ID 참조
provider: string # 서비스 제공자 (chainalysis/elliptic/crystal)
risk_score: float # 위험도 점수 (0.0~1.0, 1.0 = 최고 위험)
risk_level: RiskLevel # 위험도 등급
alerts: Alert[] # 탐지된 경보 목록
categories: string[] # 위험 카테고리 (darknet/mixer/sanctioned 등)
provider_ref: string # 제공자 측 참조 ID
screened_at: datetime # 스크리닝 시점
expires_at: datetime # 결과 유효 기간
RiskLevel:
- LOW # 낮은 위험 (정상 거래)
- MEDIUM # 중간 위험 (추가 확인 권장)
- HIGH # 높은 위험 (서명 차단 권장)
- SEVERE # 심각 위험 (서명 차단 + 즉시 보고)
Alert:
alert_id: string # 경보 ID
alert_type: string # 경보 유형 (sanctions/darknet/mixer/stolen 등)
severity: string # 심각도
description: string # 상세 설명
source: string # 출처 (OFAC/EU sanctions/UN 등)
2.3. API 통합 패턴¶
외부 서비스 연동은 REST webhook + polling 하이브리드 방식으로 설계한다.
[실시간 스크리닝 흐름 (Pre-signing)]
Operator Zone 1 대시보드 AML Provider
| | |
|-- 트랜잭션 생성 요청 --> | |
| |-- AMLScreeningRequest -->|
| | |
| |<- AMLScreeningResponse --|
| | |
| |-- 위험도 판정 ---------->|
| | (risk_level 확인) |
|<-- 판정 결과 표시 -------| |
| | |
[배치 모니터링 흐름 (Post-transaction)]
Zone 1 대시보드 AML Provider
| |
| (매 시간 배치) |
|-- 미확인 주소 목록 ----->|
| |
|<- 업데이트된 위험도 -----|
| |
|-- 기존 거래 재평가 ----->|
|-- 알림 생성 (변경 시) -->|
2.4. 연동 데이터 흐름도¶
트랜잭션 생성 (Zone 1)
|
v
Zone 1: AML 스크리닝
|-- AMLScreeningRequest -> AMLProvider API
|<- AMLScreeningResponse (risk_score, risk_level, alerts)
|
v
Zone 1: 위험도별 워크플로우 분기
|-- LOW: 정상 서명 세션 생성
|-- MEDIUM: 추가 승인자 요구 (쿼럼 상향)
|-- HIGH/SEVERE: 서명 차단 + 컴플라이언스 담당자 알림
|
v
Zone 1 -> Zone 2: QR 전달 (에어갭)
|-- AML 결과 요약만 전달:
| { risk_level: "LOW", alert_count: 0 }
|-- 상세 데이터는 Zone 1에만 보관
|
v
Zone 2: 오프라인 앱에서 서명 세션 진행
|-- AML 요약 표시 (참고 정보)
|-- SE에는 AML 데이터 전달 불가
|
v
Zone 3: SE 서명 (정책 엔진 간접 반영)
|-- 금액 한도 규칙으로 고위험 거래 간접 차단
|-- 화이트리스트 규칙으로 미승인 주소 차단
3. 서명 워크플로우 통합 설계¶
3.1. Pre-signing AML Check¶
트랜잭션 생성 시점에 대상 주소를 Zone 1에서 자동 스크리닝한다.
Pre-signing AML Check 흐름:
1. Operator가 트랜잭션 생성 요청 (Zone 1 대시보드)
2. 대시보드가 대상 주소(수신 주소)로 AMLScreeningRequest 생성
3. AMLProvider API 호출 (Chainalysis KYT 또는 Elliptic Lens)
4. AMLScreeningResponse 수신 (risk_level 판정)
5. 위험도별 워크플로우 분기 (섹션 3.2)
6. AuditRecord(TX_AML_CHECK) 생성 -> Zone 1 감사 로그
7. 서명 세션 생성 (또는 차단)
AML Check 타이밍: - 필수: 트랜잭션 생성 시 (Pre-signing, 모든 아웃바운드 거래) - 선택: 입금 감지 시 (Post-receive, 인바운드 거래 모니터링)
3.2. 위험도별 워크플로우 분기¶
| 위험도 | risk_score 범위 | 워크플로우 | 쿼럼 변경 | 알림 |
|---|---|---|---|---|
| LOW | 0.0~0.3 | 정상 서명 진행 | 변경 없음 (기본 쿼럼) | 없음 |
| MEDIUM | 0.3~0.6 | 추가 승인자 요구 | 기본 + 1명 추가 (예: 2-of-3 -> 3-of-3) | Compliance Officer 알림 |
| HIGH | 0.6~0.8 | 서명 차단 + 수동 검토 | 서명 세션 생성 불가 | CISO + Compliance Officer 즉시 알림 |
| SEVERE | 0.8~1.0 | 서명 차단 + 자동 STR 초안 | 서명 세션 생성 불가 | CISO + Compliance Officer + Org Owner 즉시 알림, STR 초안 생성 |
HIGH/SEVERE 해제 프로세스: 1. Compliance Officer가 수동 검토 수행 2. 검토 결과를 대시보드에 기록 (AuditRecord에 포함) 3. 허용 판단 시: 쿼럼 전원(Org Owner 포함) 승인으로 서명 진행 4. 거부 판단 시: 트랜잭션 폐기 + STR 제출 진행
3.3. 에어갭 구간 전달 설계¶
AML 결과를 Zone 2(오프라인 앱)에 전달하되, 에어갭 원칙을 엄격히 준수한다.
전달 데이터 구조 (QR 포함):
AMLSummaryForOffline:
# Zone 1 -> Zone 2 QR 전달용 (최소 데이터)
tx_id: string # 트랜잭션 ID 참조
risk_level: RiskLevel # LOW / MEDIUM (HIGH/SEVERE는 Zone 1에서 차단)
alert_count: int # 경보 건수 (상세 내용 제외)
screened_at: datetime # 스크리닝 시점
provider: string # 스크리닝 수행 서비스
summary_hash: string # SHA-256(전체 AMLScreeningResponse) - 무결성 검증용
# Zone 2에서 표시:
# "AML 스크리닝 결과: LOW 위험, 경보 0건 (Chainalysis, 2026-03-29T10:00:00Z)"
# 상세 정보는 대시보드에서 확인하세요.
에어갭 준수 규칙: - Zone 2에는 risk_level(enum), alert_count(int), screened_at(datetime)만 전달 - 상세 alerts[], categories[], risk_score(float)는 Zone 1에만 보관 - SE(Zone 3)에는 AML 데이터 전달 불가 -- 정책 엔진의 금액 한도/화이트리스트 규칙으로 간접 반영 - summary_hash로 Zone 1의 원본 데이터와 대조 가능 (감사 시)
4. STR/CTR 자동 보고서 생성¶
4.1. STR (의심거래보고) 자동 생성¶
AML 스크리닝에서 HIGH/SEVERE 위험을 탐지하면 의심거래보고 초안을 자동 생성한다.
생성 트리거:
| 트리거 조건 | STR 유형 | 자동화 수준 |
|---|---|---|
| AML risk_level = SEVERE | 즉시 보고 대상 | 초안 자동 생성 + 담당자 즉시 알림 |
| AML risk_level = HIGH | 검토 후 보고 대상 | 초안 자동 생성 + 담당자 검토 요청 |
| 거래 패턴 이상 탐지 (속도/금액/빈도) | 패턴 기반 보고 | 이상 패턴 플래그 + 담당자 검토 요청 |
STR 보고서 구조:
STRReport:
report_id: string # UUID v7
report_type: "STR"
status: ReportStatus # DRAFT / UNDER_REVIEW / SUBMITTED / ARCHIVED
generated_at: datetime # 생성 시점
submitted_at: datetime? # 제출 시점
# 의심거래 정보
suspicious_transaction:
tx_id: string # 트랜잭션 ID
tx_type: string # 거래 유형
amount: decimal # 거래 금액
currency: string # 통화
timestamp: datetime # 거래 시점
counterparty_address: string # 상대방 주소
# AML 분석 결과
aml_analysis:
risk_score: float # 위험도 점수
risk_level: RiskLevel # 위험도 등급
alerts: Alert[] # 경보 목록
categories: string[] # 위험 카테고리
# 보고 당사자 정보
reporting_entity:
entity_name: string # 보고 기관명
vasp_registration: string # VASP 신고 번호
# 의심 사유
suspicion_reason: string # 의심 사유 (자동 생성 + 수동 보완)
# 제출 정보
submission:
authority: string # 제출 기관 (FIU)
format: string # 제출 포맷 (금감원 FIU 양식)
submitted_by: string # 제출자 (Compliance Officer)
ReportStatus:
- DRAFT # 초안 (시스템 자동 생성)
- UNDER_REVIEW # 검토 중 (Compliance Officer)
- APPROVED # 승인 (제출 준비 완료)
- SUBMITTED # 제출 완료
- ARCHIVED # 아카이빙
4.2. CTR (고액거래보고) 자동 생성¶
설정 임계값을 초과하는 거래를 자동 탐지하고 고액거래보고 초안을 생성한다.
임계값 설정:
| 관할 | 임계값 | 근거 | 설정 위치 |
|---|---|---|---|
| 한국 | 고객 설정 (기본: 1,000만원) | 특금법/금감원 가이드라인 | JurisdictionProfile.ctr_threshold |
| 싱가포르 | SGD 20,000 | MAS PSN02 | JurisdictionProfile.ctr_threshold |
| 범용 | 고객 설정 | 내부 정책 | SYSTEM_CONFIG |
CTR 보고서 구조:
CTRReport:
report_id: string # UUID v7
report_type: "CTR"
status: ReportStatus
generated_at: datetime
# 고액거래 정보
large_transaction:
tx_id: string
amount: decimal # 거래 금액 (임계값 초과)
currency: string
threshold_exceeded: decimal # 초과 임계값
timestamp: datetime
# 보고 정보 (STR과 유사 구조)
reporting_entity: ReportingEntity
submission: SubmissionInfo
4.3. 보고서 데이터 소스¶
| 데이터 소스 | 보고서 활용 | Phase 참조 |
|---|---|---|
| AuditRecord(TX_CREATE, TX_SIGN, TX_BROADCAST) | 거래 상세 정보 | Phase 30 |
| AMLScreeningResponse | AML 분석 결과 | 본 문서 섹션 2 |
| 계정 정보 (RBAC 기반) | 보고 당사자, 거래 당사자 | v0.5 RBAC v2 |
| JurisdictionProfile | 관할별 임계값, 보고 양식 | Phase 31 |
4.4. 보고서 포맷¶
| 관할 | 규제 당국 | 포맷 | 비고 |
|---|---|---|---|
| 한국 | 금융정보분석원(FIU) | 금감원 FIU 제출 양식 (전자보고) | Phase 1 최우선 |
| 미국 (향후) | FinCEN | SAR(Suspicious Activity Report) 양식 | 향후 미국 진출 시 |
| 싱가포르 | MAS | STR 양식 (MAS PSN02) | APAC Phase 2 |
5. Travel Rule 대응 설계¶
5.1. IVMS101 메시지 표준¶
Travel Rule은 100만원(한국 기준) 이상의 가상자산 이전 시 송수신인 정보를 상대방 VASP에 전달해야 하는 의무이다. IVMS101(interVASP Messaging Standard 101)을 메시지 포맷으로 사용한다.
IVMS101 메시지 구조:
IVMS101Message:
message_id: string # 메시지 고유 ID
message_type: MessageType # TRANSFER / RESPONSE / CONFIRMATION
version: string # IVMS101 버전 (1.0)
created_at: datetime
# 발신인 정보 (Originator)
originator:
originator_person: # 자연인 또는 법인
natural_person:
name: NameIdentifier # 이름 (표준화된 형식)
geographic_address: Address? # 주소
national_identification: NationalId? # 신원 확인
date_of_birth: date? # 생년월일
legal_person:
name: LegalNameIdentifier # 법인명
registration_authority: string # 등록 기관
account_number: string[] # 가상자산 주소(들)
# 수신인 정보 (Beneficiary)
beneficiary:
beneficiary_person: # 자연인 또는 법인 (발신인과 동일 구조)
account_number: string[] # 수신 가상자산 주소(들)
# 발신 VASP 정보
originating_vasp:
vasp_id: string # VASP 식별자 (LEI 또는 등록번호)
vasp_name: string # VASP 명칭
vasp_address: Address # VASP 주소
# 수신 VASP 정보
beneficiary_vasp:
vasp_id: string
vasp_name: string
vasp_address: Address
# 전송 정보
transfer_info:
amount: decimal # 전송 금액
currency: string # 통화 코드
payment_type: string # 결제 유형
transfer_date: datetime # 전송 일시
MessageType:
- TRANSFER # 초기 Travel Rule 메시지 전송
- RESPONSE # 수신 측 응답 (수락/거부)
- CONFIRMATION # 전송 확인
5.2. TravelRuleProvider 추상화 레이어¶
벤더 독립적인 Travel Rule 프로토콜 인터페이스를 설계한다.
TravelRuleProvider:
# 인터페이스 정의 (프로토콜 독립)
interface:
send_message(message: IVMS101Message) -> TRSendResult
receive_message() -> IVMS101Message[]
verify_counterparty(vasp_id: string) -> VASPVerification
get_provider_status() -> ProviderStatus
TRSendResult:
success: boolean
message_id: string # 발송 메시지 ID
counterparty_ack: boolean # 상대방 수신 확인
protocol: string # 사용된 프로토콜 (TRISA/OpenVASP/Sygna)
sent_at: datetime
지원 프로토콜:
| 프로토콜 | 제공사 | 특징 | 한국 지원 |
|---|---|---|---|
| TRISA | TRISA Network | 글로벌 표준, mTLS 기반 | 글로벌 VASP |
| OpenVASP | OpenVASP Association | 오픈소스, 블록체인 기반 | EU 중심 |
| Sygna Bridge | CoolBitX | APAC 중심 | 한국 VASP 일부 |
| K-TRUST | 코리아 트래블룰 | 한국 국내 표준 | 한국 VASP 필수 |
5.3. Travel Rule 메시지 생성 플로우 (아웃바운드)¶
1. 트랜잭션 생성 (Zone 1 대시보드)
|
v
2. Travel Rule 적용 판단
- JurisdictionProfile.travel_rule_threshold 확인
- 한국: amount >= 1,000,000 KRW
- 해당 시: Travel Rule 메시지 생성 필요
|
v
3. IVMS101 메시지 생성 (Zone 1)
- 발신인(Originator) 정보 자동 채움 (고객 KYC DB 참조)
- 수신인(Beneficiary) 정보: 트랜잭션 생성 시 입력
- 발신 VASP 정보: 시스템 설정에서 자동
- 수신 VASP 정보: 주소 -> VASP 매핑 (Chainalysis VASP Directory 등)
|
v
4. 상대방 VASP 확인
- TravelRuleProvider.verify_counterparty(vasp_id) 호출
- VASP 등록 상태, 통신 가능 여부 확인
|
v
5. IVMS101 메시지 전송
- TravelRuleProvider.send_message(message) 호출
- K-TRUST(한국) 또는 TRISA(글로벌) 프로토콜 사용
- 전송 결과 AuditRecord(TR_SEND)에 기록
|
v
6. 서명 세션 진행
- Travel Rule 메시지 전송 완료 확인 후 서명 세션 생성
- 미전송 상태에서는 서명 진행 차단 (규제 준수 강제)
5.4. Travel Rule 메시지 수신 플로우 (인바운드)¶
1. 상대방 VASP로부터 IVMS101 메시지 수신 (Zone 1)
|
v
2. 메시지 검증
- IVMS101 스키마 유효성 검사
- 발신 VASP 신원 확인 (LEI/등록번호 검증)
- 메시지 무결성 확인 (디지털 서명 검증)
|
v
3. 발신인 정보 AML 스크리닝
- AMLScreeningRequest 생성 (발신인 주소)
- AMLProvider.screen_address() 호출
- 위험도 판정 (LOW/MEDIUM/HIGH/SEVERE)
|
v
4. 수신 승인/거부
- LOW/MEDIUM: 자동 수신 확인 (CONFIRMATION 전송)
- HIGH/SEVERE: Compliance Officer 수동 검토 후 결정
|
v
5. AuditRecord(TR_RECEIVE) 기록
- IVMS101 메시지 해시, 발신 VASP, 검증 결과 기록
- 5년 보존 (CORE-03)
5.5. 한국 시장 우선 구현¶
| 항목 | 설정 | 근거 |
|---|---|---|
| 임계값 | 1,000,000 KRW | 특금법 시행령 |
| 국내 프로토콜 | K-TRUST (코리아 트래블룰 솔루션) | 한국 VASP 간 필수 |
| 국제 프로토콜 | TRISA | 해외 VASP 연동 |
| VASP Directory | K-TRUST 참여 VASP 목록 + Chainalysis VASP Directory | 상대방 VASP 식별 |
| KYC 정보 수준 | 이름, 주소, 식별번호 (자연인) / 법인명, 등록번호 (법인) | FATF 권고 + 특금법 |
6. 감사 로그 연동¶
6.1. 신규 EventType 제안¶
Phase 30에서 정의된 기존 19개 EventType에 AML/Travel Rule 관련 4개를 추가한다.
; === E. AML/Travel Rule (4개 - 신규 제안) ===
event-tx-aml-check: 0x0501, ; AML 스크리닝 수행
event-tx-aml-alert: 0x0502, ; AML 위험 탐지 (HIGH/SEVERE)
event-tr-send: 0x0503, ; Travel Rule 메시지 발송
event-tr-receive: 0x0504, ; Travel Rule 메시지 수신
네이밍 일관성: 기존 EventType 패턴(event-{카테고리}-{동작})을 준수한다.
- 기존 트랜잭션: event-tx-create, event-tx-approve, event-tx-sign (0x01XX)
- 신규 AML: event-tx-aml-check, event-tx-aml-alert (0x05XX)
- 신규 Travel Rule: event-tr-send, event-tr-receive (0x05XX)
6.2. AMLCheckPayload 구조¶
AMLCheckPayload:
# AuditRecord.payload에 포함되는 AML 스크리닝 결과
screening_id: string # AMLScreeningResponse.response_id
provider: string # 서비스 제공자 (chainalysis/elliptic/crystal)
target_address: string # 스크리닝 대상 주소
chain: string # 체인 식별자
direction: Direction # INBOUND / OUTBOUND
risk_level: RiskLevel # LOW / MEDIUM / HIGH / SEVERE
alert_count: int # 탐지된 경보 건수
risk_score: float # 위험도 점수 (0.0~1.0)
workflow_action: string # 수행된 조치 (proceed/escalate/block)
6.3. TravelRulePayload 구조¶
TravelRulePayload:
# AuditRecord.payload에 포함되는 Travel Rule 이벤트 데이터
tr_message_id: string # IVMS101 메시지 ID
counterparty_vasp: string # 상대방 VASP 식별자
counterparty_vasp_name: string # 상대방 VASP 명칭
ivms101_hash: string # SHA-256(IVMS101 메시지 전체)
direction: Direction # INBOUND / OUTBOUND
protocol: string # 사용 프로토콜 (TRISA/K-TRUST/OpenVASP)
amount: decimal # 전송 금액
currency: string # 통화 코드
verification_result: string # 상대방 VASP 검증 결과
6.4. 감사 로그 통합 흐름¶
모든 AML/Travel Rule 이벤트:
1. Zone 1에서 발생 (외부 API 호출)
2. AuditRecord 생성 (event_type = TX_AML_CHECK / TX_AML_ALERT / TR_SEND / TR_RECEIVE)
3. payload에 AMLCheckPayload 또는 TravelRulePayload 포함
4. Zone 1 해시 체인에 링크 (prev_hash)
5. AuditSyncPayload에 포함되어 3계층 무결성 체인으로 동기화
6. ComplianceChecklist 자동 증거 수집에 활용
7. 데이터 프라이버시 및 보존¶
7.1. AML 스크리닝 결과 보존¶
| 데이터 | 보존 기간 | 근거 | 보존 위치 |
|---|---|---|---|
| AMLScreeningResponse (전체) | 관할별 보존 기간 (한국 5년, 일본 10년) | CORE-03, REG-KR-08, REG-JP-02 | Zone 1 아카이빙 저장소 |
| AML 요약 (risk_level, alert_count) | AuditRecord와 동일 보존 | AuditRecord의 일부 | Zone 1 감사 로그 DB |
| STR/CTR 보고서 | 영구 보존 (규제 당국 제출 후) | 제출 기록 보존 의무 | Zone 1 보고서 아카이브 |
7.2. Travel Rule 개인정보 처리¶
| 데이터 | 처리 방식 | GDPR Delta 적용 시 |
|---|---|---|
| IVMS101 메시지 원본 | 암호화 저장 (AES-256) | 가명처리 후 저장, 보존 기간 준수 |
| 발신인/수신인 이름, 주소 | 접근 통제 (Compliance Officer 전용) | Art. 17(3)(b) 법률 근거 예외 적용 |
| VASP 간 통신 기록 | 5년 보존 | 법률 근거 보존 후 삭제 또는 가명처리 |
GDPR Delta(DELTA-EU-03) 적용 시 처리 규칙: - GDPR Art. 17(3)(b): 법률 준수를 위한 처리가 필요한 경우 삭제권 예외 - Travel Rule은 AML 법률 의무이므로 보존 기간 중 삭제 거부 가능 - 보존 기간 종료 후: 가명처리(식별 정보 해시화) 또는 완전 삭제
7.3. 에어갭 원칙 준수 재확인¶
| 원칙 | 준수 방법 | 위반 시나리오 방지 |
|---|---|---|
| AML/KYT 원본 데이터는 Zone 1에만 존재 | AMLScreeningResponse 전체는 Zone 1 DB에만 저장 | Zone 2/3로 상세 데이터 전송 금지 |
| Zone 2/3에는 risk_level 요약만 전달 | AMLSummaryForOffline 구조 (risk_level + alert_count만) | alerts[], categories[] 전달 금지 |
| SE에는 AML 데이터 전달 불가 | 정책 엔진 간접 반영 (금액 한도, 화이트리스트) | SE에 직접 AML 데이터 전송 금지 |
| 외부 API 호출은 Zone 1에서만 | AMLProvider, TravelRuleProvider 모두 Zone 1 실행 | Zone 2 앱에서 외부 API 호출 금지 |
8. 종합 아키텍처 다이어그램¶
+================================================================+
| Zone 1: 대시보드 (온라인) |
| |
| +------------------+ +------------------+ +-----------------+ |
| | AML/KYT 연동 | | Travel Rule | | STR/CTR | |
| | 모듈 | | 모듈 | | 보고서 생성기 | |
| | | | | | | |
| | AMLProvider | | TravelRule | | STRReport | |
| | - Chainalysis | | Provider | | CTRReport | |
| | - Elliptic | | - K-TRUST | | | |
| | - Crystal | | - TRISA | | FIU 양식 출력 | |
| +--------+---------+ +--------+---------+ +-------+---------+ |
| | | | |
| v v v |
| +--------------------------------------------------------+ |
| | AuditRecord 감사 로그 DB | |
| | TX_AML_CHECK | TX_AML_ALERT | TR_SEND | TR_RECEIVE | |
| | (기존 19개 EventType + 신규 4개 = 23개) | |
| +--------------------------------------------------------+ |
| | |
+===========|=======================================================+
| QR (AMLSummaryForOffline: risk_level + alert_count)
| (에어갭)
+===========|=======================================================+
| v |
| +---------------------+ |
| | Zone 2: 오프라인 앱 | |
| | AML 요약 표시 (참고) | |
| | 서명 세션 진행 | |
| +----------+----------+ |
| | |
| | QR/NFC (서명 요청) |
| | (에어갭) |
+===========|=======================================================+
| v |
| +---------------------+ |
| | Zone 3: SE (콜드월렛) | |
| | 정책 엔진 간접 반영: | |
| | - 금액 한도 규칙 | |
| | - 화이트리스트 규칙 | |
| | (AML 직접 데이터 없음) | |
| +---------------------+ |
+================================================================+
9. 컴플라이언스 체크리스트 연동¶
본 문서에서 설계한 AML/KYT 연동 기능은 compliance-checklist-engine.md의 체크리스트 항목에 증거를 제공한다.
9.1. AML/Travel Rule 관련 체크리스트 항목 매핑¶
| 체크리스트 항목 | 프레임워크 | 증거 소스 (본 문서) | 판정 가능 상태 |
|---|---|---|---|
| CORE-07 AML/의심거래 보고 | ISMS-P, CCSS, SOC 2 | AuditRecord(TX_AML_CHECK) 존재 | Auto-Satisfied |
| REG-KR-03 STR/CTR 보고 | ISMS-P | STRReport/CTRReport 생성 이력 | Auto-Satisfied |
| REG-KR-07 Travel Rule | ISMS-P | AuditRecord(TR_SEND, TR_RECEIVE) 존재 | Auto-Satisfied |
| REG-SG-02 AML/CFT 기록 | SOC 2 | AML 스크리닝 기록 5년 보존 | Auto-Satisfied |
9.2. 자동화율 기여¶
AML/KYT 연동 구현으로 CORE-07 관련 통제 항목이 Auto-Satisfied로 판정 가능해져, 전체 자동화율이 소폭 향상된다.
관련 문서¶
- Compliance-as-Code 규제 매핑 엔진 설계 -- 규제 준수
- 규제별 컴플라이언스 체크리스트 자동 생성 엔진 설계 -- 규제 준수