Restrictions & hard stops

A restriction answers which actions are blocked, evaluated, approval-gated, or allowed for which subjects and 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 typed hold from a closed catalog—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.

Restriction lifecycle

Action matrix

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

{
  "items": [
    {
      "restrictionId": 41,
      "restrictionType": "COLLECTIONS_HOLD",
      "loanRef": "7204",
      "active": true,
      "source": "case:case_HBR_BANKRUPTCY_3",
      "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.

Scope

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 server derives the effective time.

Compliance policy layers narrower conduct controls over the holds:

• named loans or merchant advances;
• one contact point, 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.

Create and clear

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: case_HBR_BANKRUPTCY_3" \
  -H "Content-Type: application/json" \
  -d '{
    "restrictionType": "COLLECTIONS_HOLD",
    "loanRef": "7204",
    "source": "case:case_HBR_BANKRUPTCY_3"
  }'

Clearing is prospective and 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; it never rewrites prior decision records.

Immediate propagation

Applying a restriction invalidates cached eligibility, wakes affected case workflows, and causes queued actions to re-check. Scheduled work is not assumed safe because it was prepared earlier.

Degraded mode

If restriction facts are stale, contradictory, or unavailable, high-impact actions return missing_facts or follow a configured safe hold. “Restriction service unavailable” never becomes allow.