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

한 줄 요약

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

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

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

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

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

여신 심사 — 5C

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

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

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

자금세탁방지 — AML/KYC

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

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

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

전자금융과 소비자보호

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

내부통제와 정보보호

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

규제 요건이 시스템에 남기는 흔적

규제 문서는 길지만, 시스템으로 내려올 때는 몇 가지 반복되는 요구로 바뀐다. 그 형태를 알면 새 규제가 와도 무엇을 물어야 할지 안다.

기록을 지우지 않는다. AML 조사, 분쟁, 감사에서 "그때 어떤 값이었나" 를 묻는다. 갱신하는 표는 그 질문에 답하지 못하므로, 중요한 것은 이력으로 쌓고 현재 값을 계산한다.

계산의 재현이 요구된다. 자본 비율이나 충당금 같은 숫자는 "어떻게 나왔는지 보여 달라" 는 요구가 온다. 결과만 저장하면 몇 달 뒤에 재현하지 못한다. 입력·기준일·규정 버전·코드 버전을 결과와 함께 남긴다.

의심 거래는 사람이 판정하고 그 판정이 기록된다. 자동으로 차단하면 정상 거래가 막히고, 자동으로 통과시키면 보고 의무를 놓친다. 시스템의 역할은 후보를 좁혀 사람 앞에 놓고, 그 결정을 남기는 것이다.

고객 확인은 한 번이 아니라 주기적이다. 위험 등급에 따라 재확인 주기가 다르고, 등급은 거래 행태에 따라 바뀐다. 그래서 KYC 는 가입 화면이 아니라 계속 도는 배치로 설계된다.

보고에는 기한이 있다. 늦거나 형식이 틀리면 그 자체가 위반이다. 보고 배치의 실패는 서비스 장애만큼 빨리 알려져야 하고, 재제출 경로도 함께 있어야 한다.

권한을 나눈다. 거래를 만드는 사람과 그 기록을 고칠 수 있는 사람이 같으면 그것 자체가 지적 사항이다. 운영 데이터베이스에 개발자가 직접 붙는 경로가 남아 있으면 대개 여기서 걸린다.

개발자가 물어야 할 것은 셋이다. 이 값의 기준일은 언제인가, 어떤 규정 버전으로 계산했는가, 다시 계산하면 같은 값이 나오는가.

실무에서 진짜 중요한 것

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

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

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

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