How often do rate lock expirations surprise the processing team?

A rate lock has a date, but the date does not announce itself. It sits in a lender portal or a confirmation email while the team works on conditions and closing schedules. When someone finally notices, the lock may have a day left or may already be gone. The surprise is not just a date error because it changes pricing and the borrower conversation.

This study measures how often a lock expiration surprises the processing team. It defines a surprise by lead time, not by the final outcome, and it separates a late discovery from an unavoidable change. The protocol uses records the team already keeps and a short weekly review. The result helps an operations leader decide whether the problem is visibility, ownership, or process timing.

Question and scope

The question is what share of rate locks become a surprise to the processing team. The scope names the team, the lenders, the loan types, the lock terms, and the period. A team might study locks registered during a ten-week window and follow them through expiration or closing. The result applies to that setting and should be reported with it.

Define the processing team as the people who own the file after the loan officer hands it over. A surprise felt only by the loan officer is a different event, though it may have the same cause. The study can include both roles but should report them separately. The distinction matters because the fix may sit in a different part of the workflow.

Define the expiration date from the lender's lock confirmation. Do not use a date typed into a spreadsheet unless it matches the confirmation. The source should be named in the protocol and checked at registration. A date that was wrong from the start cannot be used to measure a surprise.

Defining a surprise by lead time

A surprise occurs when the team first learns of an expiring lock inside two business days of expiration. The two-day threshold is a starting point, not a universal standard. A complex file may need more lead time to extend or re-lock, while a simple file may need less. The team should set the threshold before the study and keep it fixed.

Record the date the team first acted on the expiration, not the date someone mentioned it in passing. An action could be a portal check, an email to the lock desk, or a borrower conversation. A comment in a meeting without a follow-up is not enough. The action date is the evidence that the team recognized the risk.

Also record the date the team should have acted under its own rule. If the rule says ten business days before expiration, a first action at five days is late even if it is not inside the two-day surprise window. The study can report both the surprise rate and the rule-compliance rate. The two measures answer different questions.

Why surprises happen

A lock date can be invisible for several reasons. The confirmation may sit in an inbox that nobody monitors. The loan origination system may not have a lock field. The processor may assume the loan officer is tracking the date. The team may be focused on conditions and treat the lock as a closing-week task.

The cause matters because the fix is different. An inbox problem calls for a shared mailbox or an intake step. A missing field calls for a data update. An ownership gap calls for a named role. A closing-week habit calls for earlier checkpoints. The study should code the cause before recommending a change.

A surprise is not always a process failure. A lender may change a lock date or a loan may move to a different product. The study should include these causes so the rate is not presented as entirely preventable. A credible result separates internal visibility from external change.

Sampling locks

Sample locks from the lender confirmations or the lock register rather than from the closing calendar. A closing-calendar sample over-represents files that reached closing and misses files that expired or canceled. The lock register gives a more complete view of the population. A register that includes canceled files also shows whether the team loses locks quietly.

Use consecutive weeks and include locks of different terms. A thirty-day lock and a ninety-day lock have different risk profiles. Include files from different loan officers and processors so the sample is not dominated by one person. Record the loan type and the lender for each lock.

Follow each sampled lock to its outcome: closed before expiration, extended, re-locked, expired, or canceled. The outcome is needed to interpret the surprise rate. A team with many extensions may look good on surprises but still carry a cost. A team with few extensions may be closing faster or may be losing locks quietly.

Measuring lead time

Calculate lead time as the number of business days between the first action and the expiration date. A negative lead time means the team acted after expiration. Report the median and the range, not only the average. A few very early actions can make an average look better than the typical file.

Record the action that started the clock. A portal check is a weak action if it does not lead to a decision. An email to the lock desk or a borrower conversation is a stronger action. The protocol should define which actions count so the measure is consistent.

Compare lead time with the team's own rule. If the rule says ten days and the median is four, the rule is not being followed. If the rule says ten days and the median is twelve, the team may be checking earlier than required. The comparison shows whether the problem is the rule or the execution.

Coding the cause

Use a small set of causes: no visible date, date in an unmonitored inbox, ownership gap, late file change, lender change, and unknown. Add a category for a system error only when the evidence supports it. Too many causes produce inconsistent coding and a weak report. A category that is rarely used should be removed before the next study.

Pilot the categories on ten locks before the main sample. Ask two reviewers to code the same locks and compare. If they disagree, rewrite the definition or add an example. A category that requires a meeting every time will not survive a busy week.

Resolve disagreements with a written rule. For example, decide whether a loan officer's verbal reminder counts as an action or only a written communication counts. Write the answer in the protocol and apply it to the rest of the sample. Apply the rule to the next ten locks and check agreement again.

Reporting the rate

Report the surprise rate as a range with the sample size, the period, and the scope. Show the share of locks that expired or required an extension after a surprise. Separate the outcome from the lead time so the reader can see both the frequency and the cost. The report should also state how many locks were still active at the end of the period.

Break the rate down by cause, lender, and lock term. A high share of no-visible-date causes may point to a data field problem. A high share of ownership-gap causes may point to a handoff problem. A high share for one lender may point to a portal or confirmation issue.

Pair the rate with the number of days of notice given to the borrower. A surprise that reaches the borrower with one day of notice is a different service event from one with five days. The report should show the borrower-notice distribution. That measure captures the impact better than the internal rate alone.

What the result can change

A high surprise rate does not automatically justify more staff. It may justify a watchlist, a data field, or a weekly checkpoint. The study should list the changes that could reduce surprises before it recommends additional capacity. The team should separate a visibility problem from a workload problem.

The mortgage operations support team can test a watchlist on a small group and rerun the protocol. A list refreshed from the lender portal is easy to test because the team can compare surprise counts before and after. The test should run long enough to cover a normal lock cycle. Keep the test group small enough that the rest of the team can continue the normal work.

If the rate stays high after the change, the team may have a genuine capacity gap or a lender confirmation problem. The loan processing support lead can review the lock intake and the closing calendar. The result should distinguish a visibility defect from a workload problem. A measure that leads to the wrong fix is worse than no measure at all.

Limits and sources of error

The study measures recorded surprises, not every surprise. A team that discovers an expiration and fixes it quietly may not record the event. A team that never notices may not create a record at all. The result is a lower bound on the true rate in many teams.

Recall and attribution can bias the coding. A processor who remembers the file may assign a cause that fits the outcome. Use the portal history, the email log, and the lock confirmation to check the cause. When the evidence is insufficient, code the event as unknown rather than guessing.

The sample may miss locks that were canceled before the study period ended. Those locks can still show a visibility problem. Add a short review of canceled locks each quarter. The review should focus on the cause and the notice given, not on assigning blame.

Review cadence

Repeat the study after a change to the lock intake, the watchlist, or the ownership model. Use the same definitions and the same sampling rule so the comparison is meaningful. A rate that falls while extensions rise may mean the team is catching locks earlier but still cannot close on time. A comparison across different definitions is not valid, so freeze the codebook before the second round.

Share the result with the people who recorded the events. Ask which locks were hardest to see and which actions worked. The discussion can reveal a confirmation that nobody opens or a field that nobody trusts. The next study should test one of those findings.

End with a single sentence that states the surprise rate, the period, and the main visibility change the team can make. A precise finding with a named owner is more useful than a long report. The goal is a lock date that is visible before it becomes urgent. The sentence should name the change the team can make, not a cause outside its control.