💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに

銀行の勘定系システムにおいて、受信(預金)と並ぶもう一つの柱が与信(貸出)です。受信が「お金を預かって保管する」比較的シンプルな元帳構造であるのに対し、与信は申込受付から審査、承認、約定、実行、そして数年に及ぶ返済と事後管理まで続く、長いライフサイクルを持つドメインです。その分、システムも複雑です。一件のローンが流れていく間に、信用評価システム(CSS)、限度額管理システム、担保管理システム、金利算出エンジン、勘定系元帳、信用情報機関、保証機関など、数多くのコンポーネントが噛み合って動きます。

本稿では、与信業務ドメインの全体像を描いたうえで、ローンの「誕生」を担うLOS(Loan Origination System)を中心に、申込から実行までのアーキテクチャを段階ごとに見ていきます。非対面ローンのリアルタイム審査パイプライン、限度額・担保・金利の各サブシステム、外部機関連携、そしてステートマシン設計とテストシナリオまで、実務で直面するテーマを扱います。

先にお断りしておくと、本稿はシステムアーキテクチャの観点からの技術記事であり、特定の金融商品の勧誘や投資・法律に関する助言ではありません。規制に関する内容は執筆時点の一般的な理解に基づくため、実際のプロジェクトでは必ずコンプライアンス・法務部門のレビューを受けてください。

与信業務ドメインの概観

与信の分類軸

与信商品は通常、三つの軸で分類します。システム設計においてこれらの軸がそのままデータモデルの次元になるため、正確に理解する必要があります。

| 分類軸 | 区分 | システム観点の違い |

| --- | --- | --- |

| 借主の類型 | 個人(リテール)与信 / 法人与信 | 審査モデル(CSS vs 企業信用格付)、限度額体系、必要書類が全く異なる |

| 担保の有無 | 担保ローン / 信用(無担保)ローン | 担保管理システム連携の有無、LTV検証ロジックの有無 |

| 限度額方式 | 極度(当座貸越等) / 証書(個別実行) | 元帳構造が異なる — 極度約定と個別実行を分離管理 |

リテール与信は標準化された商品(信用ローン、住宅担保ローン、賃貸保証金ローン等)を大量に処理するため自動化率が高く、法人与信は一件あたりの金額が大きく審査が定性的なため、ワークフロー中心で設計します。極度取引では「約定極度額」と「実行残高」を別々に管理する必要があり、未使用枠もBIS自己資本比率の計算時に信用換算率を適用してエクスポージャーに計上される点が、会計・リスクの観点で重要です。

与信システムの全体地図

+------------------------------------------------------------------+

| チャネル (Channel) |

| モバイルアプリ / インターネットバンキング / 営業店端末 / |

| コールセンター / 提携プラットフォーム |

+---------------------------+--------------------------------------+

+------------------------------------------------------------------+

| LOS (Loan Origination System) |

| 申込受付 -> 審査 -> 承認 -> 約定 -> 実行のオーケストレーション |

+--+----------+----------+----------+----------+-------------------+

| | | | |

v v v v v

+------+ +-------+ +-------+ +-------+ +----------+

| CSS | | 限度額 | | 担保 | | 金利 | | 対外系 |

| 信用 | | 管理 | | 管理 | | 算出 | | ゲートウェイ|

+------+ +-------+ +-------+ +-------+ +----+-----+

+--------------------------------------------+

| 信用情報集中機関 / NICE / KCB / 保証機関 / マイデータ事業者

+------------------------------------------------------------------+

| 勘定系元帳 (Core Banking Ledger) |

| 与信元帳 / 受信元帳 / 会計 / 日次締めバッチ |

+------------------------------------------------------------------+

LOSは「ローンが生まれる過程」をオーケストレーションするシステムであり、実行が完了するとローン口座は勘定系の与信元帳に移り、LMS(Loan Management System、事後管理)の領域になります。本稿はLOSの区間に集中します。

LOSパイプライン — 申込から実行まで

5段階のパイプライン

[申込] [審査] [承認] [約定] [実行]

Application -> Underwriting -> Approval -> Agreement -> Disbursement

| | | | |

本人確認信用照会決裁権者約定書作成記帳

商品選択 CSSスコア承認/条件付金利確定元帳口座生成

情報入力限度額検証承認/否決担保設定資金振込

書類提出担保評価有効期間付与期日/条件確定保証書発行確定

同意取得ポリシールール

各段階のシステム観点での要点は以下のとおりです。

**申込(Application)** — チャネルから入った申込を受け付け、申込書エンティティを生成します。核心は同意管理です。信用情報照会への同意、個人(信用)情報の収集・利用・提供への同意を取得する前に信用照会を呼び出すことはできないため、同意イベントと照会呼び出しの順序保証が監査(audit)の観点で重要です。同意書のバージョン、同意日時、チャネルをすべて履歴として残します。

**審査(Underwriting)** — パイプラインの心臓部です。信用情報機関(CB)照会、CSSスコア算出、ポリシールール(年齢、年収、DSR/DTI/LTVといった規制比率、多重債務の有無)のチェック、限度額算出がこの段階で行われます。自動審査で完結する案件と、審査担当者による手動審査に回す案件を分岐させるルーティングロジックもここに置きます。

**承認(Approval)** — 審査結果に決裁権限規程を適用します。金額・格付の区分ごとに自動承認、支店長決裁、本部審査部承認など決裁ラインが異なり、承認には有効期間(例: 30日)が付与されます。有効期間を過ぎると再審査が必要になる点を、ステートマシン設計に反映しなければなりません。

**約定(Agreement)** — ローン条件(金額、金利、期間、返済方式)を確定し、電子約定または書面約定を締結します。担保ローンであれば、根抵当権設定などの担保設定手続きがこの段階と実行の間に挟まります。約定時点の条件は不変(immutable)のスナップショットとして保存し、以後の条件変更は別途の変更約定として処理します。

**実行(Disbursement)** — いわゆる「記帳(起票)」の段階です。与信元帳にローン口座を生成し、会計仕訳(貸出金勘定の借方 / 顧客預金口座の貸方)を起こし、資金を指定口座へ振り込みます。実行は必ずトランザクション境界を明確にし、部分失敗時の補償(compensation)処理を設計しておく必要があります。

段階間データフローの原則

実務で繰り返し強調される原則が一つあります。**「審査時点の事実(facts)はすべてスナップショットとして固定せよ」**です。CB照会結果、スコア、所得情報、適用したポリシールールのバージョン、限度額計算の内訳を、申込案件に帰属する不変レコードとして保存してこそ、数か月後に監査や苦情が来たときに「その時点でなぜこの決定がなされたのか」を再現できます。マスターデータを参照ポインタとしてだけ持っていると、マスターが更新された瞬間に過去の意思決定の根拠が消えてしまいます。

非対面ローンのリアルタイムパイプライン

営業店中心の時代のLOSが数日がかりのワークフローエンジンだったとすれば、非対面の信用ローンのLOSは数十秒で完結するリアルタイムパイプラインです。ネット専業銀行とフィンテックのローン比較プラットフォームがこの流れを牽引しました。

顧客アプリ LOS 外部機関

| | |

|--- 限度額照会 ----->| |

| |--- CB照会 ----------->| NICE/KCB

| |<-- スコア/負債情報 ---|

| |--- 所得/資産収集 ---->| マイデータ事業者

| |<-- 口座/カード/負債 --| (または証明書ベースの

| | | スクレイピング:

| | | 健康保険/税務署資料)

| |-- 所得推定モデル -- |

| |-- CSSスコア算出 -- |

| |-- ポリシー/DSR -- |

| |-- 限度額/金利算出 -- |

|<-- 仮審査結果 ------| |

| (限度額/金利) | |

|--- 約定へ進む ----->| |

|<-- 電子署名/実行 ---| |

設計ポイントを整理すると次のとおりです。

- **所得推定**: 在職・所得書類を受け取る代わりに、マイデータ(本人信用情報管理業)APIまたは証明書ベースのスクレイピングで健康保険の納付履歴、税務当局の所得証明資料を収集して所得を推定します。推定所得には保守的なヘアカット(割引率)を適用するのが一般的です。

- **仮審査と本審査の分離**: ローン比較プラットフォームの「限度額照会」は仮審査であり、実際の約定直前に本審査を再度実行します。このとき、仮審査結果の有効期間と、本審査で条件が変わった場合の顧客告知フローを設計する必要があります。

- **信用照会の種類の区別**: 限度額照会の段階では信用スコアに影響しない照会タイプを使い、実際の申込時点で正式照会を行うなど、CB照会タイプを区別して呼び出します。

- **タイムアウトとフォールバック**: 外部機関一か所の遅延がパイプライン全体を塞がないよう、段階別タイムアウトと、部分失敗時の手動審査への切替(fallback to manual)経路を設けます。

- **冪等性**: 顧客がアプリで再試行すると、同じ申込が二重に流れる可能性があります。申込単位の冪等キー(idempotency key)で、重複申込と重複CB照会を防御します。

限度額管理システム

二つの層の限度額

限度額は「この顧客に総額いくらまで」という**顧客・借主単位の限度額**と、「この商品でいくらまで」という**商品・口座単位の限度額**の二層で管理します。法人与信では、さらに同一人・同一借主グループ限度という規制上の限度が加わります。銀行法上、同一の個人・法人およびその者と信用リスクを共有する者(同一借主グループ)への信用供与は自己資本の一定比率を超えられないため、承認前に必ず借主グループ全体のエクスポージャーを集計して検証しなければなりません。

エクスポージャー集計

エクスポージャー集計は言葉ほど単純ではありません。ローン残高だけでなく、未使用の約定枠、支払保証、デリバティブの信用換算額まで含め、借主グループ(系列関係)に沿って合算する必要があります。

-- 借主グループ単位のエクスポージャー集計(概念例)

SELECT g.borrower_group_id,

SUM(CASE WHEN e.exposure_type = 'LOAN_BALANCE'

THEN e.amount END) AS loan_balance,

SUM(CASE WHEN e.exposure_type = 'UNDRAWN_LIMIT'

THEN e.amount * e.ccf END) AS undrawn_equiv,

SUM(CASE WHEN e.exposure_type = 'GUARANTEE'

THEN e.amount END) AS guarantee_amt,

SUM(e.amount * COALESCE(e.ccf, 1.0)) AS total_exposure

FROM exposure_snapshot e

JOIN borrower_group_map g

ON e.borrower_id = g.borrower_id

WHERE g.borrower_group_id = :group_id

AND e.base_date = :base_date

GROUP BY g.borrower_group_id;

ここでccfは信用換算率(Credit Conversion Factor)です。設計上の核心的な決定は、**集計をリアルタイムで行うか、日次バッチのスナップショット基準で行うか**です。通常は、日次締めバッチで作成したスナップショットに当日の承認分を上乗せするハイブリッドを使います。承認時点と実行時点の間に別の案件が実行されて枠を侵食する競合状態があるため、承認時に限度額を**予約(soft reservation)**しておき、実行時に確定するパターンが安全です。

担保管理システム

鑑定評価と担保認定

担保ローンにおいて担保管理システムは、担保物マスター(不動産、預金、保証書、動産など)、鑑定評価履歴、担保設定(根抵当権など)の情報、そして担保認定価額の計算を担います。不動産であれば外部の鑑定評価法人の鑑定額または市場価格データを基準とし、先順位債権額と賃借保証金(法定の少額賃借人控除など)を差し引いて有効担保価額を算出します。

LTVの計算

LTV (Loan To Value) = 貸出金額 / 担保価値 * 100

有効担保価額 = 担保評価額 * 担保認定比率

- 先順位設定額

- 賃借保証金 / 少額賃借保証金控除

例:

マンション市場価格 : 10億ウォン

規制上のLTV上限 : 50% -> LTV基準の上限 = 5億ウォン

先順位根抵当 : 1億ウォン

実際の貸出可能額 : 5億 - 1億 = 4億ウォン (ポリシーにより異なる)

規制上のLTV比率は、地域(規制地域かどうか)、保有住宅数、商品タイプによって異なり、頻繁に改正されます。したがってLTV上限のルールはコードにハードコーディングせず、**施行日(effective date)を持つルールテーブル**として外部化すべきです。審査時点で有効なルールバージョンを検索して適用し、適用したルールバージョンIDを審査スナップショットに残すところまでがワンセットです。

もう一つ、担保価値は時間とともに変動します。事後管理の段階で定期的な再評価が行われ、LTVが悪化すれば追加担保の要求や枠の減額が発生し得るため、担保と与信の関係は1:1ではなくN:M(共同担保、追加担保)でモデリングする必要があります。

金利算出 — プライシング構造

基準金利 + 上乗せ金利

貸出金利は大きく「基準金利 + 上乗せ金利(スプレッド) - 優遇金利(減免)」という構造で算出されます。

最終金利 = 基準金利 + 上乗せ金利 - 優遇金利

基準金利 (Base Rate):

COFIX(新規取扱額/残高ベース)、金融債利回り、CDレートなど

-> 変動金利商品は再設定サイクル(3/6/12か月)ごとに更新

上乗せ金利 (Spread):

+ 信用コスト : 借主の格付別の予想損失(PD x LGD)を反映

+ 資本コスト : 規制資本の費用

+ 業務コスト : 人件費/システムなどの運営費用

+ 流動性プレミアム

+ 目標マージン

優遇金利 (Discount):

- 給与振込、カード利用、積立保有などの取引実績条件付き減免

- 条件を満たさなくなれば減免解除 -> 事後管理バッチで再判定

システム観点のポイントは三つです。

1. **基準金利マスターの管理**: 基準金利は公示日別の履歴テーブルで管理し、変動金利口座の金利再設定バッチがこれを参照します。「再設定日にどの時点の公示値を使うか」(公示日 vs 適用日)は商品説明書と一致していなければなりません。

2. **上乗せ金利の分解の保存**: 最終金利の数字一つだけを保存してはいけません。金利算定体系の合理性に関する開示・点検の要請があるため、算出時点の構成要素別の分解内訳を保存する必要があります。

3. **優遇金利の事後判定**: 優遇条件の充足可否は毎月のバッチで再判定され、金利変更は次の利息計算サイクルから反映されます。このバッチが利息計算バッチより先に走らなければならないという先後関係を、日次締めのジョブスケジュールに反映する必要があります。

約定と実行 — 記帳と元帳連携

実行(記帳)はLOSと勘定系元帳が出会う接点であり、与信システムの中で最も保守的に設計すべき区間です。

LOS 与信元帳会計/資金

| | |

|-- 1. 実行リクエスト -->| |

| (承認ID, 約定条件) | |

| |-- 2. 口座生成 |

| | (返済スケジュール |

| | 生成) |

| |-- 3. 仕訳伝票 ------>|

| | 借) 貸出金 |

| | 貸) 顧客預金 |

| |<- 4. 伝票承認 -------|

|<- 5. 実行完了 ---------| |

| (口座番号, 記帳番号) | |

|-- 6. 状態遷移 | |

| APPROVED->DISBURSED | |

設計原則は次のとおりです。

- **単一の記帳トランザクション**: 口座生成、仕訳、入金処理は元帳内で一つのトランザクションにまとめるか、不可能であればサーガ(Saga)パターンで補償トランザクションを定義します。「口座はできたのに入金されていない」状態が最も危険です。

- **冪等キー必須**: LOSの実行リクエストには承認案件基準の一意キーを載せ、元帳は同じキーの重複記帳を拒否します。タイムアウト後の再試行時、このキーが二重実行を防ぎます。

- **実行前の最終検証**: 承認の有効期間、限度額予約の有効性、担保設定完了の有無(設定登記の確認)、保証書の発行状態を実行直前に再確認します。承認と実行の間に数日の間隔があり得るためです。

- **日次締めとの関係**: 日次締め進行中の記帳遮断の可否、締め後の翌営業日付記帳の処理など、営業日切替(EOD cutover)ポリシーを明確にする必要があります。

外部連携マップ

与信パイプラインは外部機関との連携なしには成立しません。通常は対外系ゲートウェイで連携を一元化します。

+--------------------+

| 対外系ゲートウェイ |

LOS / CSS <--------->| (フォーマット変換, |

| リトライ, 履歴, |

| モニタリング) |

+---+----+----+----+-+

| | | |

+------------------+ | | +------------------+

v v v v

韓国信用情報院 NICE評価情報 KCB 保証機関

(信用情報集中機関) (個人CB) (個人CB) (住宅金融公社, 信用保証基金,

- 貸出/延滞情報の集中 - スコア/レポート照会技術保証基金, 地域信保など)

- 情報登録義務 - 法人CBは別系統 - 保証書の発行/照会

- 保証料の精算

+---------------------+--------------------+

v v v

マイデータ事業者行政ネットワーク連携金融決済院

(資産/負債の収集) (所得/在職確認など) (口座実名確認, 振込)

連携設計で押さえるべき点です。

- **照会と登録の双方向**: CBは照会するだけでなく、貸出実行・残高・延滞情報を信用情報集中機関に**登録**する義務があります。実行後の登録バッチが漏れると規制上の問題になります。

- **フォーマットとコードのマッピング**: 機関ごとに電文(固定長電文、XML、JSON)がバラバラなので、ゲートウェイで内部標準フォーマットに変換し、機関コードと内部コードのマッピングテーブルを管理します。

- **障害の隔離**: 機関別のサーキットブレーカーとキューベースのリトライを設け、必須連携(CB照会)と補強連携(付加情報)を区別して、必須でなければスキップ可能にします。

ステートマシン設計

申込案件の状態遷移はLOSの骨格です。状態と遷移をコードのあちこちのif文に散らばらせると保守が不可能になるため、明示的なステートマシンに集約します。

from enum import Enum

class AppState(str, Enum):

DRAFT = "DRAFT" # 作成中

SUBMITTED = "SUBMITTED" # 申込完了

SCREENING = "SCREENING" # 自動審査中

MANUAL_REVIEW = "MANUAL_REVIEW" # 手動審査中

APPROVED = "APPROVED" # 承認 (有効期間あり)

CONDITIONAL = "CONDITIONAL" # 条件付き承認

DECLINED = "DECLINED" # 否決

AGREED = "AGREED" # 約定締結

DISBURSED = "DISBURSED" # 実行完了

EXPIRED = "EXPIRED" # 承認有効期間切れ

CANCELLED = "CANCELLED" # 顧客による取消/撤回

TRANSITIONS: dict[AppState, set[AppState]] = {

AppState.DRAFT: {AppState.SUBMITTED, AppState.CANCELLED},

AppState.SUBMITTED: {AppState.SCREENING, AppState.CANCELLED},

AppState.SCREENING: {AppState.APPROVED, AppState.CONDITIONAL,

AppState.DECLINED, AppState.MANUAL_REVIEW},

AppState.MANUAL_REVIEW: {AppState.APPROVED, AppState.CONDITIONAL,

AppState.DECLINED},

AppState.CONDITIONAL: {AppState.APPROVED, AppState.DECLINED,

AppState.CANCELLED},

AppState.APPROVED: {AppState.AGREED, AppState.EXPIRED,

AppState.CANCELLED},

AppState.AGREED: {AppState.DISBURSED, AppState.CANCELLED},

AppState.DISBURSED: set(), # 以後はLMS(事後管理)の領域

AppState.DECLINED: set(),

AppState.EXPIRED: set(),

AppState.CANCELLED: set(),

}

def transit(app, to_state: AppState, actor: str, reason: str | None = None):

cur = AppState(app.state)

if to_state not in TRANSITIONS[cur]:

raise InvalidTransition(f"{cur} -> {to_state} is not allowed")

app.state = to_state

遷移履歴はappend-onlyテーブルへ: (app_id, from, to, actor, reason, ts)

append_history(app.id, cur, to_state, actor, reason)

実務上のヒントを付け加えます。

- **遷移履歴はappend-only**: 現在状態のカラムとは別に、誰がいつなぜ遷移させたのかを不変の履歴として残します。監査と苦情対応の基本です。

- **時間ベースの遷移はバッチで**: APPROVEDからEXPIREDへの遷移はユーザー操作ではなく日次バッチが実行します。バッチ漏れ時に期限切れの承認案件で実行が走る事故を防ぐため、実行時点の検証を二重に設けます。

- **否決理由のコード化**: DECLINEDには必ず構造化された理由コードを伴わせます。否決理由の告知義務への対応と、審査モデル改善のデータとして使われます。

再審査、条件変更、借り換え

再審査

承認有効期間の満了、仮審査と本審査の間の情報変更、増額リクエストなどは再審査を引き起こします。再審査は既存の申込案件の状態を巻き戻すのではなく、**新しい審査ラウンドを生成する**方式がきれいです。申込(application)の下に審査(assessment)を1:Nで持たせ、各審査ラウンドが自分専用のCB照会・スコア・ルールのスナップショットを持つようにします。

条件変更

実行後の期限延長、金利条件の変更、返済方式の変更などは「変更約定」として処理します。元の約定を修正するのではなく変更契約レコードを追加し、元帳の返済スケジュールは変更時点以降の区間だけを再生成します。過去の区間に手を入れると利息計算の履歴と会計が壊れるため、絶対に遡及修正しません。

借り換え(代換)

借り換え(refinancing)は、新規ローンの実行と既存ローンの完済が噛み合う複合トランザクションです。自行内の借り換えは内部トランザクションでまとめられますが、他行からの借り換えは、新規実行金を他行の返済口座へ振り込み、完済を確認する非同期フローになります。オンライン借り換えインフラのような中継システムを経由する場合は、完済確認コールバックの受信までを一つのサーガとして設計し、途中失敗時(振込はされたが完済確認が来ない場合)に手動介入キューへ落ちる経路を必ず設けます。

システム設計時の落とし穴

実際のプロジェクトで繰り返し見つかる落とし穴です。

1. **承認と実行の間の時間差の無視**: 承認時点の検証だけを信じて実行時点の再検証を省略すると、その間に別のローンが実行されてDSR・限度額が超過したまま記帳される事故が起きます。

2. **マスターデータ参照による根拠の喪失**: 顧客の所得、ルールバージョン、金利の構成要素をポインタとしてだけ持っていると、マスター更新時に過去の審査根拠を再現できなくなります。スナップショットが答えです。

3. **状態と履歴の混同**: 現在状態をUPDATEだけで管理して履歴を残さないと監査対応が不可能になります。逆に履歴テーブルから現在状態を毎回導出すると性能が崩壊します。両方必要です。

4. **同時実行を考慮しない限度額の引き当て**: 限度額の検証と引き当ての間にロックや予約がなければ、同時申込の二件が両方通ってしまいます。限度額予約レコード + 一意制約で防御します。

5. **外部連携タイムアウトの伝播**: CB一か所の30秒の遅延がスレッドプールを枯渇させ、全チャネル障害に波及するパターンです。連携別のプール隔離とサーキットブレーカーが必須です。

6. **金額計算への浮動小数点の使用**: 利息・手数料の計算にfloatを使うと、最小単位レベルの誤差が発生します。必ず整数(最小通貨単位)または固定小数点(decimal)型を使い、切り捨て・四捨五入のルールを商品条件として明示します。

7. **テスト環境における外部機関の不在**: CB・保証機関のテスト網はケースが限られています。連携レスポンスをシナリオ別に再生できるシミュレーターを初期に作っておかないと、結合テストがボトルネックになります。

テストシナリオ

与信システムのテストは、ハッピーパスよりも境界と同時実行に集中すべきです。代表的なシナリオを挙げると次のとおりです。

| 領域 | シナリオ | 期待結果 |

| --- | --- | --- |

| 審査 | CB照会タイムアウト後の再試行 | 重複照会なしで1回のみ記録、再試行成功 |

| 審査 | ポリシールール施行日の境界(改正前日/当日の申込) | 申込日基準で正しいルールバージョンを適用 |

| 限度額 | 同一顧客の同時申込2件 | 予約により1件のみ通過、または合算検証 |

| 承認 | 有効期間満了の翌日に実行を試行 | 実行拒否、EXPIRED遷移を確認 |

| 実行 | 記帳中に元帳レスポンス喪失後の再試行 | 冪等キーで二重記帳を防止 |

| 実行 | 仕訳成功、振込失敗 | 補償トランザクションで原状回復、アラート発生 |

| 借り換え | 他行完済確認コールバック未受信 | 手動介入キューへ積載、状態は保留を維持 |

| 金利 | 再設定日と基準金利公示日の境界 | 商品説明書と同一の公示値を適用 |

| 担保 | 先順位の変動後の再評価 | 有効担保価額/LTVの再計算の正確性 |

| 日次締め | 締め処理中の記帳リクエスト | ポリシーどおり遮断または翌営業日付で処理 |

これに加えて、審査ルールの変更をデプロイする前に過去の申込案件を新ルールに流す**バックテスト(シャドー評価)**環境があれば、承認率・否決率の変化を事前に定量化でき、運用リスクが大きく減ります。

おわりに

与信システムは、「ローン一件」という一見シンプルな概念の裏に、審査、限度額、担保、金利、元帳、外部連携が精緻に噛み合ったドメインです。本稿で扱ったLOS区間の核心を一行に要約すると — **すべての意思決定をスナップショットで再現可能にし、状態遷移を一元化し、お金が動く区間は冪等に設計せよ** — ということになります。

次回は審査の頭脳にあたる信用評価システム(CSS)の内部 — スコアカード、MLモデル、意思決定エンジン — を扱い、その次の回で実行以後の世界である事後管理(延滞、引当金、NPL)を見ていきます。改めて、本稿は技術アーキテクチャの解説であり、金融商品の勧誘や法律上の助言ではないことを明記します。

参考資料

- [BIS — Basel Framework (CRE: Credit Risk)](https://www.bis.org/basel_framework/)

- [BIS — Large Exposures Framework (LEX)](https://www.bis.org/bcbs/publ/d283.htm)

- [金融監督院(韓国)](https://www.fss.or.kr/)

- [金融委員会(韓国)](https://www.fsc.go.kr/)

- [韓国信用情報院](https://www.kcredit.or.kr/)

- [金融決済院(KFTC)](https://www.kftc.or.kr/)

- [NICE評価情報](https://www.niceinfo.co.kr/)

- [コリアクレジットビューロー(KCB)](https://www.koreacb.com/)

- [韓国住宅金融公社](https://www.hf.go.kr/)

- [国家法令情報センター — 銀行法/信用情報法の検索](https://www.law.go.kr/)

- [ISO 20022 — Universal Financial Industry Message Scheme](https://www.iso20022.org/)