LabHub

블로그

여신 사후관리 시스템 — 연체, 충당금, NPL의 데이터 흐름

2026-06-13 · 46 분 읽기 · #lending#loan-servicing#delinquency#npl#ifrs9#core-banking#fintech

한국어English日本語

들어가며

앞선 글에서 LOS(대출의 탄생)와 CSS(심사의 두뇌)를 다뤘습니다. 그런데 여신 시스템에서 코드 줄 수가 가장 많고, 배치가 가장 복잡하고, 감사가 가장 자주 들여다보는 곳은 사실 실행 이후의 세계 — 사후관리(LMS, Loan Management System) 영역입니다. 대출은 실행되는 순간부터 수년간 매일 이자가 붙고, 매달 상환이 들어오고, 일부는 연체되고, 그중 일부는 부실채권(NPL)이 되어 상각되거나 매각됩니다. 이 모든 흐름이 원장, 회계, 충당금, 감독 보고와 정합성을 유지해야 합니다.

사후관리 시스템이 어려운 이유는 "시간"이 일급 시민이기 때문입니다. 모든 금액은 기준일자에 종속되고, 어제의 처리 결과가 오늘의 입력이 되며, 과거를 소급해서 고치는 순간 그 위에 쌓인 모든 계산이 무너집니다. 이 글에서는 상환 스케줄 생성부터 연체 관리, 자산건전성 분류와 충당금, 추심, NPL 처리, 채무조정, 감독 보고까지 — 대출의 "그 이후"를 시스템 관점에서 끝까지 따라가 봅니다.

미리 밝혀두면, 이 글은 시스템 아키텍처와 도메인에 대한 기술 해설이며 특정 금융상품 권유나 투자/법률 자문이 아닙니다. 규제·회계 관련 내용은 작성 시점의 일반적인 이해를 바탕으로 하므로, 실제 적용 시에는 반드시 준법감시·회계·법무 부서의 검토를 거치시기 바랍니다.

사후관리 도메인 지형도

대출 계좌가 실행된 뒤 관여하는 시스템들을 한눈에 보면 다음과 같습니다.

                  +--------------------------------------+
                  |        여신 원장 (Loan Ledger)        |
                  |  계좌 마스터 / 상환 스케줄 / 거래내역 |
                  +---+--------+--------+--------+-------+
                      |        |        |        |
        +-------------+        |        |        +--------------+
        v                      v        v                       v
+---------------+  +----------------+  +-----------+  +----------------+
| 이자/상환 처리 |  | 연체 관리      |  | 건전성    |  | 충당금 엔진     |
| - 일이자 계상  |  | - 버킷 전이    |  | 분류      |  | - IFRS 9 ECL   |
| - 수납/충당    |  | - 연체이자     |  | - 5단계   |  | - Stage 판정   |
| - 중도상환     |  | - 기한이익상실 |  | - FLC     |  | - 회계 연동    |
+---------------+  +-------+--------+  +-----------+  +----------------+
                           |
              +------------+-------------+
              v                          v
       +--------------+         +----------------+
       | 추심 시스템   |         | NPL 처리       |
       | - 콜 배분     |         | - 상각(write-off)
       | - 약속(PTP)   |         | - 매각(Pool 구성)
       | - 행위 규제   |         | - 채무조정 반영 |
       +--------------+         +----------------+
              |                          |
              +------------+-------------+
                           v
              +--------------------------+
              | 감독 보고 / 정보계        |
              | - 업무보고서, 연체율      |
              | - 신용정보 집중기관 등록  |
              +--------------------------+

각 박스가 별도 시스템일 수도, 하나의 LMS 안의 모듈일 수도 있지만, 데이터 흐름의 방향은 같습니다. 원장이 사실(facts)의 원천이고, 연체·분류·충당금·추심·보고는 모두 원장에서 파생됩니다. 파생 시스템이 원장과 다른 숫자를 들고 있는 순간부터 사고가 시작됩니다.

상환 스케줄 생성

실행(기표) 시점에 가장 먼저 만들어지는 산출물이 상환 스케줄입니다. 상환 방식은 크게 세 가지입니다.

방식매월 납입액원금 상환 패턴총이자주 용도
원리금균등일정초기엔 적고 후기에 증가중간주택담보, 가계신용
원금균등점차 감소매월 동일가장 적음기업 시설자금 등
만기일시이자만 납입만기에 전액가장 많음한도성, 단기, 전세자금

세 방식의 계산을 코드로 보면 다음과 같습니다. 금액 계산에는 반드시 decimal을 쓰고, 절사·반올림 규칙을 상품 조건으로 명시해야 합니다.

from decimal import Decimal, ROUND_DOWN, ROUND_HALF_UP

WON = Decimal("1")  # 원 단위 절사용

def round_won(amount: Decimal, mode=ROUND_DOWN) -> Decimal:
    """원 단위 처리. 절사/반올림은 상품 조건에 따름."""
    return amount.quantize(WON, rounding=mode)

def equal_installment(principal: Decimal, annual_rate: Decimal,
                      months: int) -> list[dict]:
    """원리금균등: 매월 납입액이 동일.
    납입액 = P * r * (1+r)^n / ((1+r)^n - 1), r = 월이율
    """
    r = annual_rate / Decimal("12")
    factor = (Decimal("1") + r) ** months
    payment = round_won(principal * r * factor / (factor - Decimal("1")),
                        ROUND_HALF_UP)
    schedule, balance = [], principal
    for seq in range(1, months + 1):
        interest = round_won(balance * r)
        principal_due = payment - interest
        if seq == months:               # 마지막 회차에서 끝수 조정
            principal_due = balance
            payment = principal_due + interest
        balance -= principal_due
        schedule.append({"seq": seq, "payment": payment,
                         "principal": principal_due,
                         "interest": interest, "balance": balance})
    return schedule

def equal_principal(principal: Decimal, annual_rate: Decimal,
                    months: int) -> list[dict]:
    """원금균등: 매월 원금 상환액이 동일, 이자는 잔액 기준."""
    r = annual_rate / Decimal("12")
    base_principal = round_won(principal / Decimal(months))
    schedule, balance = [], principal
    for seq in range(1, months + 1):
        interest = round_won(balance * r)
        principal_due = base_principal if seq < months else balance
        balance -= principal_due
        schedule.append({"seq": seq,
                         "payment": principal_due + interest,
                         "principal": principal_due,
                         "interest": interest, "balance": balance})
    return schedule

def bullet(principal: Decimal, annual_rate: Decimal,
           months: int) -> list[dict]:
    """만기일시: 매월 이자만, 만기에 원금 전액."""
    r = annual_rate / Decimal("12")
    schedule = []
    for seq in range(1, months + 1):
        interest = round_won(principal * r)
        principal_due = principal if seq == months else Decimal("0")
        schedule.append({"seq": seq,
                         "payment": principal_due + interest,
                         "principal": principal_due,
                         "interest": interest,
                         "balance": principal - principal_due})
    return schedule

실무에서 챙겨야 할 디테일이 몇 가지 있습니다.

상환 처리 — 정상, 중도, 일부

수납과 충당 순서

상환 처리의 핵심은 들어온 돈을 어디에 먼저 꽂을 것인가, 즉 충당 순서(appropriation order) 입니다. 일반적인 순서는 비용(법적 비용 등), 이자(연체이자 포함), 원금 순이지만, 약정과 내부 정책에 따라 달라질 수 있으므로 코드에 하드코딩하지 말고 상품/계좌 속성으로 외부화해야 합니다.

from decimal import Decimal

def apply_payment(received: Decimal, dues: dict) -> dict:
    """수납액을 충당 순서대로 배분. dues는 기준일 현재 미수 항목."""
    order = ["fees", "overdue_interest", "interest", "principal"]
    applied = {}
    remaining = received
    for bucket in order:
        due = dues.get(bucket, Decimal("0"))
        take = min(remaining, due)
        applied[bucket] = take
        remaining -= take
        if remaining <= Decimal("0"):
            break
    applied["unapplied"] = remaining   # 잔여액은 선수금 처리
    return applied

배분 결과는 회계 분개와 1:1로 대응되어야 하며(이자 수익, 원금 회수, 가수금 등), 잔여액(선수금)의 처리는 다음 회차 자동 충당인지 즉시 반환인지 정책으로 정해 둡니다.

중도상환

만기 전에 원금의 전부 또는 일부를 갚는 것이 중도상환입니다. 시스템 관점의 처리는 다음과 같습니다.

중도상환수수료 (예시 구조)

수수료 = 중도상환원금 x 요율 x (만기까지 잔여일수 / 대출 총일수)

예: 잔액 1억 원 중 5천만 원 상환, 요율 1.2%,
    총기간 1,095일 중 365일 경과 (잔여 730일)
  수수료 = 50,000,000 x 0.012 x (730 / 1,095)
         = 400,000원

자동이체와 수납 채널

상환 수납은 자동이체(CMS), 가상계좌, 창구, 앱 즉시출금 등 여러 채널로 들어옵니다. 채널마다 수납 확정 시점이 다르므로(자동이체는 출금 결과 파일이 도착해야 확정), "수납 접수"와 "수납 확정"을 상태로 분리하고, 확정 전 금액이 연체 판정에 잘못 반영되지 않도록 기준일 처리에 주의해야 합니다. 납입일이 휴일이면 다음 영업일로 이연되는데, 이연된 날까지는 연체로 보지 않는 휴일 규칙도 스케줄 엔진이 알아야 합니다.

연체 관리

연체 버킷과 단계 전이

납입일에 돈이 들어오지 않으면 연체가 시작됩니다. 운영은 연체 일수를 버킷으로 끊어 관리합니다.

연체 버킷 전이 (일배치가 매일 판정)

 정상(Current) --미납 발생--> 1~29일 (Bucket 1, 초기 연체)
      ^                          |
      | 전액 정상화              v
      +<----------- 30~59일 (Bucket 2)
      |                          |
      |                          v
      +<----------- 60~89일 (Bucket 3)
      |                          |
      |                          v
      +<-----?----- 90일 이상 (부도/Default 인식 구간)
                                 |
                                 v
                        기한이익상실(EOD: Event of Default)
                                 |
                                 v
                  전액 즉시 상환 의무 / 추심 강화 / NPL 트랙

설계 포인트는 다음과 같습니다.

연체이자 계산

연체가 발생하면 약정이자 대신(또는 더해서) 연체이자가 붙습니다. 한국 실무에서 일반적인 구조는 "약정금리 + 연체가산금리(상한 규제 있음)"이며, 연체이자율은 법정 최고금리를 넘을 수 없습니다.

연체이자 계산 (일반적 구조의 예시)

연체이자율 = MIN(약정금리 + 연체가산금리, 법정 상한)

(1) 기한이익상실 전: 연체된 "그 회차의 미납액" 기준
    연체이자 = 미납 약정 납입액 x 연체이자율 x 연체일수 / 365

(2) 기한이익상실 후: "원금 잔액 전체" 기준
    연체이자 = 원금 잔액 x 연체이자율 x 경과일수 / 365

예: 미납 납입액 100만 원, 약정금리 5%, 가산 3% -> 연체이자율 8%
    연체 40일이면
  연체이자 = 1,000,000 x 0.08 x 40 / 365 = 8,767원 (절사 규칙 적용)

기한이익상실 전후로 계산 모수 자체가 바뀐다는 점이 시스템 구현의 핵심입니다. 전이 시점이 하루 어긋나면 연체이자가 통째로 달라지므로, 기한이익상실 처리일은 배치 산출이 아니라 명시적 이벤트 레코드로 박제해야 합니다.

기한이익상실

기한이익상실은 "남은 기간 동안 나눠 갚을 권리(기한의 이익)"를 차주가 잃고 전액 즉시 상환 의무가 생기는 법적 이벤트입니다. 일반적으로 일정 기간 이상의 연체(약정상 통지 요건 포함), 담보 가치의 현저한 하락, 차주의 신용 악화 사유 등으로 발생하며, 발생 전 고객 통지(예고 통지, 도래 통지) 의무가 있습니다.

시스템 관점의 처리는 다음과 같습니다.

  1. 대상 추출 배치: 연체 일수·사유 조건을 만족하는 계좌를 후보로 추출
  2. 통지 발송과 회신 대기: 통지 이력을 법적 증빙 수준으로 보관(발송 일시, 수단, 반송 여부)
  3. 기한이익상실 확정: 이벤트 레코드 생성, 계좌 상태 전이, 연체이자 계산 모수 전환
  4. 후속 연동: 신용정보 집중기관 등록, 보증기관 사고 통지(보증부 대출), 추심 강화 트랙 진입

기한이익상실 이후 고객이 연체금을 전액 정상화하면 기한이익이 부활하는 경우가 있는데, 이 부활 처리(계산 모수의 원복, 스케줄 복원)는 상실 처리보다 구현 난도가 높고 버그도 많은 지점입니다. 부활 가능 조건과 횟수 제한을 정책으로 명확히 해 두어야 합니다.

자산건전성 분류 — 5단계

감독 규정상 금융회사는 보유 여신을 차주의 상환 능력과 연체 상태에 따라 5단계로 분류합니다. 이른바 자산건전성 분류이며, 한국 감독 체계의 전통적인 분류는 다음과 같습니다.

단계명칭통상적 기준(개략)의미
1정상연체 없음, 상환 능력 양호회수 확실
2요주의1개월 이상 3개월 미만 연체 등잠재 위험
3고정3개월 이상 연체, 회수 의문이나 담보 범위 내회수에 상당한 위험
4회수의문고정 중 담보 초과 부분 등회수 불확실
5추정손실사실상 회수 불능손실 확정적

두 가지를 주의해야 합니다.

분류 결과는 최저 적립률 기반의 감독 목적 충당금과 연결되고(정상 일정 비율, 요주의·고정·회수의문·추정손실로 갈수록 높은 비율), 회계 목적의 IFRS 9 기대신용손실과는 별도의 체계로 병행 운영됩니다. 시스템은 두 체계를 모두 산출하고, 통상 둘 중 보수적인(큰) 쪽이 재무에 반영되는 구조를 지원해야 합니다.

충당금 — IFRS 9 기대신용손실

3단계 모델

IFRS 9의 기대신용손실(ECL, Expected Credit Loss)은 "손실이 발생한 뒤 적립"하던 과거 발생손실 모형을 "미래 손실을 미리 추정해 적립"하는 모형으로 바꿨습니다. 핵심은 Stage 구분입니다.

IFRS 9 ECL 3단계

 Stage 1                Stage 2                  Stage 3
 (정상)                 (신용위험 유의적 증가)    (신용 손상)
 12개월 ECL 적립        전 생애(Lifetime) ECL     전 생애 ECL
 이자수익: 총장부금액    이자수익: 총장부금액      이자수익: 순장부금액
 기준                   기준                      (장부금액 - 충당금) 기준

 전이 트리거(예):
  Stage 1 -> 2 : 30일 이상 연체(반증 가능 추정),
                 신용등급의 유의적 하락, 워치리스트 등재 등 (SICR)
  Stage 2 -> 3 : 90일 이상 연체, 기한이익상실,
                 채무조정(신용 손상 인식) 등
  회복 방향    : 치유 기간(probation) 경과 후 상향

ECL 계산의 뼈대

ECL = SUM over t [ PD(t) x LGD(t) x EAD(t) x 할인계수(t) ]

  - Stage 1: t = 향후 12개월
  - Stage 2/3: t = 잔존 만기 전체 (Lifetime)
  - 거시경제 시나리오(낙관/기준/비관)별로 산출해 확률 가중
  - PD/LGD/EAD는 CSS·IRB 체계의 파라미터를 회계 목적으로 변형

시스템 구현 관점

추심 시스템

콜 배분과 작업 큐

연체가 발생하면 추심(컬렉션) 시스템이 회수 활동을 조직합니다. 구조는 본질적으로 "우선순위가 있는 작업 큐 + 행위 규제 엔진"입니다.

연체 계좌 인입 (일배치)
   |
   v
세그먼테이션
  - 연체 버킷, 회수평점(Collection Score), 금액, 상품
  - 자체 추심 / 위탁 추심 / 법적 절차 트랙 분리
   |
   v
캠페인/큐 배분
  - 초기(1~29일): 문자/앱 알림 중심, 저비용 채널
  - 중기(30~89일): 상담원 콜 배분, 약속 관리
  - 후기(90일~): 전담 조직, 법적 절차 검토
   |
   v
상담원 워크리스트
  - 통화 결과 코드, 약속(PTP) 등록, 다음 액션 일정

추심 행위 규제 준수

채권 추심은 채권의 공정한 추심에 관한 법률 등으로 행위가 강하게 규제되는 영역입니다. 시스템이 규제를 코드로 강제해야 사람의 실수를 막을 수 있습니다.

채무조정의 시스템 반영

연체 차주의 재기를 지원하는 채무조정은 외부 제도(신용회복위원회의 채무조정, 법원의 개인회생·파산)와 금융회사 자체 프로그램(만기 연장, 금리 감면, 분할상환 전환 등)으로 나뉩니다. 시스템 관점에서는 공통적으로 다음 처리가 필요합니다.

  1. 원 채권의 동결과 조정 조건의 신규 스케줄 생성: 감면된 금리, 연장된 만기로 새 상환 스케줄을 만들되, 원 약정 조건과 조정 이력을 모두 보존합니다. 원 레코드를 덮어쓰면 안 됩니다.
  2. 회계·충당금 연동: 채무조정은 통상 신용 손상(Stage 3) 인식 사유이며, 조건 변경으로 인한 장부금액 조정(현재가치 재계산)이 발생할 수 있습니다. 조정 유형별 회계 처리 룰을 충당금 엔진과 공유해야 합니다.
  3. 건전성 분류와 치유 기간: 조정 후 일정 기간 성실 상환하면 분류를 상향할 수 있는데, 이 치유 기간 동안의 상환 이행 추적이 시스템 요건이 됩니다.
  4. 추심 동결과 신용정보 처리: 조정 확정 시 추심을 중단하고, 신용정보 집중기관에 약정 변경·연체 해제 정보를 등록 기한 내에 반영합니다.

NPL 상각과 매각

회수 가능성이 사실상 없는 채권은 두 가지 출구로 나갑니다.

상각(Write-off)

상각은 회계 장부에서 채권을 제거하는 처리입니다(통상 충당금과 상계). 중요한 것은 상각이 채권의 소멸이 아니라는 점입니다. 법적 청구권은 살아 있으므로, 상각 후에도 "상각채권 관리 원장"에서 잔액·시효·회수 활동을 계속 추적합니다. 상각 후 회수가 발생하면 수익(상각채권 회수이익)으로 인식하는 별도 분개 경로가 필요합니다. 소멸시효(통상 상사채권 5년) 관리와 시효 중단 사유(가압류, 소송, 일부 변제 등) 추적도 이 원장의 몫입니다.

매각(NPL Sale)

부실채권을 묶어 NPL 전문 투자자나 유동화 구조에 파는 것이 매각입니다.

NPL 매각 파이프라인

풀(Pool) 구성        실사(Due Diligence)      낙찰/양도 실행
  - 대상 채권 추출      - 데이터 테이프 제공      - 채권양도 계약
  - 제외 조건 필터        (차주/담보/연체 이력)   - 양도 통지 (대항요건)
    (조정 중, 소송 중,  - 입찰가 산정             - 원장 제각 처리
     보증부 등)         - Q&A 대응                - 사후 정산
                                                   (기준일 이후 회수금)

시스템 요건은 다음과 같습니다.

감독 보고와 정보계 연동

사후관리 데이터는 다양한 감독 보고의 원천입니다.

데이터 모델

핵심 엔티티를 ERD로 요약하면 다음과 같습니다.

+---------------+       +--------------------+       +-------------------+
| LOAN_ACCOUNT  |1-----N| REPAY_SCHEDULE     |       | RATE_HISTORY      |
|---------------|       |--------------------|       |-------------------|
| account_id PK |       | account_id FK      |       | account_id FK     |
| product_cd    |       | seq, due_date      |       | from_date, rate   |
| principal     |       | principal_due      |       | reason_cd         |
| open_date     |       | interest_due       |       +-------------------+
| maturity_date |       | status (예정/완납/  |
| status        |       |   부분납/연체)      |       +-------------------+
| repay_method  |       | version_no         |1-----N| TXN_HISTORY       |
+------+--------+       +--------------------+       |-------------------|
       |                                             | txn_id PK         |
       |1                                            | account_id FK     |
       |                                             | txn_date, type    |
       N                                             | amount, applied_to|
+---------------+       +--------------------+       | (비용/이자/원금)   |
| DELINQ_EPISODE|1-----N| BUCKET_TRANSITION  |       +-------------------+
|---------------|       |--------------------|
| episode_id PK |       | episode_id FK      |       +-------------------+
| account_id FK |       | trans_date         |       | CLASSIFICATION    |
| start_date    |       | from_bucket        |       |-------------------|
| end_date      |       | to_bucket          |       | account_id FK     |
| eod_flag      |       +--------------------+       | base_date         |
| eod_date      |                                    | class_cd (5단계)   |
+------+--------+       +--------------------+       | split_amount      |
       |1               | COLLECTION_ACTION  |       | reason_cd         |
       |                |--------------------|       +-------------------+
       N                | action_id PK       |
+---------------+       | episode_id FK      |       +-------------------+
| PTP_PROMISE   |       | channel, result_cd |       | ECL_RESULT        |
|---------------|       | action_ts, agent   |       |-------------------|
| promise_id PK |       +--------------------+       | account_id FK     |
| episode_id FK |                                    | base_date, stage  |
| promise_date  |                                    | ecl_amount        |
| promise_amt   |                                    | model_ver         |
| kept_yn       |                                    | scenario_set_id   |
+---------------+                                    +-------------------+

모델링 원칙 몇 가지를 덧붙입니다.

배치 설계 — 일배치와 월배치

사후관리는 배치의 세계입니다. 의존 관계가 생명입니다.

일배치 (EOD) — 순서가 곧 정합성

  01 수납 확정 처리 (자동이체 결과 반영)
  02 일이자 계상 (미수이자 적수)
  03 연체 판정 / 버킷 전이      <- 02 이후 (당일 수납 반영 후)
  04 연체이자 계산              <- 03 이후 (버킷/EOD 상태 확정 후)
  05 기한이익상실 후보 추출/통지
  06 추심 큐 적재/회수          <- 03, 05 이후
  07 신용정보 등록 전문 생성
  08 원장-회계 대사 (일마감)
  09 정보계 적재

월배치 (월마감)

  M1 우대금리 조건 재판정        <- 다음 이자 주기 전
  M2 행동평점/회수평점 산출
  M3 자산건전성 분류             <- 연체/담보 데이터 확정 후
  M4 IFRS 9 Stage 판정 / ECL 산출 <- M2, M3 이후
  M5 충당금 회계 분개 / 결산 연동
  M6 감독 보고서 산출            <- M3, M4, M5 이후
  M7 빈티지/롤레이트 분석 마트 적재

배치 설계에서 반복적으로 강조할 점은 세 가지입니다.

함정 — 소급 재계산의 유혹

사후관리 시스템에서 가장 위험한 안티패턴을 모았습니다.

  1. 소급 재계산: "금리 적용이 잘못됐으니 과거 6개월 이자를 다시 계산해서 덮어쓰자"는 요구는 반드시 옵니다. 절대 과거 레코드를 덮어쓰면 안 됩니다. 과거 거래는 그대로 두고, 차액을 별도 정산 거래(환급 또는 추가 청구)로 일으키는 조정 거래 패턴을 표준으로 삼아야 합니다. 덮어쓰는 순간 회계 마감, 보고서, 신용정보 등록, 고객 명세가 전부 어긋납니다.
  2. 연체 일수 계산기의 중복: 원장, 추심, 충당금이 각자 연체 일수를 계산하다 하루씩 어긋나는 사고가 흔합니다. 단일 모듈로 강제하고, 파생 시스템은 결과를 구독만 하게 합니다.
  3. 기한이익상실 상태의 암묵 관리: "연체 90일 넘으면 상실로 간주" 같은 유도 로직으로 처리하면, 통지 요건·부활 처리와 어긋납니다. 명시적 이벤트와 상태로 관리해야 합니다.
  4. 수납 확정 전 금액의 선반영: 자동이체 출금 결과가 오기 전에 수납으로 간주하면, 출금 실패 시 연체 판정·추심 제외가 전부 뒤집힙니다. 접수와 확정의 분리가 답입니다.
  5. 버킷 전이의 시계열 미보존: 현재 버킷만 갱신하면 롤레이트 분석이 불가능해지고, 충당금 모델의 입력 데이터도 사라집니다.
  6. 마감 후 데이터 수정: 월마감 스냅샷이 나간 뒤 원천을 고치면 보고서와 원장이 다른 숫자를 갖게 됩니다. 수정은 다음 기수의 조정으로 반영하고, 예외적 소급은 재제출 절차와 함께 통제합니다.
  7. 시효 관리 누락: 상각채권의 소멸시효를 시스템이 추적하지 않으면, 시효 완성 채권에 대한 추심으로 법적 리스크가 발생합니다. 시효 기산일·중단 사유를 데이터로 관리해야 합니다.

설계 체크리스트

마치며

사후관리 시스템은 화려하지 않습니다. 신규 가입자 수 같은 지표도 없고, 잘 돌아갈수록 조용합니다. 그러나 대출이라는 비즈니스의 손익은 결국 여기서 결정됩니다 — 연체를 얼마나 빨리 정확하게 식별하는가, 충당금을 얼마나 신뢰성 있게 산출하는가, 회수를 얼마나 규제 안에서 효율적으로 하는가. 이 글의 핵심을 한 줄로 줄이면 이렇습니다. 시간을 명시적으로 다루고(기준일, 버전, 에피소드), 과거를 절대 덮어쓰지 말고(조정 거래), 파생 숫자는 단일 원천에서만 흘러나오게 하라(원장 중심).

이것으로 여신 시리즈 — LOS(탄생), CSS(심사), 사후관리(그 이후) — 가 한 바퀴 돌았습니다. 다시 한번, 본 글은 기술 아키텍처 해설이며 금융상품 권유나 투자/법률/회계 자문이 아닙니다.

참고 자료

원문 보기: https://www.youngju.dev/blog/finance/2026-06-13-loan-servicing-delinquency-npl-systems

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다