Introduction
In the previous posts we covered the LOS (the birth of a loan) and the CSS (the brain of underwriting). Yet the place in a lending system with the most lines of code, the most intricate batches, and the most frequent audit attention is actually the world after disbursement — the servicing domain, often called the LMS (Loan Management System). From the moment a loan is funded, interest accrues daily for years, payments arrive monthly, some loans slip into delinquency, and a fraction of those become non-performing loans (NPL) that are written off or sold. Every step of this flow must stay consistent with the ledger, accounting, provisions, and supervisory reporting.
What makes servicing systems hard is that "time" is a first-class citizen. Every amount is bound to an as-of date, yesterday's processing output becomes today's input, and the moment you retroactively edit the past, every calculation stacked on top of it collapses. In this post we follow the loan all the way through its "afterlife" — schedule generation, payment processing, delinquency management, asset quality classification and provisioning, collections, NPL handling, debt restructuring, and supervisory reporting — from a systems perspective.
A disclaimer up front: this is a technical explanation of system architecture and domain concepts, not a solicitation for financial products nor investment or legal advice. Regulatory and accounting content reflects a general understanding as of the time of writing; for real applications, always obtain review from your compliance, accounting, and legal teams.
A Map of the Servicing Domain
Here are the systems involved once a loan account has been funded.
+--------------------------------------+
| Loan Ledger |
| Account master / repayment schedule / |
| transaction history |
+---+--------+--------+--------+-------+
| | | |
+-------------+ | | +--------------+
v v v v
+---------------+ +----------------+ +-----------+ +----------------+
| Interest & | | Delinquency | | Asset | | Provisioning |
| payment proc. | | management | | quality | | engine |
| - daily accrual| | - bucket moves | | classif. | | - IFRS 9 ECL |
| - receipts / | | - overdue int. | | - 5 grades| | - stage logic |
| appropriation| | - acceleration | | - FLC | | - accounting |
| - prepayment | +-------+--------+ +-----------+ +----------------+
+---------------+ |
+------------+-------------+
v v
+--------------+ +----------------+
| Collections | | NPL handling |
| - call routing| | - write-off |
| - PTP promises| | - sale (pools) |
| - conduct | | - restructuring|
| regulation | | integration |
+--------------+ +----------------+
| |
+------------+-------------+
v
+--------------------------+
| Supervisory reporting / |
| data warehouse |
| - regulatory returns, |
| delinquency ratios |
| - credit registry filing |
+--------------------------+
Each box may be a separate system or a module inside one LMS, but the direction of data flow is the same. The ledger is the source of facts; delinquency, classification, provisions, collections, and reporting are all derived from it. The moment a derived system carries numbers different from the ledger, the incident has already begun.
Generating the Repayment Schedule
The first artifact created at disbursement (booking) time is the repayment schedule. There are three main repayment methods.
| Method | Monthly payment | Principal pattern | Total interest | Typical use |
| --- | --- | --- | --- | --- |
| Equal installment (annuity) | Constant | Small early, grows later | Medium | Mortgages, retail credit |
| Equal principal | Decreases over time | Same every month | Lowest | Corporate facility loans |
| Bullet (interest-only) | Interest only | All at maturity | Highest | Credit lines, short-term, lease-deposit loans |
Here is the calculation for all three in code. Money math must use decimals, and truncation/rounding rules must be specified as product terms.
from decimal import Decimal, ROUND_DOWN, ROUND_HALF_UP
UNIT = Decimal("1") # round to the minor currency unit
def round_unit(amount: Decimal, mode=ROUND_DOWN) -> Decimal:
"""Minor-unit handling. Truncate or round per product terms."""
return amount.quantize(UNIT, rounding=mode)
def equal_installment(principal: Decimal, annual_rate: Decimal,
months: int) -> list[dict]:
"""Equal installment: identical payment every month.
payment = P * r * (1+r)^n / ((1+r)^n - 1), r = monthly rate
"""
r = annual_rate / Decimal("12")
factor = (Decimal("1") + r) ** months
payment = round_unit(principal * r * factor / (factor - Decimal("1")),
ROUND_HALF_UP)
schedule, balance = [], principal
for seq in range(1, months + 1):
interest = round_unit(balance * r)
principal_due = payment - interest
if seq == months: # residual adjustment on final term
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]:
"""Equal principal: same principal each month, interest on balance."""
r = annual_rate / Decimal("12")
base_principal = round_unit(principal / Decimal(months))
schedule, balance = [], principal
for seq in range(1, months + 1):
interest = round_unit(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]:
"""Bullet: interest only each month, full principal at maturity."""
r = annual_rate / Decimal("12")
schedule = []
for seq in range(1, months + 1):
interest = round_unit(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
Several practical details deserve attention.
- **Residual adjustment**: Per-term truncation errors accumulate, so the final term is adjusted against the remaining balance. It is normal for the last payment to differ from the others by a small amount; never "fix" this by tampering with intermediate terms.
- **Day-count rules**: The example above is monthly, but many products accrue interest daily over the actual days between payment dates (365/366, leap-year handling). The day-count convention (actual/365 and friends) must be an attribute of the product master.
- **Grace periods**: During an interest-only grace period, only interest is paid; principal amortization begins after it ends. The schedule generator must accept the grace segment and the amortizing segment as separate parameters.
- **Floating-rate repricing**: When the rate changes, regenerate only the remaining terms. Terms already past are never recalculated — a principle we revisit in the "pitfalls" section.
Payment Processing — Regular, Early, Partial
Receipts and the Appropriation Order
The heart of payment processing is deciding where incoming money lands first — the **appropriation order**. The common order is costs (legal expenses and the like), then interest (including overdue interest), then principal, but it can vary by contract and internal policy, so externalize it as a product/account attribute rather than hardcoding it.
from decimal import Decimal
def apply_payment(received: Decimal, dues: dict) -> dict:
"""Distribute a receipt along the appropriation order.
dues holds the outstanding items as of the base date."""
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 # residual goes to suspense/prepaid
return applied
The distribution result must map one-to-one onto accounting entries (interest income, principal recovery, suspense receipts, etc.), and policy must define whether residual amounts are auto-applied to the next installment or refunded immediately.
Prepayment
Repaying all or part of the principal before maturity is prepayment. The system-level handling:
- **Full prepayment (payoff)**: Compute accrued daily interest up to the base date plus the principal balance plus the prepayment fee, collect it, and transition the account to closed. For secured loans, collateral release (mortgage discharge) follows as a downstream process.
- **Partial prepayment**: After the principal balance drops, the customer chooses what happens to the remaining schedule — lower the per-term payment and keep the maturity, or keep the payment and shorten the maturity. Either way, only future terms are regenerated.
- **Prepayment fee**: A sliding formula of the form "prepaid principal x fee rate x remaining tenor / total tenor" is typical, with waiver windows (e.g., after 3 years from funding) and waiver conditions captured as product attributes.
Prepayment fee (example structure)
fee = prepaid principal x rate x (days remaining to maturity / total days)
Example: repaying 50,000,000 KRW out of a 100,000,000 KRW balance,
rate 1.2%, 365 of 1,095 total days elapsed (730 remaining)
fee = 50,000,000 x 0.012 x (730 / 1,095)
= 400,000 KRW
Direct Debit and Receipt Channels
Repayments arrive through multiple channels — direct debit (CMS), virtual accounts, branch counters, in-app instant withdrawal. Each channel confirms receipts at a different moment (a direct debit is only confirmed when the debit result file arrives), so separate "receipt accepted" from "receipt confirmed" as states, and be careful that unconfirmed amounts do not leak into delinquency determination on the base date. When a due date falls on a holiday it defers to the next business day, and the schedule engine must know the holiday rule that no delinquency arises through the deferred date.
Delinquency Management
Delinquency Buckets and Stage Transitions
When money fails to arrive on the due date, delinquency begins. Operations manage it by cutting days past due into buckets.
Delinquency bucket transitions (judged daily by the EOD batch)
Current --missed payment--> 1-29 days (Bucket 1, early delinquency)
^ |
| fully cured v
+<----------- 30-59 days (Bucket 2)
| |
| v
+<----------- 60-89 days (Bucket 3)
| |
| v
+<-----?----- 90+ days (default recognition zone)
|
v
Acceleration of maturity (Event of Default)
|
v
full balance immediately due / intensified collections / NPL track
Design points:
- **A single definition of days past due**: Exactly one days-past-due calculator may exist in the entire estate. If the collections system and the provisioning engine each compute their own day counts, they will diverge — guaranteed.
- **Partial payments and buckets**: If three installments are overdue and the customer pays only the first, the delinquency start date moves to the second installment's due date. The counting rule — "based on the oldest unpaid installment" — must be implemented explicitly.
- **Bucket transition history**: Do not just update the current bucket value; append the transition history (which date, into which bucket) as immutable records. Roll-rate analysis (migration rates between buckets) is a core input to risk management.
Calculating Overdue Interest
Once delinquent, overdue interest accrues instead of (or on top of) contractual interest. The structure common in Korean practice is "contract rate + delinquency surcharge (capped by regulation)," and the overdue rate may not exceed the statutory maximum rate.
Overdue interest (example of the common structure)
overdue rate = MIN(contract rate + delinquency surcharge, statutory cap)
(1) Before acceleration: based on the unpaid installment amount
overdue interest = unpaid installment x overdue rate x days / 365
(2) After acceleration: based on the entire principal balance
overdue interest = principal balance x overdue rate x days / 365
Example: unpaid installment 1,000,000 KRW, contract rate 5%,
surcharge 3% -> overdue rate 8%, 40 days delinquent
overdue interest = 1,000,000 x 0.08 x 40 / 365 = 8,767 KRW
(truncation rule applied)
The crux of the implementation is that **the calculation base itself changes** before versus after acceleration. If the transition date slips by one day, the entire overdue interest figure changes, so the acceleration date must be frozen as an explicit event record, not derived on the fly by a batch.
Acceleration of Maturity
Acceleration (loss of the benefit of time) is the legal event in which the borrower loses the right to repay in installments over the remaining tenor, and the full balance becomes immediately due. It is typically triggered by delinquency beyond a defined period (including contractual notification requirements), a material decline in collateral value, or credit deterioration events, and the lender carries customer notification duties beforehand (advance notice, occurrence notice).
The system-level processing:
1. Candidate extraction batch: select accounts meeting the day-count and cause conditions
2. Notification dispatch and waiting: retain notification history at legal-evidence grade (sent timestamp, channel, returned-mail status)
3. Acceleration confirmation: create the event record, transition the account state, switch the overdue interest calculation base
4. Downstream integration: credit registry filing, incident notice to guarantors (for guaranteed loans), entry into the intensified collections track
If the customer fully cures the arrears after acceleration, the benefit of time may be **reinstated**. This reinstatement (restoring the calculation base, rebuilding the schedule) is harder to implement than the acceleration itself and is a classic bug nest. Define the eligibility conditions and the permitted number of reinstatements as explicit policy.
Asset Quality Classification — The Five Grades
Under supervisory regulation, financial firms classify their loan book into five grades according to the borrower's repayment capacity and delinquency status. This is asset quality classification; the traditional grading in the Korean supervisory framework is:
| Grade | Name | Typical criteria (rough) | Meaning |
| --- | --- | --- | --- |
| 1 | Normal | No delinquency, sound capacity | Collection assured |
| 2 | Precautionary | Delinquent 1 to under 3 months, etc. | Latent risk |
| 3 | Substandard | 3+ months delinquent, doubtful but within collateral coverage | Substantial collection risk |
| 4 | Doubtful | Portion exceeding collateral within substandard, etc. | Collection uncertain |
| 5 | Estimated loss | Effectively uncollectible | Loss virtually certain |
Two caveats:
- **Days past due are only the starting point**: Classification is not a mechanical function of day counts. Under FLC (Forward Looking Criteria), the borrower's future repayment capacity (industry outlook, financial condition) can pull a grade downward, and there are cross-impairment rules — if another loan of the same borrower goes bad, related loans are downgraded together (borrower-level classification with a cross-default character).
- **Split classification by collateral**: A single account may be split by amount — the portion within effective collateral value classified "substandard," the excess classified "doubtful." Design the classification table at the account-segment (amount fragment) level, not the account level.
The classification result feeds supervisory-purpose provisioning at minimum reserve ratios (a base ratio for normal, rising sharply through precautionary, substandard, doubtful, and estimated loss), and it runs **in parallel with, and separately from**, IFRS 9 expected credit loss for accounting purposes. The system must produce both, and typically support a structure where the more conservative (larger) of the two flows into the financials.
Provisions — IFRS 9 Expected Credit Loss
The Three-Stage Model
IFRS 9 expected credit loss (ECL) replaced the old incurred-loss model ("provision after the loss happens") with a forward-looking model ("estimate future losses in advance"). The core is the stage split.
IFRS 9 ECL — three stages
Stage 1 Stage 2 Stage 3
(performing) (significant increase (credit-impaired)
in credit risk)
12-month ECL Lifetime ECL Lifetime ECL
interest revenue on interest revenue on interest revenue on
gross carrying amount gross carrying amount net carrying amount
(gross minus allowance)
Transfer triggers (examples):
Stage 1 -> 2 : 30+ days past due (rebuttable presumption),
significant rating downgrade, watchlist entry (SICR)
Stage 2 -> 3 : 90+ days past due, acceleration,
restructuring recognized as credit impairment
Cure path : upgrade only after a probation period elapses
The skeleton of the ECL calculation
ECL = SUM over t [ PD(t) x LGD(t) x EAD(t) x discount factor(t) ]
- Stage 1: t = the next 12 months
- Stage 2/3: t = the full remaining maturity (lifetime)
- Computed per macroeconomic scenario (optimistic / base /
pessimistic) and probability-weighted
- PD/LGD/EAD reuse the CSS/IRB parameter framework,
adapted for accounting purposes
Implementation Concerns
- **The SICR (significant increase in credit risk) engine**: Beyond the quantitative 30-days-past-due test, qualitative rules operate — downgrade magnitude, watchlists, industry risk. Persist the determination evidence (which rule fired) per account and base date, or audits become unanswerable.
- **Asymmetric stage transfers**: Downgrades (1 to 2, 2 to 3) take effect immediately; upgrades (cures) are allowed only after a sustained clean period. The asymmetry is standard. Transfer history is, once again, append-only.
- **Scenario-weighting infrastructure**: The engine computes ECL multiple times against per-scenario parameter sets and weights them, so computation scales with "parameter sets x accounts." Design partitioning and parallelism from day one so the run fits inside the month-end window.
- **Audit traceability**: For any single provision number, full lineage must be reconstructable — which model version, which scenario set, which parameters, which stage determination. This is where financial audits dig deepest.
The Collections System
Call Routing and Work Queues
When delinquency arises, the collections system organizes recovery activity. Structurally it is "a prioritized work queue plus a conduct-regulation engine."
Delinquent accounts feed in (daily batch)
|
v
Segmentation
- bucket, collection score, amount, product
- split tracks: in-house / outsourced / legal proceedings
|
v
Campaign / queue assignment
- early (1-29 days): SMS and app notifications, low-cost channels
- mid (30-89 days): agent call routing, promise management
- late (90+ days): dedicated unit, legal action review
|
v
Agent worklists
- call result codes, PTP registration, next-action scheduling
- **Score-driven differentiation**: To avoid wasting calls on accounts likely to self-cure, contact intensity is differentiated by a collection-likelihood score. The behavior and collection scores from the CSS infrastructure are used here.
- **Promise management (PTP, Promise to Pay)**: Promises made in calls ("I will pay this amount by this date") are registered as structured records, automatically reconciled against receipts on the promise date, and judged kept or broken. The kept-rate is a core metric of both agent quality and strategy.
- **Real-time sync with receipts**: The worst scenario is a dunning call going out right after the customer paid. Design event integration so that a receipt-confirmed event immediately removes the account from collection queues.
Conduct Regulation Compliance
Debt collection conduct is tightly regulated (in Korea, by the Fair Debt Collection Practices Act and related rules). The system must enforce the rules in code; guidance alone does not prevent human error.
- **Contact restrictions**: Night-time contact bans (commonly 9 p.m. to 8 a.m.) and daily contact-count limits are enforced at the dialer and messaging-engine level. The point is not "please do not call" but "the call cannot be placed."
- **No third-party disclosure**: Revealing the debt to family or employers is prohibited. Contact management must block automated dispatch to numbers not verified as the borrower's own.
- **Protection during restructuring and litigation**: Accounts under a Credit Counseling and Recovery Service workout application, or under court-led individual rehabilitation or bankruptcy proceedings, have restricted collection activity. When the external status feed arrives, automated freezing (hold) in the collection queues is mandatory.
- **Complete history retention**: Preserve every contact attempt and outcome (including call recordings). In complaints and disputes, the burden of proof frequently sits with the financial firm.
Reflecting Debt Restructuring in Systems
Debt restructuring for delinquent borrowers splits into external regimes (workouts via the Credit Counseling and Recovery Service, court-led individual rehabilitation and bankruptcy) and in-house programs (maturity extension, rate reduction, conversion to installment repayment). From a systems standpoint, the common processing is:
1. **Freeze the original claim and generate a new schedule under the adjusted terms**: Build the new repayment schedule with the reduced rate and extended maturity, while preserving both the original contractual terms and the restructuring history. Never overwrite the original records.
2. **Accounting and provisioning integration**: Restructuring is usually a credit-impairment (Stage 3) trigger, and the modification can require a carrying-amount adjustment (present-value recalculation). The accounting rules per restructuring type must be shared with the provisioning engine.
3. **Classification and probation**: After restructuring, a sustained period of faithful repayment can earn an upgrade; tracking repayment performance through this probation window becomes a system requirement.
4. **Collection freeze and credit registry handling**: On confirmation, stop collections and file the term-modification and delinquency-release information with the credit registry within the filing deadline.
NPL Write-off and Sale
Claims with effectively no prospect of collection exit through one of two doors.
Write-off
A write-off removes the claim from the accounting books (normally netted against the allowance). The crucial point is that **a write-off does not extinguish the claim**. The legal right to collect survives, so after write-off the balance, the limitation period, and recovery activity continue to be tracked in a "written-off receivables ledger." Recoveries after write-off are recognized as income (recoveries on written-off loans) through a dedicated accounting path. Managing the statute of limitations (commonly 5 years for commercial claims) and tracking interruption events (provisional attachment, lawsuits, partial repayment) also belong to this ledger.
Sale (NPL Sale)
Bundling non-performing loans and selling them to specialist NPL investors or securitization structures is the sale route.
NPL sale pipeline
Pool construction Due diligence Award / transfer execution
- extract targets - provide data tape - assignment contract
- exclusion filters (borrower / collateral - assignment notice
(under workout, / delinquency history) (perfection)
in litigation, - bid pricing - derecognition in ledger
guaranteed, etc.) - Q&A support - post-closing settlement
(collections after
the cut-off date)
System requirements:
- **Data tape quality**: The accuracy of the claim schedule delivered to buyers (principal, interest, delinquency history, collateral, legal status) directly drives the sale price. Rather than one-off warehouse extracts, productize a standard tape-generation capability — it pays off across repeated sales.
- **Cut-off settlement**: Collections received between the bid cut-off date and the transfer execution date belong to the buyer. Settlement logic must segregate and total receipts in this window.
- **Post-assignment events**: If a payment for an assigned claim arrives by mistake, it must be forwarded to the buyer, and customer inquiries must be routed to the assignee. This is only possible if the account preserves an "assigned" status plus assignee details.
- **Credit registry filing**: The fact of assignment must also be filed with the credit registry within the deadline.
Supervisory Reporting and the Data Warehouse
Servicing data feeds a wide range of supervisory reports.
- **Delinquency ratio reporting**: The numerator and denominator definitions (e.g., principal and interest overdue 1 month or more) can differ by report. Specify each definition's derivation in code and automate consistency checks against closed ledger data.
- **Classification and provisioning returns**: Balances and provisions by grade in regulatory returns are produced from month-end and quarter-end snapshots. Retroactive corrections after close trigger resubmission issues, so manage the close cut-off and the correction procedure strictly.
- **Credit registry filing**: Delinquency onset and release, acceleration, restructuring, and assignment events all carry filing deadlines. Put an unsent-message watchdog alarm on the queue connecting event occurrence to registry message dispatch.
The Data Model
The core entities summarized as an 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 (due/paid/ |
| status | | partial/overdue) | +-------------------+
| repay_method | | version_no |1-----N| TXN_HISTORY |
+------+--------+ +--------------------+ |-------------------|
| | txn_id PK |
|1 | account_id FK |
| | txn_date, type |
N | amount, applied_to|
+---------------+ +--------------------+ | (fees/int/princ) |
| 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 (grade) |
+------+--------+ +--------------------+ | 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 |
+---------------+ +-------------------+
A few modeling principles:
- **Delinquency lives in episodes**: One account cycles in and out of delinquency, so bundle "from onset to cure" into one episode entity — collection history and bucket transitions then attach cleanly.
- **Schedules are versioned**: Every regeneration — repricing, prepayment, restructuring — bumps version_no and preserves the prior version. You must be able to reproduce "the schedule in force at that point in time."
- **Classification and ECL are base-date snapshots**: Not in-place updates but per-date loads. The time series is both the audit trail and the analytics source.
Batch Design — Daily and Monthly
Servicing is the world of batches, and dependency ordering is life or death.
Daily batch (EOD) — the ordering IS the consistency
01 Confirm receipts (apply direct-debit result files)
02 Daily interest accrual (accrued interest balances)
03 Delinquency determination / bucket transitions
<- after 02 (after the day's receipts are applied)
04 Overdue interest calculation
<- after 03 (after bucket/acceleration states are final)
05 Acceleration candidate extraction / notifications
06 Collection queue load/unload <- after 03, 05
07 Credit registry filing message generation
08 Ledger-to-accounting reconciliation (daily close)
09 Warehouse load
Monthly batch (month-end close)
M1 Re-evaluate preferential rate conditions <- before next interest cycle
M2 Behavior / collection score computation
M3 Asset quality classification <- after delinquency/collateral data final
M4 IFRS 9 stage determination / ECL calculation <- after M2, M3
M5 Provision accounting entries / financial close integration
M6 Regulatory report production <- after M3, M4, M5
M7 Vintage / roll-rate analytics mart load
Three points worth repeating about batch design:
- **Restartability**: A design where a failure in job 04 means rerunning from 01 cannot hold the close window. Design job-level checkpoints and partial reprocessing from the start.
- **Parameterize the base date**: Every job must accept an explicit base date rather than assuming "today." After an outage, a rerun the next day must still execute exactly as of the prior date.
- **A single source for the holiday calendar**: Due-date deferral, delinquency counting, and interest day counts all depend on the business-day calendar. There must be exactly one calendar master, with a validation procedure at its annual registration.
Pitfalls — The Temptation of Retroactive Recalculation
The most dangerous anti-patterns in servicing systems, collected:
1. **Retroactive recalculation**: The request will inevitably come — "the rate was applied wrong, recalculate the last six months of interest and overwrite it." Never overwrite past records. Leave past transactions untouched and post the difference as a separate settlement transaction (refund or additional charge) — the **adjustment transaction pattern** must be the standard. The moment you overwrite, the accounting close, the reports, the credit registry filings, and the customer statements all diverge.
2. **Duplicated days-past-due calculators**: Ledger, collections, and provisioning each computing their own day counts, drifting apart by a day — a classic incident. Enforce a single module; derived systems subscribe to its output only.
3. **Implicit acceleration state**: Handling acceleration with derivation logic like "treat 90+ days as accelerated" conflicts with notification requirements and reinstatement handling. Manage it as an explicit event and state.
4. **Pre-booking unconfirmed receipts**: Treating a direct debit as received before the debit result arrives means a failed debit flips delinquency determination and collection exclusion retroactively. Separating acceptance from confirmation is the answer.
5. **Not preserving bucket transition time series**: Updating only the current bucket makes roll-rate analysis impossible and erases the input data for provisioning models.
6. **Editing data after close**: Fixing source data after the month-end snapshot has shipped leaves the reports and the ledger holding different numbers. Reflect corrections as next-period adjustments, and gate exceptional retroactive fixes behind a resubmission procedure.
7. **Neglecting the statute of limitations**: If the system does not track limitation periods on written-off claims, collecting on time-barred claims creates legal risk. Manage the limitation start date and interruption events as data.
Design Checklist
- [ ] Does the schedule generator parameterize grace periods, day-count conventions, residual adjustment, and holiday deferral?
- [ ] Is money math decimal-based, with truncation/rounding rules specified as product attributes?
- [ ] Is the appropriation order externalized, and does the receipt distribution map one-to-one onto accounting entries?
- [ ] Does schedule regeneration touch only future terms while preserving version history?
- [ ] Is days-past-due computed in a single module, with an explicit counting rule for partial payments?
- [ ] Are delinquency episodes and bucket transitions preserved append-only?
- [ ] Is acceleration managed as an explicit event, with notification history at evidence grade?
- [ ] Does classification support amount splits (collateral coverage) and load as base-date snapshots?
- [ ] Is ECL fully traceable — model version, scenarios, stage determination evidence?
- [ ] Is collection conduct regulation (time windows, contact counts, third-party disclosure bans) enforced at the system level?
- [ ] Are receipt-confirmation events synchronized with collection queues in real time?
- [ ] Is the collection freeze automated when restructuring or rehabilitation notices arrive?
- [ ] Does a separate written-off receivables ledger exist, tracking statutes of limitation?
- [ ] Are NPL data-tape generation and cut-off settlement logic productized?
- [ ] Are daily and monthly batch dependencies specified, with job-level restarts possible?
- [ ] Is the adjustment transaction pattern enforced as the standard instead of retroactive edits?
Closing
Servicing systems are not glamorous. There is no shiny new-signup metric, and the better they run, the quieter they are. Yet the profit and loss of the lending business is ultimately decided here — how quickly and accurately delinquency is identified, how reliably provisions are computed, how efficiently recovery happens within the bounds of regulation. Compressed into one line, the message of this post is: **treat time explicitly (base dates, versions, episodes), never overwrite the past (adjustment transactions), and let every derived number flow from a single source (the ledger).**
That completes one full lap of the lending series — the LOS (birth), the CSS (judgment), and servicing (everything after). Once more, this article is a technical architecture walkthrough, not a financial product solicitation nor investment, legal, or accounting advice.
References
- [IFRS Foundation — IFRS 9 Financial Instruments](https://www.ifrs.org/issued-standards/list-of-standards/ifrs-9-financial-instruments/)
- [BIS — Basel Framework (CRE: Credit Risk)](https://www.bis.org/basel_framework/)
- [BIS — Guidelines: Prudential treatment of problem assets (NPE definitions)](https://www.bis.org/bcbs/publ/d403.htm)
- [ECB — Guidance to banks on non-performing loans](https://www.bankingsupervision.europa.eu/)
- [Financial Supervisory Service (Korea)](https://www.fss.or.kr/)
- [Financial Services Commission (Korea)](https://www.fsc.go.kr/)
- [Credit Counseling and Recovery Service (Korea)](https://www.ccrs.or.kr/)
- [Korea Asset Management Corporation (KAMCO)](https://www.kamco.or.kr/)
- [Korea Credit Information Services](https://www.kcredit.or.kr/)
- [Korean Law Information Center — Fair Debt Collection Practices Act and related statutes](https://www.law.go.kr/)
- [Supreme Court of Korea — Rehabilitation and bankruptcy information](https://www.scourt.go.kr/)
- [ISO 20022 — Universal Financial Industry Message Scheme](https://www.iso20022.org/)
현재 단락 (1/372)
In the previous posts we covered the LOS (the birth of a loan) and the CSS (the brain of underwritin...