LabHub

은행 업무의 구조 · 리스크와 규제 · 이론

리스크와 규제 — 요구사항의 '왜'

LabHub 에서 이어서 보기

한 줄 요약

은행은 남의 돈으로 장사하므로 자기자본·여신 심사·자금세탁방지·전자금융·소비자보호에 걸쳐 두꺼운 규제를 받고, 그 규제의 상당 부분이 IT 요구사항으로 내려온다.

왜 규제가 IT 요구사항이 되는가

은행 시스템 요구사항서에는 기능과 무관해 보이는 항목이 가득합니다. "거래 로그를 5년 보관", "접근기록을 별도 저장", "STR 보고 사실을 화면에 노출 금지", "설명 의무 이행 여부를 기록". 이것들은 전부 규제에서 왔습니다. 은행은 예금이라는 남의 돈으로 대출을 하기 때문에, 망하면 예금자와 결제 시스템 전체가 위험해집니다. 그래서 국가는 은행에 자본을 쌓게 하고, 절차를 남기게 하고, 보고하게 합니다. IT 인력이 규제의 뼈대를 알아야 하는 이유는 요구사항의 "왜" 가 거기 있기 때문입니다.

자본과 리스크 — BIS 비율과 바젤

은행이 손실을 흡수할 수 있는 힘은 자기자본입니다. 국제 기준(바젤위원회)은 위험가중자산 대비 자기자본 비율을 요구합니다. 대출마다 위험이 다르니 같은 100억이라도 국채와 신용대출의 위험가중치가 다르고, 그 가중합이 위험가중자산입니다. 바젤 III 의 최소 총자본비율은 8% 이고, 여기에 완충자본이 더해져 실무 기준은 대략 10.5% 안팎이며, 보통주자본(CET1)처럼 질 좋은 자본에 별도 최소치가 있습니다. IT 에는 이것이 "모든 여신에 위험가중치를 붙여 매일 집계할 수 있어야 한다" 로 내려옵니다.

여신 심사 — 5C

대출을 줄지 말지의 판단 틀로 오래 쓰인 것이 5C 입니다.

Character   상환 의지. 신용 이력, 연체 기록.Capacity    상환 능력. 소득, 현금 흐름, 기존 부채(DSR 같은 지표가 여기서 나온다).Capital     자기 자본. 빌리는 사람이 얼마나 자기 돈을 넣었는가.Collateral  담보. 못 갚을 때 회수할 수 있는 것.Conditions  조건. 금리·경기·업종 환경.

심사 시스템의 데이터 항목은 대체로 이 다섯 갈래로 분류됩니다. 신용평가 모형이 정교해져도 틀은 같습니다.

자금세탁방지 — AML/KYC

은행은 고객을 확인하고(KYC), 거래를 감시하고, 의심스러우면 보고해야 합니다. 국내에서 이 의무를 정한 법이 특정금융거래정보의 보고 및 이용 등에 관한 법률(특정금융정보법)이고, 보고를 받는 기관이 금융정보분석원(FIU)입니다.

CDD/EDD   고객확인. 신원과 실제 소유자를 확인하고, 고위험 고객은 강화된 확인을 한다.CTR       고액현금거래보고. 하루 일정 금액(현재 1천만 원) 이상의 현금 입출금은 그 자체로 보고.STR       의심거래보고. 금액과 무관하게 자금세탁이 의심되면 보고. 판단이 들어간다.비밀유지   보고했다는 사실을 고객에게 알리면 안 된다.

IT 요구는 명확합니다. 거래 감시 규칙을 돌릴 수 있는 데이터, 고객 위험등급과 확인일자, 보고 이력의 격리, 그리고 보고 사실이 고객 화면·알림·상담 기록으로 새지 않는 설계입니다.

전자금융과 소비자보호

전자금융거래법은 비대면 거래의 안전을 다룹니다. 접근매체(인증서·OTP 등)의 관리, 거래 기록의 생성과 보존, 사고 시 책임 분담, 그리고 안전성 확보 의무가 핵심입니다. 세부는 전자금융감독규정이 정하는데, 망분리·정보보호 인력과 예산 비율 같은 조항은 최근 몇 년 사이 완화와 재편이 진행 중이라 지금 무엇이 유효한지는 그때의 규정을 확인해야 합니다. 금융소비자보호법은 판매 절차를 다룹니다. 적합성·적정성 원칙, 설명 의무, 불공정영업행위 금지, 부당권유 금지, 광고 규제의 여섯 원칙이 뼈대이고, IT 에는 "설명했다는 사실과 고객이 확인했다는 사실을 기록으로 남겨라" 로 내려옵니다.

내부통제와 정보보호

금융회사 지배구조 관련 법령은 내부통제 기준을 두게 하고, 최근에는 임원마다 책임 범위를 문서로 정하는 책무구조도가 도입됐습니다. 정보보호 쪽은 접근통제·권한 분리·로그 보존·취약점 점검이 감독규정으로 요구되고, 개인정보는 개인정보보호법과 신용정보법이 겹쳐 적용됩니다. IT 인력에게 이것은 "누가 언제 무엇을 봤는지 남기고, 개발자와 운영자의 권한을 나누고, 그 증거를 감사에 낼 수 있어야 한다" 는 뜻입니다.

실무에서 진짜 중요한 것

첫째, 규제 요구는 이유가 있습니다. "왜 이 로그를 5년 보관하느냐" 를 물으면 답이 있고, 그 답을 알면 어디까지 남겨야 하는지도 정해집니다.

둘째, 숫자와 조문은 바뀝니다. 비율·한도·보관 기간은 개정으로 움직입니다. 코드에 상수로 박지 말고 정책 테이블에 두고, 근거 규정을 함께 적어 두세요.

셋째, STR 은 사실로 씁니다. 룰 엔진의 출력은 판단의 근거이지 결론이 아니고, 보고서에는 거래 번호·금액·날짜·규칙이 들어갑니다. 그리고 그 사실은 고객에게 새지 않아야 합니다.

다음 실습에서 탐지 규칙 다섯 개를 직접 구현해 경보 점수를 내고, 보고 초안을 사실만으로 씁니다.