Restrictions & hard stops

A restriction is a hold of a named kind — payments, autopay, disbursement, collections, communication, or servicemember protection — that resolves into a specific answer about the exact action somebody is proposing. An account flag, by contrast, tells everybody that something is true and nobody what to do about it, so each team invents its own reading and the team that guesses wrong makes the call. A restriction is the opposite: a named hold that resolves into one answer — blocked, evaluated, approval-gated, or allowed — for one proposed action, one subject, one interval. It can affect contact, disclosure, money movement, fees, schedule changes, statements, furnishing, or terminal state independently.

On the Lending Core the enforcement fact is a hold of a named kind from a fixed list—PAYMENT_HOLD, AUTOPAY_HOLD, DISBURSEMENT_HOLD, COLLECTIONS_HOLD, COMMUNICATION_HOLD, and SCRA_MLA_PROTECTED—applied at customer scope or narrowed to one loan. Servicing compliance policy resolves what each hold means for a specific proposed action.

What the core enforces, and what policy resolves

GET /v1/customers/412/restrictions returns active and cleared rows, newest first:

{
  "items": [
    {
      "restrictionId": 41,
      "restrictionType": "COLLECTIONS_HOLD",
      "loanRef": "7204",
      "active": true,
      "source": "case:LE-CASE-1001",
      "effectiveAt": "2027-06-03T14:00:00Z"
    }
  ]
}

The core enforces its own operations directly: PAYMENT_HOLD blocks payment creation, DISBURSEMENT_HOLD blocks fundings, and AUTOPAY_HOLD or COLLECTIONS_HOLD pauses affected autopay enrollments in the same transaction. For everything else—contact, notices, fees, schedule actions—the compliance engine expands the hold into an action matrix for the exact proposed action. Common outcomes are allowed, evaluate, approval_required, and blocked. The controlling policy defines whether any override path exists; an ordinary supervisor cannot convert a non-overridable block into a warning.

The narrowest applicable outcome wins

A hold targets one customer and all linked obligations, or one loan via loanRef. One active hold exists per customer, loan, and type; reapplying the same hold is idempotent, and the platform derives the effective time. Two rows for the same protection would eventually be cleared one at a time, and the borrower would be unprotected the moment somebody cleared the one they could see.

Compliance policy layers narrower conduct controls over the holds:

• named loans or merchant advances;
• one contact detail, channel, purpose, or third party;
• money movement in one direction;
• one action family, such as fee assessment or furnishing;
• an effective start and optional end.

The narrowest applicable action-specific outcome is resolved through approved conflict policy. A loan-level payment restriction should not silently block a legally required non-collection notice unless its matrix says so.

Clearing is prospective and takes no body

Apply a hold with case context—the governing case travels in the LendEasy-Case header and holds the evidence:

curl -X POST "$BASE/v1/customers/412/restrictions" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: LE-CASE-1001" \
  -H "Content-Type: application/json" \
  -d '{
    "restrictionType": "COLLECTIONS_HOLD",
    "loanRef": "7204",
    "source": "case:LE-CASE-1001"
  }'

The clear command takes no body: POST /v1/customers/412/restrictions/41/clear. The active interval remains in history as a cleared row with its clearedAt time. Every apply and clear writes a governance record, and clearing triggers re-evaluation of affected actions without rewriting prior decision records — the calls that were refused last month were correctly refused, and a lifted hold does not make them retrospectively wrong.

Reaching work that is already queued

Applying a restriction invalidates cached eligibility, wakes affected case workflows, and causes queued actions to re-check. Everything already prepared was prepared under the old facts, and the queue is exactly where a new protection has to reach: a hold that only governed future decisions would let this afternoon’s dialler finish this morning’s plan.

Unavailable never becomes allowed

If restriction facts are stale, contradictory, or unavailable, high-impact actions return missing_facts or follow a configured safe hold. A control that fails open is not a control at all — it is a control that stops working precisely when the platform is least able to tell what is going on.