FRM Part I – Reading 7
효과적인 데이터 집계와 리스크 보고를 위한 원칙
(Principles for Effective Data Aggregation and Risk Reporting)
EXAM FOCUS
핵심 학습 목표
이 Reading은 바젤은행감독위원회(BCBS)의 효과적인 리스크 데이터 집계(Risk Data Aggregation)와 리스크 보고(Risk Reporting)를 위한 원칙을 탐구하는 매우 정성적인(Highly Qualitative) 리딩입니다. 이 리딩의 대부분은 데이터가 정확(Accurate), 완전(Complete), 적시적(Timely), 포괄적(Comprehensive), 적응 가능(Adaptable)해야 한다는 실무적 관점입니다. 거버넌스 원칙이 중요하며, 위원회는 리스크 데이터 집계와 보고가 비용이 많이 들기 때문에 최고경영진과 이사회가 이 프로세스에 완전히 투입(Fully Invested)되어 적절한 자원이 할당되어야 한다고 강조합니다.
시험에서 반드시 할 수 있어야 하는 것
- 효과적인 리스크 데이터 집계와 보고의 잠재적 이점 설명 (LO 7.a)
- 강력한 집계/보고 프로세스 구현의 도전 과제와 저품질 데이터의 잠재적 영향 설명 (LO 7.b)
- 리스크 데이터 집계와 보고에 관련된 핵심 거버넌스 원칙 설명 (LO 7.c)
- 효과적인 데이터 아키텍처, IT 인프라, 리스크 보고 관행의 특성 설명 (LO 7.d)
- 데이터 집계 원칙들(3~6)이 어떻게 상호작용하는지 이해하고, 한 원칙을 다른 원칙보다 우선시하지 말아야 한다는 점 파악
- 효과적인 리스크 보고의 5대 원칙(7~11): 정확성, 포괄성, 명확성/유용성, 빈도, 배포의 요건 이해
- BCBS 239의 14개 원칙 전체 구조와 각 원칙의 핵심 요구사항 파악
배경: 왜 이 리딩이 존재하는가?
리스크를 보려면, 데이터가 먼저다
은행의 리스크관리(Risk Management)는 겉으로는 VaR, 스트레스 테스트, 한도관리, 자본적정성 같은 '모델과 숫자'로 보이지만, 실제로는 그 모든 숫자가 데이터에서 나옵니다. 2007~2009 글로벌 금융위기 때 많은 은행이 무너진 이유 중 하나가 "리스크를 몰라서"가 아니라, 더 정확히는 다음과 같은 구조적 문제 때문이었습니다.
금융위기 당시 드러난 데이터 실패의 본질
| 문제 | 설명 |
|---|---|
| 데이터 사일로(Silo) | 리스크가 부서별/시스템별로 흩어져 있어 은행 전체 관점에서 볼 수 없었음 |
| 표준 부재 | 같은 고객/거래를 다른 방식으로 기록 (부서마다 다른 식별코드 사용) |
| 집계 불가 | 위기 상황에서 빠르게 합쳐서 볼 수 없었음 |
| 집중위험 미발견 | '은행 전체 관점에서' 위험 집중(Concentration)을 제때 발견하지 못함 |
이러한 교훈을 바탕으로 바젤은행감독위원회(BCBS)는 "리스크관리의 출발점은 리스크 데이터의 집계(Risk Data Aggregation)와 리스크 보고(Risk Reporting) 능력"이라고 선언하고, 이를 체계화한 BCBS 239(14개 원칙)를 발표했습니다.
MODULE 7.1: 데이터 품질, 거버넌스, 인프라
LO 7.a: 효과적인 리스크 데이터 집계와 보고의 잠재적 이점
1. 리스크 데이터 집계(Risk Data Aggregation)의 정의
바젤은행감독위원회에 따르면, 리스크 데이터 집계란 "은행이 리스크 허용범위/선호도(Risk Tolerance/Appetite) 대비 성과를 측정할 수 있도록, 은행의 리스크 보고 요구사항에 따라 리스크 데이터를 정의하고(Defining), 수집하고(Gathering), 가공하는(Processing) 것"을 의미합니다. 집계 과정에는 데이터와 데이터셋의 분해(Breaking Down), 정렬(Sorting), 병합(Merging)이 포함됩니다.
리스크 데이터 집계는 데이터베이스에 저장된 값을 한 파일로 모으는 행위가 아닙니다. 이는 은행이 자기 위험을 '한 화면에서' 보게 만드는 데이터 공급망(파이프라인)입니다.
| 단계 | 내용 |
|---|---|
| 정의(Define) | 어떤 리스크를 어떤 기준으로 측정/보고할지 결정 (국가별? 상품군별? 법인별?) |
| 수집(Gather) | 프론트(트레이딩), 크레딧(여신), 재무(회계), 리스크(모델) 시스템에서 필요한 데이터를 추출 |
| 가공/처리(Process) | 데이터가 서로 맞물리도록 정렬/정제/매핑/병합. 쪼개기, 정렬, 합치기, 중복 제거, 정합성 체크, 누락 보정 등 포함 |
2. 효과적인 리스크 데이터 집계와 보고의 4대 이점
효과적인 리스크 데이터 집계와 보고 시스템을 갖춘 은행에는 여러 이점이 발생합니다.
| 이점 | 영문 | 상세 설명 |
| 1. 문제 예측 능력 향상 | Increased Ability to Anticipate Problems | 집계된 데이터는 리스크 관리자가 위험을 전체적(Holistically)으로 이해할 수 있게 합니다. 위험을 개별적으로가 아니라 전체적으로 볼 때 지평선 위의 문제를 더 쉽게 발견할 수 있습니다. 예를 들어, 부서별로 보면 각각 "괜찮아 보이는" 한 기업 A에 대한 노출이 실제로는 여신/트레이딩/외환파생 부서를 합치면 470억 원의 집중위험일 수 있으며, 집계가 안 되면 아무도 이를 발견하지 못합니다. |
| 2. 위기 시 회복 경로 식별 | Identify Routes to Return to Financial Health | 금융 스트레스 시기에 효과적인 리스크 데이터 집계는 은행이 재무 건전성을 회복할 대안적 경로를 식별하는 능력을 향상시킵니다. 예를 들어, 은행이 은행의 재무 생존가능성을 회복하기 위해 적합한 합병 파트너를 더 잘 식별할 수 있습니다. 어느 국가/섹터에 노출이 과도한지, 어떤 사업부가 손실을 만드는지, 어떤 포지션을 줄이면 유동성이 얼마나 확보되는지가 빨리 나와야 살아남을 확률이 올라갑니다. |
| 3. 정리가능성 향상 | Improved Resolvability | 은행 스트레스 또는 실패 시, 규제당국은 은행의 건전성과 생존가능성에 관한 문제를 해결하기 위해 집계된 리스크 데이터에 접근할 수 있어야 합니다. 이는 특히 글로벌 시스템적으로 중요한 은행(G-SIBs)에게 중요합니다. 집계된 데이터는 당국이 은행을 "질서 있게 정리"하거나 "구제/인수합병"을 판단하는 핵심 재료가 됩니다. |
| 4. 전략적 의사결정 강화 | Strategic Decisions, Efficiency, Profitability | 은행의 리스크 기능을 강화함으로써, 은행은 전략적 의사결정을 더 잘 내리고, 효율성을 높이고, 손실 가능성을 줄이며, 궁극적으로 수익성을 증가시킬 수 있습니다. 자본을 어디에 배분할지, 어떤 상품을 키울지, 어떤 고객을 줄일지에 대한 의사결정이 빨라집니다. |
문제에서 은행이 현재 재정적 스트레스 상태라면, 가장 직접적(Direct)인 이점은 "효율성 증가"나 "IT 인프라 개선"이 아니라 "문제의 정리가능성 향상(Improved Resolvability)"입니다. 이점의 우선순위는 은행의 현재 상황에 맞춰 판단해야 합니다.
LO 7.b: 구현의 도전 과제와 저품질 데이터의 영향
3. 모델 리스크(Model Risk)와 데이터의 관계
금융기관은 리스크 익스포저 분석에서 일상 운영 지침에 이르기까지 모든 것에 모델을 사용합니다. 모델 개발 과정에서 발생하는 작은 오류조차도 은행에 심각한 결과를 초래할 수 있습니다. 모델은 데이터에 의존하므로, 데이터 획득은 모델 리스크, 특히 입력 리스크(Input Risk)의 중요한 구성요소입니다.
| 유형 | 영문 | 설명 |
|---|---|---|
| 입력 리스크 | Input Risk | 모델에 투입되는 데이터의 품질/정확성에서 발생하는 위험. 데이터 집계와 직접 연결 |
| 추정 리스크 | Estimation Risk | 모델 매개변수 추정에서 발생하는 위험 |
| 평가 리스크 | Valuation Risk | 자산/부채의 가치 평가 과정에서 발생하는 위험 |
| 헤지 리스크 | Hedging Risk | 헤지 전략 실행에서 발생하는 위험 |
모델 개발자는 모델 개발에 사용된 데이터가 모델의 이론과 방법론에 일치(Consistent)함을 입증해야 합니다. 모델은 검토(Vetted)되고 검증(Validated)되어야 합니다.
4. 은행 데이터가 구조적으로 엉망이 되기 쉬운 이유
역사적으로 은행의 데이터 수집 노력은 분절적(Disjointed)이었으며, 수집이 부서 또는 사업 기능 수준에서 이루어졌습니다. 데이터는 서로 다른 출처에서 중복되고, 방치되고 파괴되었습니다(예: 컴퓨터 시스템 변경). 컴퓨터 카드와 테이프에서 플로피 디스크와 드라이브로 — 모든 것이 사용되었지만, 한 세대의 저장 장치가 다음 세대와 호환되지 않았습니다.
표준화 부재의 실제 영향
표준(Standards)은 부서 간에 일관되어야 합니다. 데이터가 표준화되지 않으면 은행은 자신의 진정한 리스크를 이해하지 못할 수 있습니다.
예를 들어, 부서 간에 고객에 대한 식별 코드가 다르다면, 은행은 자동차 대출, 주택담보 대출, 신용카드를 보유한 고객에 대한 진정한 익스포저를 인식하지 못할 수 있습니다. 자동차 대출부서에서는 고객ID=123, 카드부서에서는 A-55, 주택담보부서에서는 000123으로 관리하면 "한 고객에 대한 총노출"이 자동으로 잡히지 않습니다.
5. BCBS 239의 탄생 배경
이러한 인식된 약점에 대응하여, BCBS의 특별 소위원회가 은행이 데이터를 수집, 저장, 분석하는 방식을 검토하기 위해 구성되었습니다. 위원회는 리스크 관리에 관한 특별 보고서에서 데이터 품질이 은행의 사업 라인 전반에 걸쳐 리스크 익스포저를 집계하고 보고하기에 부적절하다고 결론지었습니다. 그 결과 위원회는 은행이 데이터 집계 및 보고 프로세스를 전면 개편하도록 돕기 위한 14개 원칙 세트(BCBS 239)를 발표했습니다.
목표: 은행이 리스크 허용범위 대비 성과를 더 잘 측정할 수 있도록 하는 것
적용 범위: 모델 개발에 사용되는 데이터에 적용되며, 모델 리스크 관리에 관련됨
조직적 영향: BCBS 239의 결과로, 은행에는 이러한 리스크를 관리하는 최고데이터책임자(CDO, Chief Data Officer)가 더 많아졌습니다.
6. 저품질 데이터의 2차 피해
데이터 품질이 낮으면 단지 숫자가 틀리는 것에 그치지 않습니다. 보고서가 신뢰를 잃고, 리스크팀이 매번 설명과 변명에 시간을 소비하며, 중요한 의사결정이 지연되고, 위기 때는 "오늘 숫자 vs 내일 숫자"가 달라져 혼란이 커집니다. 금융위기 이전에 잘못되거나 사기성 모기지 신청이 하나씩 들어오면서 시스템에 결함 데이터를 도입했으며, 대출 신청이 하나씩 들어왔지만 궁극적 실패는 모든 사기성 신청에 기반한 글로벌 수준의 실패였습니다.
LO 7.c / LO 7.d: 거버넌스 원칙과 데이터 아키텍처
7. BCBS 239의 전체 구조: 14개 원칙 개관
BCBS 239의 핵심 메시지는 매우 현실적입니다: "데이터 집계/보고는 비싸다. 그래서 최고경영진과 이사회가 진짜로 밀어줘야 한다."
| 구분 | 원칙 번호 | 원칙명 | 핵심 초점 |
| 기반(Foundation) | 원칙 1 | 거버넌스 (Governance) | 책임, 승인, 자원, 감독 |
| 원칙 2 | 데이터 아키텍처 및 인프라 | 설계, 구축, 메타데이터, 명명규칙 | |
| 데이터 집계 (Aggregation) | 원칙 3 | 정확성과 무결성 (Accuracy & Integrity) | 자동화, 단일 소스, 수동 우회 관리 |
| 원칙 4 | 완전성 (Completeness) | 온/오프밸런스, 다차원 분류 | |
| 원칙 5 | 적시성 (Timeliness) | 리스크 성격에 맞는 속도, 위기 시 빠른 생산 | |
| 원칙 6 | 적응성 (Adaptability) | 유연성, 맞춤형, 임시 요청 대응 | |
| 리스크 보고 (Reporting) | 원칙 7 | 보고의 정확성 (Accuracy) | 합리성 점검, 에러 리포트, 중요성 기준 |
| 원칙 8 | 포괄성 (Comprehensiveness) | 전방위 리스크 커버, 전망적 정보 포함 | |
| 원칙 9 | 명확성과 유용성 (Clarity & Usefulness) | 수신자별 맞춤, 정성적 해석 포함 | |
| 원칙 10 | 빈도 (Frequency) | 수신자/리스크 유형에 따른 빈도 조정 | |
| 원칙 11 | 배포 (Distribution) | 적시 배포, 기밀성 유지 |
8. 원칙 1: 거버넌스 (Governance)
위원회에 따르면, "은행의 리스크 데이터 집계 능력과 리스크 보고 관행은 바젤위원회가 수립한 다른 원칙 및 지침과 일관된 강력한 거버넌스 체계(Strong Governance Arrangements)의 적용을 받아야 한다."
거버넌스 원칙은 리스크 데이터 집계가 은행의 전체 리스크관리 프레임워크의 일부가 되어야 한다고 제안합니다. 적절한 자원이 데이터 집계와 보고에 투입되도록 보장하기 위해, 최고경영진이 구현 전에 프레임워크를 승인해야 합니다.
| 요건 | 상세 설명 |
|---|---|
| 완전한 문서화 | "왜 이렇게 집계하는가"가 기록으로 남아야 함 |
| 독립적 검토/검증 | IT, 데이터, 리스크 보고 기능에 전문성을 가진 개인들에 의해 독립적으로 검토 및 검증 |
| 신규 이니셔티브 시 고려 | 신상품 개발, 인수합병(M&A), 사업매각 시 RDARR을 "나중에"가 아니라 "처음부터" 고려. 인수 시 대상 기업의 집계/보고 능력을 평가하고, 두 기업의 프로세스를 통합할 시간표를 수립 |
| 은행 구조에 무관 | 데이터 집계/보고에 관한 결정은 은행의 물리적 위치, 지리적 존재, 법적 조직과 독립적이어야 함 |
| 최고경영진의 우선순위 | 재정적/인적 자원으로 RDARR을 지원. 전략적 IT 계획에 포함시키고 구현이 방해받지 않도록 보장 |
| 이사회의 지원 | 은행의 구현 및 준수 상황을 인지. M&A 이후 RDARR을 검토 |
IT 시스템은 비용이 많이 들며, 리스크 집계/보고 시스템은 상당한 재정적/인적 자원의 투입을 요구합니다. 이러한 투자의 이점은 일반적으로 단기가 아닌 장기적으로 실현됩니다. 글로벌 금융위기의 기억이 흐려지면서 은행들은 필요한 IT 투자에 우선순위를 두지 않을 수 있습니다. 바젤위원회는 리스크 집계/보고 프로세스를 개선하는 장기적 이점이 은행의 투자를 상회할 것이라고 믿습니다.
거버넌스 원칙은 "데이터 소스를 여러 개 두면 신뢰성이 증가한다"는 것이 아닙니다. 오히려 BCBS는 각 리스크 유형마다 "단일 권위 있는 소스(Single Authoritative Source)"를 추구하는 방향입니다. "여러 소스를 두자"는 거버넌스가 아니라 정확성/무결성(원칙 3) 측면의 이슈이며, 방향도 반대입니다.
따라서 "은행은 신뢰성 향상을 위해 각 리스크 유형에 대해 다수의 데이터 소스를 가져야 한다"는 거짓(False) 선지입니다.
9. 원칙 2: 데이터 아키텍처와 IT 인프라 (Data Architecture and Infrastructure)
위원회에 따르면, "은행은 정상 시기뿐만 아니라 스트레스 또는 위기 시기에도, 다른 원칙을 충족하면서, 리스크 데이터 집계 능력과 리스크 보고 관행을 완전히 지원하는 데이터 아키텍처와 IT 인프라를 설계, 구축, 유지해야 한다."
원칙 2는 건물로 비유하면 "설계도 + 배관 + 전기"에 해당합니다. 평소에는 괜찮아 보여도 위기 때는 "지금 당장 국가별 익스포저 뽑아와", "이 거래상대방이 디폴트하면 손실 얼마냐", "유동성 갭을 2시간 내로 재산출해" 같은 요구가 폭증합니다.
| 요건 | 상세 설명 |
|---|---|
| 사업 영향 분석 포함 | RDARR 관행이 은행의 계획 프로세스의 일부로 편입되고 사업 영향 분석의 대상이 되어야 함 |
| 통합 데이터 분류/아키텍처 | 은행 그룹 전체에 걸쳐 통합된 데이터 분류체계와 아키텍처를 수립. 여러 데이터 모델을 사용할 수 있지만 견고한 자동화된 정합 조치(Reconciliation Measures)가 있어야 함 |
| 메타데이터 및 명명규칙 | 데이터 아키텍처는 데이터 특성(메타데이터)에 관한 정보와 법인, 거래상대방, 고객, 계정 데이터에 대한 명명 규칙(Naming Conventions)을 포함해야 함 |
| 책임/역할/소유권 정의 | 데이터에 대한 책임(Accountability), 역할, 책임, 소유권이 정의되어야 함. 데이터 수명주기 전반에 걸쳐 적절한 통제가 있어야 함 |
10. 데이터 모델(스키마)의 4가지 유형
데이터 특성에 관한 정보를 생성하기 위해 데이터 모델을 사용할 수 있습니다. 주요 데이터 모델(스키마(Schema)라고도 함)은 추상도에 따라 다음과 같이 분류됩니다.
| 데이터 모델 | 영문 | 설명 | 추상도 |
| 의미적 데이터 모델 | Semantic Data Model | 데이터를 논리적 순서로 구조화하고, 데이터의 기본적 의미와 데이터 간 관계 같은 의미 정보를 포함 | 의미 중심 |
| 개념적 데이터 모델 | Conceptual Data Model | 가장 추상적. 데이터베이스에서 사용되는 개념과 관계를 매핑하고, 인간이 시스템과 시스템 목표를 이해하는 방식을 확인 | 가장 높음 (추상적) |
| 논리적 데이터 모델 | Logical Data Model | 데이터를 가능한 한 상세하게 설명. 구현(Implementation)에는 관심 없음 | 상세하지만 구현 독립적 |
| 물리적 데이터 모델 | Physical Data Model | 데이터베이스를 구축하는 데 필요한 구성요소를 정의. 테이블 구조, 열 이름과 값, 기본/외래 키, 테이블 간 관계 포함. 개념과 논리 데이터를 하드웨어/소프트웨어 플랫폼에서 사용할 구현 가능한 데이터로 변환 | 가장 구체적 (구현용) |
Module Quiz 7.1
문제 1. 국가 규제기관의 은행 감독관 Jeffrey Gibson은 은행 검사의 일환으로, 글로벌 시스템적으로 중요한 은행(G-SIB)인 Star Bank에 리스크 데이터의 집계와 보고를 개선하도록 요청했습니다. Star Bank는 잘못된 대출 결정에서 파생상품 사용에 관한 나쁜 결정에 이르는 다양한 원인으로 상당한 손실을 경험했습니다. 은행은 현재 손실로 인해 자본이 부족한 상태입니다. Gibson은 Star Bank의 현재 어려움을 감안할 때, 효과적인 리스크 데이터 집계의 잠재적 직접 이점 중 하나가 다음과 같다고 알립니다:
A. 은행 효율성 증가
B. 더 효과적인 IT 인프라
C. 은행 문제의 정리가능성 향상
D. 은행의 리스크 선호도에 대한 더 명확한 정의
문제 2. Donna Grinstead는 Republic Bank의 리스크관리 담당관입니다. 그녀는 효과적인 리스크 데이터 집계를 위한 거버넌스 원칙을 수립하고 있습니다. 거버넌스 원칙에 관한 다음 진술 중 거짓인 것은?
A. 은행의 전체 리스크관리 프레임워크에 리스크 데이터 집계가 포함되어야 한다.
B. 인적/재정적 자원이 리스크 데이터 집계에 투입되어야 하며, 따라서 최고경영진이 프레임워크를 승인해야 한다.
C. 은행은 신뢰성 향상을 위해 각 리스크 유형에 대해 다수의 데이터 소스를 가져야 한다.
D. 리스크 데이터 집계는 인수합병 및 사업매각을 포함한 신규 이니셔티브 시 고려되어야 한다.
MODULE 7.2: 리스크 데이터 집계 및 보고 능력
데이터 집계의 4대 원칙 (원칙 3~6)
11. 원칙 3: 정확성과 무결성 (Accuracy and Integrity)
위원회에 따르면, "은행은 정상 및 스트레스/위기 보고 정확성 요구사항을 충족하기 위해 정확하고 신뢰할 수 있는 리스크 데이터를 생성할 수 있어야 한다. 데이터는 오류의 확률을 최소화하기 위해 대부분 자동화된 기반으로 집계되어야 한다."
| 요건 | 상세 설명 |
|---|---|
| 정확성과 신뢰성 | 데이터 집계와 보고는 정확하고 신뢰할 수 있어야 함 |
| 회계 수준의 통제 | 리스크 데이터에 적용되는 통제는 회계 데이터를 둘러싼 통제만큼 견고해야 함 |
| 수동 프로세스 통제 | 스프레드시트/데이터베이스 같은 수동 프로세스에 의존할 때 효과적인 통제가 있어야 함 |
| 회계 데이터와 정합 | 데이터를 회계 데이터를 포함한 다른 은행 데이터와 정합(Reconcile)하여 정확성 보장 |
| 단일 권위 소스 | 각 특정 리스크 유형에 대해 리스크 데이터의 단일 권위 있는 소스(Single Authoritative Source)를 갖추도록 노력해야 함 |
| 은행 전체 일관된 정의 | 데이터가 은행 전체에서 일관되게 정의되어야 함. 리스크 데이터 개념과 용어의 사전(Dictionary)을 유지할 수 있음 |
| 자동화 원칙 + 전문적 판단 | 데이터는 대부분 자동화된 기반으로 집계되어야 하지만, 전문적 판단이 필요할 때 인적 개입은 적절함. 수동/자동 시스템 간 균형 필요 |
| 수동 우회 문서화 | 은행 감독당국은 수동/자동 리스크 데이터 집계 시스템을 문서화하고, 수동 우회(Manual Workaround)가 있을 때 왜 필요한지, 왜 데이터 무결성에 중요한지, 영향을 최소화할 조치를 설명하도록 기대함 |
| 품질 모니터링 | 리스크 데이터의 정확성을 모니터링하고 저품질 데이터를 교정할 계획을 수립 |
자동화된 프로세스를 우회하여 수동으로 데이터를 입력/처리하는 것은 "프로토콜 위반(Breach of Protocol)"이 아니라 "수동 우회(Manual Workaround)"입니다. BCBS는 "하면 안 된다"고 말하는 것이 아니라, 수동 우회가 발생했을 때 다음을 요구합니다:
(1) 왜 수동 우회를 했는지 설명, (2) 왜 데이터 정확성에 중요한지 설명, (3) 수동 우회의 영향을 최소화할 조치를 제안
12. 원칙 4: 완전성 (Completeness)
위원회에 따르면, "은행은 은행 그룹 전체에 걸쳐 모든 중요한(Material) 리스크 데이터를 포착하고 집계할 수 있어야 한다. 데이터는 사업 라인, 법인, 자산 유형, 산업, 지역 및 기타 그룹별로 이용 가능해야 하며, 이를 통해 리스크 익스포저, 집중, 신규 리스크를 식별하고 보고할 수 있어야 한다."
- 온밸런스(On-Balance Sheet) 리스크와 오프밸런스(Off-Balance Sheet) 리스크가 모두 집계되어야 합니다. 대출/채권뿐 아니라 보증, 파생계약, 약정 등도 포함해야 합니다.
- 리스크 측정치와 집계 방법은 최고경영진과 이사회가 리스크 익스포저를 적절히 평가할 수 있도록 명확하고 충분히 구체적이어야 합니다. 그러나 모든 리스크가 동일한 지표로 표현될 필요는 없습니다.
- 리스크 데이터는 완전해야 합니다. 완전하지 않은 경우, 은행은 불완전한 영역을 식별하고 감독당국에 설명해야 합니다.
- 완전성은 "데이터가 많다"가 아니라 "중요한 리스크가 빠지지 않는다"는 것이며, 사업부/법인/자산군/산업/지역/통화 등으로 드릴다운(Drill-Down)이 가능해야 집중위험과 신규 리스크를 발견할 수 있습니다.
13. 원칙 5: 적시성 (Timeliness)
위원회에 따르면, "은행은 정확성과 무결성, 완전성, 적응성에 관한 원칙도 충족하면서, 적시에 집계된 최신 리스크 데이터를 생성할 수 있어야 한다. 정확한 시점은 측정되는 리스크의 성격과 잠재적 변동성, 은행의 전체 리스크 프로파일에 대한 중요성에 따라 달라진다."
적시성은 "빨리 만들어라"가 전부가 아닙니다. 리스크의 성격에 맞는 속도가 핵심입니다.
| 사업 라인 | 적시성 요구 |
|---|---|
| 트레이딩 포지션 | 시장이 초단위로 움직이므로 거의 실시간 필요. 정교한 평가 알고리즘 사용 |
| 포트폴리오 관리 | 기업 여신보다 빠르고 빈번하게 리스크 데이터 평가 필요 |
| 기업 여신 | 변동이 상대적으로 느리지만 위기 시에는 빈도를 올려야 함 |
위기 시 빠르게 생산해야 하는 핵심 리스크 데이터 (시험 빈출)
- 대기업 차입자에 대한 집계된 신용 익스포저
- 파생상품을 포함한 거래상대방 신용리스크 익스포저
- 트레이딩 익스포저, 포지션 및 운영 한도
- 지역 및 섹터별 시장 집중
- 유동성 리스크 지표
- 시간 민감 운영리스크 지표
14. 원칙 6: 적응성 (Adaptability)
위원회에 따르면, "은행은 스트레스/위기 상황 중 요청, 변화하는 내부 필요에 따른 요청, 감독당국 질의를 충족하기 위한 요청을 포함하여, 광범위한 주문형(On-Demand), 임시(Ad Hoc) 리스크관리 보고 요청을 충족하기 위해 집계된 리스크 데이터를 생성할 수 있어야 한다."
적응성은 "정해진 보고서만 뽑는 조직"과 "질문을 받으면 바로 답하는 조직"을 가르는 기준입니다.
- 집계 프로세스는 유연해야 하며 은행 관리자가 의사결정 목적으로 리스크를 빠르게 평가할 수 있어야 함
- 데이터는 맞춤형(Customizable)이어야 함 (예: 이상징후, 대시보드, 핵심 요약). 사용자가 특정 리스크를 더 상세하게 조사할 수 있어야 함
- 은행 전체 리스크에 영향을 미치는 새로운 사업 측면이나 외부 요인을 집계 프로세스에 포함시킬 수 있어야 함
- 규제 변경이 리스크 데이터 집계에 반영되어야 함
- 은행은 집계된 리스크 데이터에서 구체적 정보를 추출할 수 있어야 함. 예: 특정 국가/지역의 리스크 집계, 특정 국가에 대한 신용리스크 익스포저(기업, 은행, 국가, 소매)가 쉽게 접근 가능해야 함
15. 원칙 간 상호작용: "한 원칙을 위해 다른 원칙을 희생하지 마라"
정확성과 무결성, 완전성, 적시성, 적응성의 원칙들은 상호작용합니다. 은행이 한 원칙을 다른 원칙보다 앞세우거나, 한 원칙을 염두에 두고 데이터를 집계하면서 다른 원칙을 무시할 수 있습니다.
| 트레이드오프 사례 | 설명 |
|---|---|
| 적시성 우선 → 완전성 희생 | 속도와 적시성을 위해 완전성에 대한 지름길을 택할 수 있음 (빨리 내느라 누락) |
| 적시성 우선 → 정확성 희생 | 적시성 기준 준수를 서두르면 데이터의 정확성과 무결성이 저하될 수 있음 (검증 생략) |
| 정확성 우선 → 적응성 희생 | 정확성과 무결성을 지원하는 방식으로 데이터를 편집하되 데이터를 경직되고 특정 필요에 쉽게 적응할 수 없게 만들 수 있음 |
시험 정답 방향: "한 원칙을 앞세우기보다, 네 가지를 동시에 만족하도록 설계/운영해야 한다." 은행은 리스크 데이터 집계 프레임워크를 생성하고 유지할 때 모든 기준을 고려해야 합니다.
리스크 보고의 5대 원칙 (원칙 7~11)
집계가 "공급망(데이터 파이프라인)"이라면, 보고는 "의사결정용 제품(리스크 인사이트)"입니다.
16. 원칙 7: 보고의 정확성 (Accuracy)
위원회에 따르면, "리스크관리 보고서는 집계된 리스크 데이터를 정확하고 정밀하게 전달하며, 리스크를 정확한 방식으로 반영해야 한다. 보고서는 정합 및 검증되어야 한다."
| 요건 | 상세 설명 |
|---|---|
| 프로세스 정의 | 리스크 보고서를 생성하는 데 사용되는 프로세스를 정의 |
| 합리성 점검 | 데이터의 합리성 점검(Reasonableness Checks) 생성 |
| 수학/논리 관계 검증 | 검증되어야 하는 데이터 내 수학적/논리적 관계의 설명 포함 |
| 에러 리포트 | 데이터의 약점이나 오류를 식별, 보고, 설명하는 에러 리포트 생성 |
| 근사치의 신뢰성 | 리스크 근사치(시나리오 분석, 민감도 분석, 스트레스 테스트 등)의 신뢰성, 정확성, 적시성 보장 |
| 중요성 기준 | 감독당국은 리스크 데이터에 회계 중요성(Accounting Materiality)에 상응하는 정확성 요구사항을 부과하도록 기대. 누락이 리스크 의사결정에 영향을 미치면 중요(Material)한 것으로 간주 |
17. 원칙 8: 포괄성 (Comprehensiveness)
위원회에 따르면, "리스크관리 보고서는 조직 내의 모든 중요한 리스크 영역을 커버해야 한다. 보고서의 깊이와 범위는 은행 운영의 규모와 복잡성, 리스크 프로파일, 그리고 수신자의 요구사항에 일관되어야 한다."
| 항목 | 영문 |
|---|---|
| 신용리스크 | Credit Risk |
| 시장리스크 | Market Risk |
| 유동성리스크 | Liquidity Risk |
| 운영리스크 | Operational Risk |
| 스트레스 테스트 결과 | Results of Stress Tests |
| 자본적정성 | Capital Adequacy |
| 규제자본 | Regulatory Capital |
| 유동성 전망 | Liquidity Projections |
| 자본 전망 | Capital Projections |
| 리스크 집중 | Risk Concentrations |
| 자금조달 계획 | Funding Plans |
리스크 보고서는 전방적(Forward-Looking)이어야 하며 예측(Forecasts)과 스트레스 테스트를 포함해야 합니다. 은행의 리스크 선호도/허용범위는 신규 리스크(Emerging Risks)의 맥락에서 논의되어야 합니다.
Pillar 1 리스크(시장/신용/운영리스크 = 은행 운영의 핵심)와 Pillar 2 리스크(비즈니스/평판/집중/전략리스크 등으로 확장)를 모두 커버해야 합니다.
18. 원칙 9: 명확성과 유용성 (Clarity and Usefulness)
위원회에 따르면, "리스크관리 보고서는 정보를 명확하고 간결한 방식으로 전달해야 한다. 보고서는 이해하기 쉬우면서도 정보에 기반한 의사결정을 촉진할 만큼 포괄적이어야 한다. 보고서는 수신자의 필요에 맞춘 의미 있는 정보를 포함해야 한다."
| 수신자 | 보고 내용/초점 |
|---|---|
| 이사회 | 큰 그림, 한도 준수, 핵심 경고, 질문해야 할 포인트. 은행이 리스크 허용범위 내에서 운영되고 있는지 확인 |
| 리스크위원회/임원 | 원인 분석, 대안 비교, 시나리오별 영향. 더 구체적인 리스크 정보 |
| 트레이더 | 포지션, 그릭스, 한도, P&L 민감도. 대출자에게는 관련 없을 수 있는 정보 |
핵심 포인트: 집계 수준이 높아질수록(전체 합계로 갈수록) 정성적 해석(Qualitative Interpretation/Explanation)의 필요성이 더 커집니다. "총 익스포저 3조"만 던지면 의미가 없고, "어디에서 왜 늘었고, 무엇이 트리거이며, 어떤 조치 옵션이 있는지"를 말해야 합니다.
보고서에는 (1) 리스크 데이터, (2) 리스크 분석, (3) 리스크 해석, (4) 리스크의 정성적 설명이 포함됩니다. 리스크 데이터는 분류되어야 하며, 은행은 리스크 보고서에 사용되는 용어 목록(Inventory of Terms)을 개발해야 합니다. 정량적 데이터 대 정성적 데이터의 혼합(Mix)이 중요합니다.
19. 원칙 10: 빈도 (Frequency)
위원회에 따르면, "이사회와 최고경영진은 리스크관리 보고서의 생산 및 배포 빈도를 설정해야 한다. 빈도 요구사항은 수신자의 필요, 보고되는 리스크의 성격, 리스크가 변화할 수 있는 속도, 건전한 리스크관리와 효과적/효율적 의사결정에 대한 보고서의 기여 중요성을 반영해야 한다. 보고서의 빈도는 스트레스/위기 시기에 증가되어야 한다."
- 보고서 빈도는 수신자(이사회 vs 리스크위원회 vs 트레이딩 부서), 리스크 유형, 보고서 목적에 따라 달라짐
- 이사회는 리스크위원회 구성원보다 덜 빈번하게 보고서가 필요하고, 트레이딩 부서는 여신 부서보다 더 빈번하게 필요
- 스트레스/위기 시기에는 유동성, 신용, 시장리스크 보고서가 증가하는 리스크에 대응하기 위해 즉시 필요할 수 있음
- 그러나 일부 경우 데이터 양이 너무 방대하면(예: 확률적 현금흐름 시뮬레이션) 보고 빈도를 늦춰야 할 수 있음. 출력 데이터가 너무 많으면 데이터 품질 점검을 유지하기 어려움. 시나리오 반복 간 일관성도 유지되어야 함
위기 시 보고 빈도를 높여야 하지만, 데이터 양이 너무 방대하면 오히려 품질 체크가 무너질 수 있어 "무조건 더 자주"가 답이 아닙니다. 빈도와 품질 간의 균형감각이 포인트입니다.
20. 원칙 11: 배포 (Distribution)
위원회에 따르면, "리스크관리 보고서는 기밀성을 유지하면서 관련 당사자에게 배포되어야 한다."
보고서는 기밀성(Confidentiality)을 유지하면서 적시에 배포되어야 합니다. 감독당국은 수신자가 보고서를 적시에 수신하는지 확인하도록 은행에 기대합니다. 필요한 사람이 제때 받아야 하고(지연되면 무의미), 동시에 기밀은 지켜야 합니다(리스크 정보는 민감 정보).
21. 효과적 vs 비효과적 리스크 데이터 집계와 보고의 비교
BCBS는 최근 보고서에서 효과적/비효과적 리스크 데이터 집계와 보고를 대비합니다.
| 효과적 (Effective) | 비효과적 (Ineffective) |
| 적절한 데이터 요소 인증 (이 값이 무엇이고 어디서 왔는지) | 데이터 품질 통제의 비효율성 |
| 데이터 품질 문서화 (룰/기준/예외) | 부적절하게 수립된 데이터 품질 규칙 (보고 최소 기준 부재) |
| 데이터 품질 보증 메커니즘 (자동 체크, 승인 절차) | 감독(Oversight) 부재 |
| 리스크 유형별 데이터 품질 평가 | 효과적인 에스컬레이션 모델 부재 (문제 발견해도 올라가지 않음) |
| 수동 프로세스에 대한 문서화되고 효과적인 통제 | 부적절하게 문서화된 수동 프로세스의 과도한 사용 |
| 핵심 리스크 보고서 간 정합(Reconciliation) 부재 | |
| 분산 분석(Variance Analysis) 부재 | |
| 해외 자회사로부터 적시에 리스크 데이터를 획득할 수 없음 | |
| 참조 데이터의 표준화 부재 (고객/법인/상품 코드 불일치) |
일반적으로 연구에 따르면 은행들은 원칙 준수에 어려움을 겪고 있습니다. PwC 연구에 따르면 리스크 보고 원칙 7~11에서는 상대적으로 더 높은 성과를 보이지만, 데이터 집계 원칙 3~6에서는 저조한 성과를 보이고 있습니다. 또한 원칙 1과 2(거버넌스, 데이터 아키텍처/인프라)도 낮은 준수율을 보이고 있습니다.
Module Quiz 7.2
문제 1. 은행은 집계된 리스크 데이터에 데이터 특성(메타데이터)에 관한 정보와 법인, 거래상대방, 고객, 계정 데이터에 대한 명명규칙을 포함해야 합니다. 이것은 바젤은행감독위원회가 다음과 관련된 원칙에서 제안한 것입니다:
A. 정확성
B. 완전성
C. 명확성과 유용성
D. 데이터 아키텍처와 인프라
문제 2. American Bank and Trust의 리스크관리 전문가 Emily Lister는 집계된 리스크 데이터의 정확성과 무결성에 관한 원칙 3의 일환으로, 은행 직원이 리스크관리팀이 마련한 자동화 프로세스를 포기하고 수기로 데이터를 입력한 이유에 대한 보고서를 은행 감독당국에 제공하도록 요청받았습니다. Lister는 직원과 논의 후 그것이 필요했다고 믿습니다. 보고서에서 그녀는 자동화 프로세스를 포기한 것이 왜 필요했는지, 데이터의 무결성이 여전히 온전하다고 믿는 이유를 상세히 기술합니다. 보고서에서 그녀가 설명하고 있는 것은:
A. 프로토콜 위반
B. 수동 우회
C. 원칙 3에 대한 신뢰성 예외
D. 리스크 데이터 집계 원칙에 대한 용인되지 않는 예외
문제 3. 최고경영진과 이사회가 정확하고 적시적인 집계된 리스크 데이터 보고서를 받아야 하는 이유로 다음 중 해당하지 않는 것은?
A. 은행 감독당국이 이사회 구성원에게 리스크 보고서를 요청하며, 이사회는 은행 검사 시 이 정보를 제공할 준비가 되어야 한다.
B. 최고경영진과 이사회 구성원은 은행 리스크에 관한 의사결정을 위해 리스크 보고서를 사용한다.
C. 최고경영진과 이사회 구성원은 금융 스트레스/위기 시 대응해야 하며, 좋은 의사결정을 위해 신뢰할 수 있는 리스크 보고서가 필요하다.
D. 이사회는 은행이 리스크 허용범위/선호도 내에서 운영되고 있음을 보장해야 하므로, 판단을 내리기 위해 관련 리스크 정보를 수신하도록 해야 한다.
정답 및 해설
| 문제 | 정답 | 해설 |
| Quiz 7.1-1 | C | Star Bank는 손실로 자본이 훼손된 상태(재정적 스트레스)입니다. 이때 잘 집계된 리스크 데이터의 가장 직접적인 가치는 감독당국/정리당국이 은행의 문제를 정확히 파악하고 정리(Resolution)/회복 전략을 세우는 데 도움이 된다는 점입니다. 따라서 "문제의 정리가능성 향상(Improved Resolvability)"이 현재 상황에서 가장 관련 있는 이점입니다. 효율성 증가(A)나 IT 인프라 개선(B)은 직접적 이점이 아니며, 리스크 선호도 정의(D)도 현재 위기 상황에서의 핵심 이점이 아닙니다. |
| Quiz 7.1-2 | C | 거버넌스 원칙은 "조직 차원의 책임/승인/자원/감독"에 대한 원칙입니다. "각 리스크마다 데이터 소스를 여러 개 두자"는 거버넌스가 아니라 정확성/무결성(원칙 3) 측면의 이슈이며, BCBS는 오히려 "가능하면 단일 권위 소스(Single Authoritative Source)"를 지향합니다. 따라서 C가 거짓입니다. A(전체 프레임워크 포함), B(자원 투입/승인), D(M&A 시 고려)는 모두 올바른 거버넌스 원칙 진술입니다. |
| Quiz 7.2-1 | D | 메타데이터와 명명규칙은 전형적인 아키텍처 설계 요소입니다. 데이터가 어떤 의미인지(메타데이터), 법인/고객/거래상대방을 어떻게 부를지(명명규칙)가 통일되어야 통합이 됩니다. 이는 원칙 2(데이터 아키텍처 및 인프라)의 요건입니다. 정확성(A), 완전성(B), 명확성/유용성(C)의 원칙과는 직접적으로 관련되지 않습니다. |
| Quiz 7.2-2 | B | 자동화된 프로세스를 우회하여 수동으로 처리하는 것은 수동 우회(Manual Workaround)입니다. 원칙 3에서 은행 감독당국은 수동/자동 리스크 데이터 집계 시스템을 문서화하고, 수동 우회가 있을 때 왜 필요한지, 왜 데이터 정확성에 중요한지, 영향을 최소화할 조치를 제안하도록 기대합니다. 이는 프로토콜 위반(A), 신뢰성 예외(C), 용인되지 않는 예외(D)가 아닙니다. |
| Quiz 7.2-3 | A | 이사회와 경영진이 보고서를 받는 이유는 내부 거버넌스 목적입니다: (B) 의사결정, (C) 위기 대응, (D) 리스크 허용범위 준수 확인. "감독당국이 이사회 구성원에게 직접 보고서를 요청한다"는 방향이 틀립니다. 감독당국의 정보 요청은 은행(Bank Level)에 이루어지며, 이사회 수준이 아닙니다. 이사회는 감독당국에 보고서를 제공하는 주체가 아닙니다. |
KEY CONCEPTS (핵심 개념 정리)
LO 7.a 핵심
- 효과적인 리스크 데이터 집계/보고의 4대 이점: (1) 문제 예측 능력 향상, (2) 금융 스트레스 시 회복 경로 식별, (3) 은행 스트레스/실패 시 정리가능성(Resolvability) 향상, (4) 전략적 의사결정 강화, 효율성 증가, 손실 확률 감소, 수익성 증가
LO 7.b 핵심
- 금융 모델은 리스크 분석부터 일상 운영까지 모든 것에 사용됨. 작은 오류도 심각한 결과 초래
- 모델은 데이터에 의존하므로, 데이터 획득은 모델 리스크의 중요한 구성요소, 특히 입력 리스크(Input Risk)
- 모델 리스크 유형: 입력/추정/평가/헤지 리스크
- 데이터 표준화(Standardization)가 없으면 은행은 자기 리스크를 정확히 모름
- BCBS 239 = 14개 원칙. 은행의 데이터 집계/보고 프로세스 전면 개편을 위한 지침
LO 7.c 핵심
- 원칙 1(거버넌스): 리스크 데이터 집계는 은행의 전체 리스크관리 프레임워크의 일부가 되어야 함
- 이사회와 최고경영진이 적절한 자원을 투입. 문서화, 독립적 검증, M&A 시 고려, 구조 무관, 경영진 우선순위를 요구
- 단일 권위 소스 지향 (다수 소스가 아님)
LO 7.d 핵심
- 원칙 2(데이터 아키텍처/IT 인프라): 정상 시기뿐 아니라 스트레스/위기 시기에도 완전히 지원하는 아키텍처. 메타데이터, 명명규칙, 데이터 수명주기 통제 포함
- 원칙 3~6(데이터 집계): 정확성(Accuracy), 완전성(Completeness), 적시성(Timeliness), 적응성(Adaptability). 한 원칙을 다른 원칙 희생으로 달성하지 말 것
- 원칙 7~11(리스크 보고): 정확성(Accuracy), 포괄성(Comprehensiveness), 명확성/유용성(Clarity/Usefulness), 빈도(Frequency), 배포(Distribution)
- 빈도는 수신자 역할과 사업 라인에 따라 달라짐. 이사회 < 리스크위원회, 여신 < 트레이딩
- 보고서는 관련 당사자에게 적시 배포하되 기밀성 유지
시험 대비 한 줄 암기 체크리스트
| 주제 | 암기 포인트 |
|---|---|
| 리스크 데이터 집계 정의 | 정의 + 수집 + 가공 → 리스크 허용범위 대비 성과 측정 |
| 4대 이점 | 문제 예측 / 회복 경로 / 정리가능성 / 전략적 의사결정 |
| 모델 리스크와 데이터 | 데이터 획득 = 입력 리스크(Input Risk). 작은 오류도 대형 사고 |
| BCBS 239 | 14개 원칙. 원칙 1-2 = 기반, 3-6 = 집계, 7-11 = 보고 |
| 원칙 1: 거버넌스 | 경영진 승인, 문서화, 독립 검증, M&A 시 고려, 자원 투입 |
| 원칙 2: 아키텍처/인프라 | 메타데이터, 명명규칙, 데이터 모델(의미/개념/논리/물리), 정상+위기 시 모두 지원 |
| 원칙 3: 정확성/무결성 | 자동화 중심, 회계 수준 통제, 단일 권위 소스, 수동 우회 문서화 |
| "다수 소스" 함정 | "여러 소스 = 신뢰성 향상" → 거짓. 단일 소스 지향 |
| 수동 우회 | 프로토콜 위반이 아닌 "Manual Workaround". 문서화 + 이유 + 최소화 조치 제시 |
| 원칙 4: 완전성 | 온/오프밸런스 모두. 다차원 드릴다운 가능해야 |
| 원칙 5: 적시성 | 리스크 성격에 맞는 속도. 트레이딩 = 실시간, 위기 시 핵심 리스크 즉시 생산 |
| 원칙 6: 적응성 | 유연성, 맞춤형, 임시(Ad Hoc) 요청 대응, 규제 변경 반영 |
| 원칙 간 트레이드오프 | 한 원칙을 위해 다른 원칙을 희생하지 마라. 동시 충족이 핵심 |
| 원칙 7: 보고 정확성 | 합리성 점검, 에러 리포트, 회계 중요성에 상응하는 정확성 |
| 원칙 8: 포괄성 | Pillar 1 + 2 리스크 모두 커버. 전방적(Forward-Looking) 정보 포함 |
| 원칙 9: 명확성/유용성 | 수신자별 맞춤. 집계 높을수록 정성적 해석 필요성 증가 |
| 원칙 10: 빈도 | 수신자/리스크 유형에 따라 다름. 위기 시 증가하지만 품질과 균형 |
| 원칙 11: 배포 | 적시 배포 + 기밀성 유지 |
| 이사회와 감독당국 | 이사회는 감독당국에 직접 보고서를 제공하지 않음. 감독당국 요청은 은행 수준 |
| 준수 현황 | 보고(7-11)가 집계(3-6)보다 성과 높음. 거버넌스(1)/인프라(2)도 준수율 낮음 |