CEX 핫 월렛에 오전 3시 14분에 입금이 들어온다. 이체 금액은 소액으로 플랫폼의 보고 기준에 미치지 않으며, 출처 주소는 내부 제재 파일에 어떠한 플래그도 없다. 시스템은 사용자 계정에 자산을 크레딧한다. 20분 후, 외부 인텔리전스 피드가 동일한 출처 주소를 제재 대상 기관으로 업데이트한다. 이제 거래소는 불법 자금을 보유하고 있으며, 온보딩은 누구도 개입할 수 없는 시점에 이루어졌고, 감사 로그에는 정상 승인으로 기록되어 있다. 이것이 바로 규제 당국이 가상자산 서비스 제공업체(VASP)에 대한 집행 조치에서 지속적으로 인용하는 입금 스크리닝 실패 패턴이다.
그 이유는 구조적인 문제에 있다. 입금은 외부 자금이 플랫폼 관리 지갑에 최초로 접촉하는 순간으로, 거래소의 자금 세탁 방지(AML) 체계에서 가장 높은 노출 지점이 된다. 금융행동기구(FATF)는 VASP가 모든 수신 이체에 위험 기반 접근법을 적용할 것을 요구하며, FinCEN의 은행비밀보호법(BSA)에 따른 의무는 미국 등록 플랫폼에도 동일한 기대를 확장한다. 이 글에서는 입금 흐름 매핑부터 방어 가능한 감사 추적 구축까지, 입금 측 AML 스크리닝을 4단계로 구현하는 방법을 안내한다.
입금 측 AML 스크리닝이 첫 번째 방어선인 이유
일반적인 집행 패턴을 살펴보자. 디지털 자산 회사를 검토하는 검사관은 수신 입금에 대한 승인 결정에 출처 주소 스크리닝에 관한 문서가 전혀 없다는 사실을 발견한다. 이 발견은 신원 확인(KYC)에 관한 것이 아니었다. KYC는 해당 회사가 별도로 처리한 사항이었다. 문제는 자금이 크레딧되어 거래소의 통합 핫 월렛으로 이전되기 전에, 자금을 전송하는 지갑을 평가하는 어떠한 통제도 없었다는 점이었다.
입금 스크리닝은 이 gap을 메우는 통제 장치로, 신원 계층이 아닌 주소 및 거래 계층에서 작동한다. KYC는 온보딩 시 고객을 검증한다. KYA(Know Your Address)는 실제로 플랫폼에 가치를 전달하는 블록체인 주소를 평가한다. KYT(Know Your Transaction)는 확인 시점에 자금 이동을 모니터링한다. 입금에 대한 AML 스크리닝은 플랫폼이 이미 완료했을 수 있는 신원 확인이 아닌 KYA와 KYT를 기반으로 구축된다.
입금이 첫 번째 방어선인 이유는 타이밍에 있다. 자금이 크레딧되어 공유 핫 월렛에 통합되면, 특정 출처로 거슬러 올라가는 추적이 훨씬 어려워진다. 제재 대상 자금이 정상 입금과 혼합되면 이후 출금을 오염시킬 수 있으며, 입금 단계에서 스크리닝을 한 번이라도 놓치면 몇 주 후 규제 발견 사항으로 나타날 수 있다.
1단계: 입금 흐름 매핑 및 스크리닝 트리거 지점 파악
사용자가 입금 주소를 생성하는 순간부터 자금이 크레딧되어 거래에 사용 가능해지는 순간까지, 입금 흐름을 처음부터 끝까지 그려보는 것부터 시작한다. 대부분의 CEX 파이프라인은 스크리닝을 배포할 수 있는 네 가지 명확한 통제 지점을 거치며, 각각 다른 위험 프로필을 가진다.
네 가지 트리거 지점은 명확하다. 첫째, 주소 생성 시 스크리닝으로, 플랫폼이 불법 활동과 연결된 지갑에 입금 주소를 제공하기 전에 실시한다. 둘째, 첫 번째 온체인 확인 시 스크리닝으로, 실제 이체를 평가한다. 셋째, 자금이 핫 월렛으로 통합되기 전 사전 스윕 확인으로, 혼합 전 마지막 기술적 체크포인트다. 넷째, 자동화된 검사를 통과했지만 인간의 검토가 필요한 패턴을 보이는 대규모 또는 비정상적인 입금에 대한 임계값 기반 검토다.
비즈니스 모델에 따라 이러한 통제의 배분 방식이 달라진다. 소매 흐름을 가진 현물 거래소는 확인 시 자동 스크리닝을 배포하고 대규모 입금에만 수동 검토를 유지할 수 있다. OTC 데스크는 가격 제시 전에 사전 거래 스크리닝을 요구할 수 있다. 입금과 출금을 모두 처리하는 지급 기관은 입금 스크리닝 계층을 더 넓은 컴플라이언스 파이프라인 내의 하나의 모듈로 취급할 수 있다. 매핑 작업을 통해 팀은 통합 코드를 작성하기 전에, 각 통제가 기존 코드베이스의 어디에 위치하며 누가 담당하는지 결정하게 된다.
2단계: 입금 파이프라인에 주소 스크리닝 API 통합
트리거 지점이 매핑되면, 다음 단계는 각 지점에 스크리닝 API를 연결하는 것이다. 통합 순서는 호출이 어디에 위치하든 일관적이다. 먼저 주소 형식을 정규화한다. 다음으로 KYA 엔진에 제출한다. 그런 다음 카테고리 컨텍스트와 함께 위험 수준을 수신한다. 마지막으로 해당 수준에 따라 입금 워크플로를 분기한다.
정규화는 생각보다 중요하다. 이더리움 주소는 체크섬, 소문자, EVM 별칭 형식으로 나타날 수 있으며, 트론 주소는 16진수 대신 base58을 사용한다. 스크리닝 호출은 해당 체인에 대해 엔진이 기대하는 형식으로 주소를 전달해야 하며, 그렇지 않으면 결과가 자동으로 실패한다. 정규화 후, 엔진은 사전 구축된 레이블 그래프와 주소를 대조하여 위험 수준과 이를 유발한 레이블 카테고리를 반환한다. BlockSec의 KYA 엔진은 6억 개 이상의 사전 구축된 레이블과 200개 이상의 위험 신호를 밀리초 수준의 응답으로 처리한다(Phalcon Compliance Docs). 이 응답은 입금 파이프라인의 허용(Allow), 검토(Review), 차단(Block) 분기로 직접 연결된다.
파이프라인 자체가 대부분의 구현에서 문제가 발생하는 지점이다. 스크리닝 호출이 거래 확인과 계정 크레딧 사이의 동기 경로에 있으면, 지연 시간이 사용자 경험에 직접 영향을 미친다. 배치로 처리하는 비동기 큐에 있으면, 배치 사이에 발행된 제재 지정으로 인해 플랫폼이 노출될 수 있다. 운영 환경 배포에서는 일반적으로 초기 결정을 위한 동기식 사전 크레딧 확인과, 이후 도착하는 레이블 업데이트를 위한 비동기식 재스크리닝을 함께 사용한다.
3단계: 위험 임계값 및 대응 조치 정의
스크리닝이 통합되면, 플랫폼은 각 위험 수준을 구체적인 조치와 연결하는 정책이 필요하다. 임계값이 없으면 스크리닝 결과는 실행 불가능하고, 임계값이 있으면 집행 가능한 통제가 된다.
Phalcon Compliance는 각 스크리닝된 입금에 대해 위험(Critical), 높음(High), 보통(Medium), 낮음(Low), 정보성(Informational), 위험 없음(No Risk)의 여섯 가지 위험 수준 중 하나를 반환한다. 각 조직은 자체 컴플라이언스 정책 및 위험 성향에 맞게 각 등급의 의미를 설정한다. 입금에 대한 일반적인 매핑은 다음과 같다. 위험(Critical)은 자동 차단 및 즉각적인 조사로 연결되고, 높음(High)과 보통(Medium)은 수동 검토 또는 보류로 연결되며, 낮음(Low)과 정보성(Informational)은 지속적인 모니터링으로 계속되고, 위험 없음(No Risk)은 자동 크레딧된다.
| 위험 수준 | 일반적인 시스템 조치 | 분석가 조치 | 보존 증거 | 규제 트리거 |
|---|---|---|---|---|
| 위험(Critical) | 자동 차단, 에스컬레이션 | 즉시 조사, 필요 시 STR 제출 | 전체 스크리닝 추적, 결정 체인 | 의심 활동 보고 |
| 높음(High) | 크레딧 보류, 큐로 전달 | 레이블 컨텍스트 검토, SLA 내 결정 | 분석가 ID, 결정 근거 | 강화된 고객 확인 파일 |
| 보통(Medium) | 크레딧 보류, 큐로 전달 | 레이블 컨텍스트 검토, 결정 | 분석가 ID, 결정 근거 | 강화된 고객 확인 파일 |
| 낮음(Low) | 자동 크레딧, 지속 모니터링 | 조치 불필요 | 수준, 카테고리, 타임스탬프 | 표준 기록 보관 |
| 정보성(Informational) | 플래그와 함께 자동 크레딧 | 컨텍스트 인지, 조치 없음 | 수준, 카테고리, 타임스탬프 | 표준 기록 보관 |
| 위험 없음(No Risk) | 자동 크레딧 | 조치 불필요 | 수준, 타임스탬프 | 표준 기록 보관 |
두 가지 임계값 함정이 집행 발견에서 자주 나타난다. 첫째는 위협 패턴이 변해도 조정되지 않는 정적 구성으로, 제재 급증 시 위험(Critical) 또는 높음(High) 기준의 일시적 강화가 필요할 수 있다. 둘째는 팀이 감당할 수 없는 큐로 모든 애매한 입금을 몰아넣는 보통(Medium) 기준으로, 분석가가 형식적으로 결정을 승인하게 되어 수동 검토의 목적이 무너진다. Phalcon Compliance는 구성 가능한 위험 정책을 지원하므로, 각 등급의 매핑을 플랫폼의 위험 프로필에 맞게 조정하고 노출 변화에 따라 수정할 수 있다.
4단계: 입금 스크리닝을 위한 컴플라이언스 감사 추적 구축
마지막 단계는 규제 당국이 가장 먼저 검토하는 항목인 감사 추적이다. 몇 달 후 재현할 수 없는 스크리닝 결정은, 검사 목적상 스크리닝이 이루어지지 않은 것과 같다.
모든 스크리닝 이벤트는 스크리닝된 주소, 타임스탬프, 반환된 위험 수준, 평가를 유발한 레이블 카테고리, 결과 결정과 함께 기록되어야 한다. 로그는 변조 방지 기능을 갖추고 요청 시 내보낼 수 있어야 한다. 검사관이 특정 날짜에 특정 입금이 왜 통과되었는지 묻는다면, 그에 대한 응답은 서술적 설명이 아니라 해당 타임스탬프의 스크리닝 기록을 그대로 재현한 것이어야 한다. Phalcon Compliance 플랫폼은 각 결정을 검사용으로 내보낼 수 있는 컴플라이언스 로그에 기록하며, 주요 규제 관할권에 맞춘 원클릭 STR 생성을 지원한다(Phalcon Compliance Docs, Risk Levels).
감사 추적은 또한 장기적 검토를 가능하게 한다. 한 번 스크리닝된 단일 입금은 특정 시점의 결정이다. 생애 주기 동안 지속적으로 스크리닝된 입금 주소는 위험 이력이 된다. 레이블 업데이트가 플랫폼과 이전에 상호작용한 주소를 제재 대상으로 지정하면, 감사 추적이 그 이전 관계를 드러낸다. 컴플라이언스 팀은 해당 출처의 모든 입금을 재구성하고 소급 조치가 필요한지 판단할 수 있다.
거래소와 VASP를 위한 전체 AML 컴플라이언스 프로그램에서 입금 스크리닝이 어떻게 적용되는지에 대한 더 폭넓은 내용은 Crypto AML Compliance를 참조하라. Phalcon Compliance 플랫폼은 위 단계를 운영 환경에서 실행한다.
→ Phalcon Compliance 데모를 예약하고 거래소 워크플로에 입금 AML 스크리닝을 구현하세요: 데모 예약
FAQ
입금 측 AML 스크리닝은 KYC와 어떻게 다른가요? KYC는 온보딩 시 고객 신원을 문서 계층에서 검증한다. 입금 측 AML 스크리닝은 주소 및 거래 계층에서 실행되며, 이체를 시작한 사람이 아니라 각 수신 이체의 블록체인 출처를 평가한다. 두 가지는 완전한 AML 프로그램에서 상호 보완적인 통제 수단이다.
입금 흐름의 어느 시점에 스크리닝을 실행해야 하나요? 스크리닝은 자금이 사용자 계정에 크레딧되기 전, 거래 확인 시 최소 한 번 실행되어야 한다. 많은 플랫폼이 핫 월렛으로 통합되기 전 사전 스윕 확인과 규모가 크거나 구조적으로 비정상적인 입금에 대한 임계값 기반 검토를 추가한다.
입금이 이미 크레딧된 후 위험 수준이 업데이트되면 어떻게 되나요? 감사 추적을 통해 컴플라이언스 팀은 동일 주소의 이전 입금을 식별하고 소급 조치를 평가할 수 있다. 입금 시 스크리닝과 함께 실행되는 지속적 모니터링 레이어가 초기 결정 이후 도착하는 레이블 업데이트를 포착하여 재평가를 위해 표면화한다.
입금 스크리닝이 사용자 경험을 느리게 만들지 않나요? 밀리초 수준의 응답을 반환하는 스크리닝 엔진은 입금 경로에서 체감할 수 있는 지연을 유발하지 않는다. 병목 지점은 보통 스크리닝 호출이 아니라 블록체인 확인 시간이며, 스크리닝은 확인 폴링과 병렬로 실행된다.
각 입금에 대한 감사 추적에는 무엇이 포함되어야 하나요? 최소한 다음 항목이 포함되어야 한다. 스크리닝된 주소, 타임스탬프, 위험 수준, 평가를 유발한 위험 카테고리, 취해진 결정, 적용된 정책 버전. 보통(Medium) 및 높음(High) 기준의 경우, 분석가 신원과 결정 근거도 보존되어야 한다.
