Baseline Loan Scenarios

To make servicing examples concrete, every servicing loan now references one of four baseline loans. Each scenario below lists the exact inputs, the initial repayment schedule, and the assumptions (interest method, day-count, allocation strategy). When a servicing action modifies a loan, the guide cites “Baseline A”, “Baseline B”, or “Baseline C” so you can compare before/after at a glance.

Baseline A – Fixed EMI Loan

Parameters:

• Principal: USD 12,000
• Tenor: 12 months
• Interest method: Declining balance, monthly amortization
• EMI: USD 1,066.19 (using r = 1% per month; rounded for readability)
• Interest recalculation: Enabled (Embarc reprocesses interest on each servicing command).
• First due date: 13 Jan 2026
• Allocation: Standard (Interest → Principal → Fees → Penalties)

Initial schedule (excerpt):

We reuse this loan whenever a servicing action targets a traditional EMI product (prepay, waive interest, goodwill credit, re-amortize “Installment Smoothing”, etc.).

Initial loan summary

Transaction log

---

Baseline B – Dynamic BNPL Plan

Parameters:

• Principal: USD 600
• Tenor: 6 installments, bi-weekly cadence (every 14 days)
• Interest policy: Installments 1–3 promotional 0% APR, installments 4–6 at 24% APR (0.24/26 ≈ 0.923% per period)
• Interest recalculation: Enabled
• Allocation strategy: Advanced Payment Allocation (ADJUST_LAST_UNPAID_PERIOD)
• First due date: 10 Jan 2026
• Principal schedule: USD 100 per installment

Initial schedule:

This loan underpins Dynamic Schedule examples that require interest-bearing behaviour (Promo Interest Credit, Contract Termination, Buy-down Fee amortization, Capitalized Income). Because the Dynamic engine can be sensitive to due-date shifts and allocations, every before/after table in the guides references these exact installments.

Promo interest logic: LoanPromoPeriodCalculator only keeps installments 1–3 at 0% if the borrower pays on or before each due date. Any delinquency causes the first interest-bearing installment (installment #4 here) to include catch-up interest from prior periods. Baseline B assumes on-time payments so the promo periods stay interest-free.

Initial loan summary

Transaction log

---

Baseline C – Dynamic Hardship Plan (non-interest)

Parameters:

• Principal: USD 600
• Tenor: 6 installments, bi-weekly cadence (every 14 days)
• Interest: 0% (non-interest-bearing as required by validators)
• Allocation strategy: Advanced Payment Allocation (ADJUST_LAST_UNPAID_PERIOD)
• First due date: 10 Jan 2026

Initial schedule:

This baseline powers reAge, reAmortize, and any other Dynamic-only command that rejects interest-bearing loans.

Initial loan summary (Baseline C)

Transaction log (Baseline C)

---

Baseline D – Dynamic BNPL with Down Payment

Parameters:

• Principal: USD 800
• Down payment: 25% (USD 200) collected on the disbursement date
• Remaining tenor: 6 installments, bi-weekly cadence after the down payment
• Interest policy: Installments 1–3 promotional 0% APR, installments 4–6 at 24% APR
• Interest recalculation: Enabled
• Allocation strategy: Advanced Payment Allocation (ADJUST_LAST_UNPAID_PERIOD)
• First disbursement / down payment date: 05 Jan 2026

Initial schedule:

Use this baseline whenever you need to demonstrate down-payment servicing behaviour (auto-collection at disbursement, manual down payment command, chargeback, etc.). Its promo/interest pattern mirrors Baseline B so comparisons stay simple.

Initial loan summary

Transaction log

---

When a servicing action modifies one of these baselines, the corresponding servicing guide will include:

1. A “Baseline impact” subsection that links back here.
2. A small before/after table (affected installments only).
3. A note explaining how the command parameters produced that delta (with references to validators or processors when useful).

Verification & sandbox tips

To reproduce any scenario end-to-end:

1. Clone the baseline state – Create loans in your tenant that mirror Baseline A, Baseline B, Baseline C and Baseline D.
2. Capture “before” data – Call GET /v1/loans/{loanId}?associations=all and save the loanSummary, repaymentSchedule, and transactions.
3. Apply the servicing command (per the servicing guide) and repeat the same GET call to diff schedules, summaries, and transaction logs.

Each servicing guide now references the exact sections above plus a ready-to-use curl template so teams can replay the scenario without rebuilding context from scratch.

---

Shared Product-to-Accounting Mapping

All baselines use the same comprehensive mapping so every accounting example references familiar GL accounts.

Note: Some deployments use separate GLs for Dynamic vs. Fixed Schedule products; feel free to swap the examples while keeping the same mapping structure.

How servicing guides use this mapping

• Promo Interest Credit (interest payment waiver) → Debit INTEREST_ON_LOANS (404000) / Credit LOAN_PORTFOLIO (112601, interest component).
• Waive Interest (waiveinterest) → Debit INTEREST_ON_LOANS or INTEREST_RECEIVABLE (119200) / Credit LOAN_PORTFOLIO (112601 – interest component).
• Contract Termination → No immediate GL impact (entries occur when a payoff/refund or charge-off follows).
• Buy-down fee → Initial subsidy: Debit BUY_DOWN_EXPENSE (171000) / Credit INCOME_FROM_BUY_DOWN (405600); amortization reverses the entry over time.
• Capitalized income → Capitalise: Debit LOAN_PORTFOLIO (112601) / Credit DEFERRED_INCOME_LIABILITY (212500); amortization: Debit DEFERRED_INCOME_LIABILITY / Credit INCOME_FROM_CAPITALIZATION (405500).
• Goodwill credit → Debit GOODWILL_CREDIT (505100) / Credit LOAN_PORTFOLIO split across components per allocation order.
• Charge-off / recovery → Commands reference the charge-off expense/income accounts listed above.

General rule: when a product guide references an “Accounting snapshot,” it uses the account names above so finance teams can reconcile quickly. Swap the GL codes as needed for your environment—the mechanics (asset/liability vs. income/expense) remain identical.