Do mortgage teams measure condition aging consistently across lenders?

Condition aging looks like a simple number until two lenders report different ages for the same kind of condition. One team starts the clock when the condition is issued, another when the borrower is notified, and a third when the document arrives. The difference can be several days, which is enough to change a priority list and a staffing decision. A comparison that ignores the start event can make a well-run team look slower than it is.

This review compares the aging definitions teams use across lenders and asks whether the numbers are consistent enough to combine. It does not assume that one definition is correct. It treats the definition as part of the measurement and reports the differences before any comparison. The result is a method a team can use to align its own reporting.

Question and scope

The review asks whether condition aging definitions are consistent across the lenders a team works with. Scope names the lenders, the condition types, the stages, and the period. A team might review purchase and refinance files from three lenders during a quarter. The result applies to that lender mix and should be reported with the scope.

Define the unit of analysis before collecting data. A condition is a lender requirement that must be satisfied before the file can move forward. A condition may have several documents and several review rounds. The review should count the condition, not each document, unless the lender treats each document as a separate requirement.

Decide which conditions to include. A broad review might cover income, asset, property, and title conditions. A narrow review might focus on the conditions that most often delay closing. The scope should name the condition types and exclude the ones that are not comparable across lenders.

The start event problem

The start event is the first source of inconsistency. A condition may start when the underwriter issues it, when the system logs it, when the processor acknowledges it, or when the borrower is notified. Each event can be days apart. A report that does not name the start event cannot be compared with another report.

Ask each lender or team to name the start event in writing. If the answer is "when the condition is created," ask which system creates it and whether the creation is automatic. A condition created by an underwriting engine may appear before a person reviews it. The clock may start before anyone can act.

Test the definition against a sample. Pick five conditions and trace the dates from the system log, the borrower message, and the underwriter note. If the dates differ, the definition is not stable enough for a cross-lender comparison. The test should be repeated when a lender changes its workflow.

Pause rules and business days

Aging definitions also differ in how they handle pauses. Some teams pause the clock when a condition is waiting on a third party, while others keep counting. Some pause on weekends and holidays, while others use calendar days. The choices change the age of a condition and the priority it receives.

Write the pause rule down and apply it consistently. If the rule is "pause when the appraisal desk confirms a scheduled date," record the confirmation date and the resume date. A pause without a resume date becomes a way to hide a stalled condition. The report should show the paused days separately.

Choose a calendar and state it. Business days are more meaningful for a team that does not work weekends, but calendar days are easier to reproduce from a system timestamp. The important thing is consistency. A report that mixes calendars cannot be compared across lenders or across months.

Building a comparable measure

A comparable measure needs a shared start event, a shared pause rule, and a shared calendar. If the lenders cannot agree, create a normalized measure for internal use. The normalized measure can use the date the condition first appears in the team's queue and count business days until the condition is cleared or the file closes. Label it clearly so nobody mistakes it for a lender-reported figure.

Keep the lender's native measure beside the normalized one. The native measure may be required for a lender scorecard or a contract. The normalized measure helps the team compare its own work across lenders. The two measures should be labeled clearly so nobody mixes them.

Document the normalization rule in a short note. Include the start event, the pause rule, the calendar, and the rounding rule. A reader should be able to reproduce the number from the note and the source data. A measure that cannot be reproduced is a claim, not a metric.

Sampling conditions across lenders

Use a sample that covers each lender and each major condition type. A sample of one lender's income conditions will not show whether the difference is lender-specific or condition-specific. A rotating sample over a quarter gives a fairer picture without reviewing every file. Report the lender mix beside the median so a reader can see what the sample represents.

Include conditions that were cleared and conditions that are still open at the end of the period. Excluding the open conditions would understate the age and hide the hardest cases. For open conditions, report the age at the end of the period and mark them as censored. A censored condition is not a failure; it is an incomplete observation.

Record the file, the lender, the condition type, the start date, the pause dates, the clear date, and the reviewer. Add a short note for any condition that changed type or was replaced. A replaced condition can otherwise look like a new condition with a young age. The note preserves the history.

Comparing medians and ranges

Compare medians rather than averages. A few very old conditions can pull an average away from the typical experience. The median shows what most conditions experience, and the range shows the outliers. With a small sample, show each condition rather than a summary.

Report the sample size and the censored count beside every median. A median based on eight conditions is a weak signal, even when the number looks precise. The report should say so. A reader should be able to judge whether the comparison is strong enough to act on.

Do not rank lenders on a single median. A lender with a longer median may have more complex conditions or a different borrower mix. The comparison should include the condition type, the documentation requirement, and the sample size. A ranking without context invites the wrong conclusion.

Reporting the differences

Start the report with the definitions, not the numbers. Show how each lender defines the start event, the pause rule, and the calendar. Then show the normalized measure and the native measure side by side. A reader who sees the definitions first will interpret the numbers more carefully.

Use a short table for the definitions and a chart for the distribution. The table should fit on one page and use plain language. The chart should show the median and the range, not only a single point. A chart that hides the sample size is easy to misread.

End with the conditions that are not comparable and explain why. A condition that is defined differently by each lender may need to be excluded from the comparison. Excluding it is more honest than forcing it into a shared category. The report should name the exclusion and the reason.

What the comparison can change

A definition difference is often a process opportunity. If one lender starts the clock at notification and another at issuance, the team can standardize its internal queue to the notification date. That change makes the internal priority list more realistic without waiting for the lenders to agree. The team can also ask a lender to clarify its definition.

The mortgage operations support lead can test the normalized measure on one lender and compare it with the native measure. A small pilot is enough to show whether the normalization changes the priority order. The pilot should run long enough to cover a normal closing cycle. Keep the pilot group small enough that the rest of the team can continue the normal work.

If the normalized measure shows a persistent gap, the team may have a genuine capacity problem or a lender process that requires more time. The loan processing support team can review the condition types and the escalation path. The result should distinguish a definition problem from a workload problem. A comparison that leads to the wrong fix is worse than no comparison.

Limits and sources of error

The review measures recorded dates, not the actual work. A condition may be cleared in the system days after the document was accepted. The recorded age may be longer than the borrower experienced, or shorter if the system was updated late. Report the recording rule with the result.

The sample may miss conditions that were never entered into the system. A processor who resolves an issue by phone may not create a condition. Add a short end-of-day prompt that asks for unlogged work. The prompt improves coverage without turning the review into surveillance.

The lender definitions may change during the period. A mid-quarter change can make the comparison invalid. Record the date of each definition and split the sample when a definition changes. A report that ignores the change will mix two different measures.

Review cadence

Repeat the review after a lender changes its workflow, after a system migration, or after the team changes its own queue rules. Use the same normalization rule and the same sampling method so the comparison is meaningful. A median that falls while the number of open conditions rises may mean the team is closing the easy conditions first. A comparison across different definitions is not valid, so freeze the rule before the second round.

Share the result with the people who record the dates. Ask which start event was hardest to identify and which pause rule caused the most debate. The discussion can reveal a system field that nobody trusts or a notification that arrives late. The next review should test one of those findings.

End with a single sentence that states the normalized median, the period, and the definition difference the team can fix. A precise finding with a named owner is more useful than a long report. The goal is a condition queue that measures the same thing every week. The sentence should name the change the team can make, not a cause outside its control.