SWIFT에서 Finternet까지, 국제 금융 인프라의 변화

금융 데이터를 빠르게 보내는 일과, 돈의 이전을 최종적으로 확정하는 일은 서로 다른 문제다.

국내에서는 계좌이체를 하면 몇 초 안에 상대방이 돈을 확인하는 경우가 많다. 그런데 해외송금에서는 수취까지 시간이 걸리고 중간 수수료나 환율 때문에 실제 도착 금액을 이해하기 어려울 때가 있다.

인터넷으로 정보는 즉시 전달되는데, 국경을 넘는 돈의 이동은 왜 복잡할까?

국제 금융에서는 메시지 전송 외에도 여러 기관의 장부 갱신, 통화 교환, 유동성 확보, 규제 확인이 연결돼야 한다. 시스템이 서로 연결돼 있다는 사실만으로 이 과정이 모두 동시에 끝나는 것은 아니다.

이번 글에서는 SWIFT와 기존 국제 금융의 구조를 살펴본 뒤, Finternet과 토큰화 기반 인프라가 무엇을 바꾸려는지 정리한다.

1. 메시지 vs 청산 vs 결제

해외송금을 이해하려면 ‘송금 처리’라는 표현 안에 여러 단계가 있다는 점부터 알아야 한다.

표는 개념을 단순화한 것이다. 실제 시스템에서는 일부 단계가 통합되거나 서로 다른 방식으로 구현된다.

특히 결제완결성은 화면에 ‘성공’이라고 표시하는 것보다 넓은 개념이다. 시스템의 규칙과 법적 기반까지 연결된다. 금융시장인프라 원칙도 명확한 결제완결성과 법적 근거를 중요하게 다룬다. CPMI-IOSCO 금융시장인프라 원칙

따라서 다음 상태는 구분해서 봐야 한다.

요청을 접수했다
      ↓
지급 메시지를 전달했다
      ↓
기관 간 의무가 결제됐다
      ↓
수취인이 자금을 이용할 수 있다

모든 거래가 정확히 이 순서로 진행되는 것은 아니지만 각 상태가 가리키는 대상은 다르다.

2. SWIFT는 국제 금융에서 어떤 역할을 할까?

SWIFT는 은행과 금융기관 등이 금융거래 관련 메시지를 안전하고 표준화된 방식으로 교환하는 네트워크다.

기존 SWIFT 메시징의 중심 역할은 지급 지시와 금융정보를 전달하는 것이다. SWIFT 공식 설명도 실제 자금 이전은 은행 등 관련 기관을 통해 이루어진다고 구분한다. SWIFT 공식 소개

가상의 예시로 표현하면 다음과 같다.

한국 기업
   ↓ 지급 요청
한국 은행
   ↓ 금융 메시지 교환
관련 금융기관
   ↓
해외 수취 은행
   ↓
해외 거래처

메시지가 전달되는 동안 관련 기관들은 각자의 계좌와 장부를 갱신하고 필요한 절차를 수행한다. 메시지 경로와 실제 결제 경로가 항상 단순한 일대일 관계인 것도 아니다.

SWIFT는 수취 은행에 지급이 도달한 시점과 최종 고객 계좌에 입금되는 시점 사이에서도 지연이 발생할 수 있다고 설명한다. 따라서 네트워크의 전달 속도와 사용자가 체감하는 전체 소요시간을 구분해야 한다. SWIFT의 지급 처리 설명

이후 살펴보겠지만 SWIFT도 기존 메시징에 더해 공유원장 기반 기능을 개발하고 있다.

3. 해외송금에서는 왜 여러 은행이 등장할까?

모든 은행이 세계의 모든 통화와 지급결제 시스템에 직접 참여하기는 어렵다.

그래서 다른 은행과 관계를 맺고 계좌와 서비스를 이용하는 환거래은행(Correspondent Banking) 구조를 활용한다.

예를 들어 한국 은행이 외국 은행에 보유한 외화 계좌를 통해 지급을 처리할 수 있다.

이때 자주 등장하는 용어가 다음과 같다.

같은 계좌를 어느 은행의 입장에서 보느냐에 따라 표현이 달라질 수 있다.

국경을 넘는 지급은 이런 계좌 관계와 각국의 지급결제 시스템을 조합해 처리된다. BIS도 환거래은행 구조에서 외환 교환, 사전 자금 확보, 시스템 간 상호운용성을 주요 과제로 설명한다. BIS: Payments without borders

유동성을 미리 준비하는 비용

은행이 필요한 통화의 지급을 처리하려면 사용할 수 있는 자금이 있어야 한다.

관련 계좌에 미리 잔액을 확보하면 지급 실패 가능성을 줄일 수 있지만 여러 곳에 자금이 묶이는 비용이 발생한다. 다른 은행이 신용을 제공하는 구조라면 그에 따른 위험도 고려해야 한다. BIS의 국경 간 유동성 설명

빠른 메시징만으로 해결하기 어려운 부분이다.

4. 국제 지급의 지연은 어디서 발생할까?

국제 지급에서는 여러 종류의 마찰이 겹친다.

연방준비제도의 국경 간 지급 설명도 통화, 시간대, 규제 차이와 환거래은행 관계, 유동성 문제를 주요 과제로 다룬다. Federal Reserve: Cross-Border Payments

여기서 IT 관점의 핵심은 여러 기관이 각자 관리하는 상태를 일관되게 맞추는 일이다.

한 기관에서는 처리가 끝났는데 다음 기관에서 정보가 부족할 수 있다. 지급 지시는 유효하지만 결제할 자금이 준비되지 않았을 수도 있다.

이 문제를 개선하는 방향은 다음처럼 나눌 수 있다.

• 기관들이 더 정확한 데이터를 교환하도록 한다.
• 기존 지급 시스템의 연결과 운영 방식을 개선한다.
• 여러 자산과 결제 단계를 함께 처리할 새로운 구조를 만든다.

ISO 20022, 지급 시스템 연계, 토큰화와 공유원장은 각각 이 중 일부를 다룬다.

5. ISO 20022는 금융 메시지의 공통 언어다

ISO 20022는 금융정보를 공통된 의미와 구조로 모델링하고 메시지를 정의하는 국제 표준 체계다.

단순히 파일 확장자를 바꾸는 작업으로 보기보다는, 금융기관이 교환하는 데이터의 의미를 맞추는 기반으로 이해하는 편이 좋다. ISO 20022 공식 FAQ

예를 들어 지급 관련 정보를 구분된 항목으로 다루면 다음 업무를 지원할 수 있다.

• 송금인과 수취인 정보 처리
• 지급 목적과 참조정보 연결
• 자동 대사
• 규제 확인과 예외 처리

하지만 형식이 같다고 데이터 품질까지 보장되지는 않는다. 같은 필드라도 입력 기준과 사용 규칙이 맞아야 한다.

SWIFT의 관련 전환에서는 2025년 11월 22일 CBPR+ 지급지시 메시지의 MT·ISO 20022 공존 기간이 종료됐다. 이를 모든 금융 메시지와 전 세계 시스템이 같은 날 일괄 전환됐다는 의미로 확대해서는 안 된다. SWIFT ISO 20022 구현 안내

이 표준의 역할은 정보를 더 잘 교환하도록 돕는 것이다. 그 자체가 결제 자산이나 새로운 지급 네트워크는 아니다.

6. Finternet은 무엇일까?

Finternet은 여러 금융 생태계를 인터넷처럼 상호 연결하자는 미래 금융 시스템의 비전이다.

Agustín Carstens와 Nandan Nilekani가 2024년 BIS 워킹페이퍼에서 제안했다. 특정 제품이나 이미 전 세계에서 운영되는 단일 네트워크의 이름으로 읽으면 부정확하다. Finternet 원문

구상의 중심에는 사용자가 금융기관과 자산 종류 사이의 장벽을 덜 느끼면서 금융서비스를 이용하도록 하자는 목표가 있다.

이를 위해 원문은 다음 기반을 함께 다룬다.

• 경제, 금융 구조
• 토큰화 등 디지털 기술
• 법률, 규제, 거버넌스
• 상호운용성, 검증 가능성, 보안과 개인정보 보호

즉, 기술적인 연결만으로 완성되는 구상이 아니다.

예를 들어 다른 기관에 있는 자산을 담보로 사용하면서 대출과 결제를 연계하려면, 데이터와 자산 이전뿐 아니라 권리의 유효성, 담보 집행, 참여기관의 책임도 정해져야 한다.

또한 해당 워킹페이퍼의 견해는 저자들의 것이며, BIS나 회원 중앙은행 전체의 공식 입장을 반드시 뜻하지는 않는다. BIS 워킹페이퍼 설명

7. 토큰화는 기존 디지털 장부와 무엇이 다를까?

은행 예금과 증권은 이미 전산 장부로 관리된다.

그렇다면 토큰화가 추가로 제공하려는 기능은 무엇일까?

BIS는 토큰화를 기존 장부에 있는 실물·금융자산에 대한 권리를 프로그래밍 가능한 플랫폼에 기록하는 과정으로 설명한다. 이를 통해 메시지, 대사, 자산 이전을 더 긴밀하게 결합하는 가능성을 제시한다. BIS: 차세대 통화·금융 시스템

예를 들어 증권 거래에서 다음 조건을 연계할 수 있다.

매수자의 지급 준비 확인
          +
매도자의 증권 이전 준비 확인
          ↓
연결된 조건을 충족하면 교환 실행

핵심은 자산을 표현한 데이터와 그 자산에 적용되는 처리 규칙을 같은 흐름으로 다룰 수 있다는 점이다.

다만 토큰을 발행했다는 사실만으로 현실의 권리가 새로 생기는 것은 아니다. 토큰이 어떤 청구권을 나타내며 누가 이행 책임을 지는지 정해져야 한다.

무엇이 토큰화됐는지도 중요하다

이름에 ‘토큰’이 붙었다고 같은 위험과 법적 성격을 갖는 것은 아니다.

8. 통합원장에서는 무엇을 통합하려는 걸까?

Unified Ledger·통합원장은 토큰화된 자금과 자산, 관련 거래 규칙을 함께 처리할 수 있도록 하는 구상이다.

관련된 상태 변경을 조정해 여러 기관의 순차적인 확인과 대사 부담을 줄이려는 목적이 있다.

하지만 ‘통합’이 반드시 전 세계가 하나의 데이터베이스를 공유한다는 뜻은 아니다.

BIS는 단일 원장부터 서로 연결된 원장까지 여러 구조를 설명하며, 프로그래밍 가능성과 결합 가능성, 데이터·거버넌스의 독립성 사이에서 선택이 필요하다고 본다. BIS: 통합원장 아키텍처

예를 들어 국가별 데이터 보관 요건이 다르면 모든 정보를 한곳에 모으기 어려울 수 있다. 여러 원장을 연결하면 각자의 통제는 유지하기 쉽지만, 원장 사이의 상태를 맞추는 작업이 복잡해진다.

따라서 “원장을 합치면 해결된다”보다 다음 질문이 먼저다.

어떤 상태를 함께 확정해야 하고, 어떤 정보와 통제는 분리해야 할까?

9. 원자적 결제는 무엇을 해결할까?

원자성·Atomicity는 연결된 작업을 모두 실행하거나, 모두 실행하지 않는 방식으로 다루는 성질이다.

외환 거래를 생각하면 의미가 분명해진다.

거래 당사자 A의 통화 지급
             ↕ 조건 연결
거래 당사자 B의 다른 통화 지급

한쪽 지급만 최종 완료되고 반대쪽 지급이 실패하는 위험을 줄이려면 두 이전을 연결해야 한다.

이와 관련된 대표 개념이 다음과 같다.

• PvP·Payment versus Payment: 서로 다른 통화의 지급을 연결
• DvP·Delivery versus Payment: 증권 등의 인도와 대금 지급을 연결

금융시장인프라 원칙도 연결된 의무의 최종 결제가 조건부로 함께 이루어지도록 하는 원칙을 다룬다. 이 접근은 기존 금융시장에서도 사용되며, 토큰화 플랫폼은 이를 구현·확장하는 방법을 연구한다. CPMI-IOSCO 금융시장인프라 원칙

원자성이 있더라도 유동성 부족, 잘못된 지시, 운영 장애까지 사라지는 것은 아니다. 어떤 작업 범위에 원자성을 적용했고, 외부 시스템과 법적 확정까지 어떻게 연결했는지 확인해야 한다.

10. 중앙은행 돈은 왜 계속 등장할까?

은행 계좌의 예금과 은행이 중앙은행에 보유한 준비금은 역할이 다르다.

은행 간 지급에서는 중앙은행 돈이 최종 결제의 기준 자산으로 중요한 역할을 한다. BIS와 중앙은행들의 공동 보고서도 기존의 이층 구조와 중앙은행 결제 자산이 통화에 대한 신뢰를 뒷받침한다고 설명한다. BIS: 기술혁신과 도매 중앙은행 돈

토큰화된 예금과 중앙은행 준비금을 함께 다루려는 프로젝트도 이 구조와 연결된다.

형태와 처리 방식은 바꾸되, 어떤 기관의 부채를 주고받으며 최종적으로 무엇으로 결제하는지 명확하게 하려는 것이다.

일반 사용자가 쓰는 소매형 CBDC와 금융기관 간 결제용 중앙은행 돈도 구분해야 한다. 도매 결제 실험이 곧 모든 국민을 위한 새 지갑 서비스의 도입을 뜻하지는 않는다.

11. 실제로 어디까지 진행됐을까?

Project Agorá: 다중통화 도매 지급 실험

Project Agorá는 BIS와 국제금융협회 IIF가 추진하는 민관 협력 프로젝트다.

토큰화된 상업은행 예금과 중앙은행 준비금을 공유된 프로그래밍 가능 플랫폼에서 결합해 국경 간 도매 지급을 개선할 수 있는지 살핀다.

공식 페이지에 따르면 2026년 7월 통제된 환경에서 실가치 테스트를 수행했다. 금융기관과 중앙은행 28곳이 참여했으며, 총거래 규모는 약 80만 스위스 프랑 상당이었다. 한국은행도 해당 테스트 참여 중앙은행에 포함된다. BIS Project Agorá

이는 실제 가치를 사용한 시험이라는 점에서 의미가 있다. 다만 제한된 참여자와 거래 시나리오에서 수행한 테스트이며, 일반 고객에게 개방된 전 세계 상용 서비스로 해석해서는 안 된다.

또한 24시간 처리를 지향하는 설계와 실제 테스트가 24시간 연속 운영을 입증했는지는 별개의 문제다.

SWIFT 공유원장: 기존 시스템과 연결하는 접근

SWIFT는 2026년 7월 9일, 블록체인 기반 공유원장이 초기 사용을 위한 준비를 마쳤다고 발표했다.

이 구조에서는 은행들이 자체 원장에 발행한 토큰화 예금을 조정하고, 최종 결제는 기존 시스템을 통해 완료하는 방식을 설명한다. SWIFT 공유원장 발표

이후 Standard Chartered와 HSBC도 해당 원장을 활용한 실거래를 발표했다. 설명에 따르면 두 은행 사이 의무를 기록·매칭·상계하고 기존 시스템에서 최종 결제를 수행했다. Standard Chartered 공식 발표

여기서는 공유원장에서 처리했다는 사실과 중앙은행 돈으로 최종 결제가 끝났다는 사실을 구분해야 한다.

Nexus: 기존 즉시지급 시스템을 연결하는 방향

모든 개선이 토큰화 원장을 필요로 하는 것은 아니다.

Project Nexus는 각국의 국내 즉시지급 시스템을 연결해 국경 간 지급을 지원하는 접근이다. BIS Project Nexus

현재 금융 인프라를 개선하는 길에는 메시지 표준화, 기존 시스템 연계, 공유원장 실험이 함께 존재한다.

12. SWIFT와 Finternet을 같은 종류로 비교하면 어려운 이유

지금까지의 내용을 나란히 두면 차이가 보인다.

따라서 “Finternet이 SWIFT를 대체하는가?”라는 질문만으로는 변화의 방향을 충분히 설명하기 어렵다.

SWIFT 같은 기존 참여자가 새로운 원장 기능을 추가할 수도 있고, 새로운 플랫폼이 기존 메시지 표준과 결제 시스템을 사용할 수도 있다.

앞으로 무엇이 바뀌는지는 어떤 업무가 어느 계층으로 이동하는지를 살펴봐야 알 수 있다.

13. 앞선 신원과 AML 주제는 어디에 연결될까?

금융 인프라가 빨라져도 거래 당사자와 권한, 위험을 확인하는 문제는 남는다.

이 표는 역할을 연결한 설명이다. 모든 프로젝트가 해당 기술을 필수로 사용한다는 뜻은 아니다.

새로운 플랫폼에서는 이런 확인을 거래 준비 단계와 연결하는 설계를 시도할 수 있다. Project Agorá도 규제 준수, 결제완결성, 개인정보 보호 같은 법적·운영적 문제를 함께 검토한다. BIS Project Agorá

확인 절차를 자동화하더라도 판단 근거와 책임이 없어지는 것은 아니다. 오히려 거래가 빨라질수록 실행 전 확인과 예외 처리의 중요성이 커진다.

14. 개발자는 어떤 질문으로 인프라를 평가해야 할까?

새로운 금융 기술을 볼 때 처리 속도와 원장 종류 외에도 확인할 항목이 있다.

다음은 시스템을 검토하기 위한 질문이다.

특히 하나의 SUCCESS 상태로 모든 결과를 표현하면 문제가 생기기 쉽다.

메시지 전송에 성공했지만 결제는 대기 중일 수 있다. 고객이 자금을 사용할 수 있어도 은행 간 최종 결제는 나중에 이루어지는 구조일 수 있다.

시스템의 상태 모델은 실제 금융상의 책임과 확정 시점을 반영해야 한다.

국제 금융 인프라의 변화는 정보를 보내는 속도와 함께 서로 다른 기관의 장부·자산·규칙을 얼마나 일관되게 연결하는지에서 평가할 수 있다. Finternet과 관련 실험을 읽을 때도 이 기준을 적용하면, 기술적 가능성과 실제 운영 성과를 구분하기 쉬워진다.

참고 자료

• SWIFT — Who We Are
• ISO 20022 — 공식 FAQ
• BIS — Finternet: The Financial System for the Future
• BIS — The Next-Generation Monetary and Financial System
• BIS — Project Agorá
• BIS — Project Nexus
• CPMI-IOSCO — 금융시장인프라 원칙

AML, KYC, CDD와 금융 범죄 방지의 구조

상대방이 누구인지 확인했다면, 그 사람이 하는 거래도 안전하다고 볼 수 있을까?

은행 앱에서 계좌를 개설하다 보면 여러 질문을 받는다.

직업은 무엇인지, 계좌를 어떤 목적으로 사용하는지, 거래자금은 어디에서 마련했는지 확인한다. 법인 계좌를 만들 때는 회사 정보뿐 아니라 실제 소유자와 거래 담당자의 권한을 묻기도 한다.

이미 신분증을 제출했는데 왜 이런 정보까지 필요한 걸까?

신원이 확인됐다는 사실과 금융거래의 위험이 충분히 파악됐다는 사실은 다르기 때문이다.

앞선 글에서는 개인의 디지털 신원과 기업의 LEI와 vLEI를 살펴봤다. 이번에는 확인한 신원정보가 금융 범죄 방지 과정에서 어떻게 활용되는지 알아본다.

국제 기준은 FATF 권고를, 한국 제도는 금융정보분석원과 관련 법령을 기준으로 설명한다. 금액 기준과 국내 제도 설명은 2026년 10월 22일 확인한 공식 자료를 바탕으로 한다.

1. AML은 금융 범죄 방지 체계의 한 부분이다

AML은 Anti-Money Laundering, 자금세탁방지를 뜻한다.

자금세탁은 일반적으로 불법적인 자금의 출처를 숨겨 합법적인 것처럼 보이게 만드는 과정이다. AML은 이를 예방하고 발견하기 위한 법률, 제도, 내부 통제와 업무 절차를 포함한다.

금융정보분석원도 자금세탁방지제도를 사법제도, 금융제도, 국제협력이 연결되는 종합적인 관리체계로 설명한다. 금융정보분석원: 자금세탁방지제도

함께 등장하는 용어도 구분해 두면 좋다.

이 업무들은 데이터를 공유하고 함께 운영될 수 있지만, 목적과 법적 판단 기준이 모두 같지는 않다.

FATF는 자금세탁, 테러자금조달, 대량살상무기 확산금융에 대응하는 국제 기준을 제시한다. 각국은 이를 자국의 법률과 제도에 맞게 이행한다. 따라서 FATF 문서의 설명과 특정 국가에서 직접 적용되는 의무를 구분해야 한다. FATF Recommendations

2. KYC, CDD, EDD는 어떻게 다를까?

처음 접하면 가장 헷갈리는 용어들이다.

KYC와 CDD의 경계는 자료나 조직마다 겹친다. 금융정보분석원도 고객확인제도를 고객알기정책이라고 설명한다. 두 용어가 언제나 엄격하게 분리된 별도 단계라고 이해할 필요는 없다. 금융정보분석원: 고객확인제도

실무에서는 KYC를 전체 정책이나 고객확인 업무의 이름으로, CDD를 구체적인 확인 의무와 절차를 설명하는 말로 사용하는 경우가 많다.

또한 KYB를 사용한다고 해서 법적 의무가 새로운 이름으로 대체되는 것은 아니다. 기업 고객에 대한 CDD를 설명하는 실무 용어로 읽는 편이 안전하다.

3. 고객확인은 무엇을 확인하는 과정일까?

신분증 확인은 중요한 출발점이다. 하지만 고객확인에는 그보다 넓은 내용이 포함된다.

FATF 권고 10의 핵심을 정리하면 다음과 같다.

1. 고객을 식별하고 신원을 검증한다.
2. 실제 소유자를 파악하고 신원을 검증하기 위한 합리적 조치를 취한다.
3. 거래 관계의 목적과 성격을 이해한다.
4. 거래 관계 동안 지속적으로 주의를 기울이고 거래를 살핀다.

즉, 고객에 대한 이해와 실제 거래를 연결하는 과정이다. FATF 권고 10

한국의 고객확인제도도 신원 확인과 검증, 실제 소유자 확인, 필요한 거래 목적과 자금 원천 확인 등을 다룬다. 실명확인만으로 고객확인이 모두 끝나는 구조는 아니다. 금융정보분석원: 고객확인 내용

가상의 기업 고객을 예로 들면 다음 질문들이 이어진다.

어느 회사인가?
      ↓
누가 회사를 지배하거나 통제하는가?
      ↓
신청자는 회사를 대신할 권한이 있는가?
      ↓
어떤 사업과 거래를 위해 서비스를 사용하는가?
      ↓
실제 거래가 이 설명과 부합하는가?

확인 항목과 증빙의 범위는 고객 유형, 상품, 위험, 적용 법령에 따라 달라진다.

4. 실제 소유자는 대표자와 다를 수 있다

실무에서 말하는 ‘실소유자’는 국내 제도에서 실제 소유자라고 표현한다. 영어로는 Beneficial Owner다.

중심 질문은 다음과 같다.

고객을 최종적으로 소유하거나 지배·통제하는 자연인은 누구인가?

법인 등기상 대표자나 계좌를 개설하러 온 담당자가 반드시 실제 소유자인 것은 아니다.

예를 들어 다음과 같은 구조를 생각할 수 있다.

자연인 A
   ↓
해외 지주회사 B
   ↓
국내 사업회사 C

고객이 C라고 해서 B의 회사 이름을 확인하는 것으로 모든 질문이 해결되지는 않는다. 적용 기준에 따라 상위 소유 및 통제 구조와 자연인을 파악해야 한다.

FATF는 정확하고 최신인 실제 소유자 정보에 접근할 수 있도록 여러 정보원을 결합하는 접근을 강조한다. FATF: 법인의 실제 소유자 지침

지분율만 계산하면 끝날까?

지분은 중요한 판단 근거지만 통제는 다른 방식으로도 발생할 수 있다. FATF 용어집도 소유를 통한 통제 외에 다른 수단을 통한 통제를 다룬다. FATF Glossary

한국 금융정보분석원의 일반 안내는 법인·단체의 경우 25% 이상 지분 소유자 확인을 출발점으로 하고, 확인이 어려운 경우 다른 지배 기준과 대표자 확인으로 이어지는 단계적 절차를 설명한다. 구체적인 적용과 예외는 관련 법령에 따라 확인해야 한다. 금융정보분석원: 실제 소유자 확인

어떤 국가의 지분 기준 하나를 전 세계 공통의 완전한 정의로 사용해서는 안 된다.

5. 위험기반접근법: 모두에게 같은 강도의 확인이 필요할까?

RBA·Risk-Based Approach, 위험기반접근법은 위험에 비례해 조치를 설계하는 접근이다.

고객, 상품, 거래 방식, 지역 등 관련 요소를 평가하고 필요한 확인과 모니터링의 강도를 정한다.

예를 들어 일상적인 국내 거래를 위한 개인 계좌와 복잡한 소유 구조를 가진 기업의 국제 거래는 살펴봐야 할 위험이 다를 수 있다. 이것만으로 어느 한쪽이 불법이라는 뜻은 아니다.

위험이 높으면 추가 정보와 검증, 더 강한 모니터링 등이 필요할 수 있다. 낮은 위험에서는 법과 제도가 허용하는 간소화 조치를 적용할 수 있다. FATF도 비례성과 저위험 영역의 간소화 조치를 강조한다. FATF 위험기반접근법 관련 개정 안내

EDD는 서류를 많이 받는 일일까?

추가 서류의 양보다 어떤 위험을 해소하려는지가 중요하다.

확인 목적에 따라 다음과 같은 조치를 고려할 수 있다.

• 사업과 거래 목적에 대한 추가 설명
• 자금이나 재산 형성 경위에 대한 확인
• 소유 및 통제 구조의 추가 검증
• 필요한 상위 책임자의 승인
• 모니터링 강도와 검토 주기 조정

‘서류를 받았다’와 ‘위험에 관한 의문이 해소됐다’는 다른 상태다.

6. 자금의 원천과 재산의 원천도 다르다

EDD 문서에서는 Source of Funds와 Source of Wealth가 자주 등장한다.

이번 입금이 다른 은행 계좌에서 왔다는 설명만으로 경제적인 자금 원천이 충분히 밝혀졌다고 볼 수는 없다. 어느 계좌에서 이동했는지와 어떤 활동으로 만들어진 돈인지는 서로 다른 질문이다.

FATF의 PEP 지침도 자금의 원천과 재산의 원천을 구분해 다룬다. 확인 범위와 검증 강도는 적용 요건과 위험에 맞춰 정해야 한다. FATF PEP Guidance

7. 제재 대상 확인과 PEP 확인은 같은 일이 아니다

고객 이름을 명단과 비교한다고 해서 모든 스크리닝이 동일한 판단을 하는 것은 아니다.

제재 스크리닝

적용되는 제재나 거래 제한의 대상인지 확인하는 업무다.

한국에서도 특정 개인, 법인, 단체를 금융거래 등에서 제한대상자로 지정하고 관련 거래를 제한하는 제도를 운영한다. 구체적인 제한과 허가 요건은 적용 제도에 따라 판단해야 한다. 금융정보분석원: 금융거래등 제한대상자

PEP 확인

PEP는 Politically Exposed Person, 주요 공적 직무를 맡았거나 맡은 사람 등을 가리킨다.

직무와 영향력이 악용될 가능성에 대응하는 예방적 조치의 대상이지, 범죄자 명단이라는 뜻은 아니다. FATF도 PEP라는 이유만으로 범죄에 연루됐다고 해석해서는 안 된다고 명시한다. 외국, 국내, 국제기구 PEP 등에 대한 구체적 조치도 구분된다. FATF PEP 안내

이름이 같으면 바로 같은 사람일까?

동명이인, 번역과 음역, 약칭 때문에 일치 후보가 생길 수 있다.

서비스에서는 생년월일, 식별정보, 소재지 등 사용 가능한 근거를 대조해 동일인 여부를 검토하도록 설계할 수 있다.

중요한 구분은 다음과 같다.

이름 유사성 발견
        ≠
동일인 확인
        ≠
적용되는 법적 조치 결정

이름 매칭 점수 하나에 최종 판단까지 맡기면 정상 고객에게 불필요한 피해를 줄 수 있다.

8. 거래 모니터링은 고객확인과 어떻게 연결될까?

고객확인으로 거래 목적과 사업을 이해했다면 이후 거래가 그 설명과 부합하는지 살펴볼 수 있다.

예를 들어 고객이 설명한 사업 규모나 거래 상대방과 실제 활동 사이에 큰 차이가 발견됐다고 하자. 시스템은 검토할 신호를 만들 수 있지만 그 차이만으로 범죄가 확정되지는 않는다.

바젤위원회 지침은 최신 CDD 정보와 고객 프로필을 활용해 위험 변화를 파악하고, 비정상 거래 경보를 추가 평가하도록 설명한다. 바젤위원회 AML/CFT 지침

이를 서비스 흐름으로 표현하면 다음과 같다.

고객정보 + 거래정보
         ↓
탐지 규칙, 분석 모델
         ↓
검토 경보 생성
         ↓
관련 정보와 고객 맥락 조사
         ↓
추가 확인, 위험 재평가, 보고 여부 판단

이 흐름은 설명용 예시다. 실제 처리 순서와 조치는 기관 및 법적 요건에 따라 달라진다.

특히 경보, 내부 조사 사건, 외부 보고를 구분해야 한다. 경보가 생성됐다는 이유만으로 자동으로 외부 보고나 거래 제한이 결정되는 것은 아니다.

9. STR과 CTR: 의심을 보고하는가, 현금거래 사실을 보고하는가?

한국 제도에서 자주 혼동하는 두 가지가 있다.

STR: 의심거래보고

금융정보분석원은 불법재산이나 자금세탁행위 등으로 의심되는 합당한 근거가 있는 경우 보고하는 제도로 설명한다.

보고 이후에는 KoFIU가 관련 정보를 종합 및 분석하고 필요한 경우 법집행기관에 정보를 제공하는 과정이 이어진다. 보고 자체와 수사, 기소, 유죄 판단은 다른 단계다. 금융정보분석원: STR

CTR: 고액현금거래보고

공식 안내에 따르면 한국에서는 동일 금융회사에서 동일인 명의로 1거래일 동안 1천만원 이상 현금이 입금되거나 출금되는 경우가 기본적인 보고 기준이다. 실제 적용에는 법령상 합산 방식과 예외 등을 함께 확인해야 한다. 금융정보분석원: CTR

여기서 ‘현금거래’라는 범위가 중요하다. 금융위원회는 이체나 송금이 CTR의 현금거래 대상과는 다르다고 설명한다. 금융위원회 CTR 설명

CTR 기준에 해당하지 않는 거래라도 별도의 의심 근거가 있다면 STR 검토 대상이 될 수 있다. 두 제도를 같은 금액 필터로 구현하면 안 되는 이유다.

10. 고객확인은 가입 이후에도 계속된다

계좌를 개설할 때 확인한 정보가 계속 정확하리라는 보장은 없다.

기업의 실제 소유자가 바뀔 수 있고 사업 내용이나 거래 목적이 달라질 수도 있다. 또 개인 고객의 거래 양상이 변화할 수도 있다.

따라서 서비스 설계에서는 보통 두 가지 갱신 경로를 함께 고려할 수 있다.

모든 고객에게 같은 주기를 적용해야 한다는 뜻은 아니다. 중요한 변화가 생기면 예정된 검토일 이전에도 대응할 수 있어야 한다.

한국에서는 정보 제공 거부 등으로 고객확인을 할 수 없는 경우 신규 거래 거절이나 기존 거래 종료, 의심거래보고 여부 검토에 관한 규정도 있다. 다만 일시적인 시스템 오류를 곧바로 고객의 정보 제공 거부와 동일하게 처리해서는 안 된다. 특정금융정보법 제5조의2

11. 디지털 신원과 LEI, vLEI는 어디에 도움이 될까?

앞선 두 편과 연결하면 역할이 명확해진다.

FATF의 디지털 신원 지침은 디지털 ID를 고객 식별하거나 검증에 사용할 때 기술, 운영체계, 보증 수준과 위험에 대한 적합성을 평가하도록 다룬다. 또한 지속적인 고객확인을 지원할 가능성도 설명한다. FATF Digital Identity Guidance

따라서 디지털 신원 증명에 성공했다는 이유만으로 고객확인 전체가 끝났다고 처리해서는 안 된다.

기업 식별정보와 역할 자격증명을 활용할 때도 실제 소유자 자료, 상태의 최신성, 거래 목적에 대한 판단을 연결해야 한다.

12. IT 시스템으로 구현하면 무엇이 중요할까?

다음은 AML 시스템을 이해하기 위한 개념적인 구성이다.

고객, 기업, 실제 소유자 정보
                ↓
       신원 검증 및 스크리닝
                ↓
          고객 위험평가
                ↓
     거래 모니터링과 정보 갱신
                ↓
        경보 검토, 사건 관리
                ↓
     필요한 조치, 보고, 증거 보관

운영에서는 이 흐름이 반복되며, 새 정보가 이전 판단을 바꿀 수도 있다.

판단 결과와 근거를 함께 남긴다

‘고위험’이라는 결과만 저장하면 나중에 설명하기 어렵다.

설계 시 다음 정보를 함께 관리하는 것을 고려할 수 있다.

• 평가에 사용한 정보와 확인 시점
• 규칙, 모델, 정책의 버전
• 경보와 판단을 연결하는 근거
• 검토자와 승인자
• 예외 처리 및 재검토 이력

외부 솔루션의 결과 해석

이름 매칭, 신원 검증, 위험평가를 외부 사업자에게 맡길 수 있다. 그래도 결과가 무엇을 의미하고 어떤 한계가 있는지 이해해야 한다.

바젤위원회도 은행이 제3자를 활용하더라도 고객확인과 AML/CFT 준수 책임은 은행에 남는다고 설명한다. 바젤위원회 제3자 활용 지침

AI는 검토를 돕되 근거를 만들어내지 않게

활용 예시로는 자료 추출, 동명이인 검토 보조, 사건 시간순 정리, 조사 문서 초안 작성 등을 생각할 수 있다.

이때 AI가 추론한 내용과 확인된 사실을 구분하고, 원문 자료로 돌아갈 수 있어야 한다. FATF의 신기술 보고서도 효율성뿐 아니라 설명가능성, 데이터 품질과 운영상의 위험을 함께 다룬다. FATF: AML/CFT 신기술의 기회와 과제

경보 수만으로 성과를 판단하지 않는다

많은 경보가 항상 좋은 탐지를 뜻하지는 않는다. 정상 거래를 지나치게 많이 경보로 만들면 검토 역량이 소진될 수 있다.

다음은 운영 지표의 예시다.

이 지표들은 함께 봐야 한다. 보고 건수 증가만으로 범죄 탐지 성과가 높아졌다고 단정할 수도 없다.

신원정보와 거래의 맥락

개인의 신원을 확인하면 누구인지에 대한 정보를 얻는다. 기업 신원을 확인하면 어느 법적 실체이며 담당자가 어떤 역할을 하는지 이해할 수 있다.

금융 범죄 방지에서는 그다음 질문이 이어진다.

이 고객은 왜 서비스를 사용하는가? 실제 거래가 설명과 부합하는가? 새로운 정보가 기존 판단을 바꿔야 하는가?

고객확인 정보는 이런 질문을 판단하기 위한 기준점이 된다. 거래 모니터링에서 발견한 변화는 다시 고객정보와 위험평가를 갱신하는 근거가 된다.

AML 시스템을 설계한다면 신분증 검사 결과를 저장하는 기능과 함께 정보, 위험, 거래, 검토 결과가 서로 갱신되는 구조를 살펴봐야 한다.

참고 자료

• 금융정보분석원 — 자금세탁방지제도
• 금융정보분석원 — 고객확인제도
• 금융정보분석원 — 의심거래보고
• 금융정보분석원 — 고액현금거래보고
• FATF — Recommendations
• FATF — Beneficial Ownership Guidance

금융권 생성형 AI와 AI 에이전트

한눈에 보기

• 핵심: 생성형 AI가 질문에 답하는 도구에서 벗어나, 여러 시스템과 도구를 사용해 업무를 계획하고 실행하는 AI 에이전트로 발전하고 있다.
• 금융권의 변화: 상담·문서 요약 같은 보조 업무를 넘어 신용분석, 상품 추천, 이상거래 조사, 내부통제 점검 등으로 활용 범위가 넓어지고 있다.
• 중요한 조건: 금융에서는 정확성, 개인정보보호, 설명 가능성, 접근권한과 최종 책임을 확보해야 실제 업무에 적용할 수 있다.

1. 핵심 개념

생성형 AI

대규모 데이터를 학습한 모델이 질문에 대한 답변, 보고서, 코드, 이미지 등 새로운 결과물을 생성하는 기술이다.

AI 에이전트

사용자의 목표를 받아 다음 행동을 계획하고, API·DB·검색·업무시스템 같은 도구를 호출하며, 결과를 확인해 후속 작업까지 수행하는 시스템이다.

사용자 목표
  → 업무 계획
  → 필요한 데이터 조회
  → 도구·시스템 실행
  → 결과 검증
  → 사용자 승인 또는 최종 처리

단순 챗봇과의 가장 큰 차이는 답변 생성에 그치지 않고 외부 시스템에서 행동을 수행한다는 점이다.

2. 주목받는 이유

1. 자연어로 복잡한 금융 업무를 처리해 직원 생산성과 고객 편의성을 높일 수 있다.
2. 여러 시스템에 흩어진 정보를 검색·요약해 의사결정 시간을 줄일 수 있다.
3. 반복적인 심사·보고·점검 업무를 자동화할 수 있다.
4. 금융당국의 규제 개선으로 실제 금융 서비스 적용 속도가 빨라지고 있다.

금융위원회는 2026년 4월 보안 위험이 낮은 단순 생성형 AI 모델 변경의 경우 혁신금융서비스 재지정 없이 서면확인으로 출시할 수 있도록 절차를 간소화했다. 이는 금융회사 내부 업무 효율화와 AI 기반 금융서비스 출시가 더 빨라질 수 있음을 의미한다.

3. 금융권 활용 사례

분야 활용 예시 기대 효과

AI가 대출 승인이나 송금 같은 중대한 결정을 완전히 단독 수행하기보다는, 위험도에 따라 사람의 승인과 검증을 포함하는 구조가 적절하다.

4. 핵심 기술

• RAG: 내부 규정·상품 설명서·공시 등 신뢰할 수 있는 문서를 검색한 후 답변 생성
• 도구 호출: API, 데이터베이스, 업무시스템을 AI가 정해진 방식으로 이용
• 에이전트 오케스트레이션: 계획, 실행, 검증 등 여러 단계와 역할을 관리
• 가드레일: 금지된 요청·개인정보·위험한 행동을 탐지하고 제한
• LLMOps: 모델 버전, 프롬프트, 품질, 비용, 지연시간과 오류를 지속 관리
• 평가 체계: 정확성, 근거성, 안전성, 편향, 보안과 업무 성과를 측정

5. 한계와 위험 요소

위험 설명 대응 방향

출처

• 금융위원회 — 생성형 AI 모델 변경 시 혁신금융서비스 절차 개선 (2026-04-15)
• NIST — AI Agent Standards Initiative (2026)
• NIST — AI 에이전트 보안 고려사항 분석 (2026-05-18)
• IBK기업은행 — 2025 연차보고서 및 2026 추진 방향