リスクと規制 — 要件の「なぜ」

一言でいうと

銀行は他人のお金で商売をするので、自己資本・与信審査・マネーロンダリング防止・電子金融・消費者保護にわたって厚い規制を受け、その規制の相当部分が、ITの要求事項として降りてきます。

なぜ規制がIT要求事項になるのか

銀行システムの要求事項書には、機能と無関係に見える項目がいっぱいです。「取引ログを5年保管」、「アクセス記録を別に保存」、「STRを報告した事実を画面に表示しない」、「説明義務の履行有無を記録」。これらはすべて規制から来ています。銀行は預金という他人のお金で貸出を行うので、破綻すれば、預金者と決済システム全体が危険になります。そのため国は、銀行に資本を積ませ、手順を残させ、報告させます。IT人材が規制の骨格を知らなければならない理由は、要求事項の「なぜ」がそこにあるからです。

資本とリスク: BIS比率とバーゼル

銀行が損失を吸収できる力は、自己資本です。国際基準(バーゼル委員会)は、リスク加重資産に対する自己資本比率を求めます。貸出ごとにリスクが違うので、同じ100億でも、国債と信用貸出では、リスクウェイトが違い、その加重和がリスク加重資産です。バーゼルIIIの最低総資本比率は8%で、そこにバッファー資本が加わり、実務の基準はおおよそ10.5%前後で、普通株式資本(CET1)のように質の良い資本には、別に最低値があります。ITには、これが「すべての与信にリスクウェイトを付けて、毎日集計できなければならない」として降りてきます。

与信審査: 5C

貸出を出すか出さないかの判断の枠組みとして、長く使われてきたのが5Cです。

5C	見るもの
Character	返済の意思。信用履歴、延滞の記録。
Capacity	返済能力。所得、キャッシュフロー、既存の負債(DSRのような指標はここから出ます)。
Capital	自己資本。借り手がどれだけ自分のお金を入れたか。
Collateral	担保。返せないときに回収できるもの。
Conditions	条件。金利・景気・業種の環境。

審査システムのデータ項目は、おおむねこの5つの系統に分類されます。信用評価モデルが精巧になっても、枠組みは同じです。

マネーロンダリング防止: AML/KYC

銀行は、顧客を確認し(KYC)、取引を監視し、疑わしければ報告しなければなりません。韓国で、この義務を定めた法律が、特定金融取引情報の報告及び利用等に関する法律(特定金融情報法)で、報告を受ける機関が、金融情報分析院(FIU)です。

義務	内容
CDD/EDD	顧客確認。身元と実質的支配者を確認し、高リスク顧客には強化された確認を行います。
CTR	高額現金取引報告。1日に一定額(現在1,000万ウォン)以上の現金の入出金は、それ自体で報告します。
STR	疑わしい取引の報告。金額に関係なく、マネーロンダリングが疑われれば報告します。判断が入ります。
守秘	報告した事実を顧客に知らせてはなりません。

ITの要求は明確です。取引監視ルールを回せるデータ、顧客のリスク等級と確認日、報告履歴の分離、そして、報告した事実が顧客の画面・通知・相談記録に漏れない設計です。

電子金融と消費者保護

電子金融取引法は、非対面取引の安全を扱います。アクセス手段(認証書・OTPなど)の管理、取引記録の生成と保存、事故時の責任分担、そして安全性確保義務が核心です。細部は電子金融監督規程が定めていますが、ネットワーク分離・情報保護人員と予算の比率のような条項は、ここ数年で緩和と再編が進んでいるので、今何が有効かは、そのときの規程を確認しなければなりません。金融消費者保護法は、販売手続きを扱います。適合性・適正性の原則、説明義務、不公正営業行為の禁止、不当勧誘の禁止、広告規制の6つの原則が骨格で、ITには、「説明したという事実と、顧客が確認したという事実を、記録として残せ」として降りてきます。

内部統制と情報保護

金融会社のガバナンス関連法令は、内部統制基準を置かせ、最近では、役員ごとに責任範囲を文書で定める責務構造図が導入されました。情報保護の面では、アクセス統制・権限分離・ログ保存・脆弱性点検が監督規程で求められ、個人情報は、個人情報保護法と信用情報法が重なって適用されます。IT人材にとって、これは、「誰がいつ何を見たかを残し、開発者と運用者の権限を分け、その証拠を監査に出せなければならない」という意味です。

規制要件がシステムに残す痕跡

規制文書は長いですが、システムに降りてくるときは、いくつかの繰り返される要求に変わります。その形を知っていれば、新しい規制が来ても、何を尋ねるべきかがわかります。

記録を消しません。AML調査、紛争、監査では、「そのときどんな値だったか」を問います。更新する表は、その問いに答えられないので、重要なものは、履歴として積み、現在の値は計算します。

計算の再現が求められます。自己資本比率や引当金のような数字には、「どう出たのかを示してほしい」という要求が来ます。結果だけを保存すると、数か月後に再現できません。入力・基準日・規程のバージョン・コードのバージョンを、結果と一緒に残します。

疑わしい取引は、人が判定し、その判定が記録されます。自動で遮断すれば、正常な取引が止まり、自動で通過させれば、報告義務を見逃します。システムの役割は、候補を絞って人の前に置き、その決定を残すことです。

顧客確認は、1回ではなく定期的です。リスク等級によって再確認の周期が違い、等級は取引の行動によって変わります。そのため、KYCは加入画面ではなく、回り続けるバッチとして設計されます。

報告には期限があります。遅れたり、形式が間違っていたりすること自体が違反です。報告バッチの失敗は、サービス障害と同じくらい早く知らされなければならず、再提出の経路も一緒に必要です。

権限を分けます。取引を作る人と、その記録を直せる人が同じなら、それ自体が指摘事項です。運用データベースに開発者が直接接続する経路が残っていれば、たいてい、ここで引っかかります。

開発者が尋ねるべきことは3つです。この値の基準日はいつか、どの規程のバージョンで計算したか、もう一度計算すると、同じ値が出るか。

実務で本当に大切なこと

1つ目に、規制の要求には理由があります。「なぜこのログを5年保管するのか」と尋ねれば、答えがあり、その答えを知っていれば、どこまで残すべきかも決まります。

2つ目に、数字と条文は変わります。比率・限度・保管期間は、改正で動きます。コードに定数として埋め込まず、ポリシーテーブルに置き、根拠となる規程を一緒に書いておいてください。

3つ目に、STRは事実で書きます。ルールエンジンの出力は、判断の根拠であって結論ではなく、報告書には、取引番号・金額・日付・ルールが入ります。そして、その事実は、顧客に漏れてはいけません。

次のラボで、検知ルール5つを自分で実装して、アラートスコアを出し、報告の草案を、事実だけで書きます。