온체인 데이터 분석, STR, AI 에이전트 도입까지, 금융기관이 검토해야 할 실무 과제

2026년 8월 20일 개정 특정금융정보법이 시행됩니다. 직접 의무의 주체는 가상자산사업자이지만, 실명계좌를 제공하는 은행은 제휴 사업자의 관리체계 수준을 확인해야 하고, 거래소를 통해 유입되는 자금의 AML 판단 기준도 함께 달라집니다. 이번 개정은 사실상 은행의 온체인 리스크 관리 의무를 간접적으로 높이는 조치입니다.

이번 개정에서 해외 이전거래 보고 방식이 일률 보고에서 사업자별 관리체계 운영으로 바뀌었습니다. 규제가 요구하는 것이 보고 건수에서 관리체계의 합리성 입증으로 옮겨가고 있다는 신호입니다.

디지털자산이 원화로 전환되어 금융기관으로 유입되면 계좌에는 일반적인 입금 거래 한 건으로 기록됩니다. 그 이전의 온체인 자금 흐름과 경유 주소의 위험도는 별도의 분석 없이 확인되지 않습니다. 고객정보와 계좌, 금융거래를 중심으로 발전해온 기존 자금세탁방지(AML)와 이상거래탐지(FDS)에서 이 구간은 관측 범위 밖에 있습니다.

이미 운영하고 있는 AML 체계에 온체인 데이터와 새로운 업무를 어떻게 연결할 것인가. 이 글은 그 질문을 다섯 개 과제로 나누어 정리합니다.

이 글에서 다루는 내용

1. 기존 AML의 확장 범위와 연동 방식
2. 고객, 계좌, 지갑, 온체인 거래의 맥락 연결
3. Alert 이후 조사와 STR 워크플로우
4. 설명 가능성과 감사 가능성을 전제로 한 컴플라이언스 AX
5. 디지털자산 사업 검토 단계의 AML 요건

1. 기존 AML을 어디까지 확장할 것인가

금융기관은 이미 고객확인(KYC/CDD), 거래 모니터링, FDS, 의심거래보고(STR) 등 다양한 시스템과 업무 프로세스를 운영하고 있습니다.

온체인 분석 환경을 별개의 AML 시스템으로 구축하면 검토 범위가 빠르게 커집니다. 기존 고객정보와의 매핑, 데이터 이관, 접근권한, 내부 보안정책, 망분리, 규제 보고 체계까지 함께 설계해야 합니다. 시스템 하나를 추가하려던 일이 전체 AML 아키텍처를 다시 설계하는 프로젝트가 됩니다.

현실적인 접근은 기존 시스템의 역할을 유지하면서 필요한 온체인 데이터와 분석 결과를 기존 AML 업무 안으로 연결하는 것입니다. 거래 모니터링은 기존 시스템에서 수행하고, 분석이 필요한 거래에 대해서만 블록체인 거래내역과 지갑 정보를 조회해 그 결과를 내부 조사와 보고 프로세스에 반영합니다.

이 단계에서 갈리는 것은 기능 비교가 아니라 금융기관 환경에서의 적용 가능성입니다. 다음 항목을 함께 정해야 합니다.

• 온체인 데이터를 내부에 어디까지 적재할 것인가
• 기존 AML과 TMS에 어떤 방식으로 연동할 것인가
• 망분리와 온프레미스 환경에서 데이터 경계를 어디에 둘 것인가

2. 계좌와 지갑의 맥락은 어디서 끊기는가

온체인 AML에서 데이터 자체가 부족한 경우는 드뭅니다.

금융기관에는 고객과 계좌, 거래정보가 있고 블록체인에는 지갑과 트랜잭션 기록이 남습니다. 제재 명단, 위험 주소, 법령과 내부 규정도 각각 존재합니다. 이 정보들이 서로 다른 시스템과 기준으로 관리된다는 데서 문제가 시작됩니다.

AML 조사에서 필요한 관계를 단순화하면 다음과 같습니다.

고객 → 계좌 → 지갑 → 거래 → 거래주체 → 위험정보 → 관련 규정

이상 징후가 발견된 거래 하나만 보고 판단할 수는 없습니다. 담당자는 고객의 KYC/KYB 정보, 연결된 계좌와 지갑, 거래 상대방, 자금의 이동 경로, 제재 대상과의 연관성, 그 거래에 적용되는 내부 룰과 규정을 함께 확인합니다.

이때 필요한 것은 하나의 고객과 사건을 기준으로 분산된 정보를 이어서 볼 수 있는 구조입니다. 데이터의 물리적 위치를 옮기지 않고 관계만 연결해도 됩니다.

계좌와 지갑의 맥락이 끊기는 지점은 Fraud에서 AML로 이어지는 위험 흐름이 단절되는 지점이기도 합니다. 이상출금이 발생한 순간부터 해당 자금은 온체인에서 빠르게 이동하지만, 은행의 FDS와 거래소의 AML 시스템이 신호를 주고받지 못하면 레일을 갈아타는 순간 위험 스코어링이 초기화됩니다. FRAML은 이 단절을 하나의 사건 흐름으로 연결하는 접근입니다.

온톨로지와 지식그래프는 이 지점에서 데이터 간 관계를 구조화하는 역할을 합니다. 금융기관 내부 데이터와 온체인 거래, 법령, 제재정보를 연결해 담당자가 거래의 맥락과 판단 근거를 한 화면에서 보게 만드는 것입니다.

3. STR 보고를 위해 필요한 분산된 정보들

AML 시스템의 역할은 이상거래 탐지에서 끝나지 않습니다.

Alert가 발생한 이후에 고객정보 확인, 거래 분석, 자금 흐름 조사, 보고 여부 판단, STR 작성과 사후 기록 관리가 이어집니다.

탐지 → 고객 확인 → 거래 분석 → 자금 흐름 조사 → 판단 → STR → 감사 기록

이 과정에서 담당자는 KYC/KYB 정보, 입출금 내역, 거래 빈도와 패턴, 자금 출처, 상대방 정보, 탐지 사유와 관련 규정을 각각 조회합니다. 정보가 여러 시스템에 흩어져 있으면 조회한 자료를 다시 취합하는 작업이 붙습니다. STR 한 건을 완성하는 데 수 일이 걸리는 경우도 있습니다. False Positive가 많을수록 실제 조사가 필요한 거래를 선별하는 부담도 함께 커집니다.

그래서 AML 고도화의 기준을 탐지 건수만으로 잡기는 어렵습니다. 실제 업무 효율은 Alert 이후 필요한 정보를 얼마나 빠르게 연결하고, 조사와 판단, 보고를 하나의 흐름으로 이어가는지에서 갈립니다.

Alert가 발생하면 관련 고객정보와 거래내역을 자동으로 모으고, 연결된 지갑과 거래 상대방의 관계를 분석해 자금 이동 경로를 제시할 수 있습니다. 여기에 제재정보와 규정을 연결하면 담당자가 보고 여부를 판단할 근거가 한자리에 모입니다.

STR 작성도 같은 방식으로 접근합니다. 자동화 대상은 최종 보고 판단이 아니라 판단에 필요한 고객·거래·규제 정보를 취합해 담당자 검토용 초안을 만드는 영역입니다.

람다256의 클레어(CLAIR)는 온·오프체인 데이터를 기반으로 자금 흐름을 추적하고, Alert 이후 조사와 STR을 하나의 업무 흐름으로 연결합니다. FDS와 AML을 함께 다루는 FRAML 구조로, 기존에 분리되어 있던 탐지와 보고 업무를 잇습니다.

4. 금융권 컴플라이언스 AX의 전제조건: 설명과 감사

AI를 활용하면 데이터 검색과 분석, 문서 작성처럼 AML 담당자가 반복하는 업무를 줄일 수 있습니다.

다만 규제와 내부통제가 중심인 금융업에서 AI 적용 기준은 일반적인 업무 자동화와 다릅니다. AI 에이전트의 자율성에 앞서 통제 가능성, 데이터 품질, 접근통제와 감사 추적이 전제조건으로 다뤄집니다.

AI가 특정 거래의 위험도가 높다고 제시했다면 결과만으로는 부족합니다. 어떤 고객정보와 거래 데이터를 확인했는지, 어떤 위험정보와 규정을 참고했는지, 그 판단에 적용된 룰이 무엇인지 담당자가 되짚을 수 있어야 합니다.

규제나 내부 기준이 바뀌는 경우도 같습니다. 새 룰을 실제 시스템에 적용하기 전에 과거 데이터로 탐지 건수 변화를 검증하고, 변경 전후의 결과와 이력을 남겨야 합니다.

따라서 금융권 컴플라이언스 AX에서는 세 가지가 함께 검토됩니다.

자동화(Automation)

반복적인 정보 조회와 자료 취합, 분석 및 보고서 작성 업무가 줄어드는가.

설명 가능성(Explainability)

시스템이 제시한 분석 결과와 판단 근거를 담당자가 확인할 수 있는가.

감사 가능성(Auditability)

룰 변경과 분석, 담당자의 최종 판단 과정이 재현 가능한 기록으로 남는가.

이 조건에서 AI 에이전트의 역할도 정해집니다. 최종 판단은 담당자가 유지하고, AI는 관련 정보를 탐색하고 고객·거래·규제 정보를 연결해 STR 초안과 판단 근거를 준비하는 단계를 맡습니다.

클레어는 금융기관이 탐지 룰을 직접 구성하고 적용 전에 시뮬레이션하도록 지원합니다. 법령과 제재 정보를 근거로 STR 초안과 감사 기록을 연결하는 기능을 지속적으로 고도화하고 있습니다.

5. 디지털자산 사업 설계 단계에서 결정되는 AML 요건

온체인 AML을 가상자산사업자의 규제 대응으로만 보면 전통 금융기관에는 먼 과제로 읽힙니다.

스테이블코인 결제·정산, 법인의 디지털자산 활용, 크로스보더 결제를 검토하기 시작하면 상황이 달라집니다. 컴플라이언스가 기술 인프라와 붙어 있는 문제가 됩니다. 크로스보더 결제·정산에서의 AML 요건과 투명성 과제는 별도 아티클에서 상세히 다루고 있습니다.

기존 금융서비스는 고객과 계좌를 중심으로 거래를 관리했습니다. 디지털자산 환경에서는 여기에 지갑과 온체인 거래, 거래 상대방 정보가 더해집니다.

그래서 사업 검토 단계에서 AML 부서가 먼저 확인해야 하는 항목이 생깁니다. 기술 구조가 확정된 뒤에 요구하면 이미 바꾸기 어려운 결정들입니다.

• 개인과 법인의 지갑을 어떤 방식으로 식별할 것인가
• 거래 상대방의 위험을 어떤 기준으로 확인할 것인가
• 기존 KYC/KYB와 온체인 데이터를 어디에서 연결할 것인가
• 새로운 거래 유형의 탐지 룰은 누가 관리할 것인가
• 이상거래 발생 시 기존 AML 조직과 어떤 절차로 조사하고 보고할 것인가

컴플라이언스를 서비스 출시 이후의 규제 요건으로 두면 사업 속도를 늦추는 요소가 됩니다. 초기 단계에서 데이터와 통제 체계를 함께 설계하면 어떤 거래를 허용하고 어떤 거래를 추가로 확인할지 판단할 수 있는 사업 인프라가 됩니다.

다섯 과제가 가리키는 하나의 방향

금융기관마다 운영 중인 AML 시스템과 데이터 구조, 디지털자산 사업의 준비 단계가 다릅니다. 모든 기관에 동일하게 적용할 구축 방식은 없습니다.

다만 앞의 다섯 과제에는 공통점이 있습니다. 기존 AML과 온체인 데이터를 잇고, 고객과 계좌·지갑의 관계를 잇고, 탐지와 조사·STR을 잇고, AI의 결과와 판단 근거를 잇는 일입니다.

온체인 AML에서 결정적인 것은 기존 컴플라이언스 체계에 새로 등장한 데이터와 업무를 어디에서 연결하는가입니다.

기존 AML에서 온체인까지, 클레어가 제안하는 컴플라이언스 확장

두나무의 블록체인 기술 자회사 람다256이 운영하는 클레어는 국내 블록체인 업계 최초로 SOC 2 Type II 인증을 받았습니다. 여신금융협회, 케이뱅크, 케이에스넷 등이 도입했고, 글로벌 공공·수사기관 10곳 이상이 화이트라벨 형태로 활용하고 있습니다.

클레어는 기존 AML 시스템을 유지한 상태에서 온체인 데이터와 분석 결과를 연동하고, 분산된 컴플라이언스 정보를 하나의 업무 맥락에서 활용하도록 설계되었습니다.

도입 방식은 SaaS 구독형, API Turn-key, API 기능별 패키지, Investigation Add-on, On-Premise 구축형 다섯 가지로, 규모와 환경에 맞춰 선택할 수 있습니다.

디지털자산 규제 동향을 이메일로 받아보실 수 있습니다

온체인 AML 실무 자료와 규제 변화 정리를 정기적으로 보내드립니다.

2026 금융권 AX 리스크 & 컴플라이언스 컨퍼런스

• 발표: 2026년 8월 20일(목) 13:00 ~ 13:30
• 장소: 전국은행연합회 은행회관 2층 국제회의실
• 주제: 컴플라이언스 정보를 실행 가능한 AML 대응체계로: 온톨로지와 AI 에이전트 기반 혁신
• 현장 클레어 부스에서 온체인 자금 흐름 분석과 금융기관 AML 업무 연계 방식을 확인하실 수 있습니다.
• 사전등록: https://www.ddaily.co.kr/seminar/view?idx=376