Hardship & disaster

The platform carries a borrower from I cannot pay this month to a schedule they can keep, on the call it started on. The voice agent takes the hardship conversation, works out what the borrower can actually afford, and agrees relief inside the lender’s configured programs and bounds; the Lending Core applies it to the contract, and the case closes only once the new schedule reads back. A person is asked only where the request falls outside those bounds, or where policy reserves the decision for one. A hardship case explains the circumstances and the decision. A governed core command changes the contract or ledger. Run together, they fail together: a borrower’s medical circumstances end up in a ledger note, and a plan agreed on a call is never actually applied to the loan. Kept apart, servicing preserves sensitive context while the Lending Core applies exact financial rules.

Cedar: past due moves, term does not

Cedar is a zero-interest community loan with 12 monthly installments of $330.00. After three missed installments, amount past due is $990.00 and nine future installments remain.

The customer reports a temporary income reduction but can resume $330.00 monthly. Re-amortization moves the $990.00 past-due principal across the nine future installments:

If $440.00 is unaffordable, re-age or reschedule may be more appropriate because they can change dates or term. See Choosing among schedule actions.

Six programs, and what each does not do

The third column is the one that prevents complaints. Every relief option is offered to somebody in difficulty who will hear it as the problem is handled, so the boundary of each program is stated as plainly as its effect:

Every option is projected from the same authoritative loan reads, with before/after installment schedule, total cost, maturity, disclosures/notices, accounting effect, restrictions, approval need, and reversibility.

Declared-event populations

A declared-event population accelerates discovery and consistent offer design; it never creates a bulk compliance bypass. Each customer keeps an individual subcase, current eligibility, restrictions, decision, action ID, and outcome. Adding a ZIP code or county creates a new population version rather than editing the old one, so a borrower’s decision can still be explained against the cohort they were actually in when it was made — a widened boundary would otherwise reach backwards and change who a past decision applied to.

Finding the borrowers inside a disaster

When a disaster is declared, the borrowers inside it are the least likely people to call — they are dealing with a flood. A servicer who waits to be told learns about it from the delinquency report six weeks later, having spent those six weeks calling into a declared disaster area.

So the platform reads the federal disaster record directly, every six hours. It is public data: no borrower information is ever sent anywhere to do this.

Reading a list that grows and gets revised in place is harder than it sounds, and three rules keep it honest. Pages are walked in record order rather than by date, so a row cannot slip between pages while the walk is running. Each read reaches back a week past the last one, because a record revised after it was first published would otherwise be seen once and never again. And once a week the whole catalogue is re-read rather than just the recent slice.

Only that full re-read is allowed to mark a declaration withdrawn. An incremental read that simply fails to mention a record proves nothing about it — and treating silence as withdrawal would end somebody’s relief because a page boundary moved. A withdrawal is recorded, never applied by deletion, and it opens a review rather than terminating relief already granted.

Not every declaration means anything to a borrower. A declaration can designate a county for infrastructure funding — roads, public buildings, debris removal — without any household assistance at all. Matching borrowers against one of those would open assistance cases for people who are not eligible for anything, in a county where nothing happened to them. The platform reads which programs a declaration actually carries.

Matching borrowers to a declared county

Disasters are declared by county. Borrower addresses carry postcodes. Bridging the two is where most implementations quietly overstate what they know.

The platform uses a census table that maps each postcode to the county holding most of its land. Two limits come with that, and both are stated rather than papered over:

• Some postcodes — post-office boxes, single-building codes — have no county at all, and resolve to nothing rather than to a guess.
• A postcode straddling a county line resolves to the larger side, so a borrower on the other side is someone the match can neither confirm nor rule out.

Because those limits are real, a disaster match is recorded as partial evidence, never proof. Being inside a declared county is a good reason to ask whether someone was affected. It is not a finding that they were, and the stored record says so on its face. Exposure is assessed against incidents beginning within the last 180 days, so a declaration from two years ago does not resurface as new work.

At intake a disaster case pauses collections contact — and deliberately does not block payment. A borrower who wants to pay during a disaster is still allowed to. Suppressing outreach protects someone dealing with a flood; refusing their money does not.

A declaration that touches borrowers opens one container for the event itself, with each affected borrower’s case beneath it — so an operations lead sees the whole exposed population and works it as a cohort, instead of discovering the same storm eighty separate times in a queue.

The case closes when the schedule reads back

The chosen action carries structured inputs, a reason, evidence, and effective date. A command placed by a person carries the case’s stable externalCaseRef in LendEasy-Case; an agent or registered automation records its own trigger instead. The case holds the before/after comparison the decision was based on. Execution re-checks eligibility and posts once, and the case closes only after the resulting schedule or balance is readable and matches the acknowledgement — an acknowledgement is a promise that something was accepted, and the borrower’s next statement is the proof it happened.