Delinquency & arrears
Read days past due and delinquency buckets as ledger facts derived from posted history—recalculated on every posting, never edited by hand.
Delinquency is a fact about an active obligation, not a lifecycle state, and nobody sets it. It is derived from the authoritative ledger every time something posts, which is the only way the number a collector acts on can be the same number the borrower’s money produced. A delinquency that could be typed in is one that can disagree with the ledger, and every downstream consequence—calls, fees, credit reporting—would then be attached to an opinion. A loan that is 22 days past due is still ACTIVE; the delinquency overlay changes collections, fees, reporting, and eligibility facts without replacing the underlying state.
Five buckets, and one day is delinquent
Days past due measure how long the earliest unmet scheduled obligation has been outstanding: the loan’s derived overdue-since date counted forward to the current business date.
Product policy can configure an arrears tolerance and grace on arrears aging before an unpaid amount starts the clock; like every calculation setting, the policy the loan resolved at origination stays with the loan.
Read the position from the loan summary—GET /v1/loans/{loanId}/summary carries the overdue components alongside balances and payoff. A client that recomputes days past due from the raw schedule bakes in today’s tolerance and grace policy, and will disagree with the loan the moment either one changes for new business.
Only posted history moves the number
Delinquency is recalculated whenever a transaction posts against the loan, and a scheduled pass keeps quiet accounts aging as the business date advances. The recalculating events are the ones that change effective posted history:
- Value-dated and backdated postings. Harbor’s ACH debit settles September 15 but posts value-dated September 12, the date the borrower paid—allocation and delinquency are recomputed from September 12, not from settlement day. Backdating replays dependent allocation and accrual deterministically; it never edits posted lines.
- Returned payments. A return reverses the posted allocation with explicit linkage, and delinquency recalculates from authoritative posted history. See reverse a payment.
- Schedule modifications. A re-age or re-amortization produces a new authoritative remaining schedule, and delinquency is measured against it from then on. Transaction history still shows which obligations went unpaid, so reporting can distinguish delinquency cured by payment from delinquency resolved by modification.
- Charge waivers. Waiving a charge posts a non-cash transaction that can reduce amount due and delinquency.
In-flight protection is visible, not hidden
A covering payment in flight is recognized provisionally: the loan summary exposes the inFlightPaymentAmount next to the authoritative balance, scoped to the covering amount. Netting it into the balance instead would leave a collector unable to tell a borrower who has paid from one who merely might have. If the debit fails or returns, the protection ends and delinquency is recalculated from posted history. Payments & repayments walks the full timeline.
A late charge is an ordinary charge
It runs through the same charge model as any other: a configured definition with its calculation method, penalty flag, finance-charge classification, amount bounds, and ledger accounts. The applied charge carries assessed, paid, waived, and outstanding amounts under a stable loan-charge id, and charge frequency policy on the definition prevents business duplicates such as two late fees for one installment. Forgiveness runs through the governed charge waiver, never a balance edit.
There is only one delinquency calculator
When a loan’s position changes—state, bucket, days overdue, or the covering in-flight amount—a deduplicated change signal is emitted; an unchanged position emits nothing, so a nightly aging pass over a quiet portfolio does not reopen yesterday’s collections cases on a hundred thousand loans that have not moved. A qualifying signal opens or exactly deduplicates a collections case, and servicing reads join those financial facts—daysOverdue, delinquencyBucket, overdueAmount, with their financialFactsSource—to contact and promise state. The servicing workspace never recomputes delinquency; it decides what work is permitted on top of it. Two calculators would eventually hand a collector one number and a regulator another, with no way to say which one the loan actually was.
For portfolio analysis, the delinquency roll report produces one row per loan and bucket date from effective payment facts and bucket policy.