프로그래머블 컴플라이언스란? 정책 코드·규제 자동화부터 토큰화 금융 병목 제거까지 한 번에 정리


한 줄 요약

**프로그래머블 컴플라이언스(Programmable Compliance)**는 AML/CFT·제재·자본유출입 규제 같은 관할권별 규정 요건을 ‘기계가 읽을 수 있는 규칙’으로 변환해 거래 흐름에 내장하는 접근이다. BIS Project Mandala는 이를 “컴플라이언스 바이 디자인”으로 구현해, 국경 간 결제에서 가장 큰 병목인 규정준수 지연과 예외처리를 줄일 수 있는지 시험한다.




1) 왜 지금 컴플라이언스를 ‘코드’로 바꾸려 하나

국경 간 결제의 지연·비용은 종종 “결제 레일”보다 **규정준수 프로세스(제재 스크리닝, 자본규제, 문서 확인, 조사)**에서 발생한다. G20 크로스보더 결제 개선 프로그램에서도 데이터 표준화(ISO 20022)와 조화된 데이터 요구사항을 핵심 축으로 잡는 이유가 여기 있다.

핵심 논리

  • 규정준수는 “사후 점검”으로 두면 수동 보정·조사·반송이 늘어난다.
  • 규정준수를 “거래 설계에 포함”하면 처음부터 통과 가능한 거래만 흘리거나, 필요한 경우 즉시 보완·차단이 가능해진다.




2) 정의: 프로그래머블 컴플라이언스가 하는 일

프로그래머블 컴플라이언스는 크게 3단계를 포함한다.

  1. 정책·규정 요건의 구조화
  • 규정 문장을 “필수 데이터·조건·금지 조건” 형태로 정리
  1. 머신 리더블 규칙(정책 코드)로 변환
  • 특정 관할권의 규정(예: 제재 대상, 자본유출입 제한)을 공통 프로토콜에 실어 거래에 적용
  1. 거래 흐름에 내장된 준수 판단
  • 거래 생성/전송 단계에서 실시간 준수 여부를 평가하고, 필요한 경우 규제기관에 모니터링 신호 제공




3) Project Mandala가 보여준 구조: 컴플라이언스 바이 디자인

BIS는 Mandala가 관할권별 규정(제재 스크리닝, 자본흐름관리 등)을 시스템에 인코딩해, 금융기관의 크로스보더 컴플라이언스를 간소화할 수 있는지 탐구한다고 명시한다.

Mandala의 포인트 3가지

  • **기존 규제 프레임을 ‘대체’하지 않고 ‘그대로 인코딩’**한다
    → 제도권 확장 가능성을 높이는 접근
  • 실시간 모니터링 가능성
    → 규제기관/중앙은행 입장에서 “사후 보고”가 아닌 “상시 가시성” 방향
  • 공통 프로토콜로 관할권 차이를 흡수하려는 시도
    → 국경 간 결제의 조각난 규칙을 “기계가 처리 가능한 형태로 정렬”




4) 데이터 표준과의 결합: ISO 20022가 깔려야 자동화가 돈이 된다

규정준수 자동화는 결국 데이터 품질 게임이다. CPMI의 “조화된 ISO 20022 데이터 요구사항”은 국가·기관별 상이한 데이터 요구를 맞춰 직접처리율(STP) 개선과 비용 절감을 추진하는 문서다.

즉,

  • ISO 20022로 데이터 구조를 맞추고,
  • Mandala처럼 규정 준수 규칙을 코드화하면,
  • 결제·정산 레일을 바꾸지 않아도 병목이 줄어드는 구간이 생긴다.




5) 개인정보·프라이버시 쟁점: “많이 수집”이 아니라 “필요 최소 + 증명”으로 간다

프로그래머블 컴플라이언스는 규정준수를 강화하지만, 동시에 개인정보·데이터 보호와 충돌할 수 있다. 그래서 방향성은 보통 다음 중 하나로 수렴한다.

  • 필요 최소 데이터만 전송
  • 검증 가능한 증명(예: 특정 요건 충족 여부) 중심
  • 규제기관에 제공되는 데이터는 목적 제한·접근 통제가 필수

이 흐름은 결제 투명성을 강화하려는 FATF의 결제 투명성(Recommendation 16) 개정 취지와도 맞물린다. FATF는 2025년 6월 개정에서 국경 간 결제에 동반되는 정보 투명성 강화와 사기·오류 방지 수단 도입을 강조했다.




6) 시장 구조 영향: 무엇이 달라지나

변화 A. ‘결제 속도’보다 ‘컴플라이언스 SLA’가 먼저 개선된다

Agorá는 도매 크로스보더 결제에서 통합 원장 + 토큰화 + 스마트컨트랙트를 통해 코레스폰던트 모델을 개선하려는 프로젝트다. 여기서도 사실상 병목은 “규정준수 지연”과 운영시간 차이 같은 현실 제약이다.

변화 B. 레그테크·데이터·규정 코드화가 핵심 가치사슬로 부상

  • 규정 문서 → 정책 코드 변환
  • 관할권별 규칙 버전 관리
  • 감사 가능성(누가 어떤 규칙으로 어떤 거래를 통과시켰는지)
    이 영역이 “토큰화 테마”보다 훨씬 실용적인 인프라 수요로 연결될 수 있다.

변화 C. 리스크도 ‘신용’보다 ‘코드/거버넌스’로 이동

규정 준수가 코드로 내장되면, 리스크는 다음으로 이동한다.

  • 규칙 업데이트 오류(정책 변경 반영 지연)
  • 스마트컨트랙트/정책 코드 버그
  • 접근권한·감사권한의 거버넌스 리스크
    Mandala가 “기존 프레임 유지”를 강조하는 것도 이런 리스크를 제도권 방식으로 관리하려는 의도와 연결된다.




7) 개인 투자자 실전 대응: 조건부 시나리오

  • 만약 Mandala류가 확산되면
    → (해석) ‘결제 레일 교체’보다 규정준수 자동화로 처리율이 올라가는 방향이 먼저 체감될 수 있다.
    → (대응) 토큰화 테마 추격보다 레그테크·데이터 인프라·감사/보안 관점으로 관찰 축 이동
  • 만약 결제 투명성 규제가 강화되면
    → (해석) “데이터 동반”이 강화되고, 표준·신원·검증 체계가 더 중요해진다.
    → (대응) 익명성 서사보다 합법적 상호운용(표준/신원/컴플라이언스) 서사에 무게를 두는 편이 안정적
  • 만약 통합 원장 실험(Agorá)이 진전되면
    → (해석) 코레스폰던트 모델이 ‘대체’보다 토큰화·정책 코드·원자적 정산으로 업그레이드되는 경로가 강해질 수 있다.
    → (대응) “누가 채택했는지(기관/통화/범위)”와 “운영 범위 확대”가 핵심 신호




8) 실행 체크리스트

  1. ‘테마’가 아니라 ‘채택’과 ‘운영 KPI’로 관찰하고 있는가?
  2. 규정 준수 병목이 “결제망”이 아니라 “컴플라이언스 프로세스”인지 분리했는가?
  3. 데이터 표준(ISO 20022, 조화된 데이터 요구사항) 위에서 자동화가 돌아가는지 확인했는가?
  4. 정책 코드가 관할권별로 어떻게 버전 관리되는지(업데이트/감사) 확인했는가?
  5. 프라이버시 설계가 “최소 제공 + 증명” 구조인지 확인했는가?
  6. 규정 준수가 실시간 모니터링으로 확장되는지(규제기관 관점) 확인했는가?
  7. 실패 시 처리(오탐/누락/분쟁)와 책임 소재가 문서화돼 있는가?

댓글 남기기