The lock lifecycle, the audit posture you should expect, sell-side pricing, and how to evaluate one without getting trapped in vendor terminology.
Lock-desk policy gates the request (program/period/approver). The pricing engine pins the current price and adds margin layers; the lock journal records inputs, outputs, actor, and timestamp. correlationId joins this row to the originating quote.
Extension is a new journal entry with the policy-driven extension fee, a new expiry timestamp, and a hash-chain link back to the original lock. Optimistic locking prevents two operators from extending the same lock simultaneously; the second writer gets a 409 with the current state.
Cancellation is irreversible — the lock transitions to CANCELLED, the journal records the actor and reason, and downstream subscribers (hedge desk, ops) are notified via webhook. Sell-side audit captures the cancellation cost if any.
Locks either fund (close the loan, terminal state FUNDED) or expire (terminal state EXPIRED via the sweeper). Both transitions emit lock-lifecycle events with full audit trail. Indefinite-retention is the recommended posture for the lock journal.
Pricing returns candidate quotes; lock software commits to one of them. That commitment carries five concerns the platform has to handle together: policy enforcement, journal integrity, sell-side alignment, expiry safety, and event distribution.
Lock-desk policy lives in version-pinned configuration: max lock period per program, extension fees by tier, who can override and with what approval flow, business-hour gating. The platform should be able to replay any prior policy at any prior moment — auditors ask "what was the rule on March 14th?" and the answer has to be deterministic, not a memory test.
Every state transition is a journal entry. Append-only storage with a SHA-256 hash chain makes mutation detectable. The journal row carries the actor, the timestamp, the correlation ID, the effective ratesheet version, and the policy version that was active at the moment of the transition.
Sell-side pricing returns alongside loan-level pricing in the same call. The secondary desk and the retail loan officer read the same numbers. When the bid tape comes back, the join key is the correlation ID, not a fuzzy match across timestamps and loan IDs.
An expiry sweeper runs on a schedule, processes locks past their expiration, and emits expiry events. Distributed coordination is non-negotiable in any multi-instance deployment — without it, two workers can both expire the same lock and emit duplicate events. ShedLock (or equivalent JDBC-row coordination) is the standard.
Every state change emits a webhook event: locks.created, locks.extended, locks.cancelled, locks.funded, locks.expired. HMAC-signed deliveries with retry, DLQ, and replay are how the hedge desk, ops, and downstream BI keep up with the lock pipeline.
Frequently asked
Software that manages the full rate-lock lifecycle: creation, extension, cancellation, funding, and the audit trail of every state change. Lock-desk operations layer policy on top — who can lock what, for how long, with what approval flow — and most platforms include sell-side pricing for the secondary marketing handoff.
Because the lock is a binding event, not a quote. The lock pins a specific price (with margin layered) for a specific time window, generates a rate-lock journal entry, and triggers downstream events (notifications, funding workflows, audit). Pricing engines compute candidate prices; lock subsystems commit to one and manage what happens next.
Per-organization rules: maximum lock period by program, extension fees by tier, who can override the policy and with what approval, what happens when a lock is requested outside business hours. Production-grade systems version-pin the policy so an audit can replay any prior policy at any prior moment — not just look at today's rules.
The price the secondary-marketing desk would receive when selling a loan to its takeout investor. Locking on the retail (loan-officer) side and reading the sell-side number in the same call lets the secondary desk monitor margin in real time. Without it, sell-side and retail diverge silently and you find out at month-end.
Every lock state change (CREATE / EXTEND / CANCEL / FUND) is a regulatory event. Append-only audit logs with a SHA-256 hash chain make any post-write mutation detectable; the difference between 'we trust no one mutates the table' and 'we can prove no one mutated the table' is enormous to compliance and to insurers.
Locks expire on a defined schedule — usually 15, 30, 45, 60, 75, or 90 days. The platform must run an expiry sweeper that handles distributed-safe coordination (so two processes don't both expire the same lock), emits expiry events, and produces audit rows for the expiry transition. ShedLock or equivalent JDBC-coordinated locking is the standard pattern.
Yes, in principle. In practice the integration friction is significant — pricing data shapes differ between vendors, audit chains don't span systems, sell-side reconciliation gets messy. Best-in-class platforms ship pricing and lock subsystems together with a shared event backbone, so the seams are internal and clean.
See the lifecycle on your data
Create, extend, cancel, fund. Watch the audit chain grow, see the sell-side number, replay a prior policy. We'll spin up a sandbox with your investor pack.