작성자: Agata Wojtas, Digital Colliers 최고 상업 책임자 (Chief Commercial Officer)

귀하의 AML (자금세탁방지) 등급은 사실 귀하의 통제(controls)에 대한 등급이 아닙니다. 그것은 18개월 전에 발생한 거래에 대해, 당시 존재했던 고객 기록과 당시 존재했던 제재 목록(sanctions list)을 사용하여 질문에 답하고, 왜 경고(alert)가 발생했는지 또는 발생하지 않았는지를 재구성할 수 있는지에 대한 등급입니다. 만약 귀하의 데이터 모델(data model)이 이를 깔끔하게 수행할 수 없다면, 아무리 많은 정책 문서도 귀하를 구원할 수 없습니다.

중견 은행과 결제 기업에서 제가 계속해서 보고 있는 패턴은 동일합니다. 컴플라이언스(Compliance) 리더들은 통제 강화(controls uplift)를 쫓습니다. 감사 결과(Audit findings)는 계속해서 동일한 취약점에 도달합니다. 회의실에 있는 그 누구도 속마음을 말하지 않는데, 그것은 바로 근본적인 데이터 모델(data model)이 규제 재구성(regulatory reconstruction)이 아닌 운영 보고(operational reporting)를 위해 구축되었다는 사실입니다.

아무도 대비하지 않는 감사 질문 패턴

규제 기관과 외부 감사인은 귀하에게 정책이 있는지 묻지 않습니다. 그들은 특정 날짜에 특정 사건이 발생했는지 또는 발생하지 않았는지를 증명하라고 요구합니다. 질문들은 다음과 같은 형태로 모입니다:

• 이 두 날짜 사이에 이 고객에 대해 생성된 모든 경고(alert)와 각 경고의 처리 결과(disposition)를 보여주십시오.

• 이 거래가 승인된 날 기준으로 고객 위험 점수(customer risk score)가 어떠했는지 재구성하십시오.

• 이 날짜의 14:07 UTC에 귀하의 스크리닝 엔진(screening engine)은 제재 목록(sanctions list)의 어떤 버전을 사용하고 있었습니까.

• 2주 전의 유사한 거래는 에스컬레이션(escalated)되었는데, 왜 이 거래는 그렇지 않았습니까.

이 모든 질문은 아마도 그런 방식으로 결합되도록 설계되지 않았을 시스템들 간의 시점 조인(point-in-time join)입니다. 만약 귀하의 팀이 CSV로 내보내고 스프레드시트에서 대조(reconciling)하고 있다면, 귀하는 감사인에게 방향은 맞지만 포렌식(forensically) 관점에서는 틀린 답변을 제공하게 될 것입니다. 그것이 바로 등급이 하락하는 방식입니다.

통제 중심 접근 방식이 진짜 문제를 놓치는 이유

낮은 등급을 받은 후 제가 보는 대부분의 시정 프로그램(remediation programs)은 곧바로 통제 계층(controls layer)으로 향합니다. 새로운 튜닝 임계값(tuning thresholds). 더 많은 유형 규칙(typology rules). 두 번째 방어선(second-line)의 QA 샘플 규모 확대. 이 모든 것은 방어 가능하지만, 근본 원인(root cause)을 해결하는 것은 아무것도 없습니다.

근본 원인은 대개 트랜잭션 모니터링 (transaction monitoring)이 적절한 유효 날짜 (effective-dating)를 가진 서서히 변하는 차원 (SCD, slowly-changing dimensions)으로 모델링되지 않고, 분석가가 쿼리 시점에 고객, 거래 상대방, 상품 및 스크리닝 이력을 조인 (join)해야 하는 데이터 모델 위에서 실행되고 있다는 점입니다. 일반적인 중견 은행의 AML 트랜잭션 모니터링에서 오탐률 (false-positive rates)은 이미 85~95%에 달합니다. 분석가들이 노이즈에 휩쓸리고 과거 이력을 깔끔하게 재구성할 수도 없을 때, 경고 (alert)의 품질은 감사 (audit)에서 발견될 방식으로 저하됩니다.

통제 장치 (controls)가 잘못된 것이 아닙니다. 그것들이 모래 위에 세워져 있을 뿐입니다.

제대로 된 데이터 모델의 모습

규제 수준의 재구성 (regulatory-grade reconstruction)을 위해 시스템을 재구축하고 있다면, 몇 가지 타협할 수 없는 사항들이 있습니다. 이는 생소한 것이 아닙니다. 그저 운영 스택 (operational stack)이 보통 생략해 왔던 규율일 뿐입니다.

• 모든 차원 (dimension)은 이중 시간적 버전 관리 (bi-temporally versioned)가 되어야 합니다. 사실 (fact)이 실제 세계에서 언제 유효했는지와 시스템이 이를 언제 인지했는지 두 가지를 모두 저장해야 합니다. 이 둘은 서로 다르며, 감사는 두 가지 모두를 중요하게 여깁니다.

• 제재 (sanctions) 및 PEP (정치적 주요 인물) 리스트는 현재 상태뿐만 아니라 정확한 벤더 페이로드 (vendor payload)가 영구 저장되는 일급 데이터 자산 (first-class data assets)으로 버전 관리되어야 합니다.

• 경고 결과 (alert outcomes)는 모델 버전, 설정된 임계값 (threshold), 참조 데이터 스냅샷 ID (reference data snapshot IDs)를 포함하여 결정 시점의 전체 피처 벡터 (feature vector)를 보유해야 합니다.

• 고객 위험 점수 (customer risk scores)는 이벤트 소싱 (event-sourced) 방식이어야 합니다. 현재 데이터로부터 다시 계산하지 않고도 특정 날짜의 점수를 재생 (replay)할 수 있어야 합니다.

테스트는 간단합니다. 14개월 전의 트랜잭션을 하나 골라보세요. 엔지니어가 누구에게도 묻지 않고, 해당 트랜잭션이 승인되었을 당시 모니터링 시스템이 보았던 세상의 완전한 상태를 만들어낼 수 있습니까? 만약 대답이 '아니오'라면, 감사는 결국 그 사실을 찾아낼 것입니다.

시점 조인 (point-in-time joins) 문제

이것은 명명할 가치가 있는 구체적인 실패 모드 (failure mode)입니다. 팀이 감사 질문에 답하기 위해 수동으로 SQL을 실행할 때, 그들은 거의 항상 현재의 차원 테이블 (dimension tables)을 과거의 사실 테이블 (fact tables)과 조인합니다. 겉보기에는 맞게 보이지만, 실제로는 조용히 잘못된 것입니다. 거래가 승인되었을 당시 적용되었던 위험 등급이 아니라, 고객의 현재 위험 등급을 얻게 됩니다. 스크리닝 (screening) 당시 기록되어 있던 실소유자 정보가 아니라, 오늘날의 실소유자 정보를 얻게 되는 것입니다.

해결책은 절차적인 것이 아니라 아키텍처적인 것입니다. 시점 조인 (As-of joins), 유효 날짜가 지정된 차원 (effective-dated dimensions), 그리고 참조 데이터 스냅샷 (reference data snapshots)이 데이터 팀에 특별히 요청하는 부탁이 아닌, 기본 쿼리 패턴 (default query pattern)이 되어야 합니다.

금융 서비스에 대한 규제 범위가 계속해서 넓어지고 있기 때문에 이는 현재 더욱 중요합니다. DORA는 2025년 1월부터 시행되었으며 데이터 계보 (data lineage)와 운영 탄력성 (operational resilience) 증거를 강력하게 요구합니다. 자동화된 의사 결정 (automated decisioning)에 대한 GDPR 노출 위험은 2023년 말 SCHUFA 판결 이후 실질적인 문제가 되었습니다. GDPR 위반에 대한 과징금은 최대 2,000만 유로 또는 전 세계 매출액의 4%에 달합니다. 이 위기를 잘 헤쳐 나가는 팀은 감사가 끝난 후가 아니라, 감사 전에 데이터를 수정해 둔 팀들입니다.

출처 (Sources)

• ACAMS

• European Commission

• Court of Justice of the European Union

이 기사는 원래 Digital Colliers Blog에 게시되었습니다. Digital Colliers는 DACH 및 영국 기업들이 AI를 구현하도록 지원합니다 — 당사의 AI 컨설팅 서비스를 확인하거나 문의하기를 이용해 주세요.