Collections
A delinquency matter runs on the Lending Core's own figures, so servicing can decide what work is permitted without ever computing a balance of its own.
The platform works a delinquent account from the missed payment to the cure: the case opens from the Lending Core’s own figures, the voice agent calls inside the contact rules, an arrangement is negotiated within the lender’s bounds and recorded, and the case closes when the money arrives. Collections is a workflow over authoritative loan facts, never a second delinquency calculator. Two systems that each work out what is owed will disagree on the day it matters, and the borrower is the one who hears both numbers. So the system of record supplies balance, due obligations, posted and in-flight payments, restrictions, and freshness; the Servicing Workspace decides what work is permitted and records what happened.
Harbor: one signal, one lasting matter
On May 1, 2027, Harbor is 22 days past due. The monitor emits one deduplicated signal:
{
"customerRef": "412",
"caseTypeCode": "COLLECTIONS",
"reasonCode": "DELINQUENCY_SIGNAL",
"priority": "HIGH",
"loanRefs": ["7204"],
"sourceType": "LMS_EVENT",
"sourceRef": "signal_2027-05-01_HBR"
}
POST /v1/servicing/cases creates or exactly deduplicates that matter by source. The response uses numeric caseId and a stable string externalCaseRef. The same delinquency reported every night is one matter with one contact history — without the deduplication it becomes a fresh case each morning, and every one of them thinks it is allowed its first call.
The fact snapshot, and when it fails closed
Material decisions freeze a snapshot that records where each fact came from:
| Fact | Harbor example | Freshness expectation |
|---|---|---|
| Days past due | 22 |
Current servicing facts. |
| Amount past due | $517.14 |
Current, net of posted activity. |
| Payments in flight | $0.00 |
Current rail/intents. |
| Last posted payment | 2027-03-10 |
Authoritative ledger. |
| Active promise | none | Current servicing record. |
| Contact budget | 3 attempts remaining under configured policy | Real-time interaction history. |
| Restrictions | none | Highest-freshness control domain. |
Stale or missing balance facts may permit a read-only task but fail closed for an amount representation, payment request, or account-changing action. Reading yesterday’s figure aloud to a borrower creates an agreement the ledger will not honour, and the person who has to explain it is the one who quoted it.
The gate runs at dial, not at plan
- Resolve the customer time zone, destination, purpose, consent, representation, restrictions, debt, and recent interaction history.
- Reserve the task for the voice agent with
POST /v1/servicing/tasks/reserve-next— a person receives it only where policy reserves that call for one. - Dial now with
POST /v1/servicing/calls/outbound, or book a borrower-promised window withPOST /v1/servicing/cases/{caseId}/scheduled-callbacks. - Let the owning operation evaluate compliance with current facts immediately before send or dial — for a scheduled callback, the gate runs again at
start-call. - Record attempted, blocked, connected, delivered, and opt-out outcomes as interactions.
A caller cannot mint a reusable eligibility decision and attach it to an execution, which is what stops a permission from outliving the facts it was granted on.
LendEasy can encode counsel-approved Regulation F controls, including the telephone-call-frequency presumptions in 12 CFR 1006.14, where applicable or adopted as policy. It does not describe those presumptions as a universal “seven-call allowance,” and a remaining budget never overrides a separate prohibition.
Agreeing to pay is not paying
Read the third column across. Only a payment moves money; everything else a borrower can say on a call produces a record and a next step, which is why a book of arrangements is not a book of cash.
| Customer outcome | Structured record | Money moves? | Follow-up |
|---|---|---|---|
| Pays now | Payment intent | After rail settlement and posting | Monitor posting or return. |
| Commits to dates | Promise-to-pay | No | Evaluate against posted payments. |
| Requests relief | Hardship case + projected relief options | No until approved action/payment | Specialist review. |
| Disputes or reports identity theft | Linked specialist case + restriction | No | Dispute workflow and deadlines. |
| Gives cease request | Consent/restriction change | No | Contact attempts blocked by scope. |
| Gives bankruptcy notice | Bankruptcy case + restriction review | No | Specialist evidence and stay controls. |
Working the whole book: the collections report
GET /v1/servicing/reports/collections reads the whole book the way this guide reads one matter: each row joins current Lending Core financial facts — daysOverdue, delinquencyBucket, overdueAmount, and the financialFactsSource that supplied them — to servicing state such as promiseState, contactIntensity, remainingContactCapacity, nextPermittedContactAt, and contactBlocked.
That makes it possible to plan a day’s outreach against who is actually contactable, filtering by bucket, overdue range, promise state, or next permitted contact window. It does not authorize anything: the owning operation still evaluates policy with current facts immediately before send or dial, and can block a contact this report listed as permitted. See Servicing reports.
Closing a collections case
A case resolves when the configured authoritative outcome exists—for example, the amount past due becomes zero, an approved relief arrangement takes effect, or work transfers to a specialist matter. Closure records the outcome, reason, final fact snapshot, unresolved links, and evidence package, so a matter reopened next quarter starts from what was true when it closed rather than from what somebody remembers.
Follow the runnable Handle a delinquency case recipe for Harbor.