Rate lock management, end to end

What a rate lock is

A rate lock is a contract: in exchange for a price the investor offers today, the borrower receives a guarantee that the rate will be available for a defined period (typically 15 to 60 days). The lender sits between them, accepting pipeline risk for the lock period.

The mechanics matter operationally: while the lock is in force, the lender can't reprice the loan to the borrower without explicit cause. If rates rise, the lock is valuable to the borrower; if rates fall, the lock is the constraint. The lender hedges either case.

What a lock actually pins

A serious lock subsystem captures a complete pin at lock time:

• The ratesheet version that produced the price.
• The investor and the program.
• The note rate.
• The lock period in days.
• The execution mode (best-effort, mandatory, or specific delivery).
• The full per-rule trace that built the price.
• The actor who locked (LO, autopilot, system).
• The borrower's loan facets at lock time.

With this pin, the engine can reproduce the lock-day price exactly, on demand, for the life of the lock and beyond. Without it, lock pricing drifts and disputes become forensic.

Lifecycle: create, extend, cancel, fund

A lock progresses through a small state machine:

• LOCKED: lock is in force. Most locks live here.
• EXTENDED: lock has been extended; the expiry timestamp has slid forward. Functionally the same as LOCKED for downstream purposes.
• FUNDED: loan has closed and the lock has been consumed. Terminal happy state.
• CANCELLED: lock was cancelled before funding, with a documented reason. Terminal.
• EXPIRED: lock period elapsed without funding or extension. Terminal.

Every state transition writes a journal entry: who, when, prior state, new state, reason if applicable. The journal is hash-chained into the platform-wide audit log, so a regulator can verify the sequence has not been tampered with.

Lock-desk policy as configuration

Most lock-desk policy lives in tribal knowledge or a stale wiki. A mature implementation makes it configuration:

• Cutoff time: the time of day past which locks cannot land for today's ratesheet.
• Allowed lock periods: per program (e.g., 15, 30, 45, 60 days for conforming; different sets for non-QM).
• Maximum extension days: how far you'll let a lock slide.
• Free-extension grace window: extensions within N days are no-charge.
• Extension fee curve: a function of (lock period, extension days, days remaining) producing a price hit.
• Cancellation fee policy: typically zero for best-effort locks; non-zero for mandatory delivery in some configurations.

With effective-dated policy inheritance, the desk-config layer carries the same versioning posture as ratesheets: change a fee curve today and it applies forward; historical locks remain priced against the curve effective when they wrote. Audit clarity follows.

Extensions in practice

Lock extensions are the most common operational interaction with the lock subsystem after creation. The pattern:

1. Operator (or LO via API) requests extension by N days.
2. Engine validates: extension within max-extension cap, lock not already in a terminal state.
3. Engine applies the fee curve to determine the price hit (or zero in the grace window).
4. Lock journal entry writes with the extension delta and fee.
5. Lock's expiry timestamp slides forward by N days, atomic with the journal write.
6. Webhook fires (locks.extended) for downstream consumers (hedge stack, BI).

Concurrency safety: the lock row uses optimistic locking. Two operators attempting to extend simultaneously result in one success and one 409 Conflict on the second; the second operator retries with the new state visible.

Distributed-safe expiry sweeping

Locks that pass their expiry without being extended must transition to EXPIRED. This is a scheduled job that runs on a short cadence (typically every minute). In a multi-replica deployment, you cannot naively run it on every replica — you'd expire each lock N times and emit N webhook deliveries.

The standard pattern uses distributed locking (ShedLock with a JDBC backend in the JVM ecosystem) so that exactly one replica wins the lock per cadence. The winner sweeps; everyone else observes the outcome via the audit log and event stream. This is one of those small details that separates production-grade from demo-grade.

Sell-side pricing alongside

For correspondents and mini-correspondents who hold loans on balance sheet before delivery, sell-side pricing is the desk's primary tool. Sell-side runs the same engine against the same loan facets but against the buy-side investor pack, returning the price that investor would pay for the closed loan.

A serious lock subsystem returns sell-side alongside the loan-level lock so the desk sees the bid-tape outcome next to the retail commitment. Sell-side completion writes its own audit row keyed by (lockId, sellSideId, executingInvestor) so reconciliation against actual investor settlements is a deterministic join, not fuzzy matching on timestamps.

The audit story

Lock journals tend to be the single most-audited data set in a lender. Make the audit story trivial: every state transition writes a journal entry; every journal entry is hashed into the platform audit chain; every entry carries the actor and the correlationId; the verify endpoint walks the chain and reports the first break, if any.

Done well, a regulator's "reproduce this lock's history" ask becomes a single API call returning the ordered journal plus the chain hashes. Done poorly, it's a database forensics exercise you'd rather not run.

Metrics every desk should watch

• Lock-to-fund ratio (pull-through): % of locks that fund vs. cancel/expire. Tracks origination quality.
• Lock breakage rate: % of locks that get cancelled and re-locked at a different rate. High breakage indicates pricing volatility or operational issues.
• Average extension days per funded lock: trend up indicates pipeline congestion or processing bottlenecks.
• Free-extension consumption: % of extensions that hit the grace window. Tunes the policy parameters.
• Sell-side execution spread: gap between expected sell-side and actual settlement. Drives hedging adjustments.

None of these are exotic. The discipline is collecting them consistently and reviewing them on a cadence — weekly for operations, monthly for the desk head.