What share of condition rework starts with a missing borrower explanation?

A condition clears, the file moves forward, and then the same issue returns because the borrower's explanation was never attached. The second review costs more than the first because the team has to reconstruct why the document was accepted. Rework is easy to notice and hard to attribute without a consistent definition. This protocol helps a mortgage team measure how much condition rework begins with a missing borrower explanation.

Question and scope

The question is what share of condition rework events can be traced to a missing or incomplete borrower explanation at the time the condition was first cleared. The scope should name the queue, the condition types, the time period, and the reviewers involved. A team might study income and asset conditions in one processing pod during a quarter. The narrower scope keeps the attribution close to the evidence.

Define rework as work that repeats a step already recorded as complete. A new condition is not rework, even when it concerns the same document type. A correction made before the first clearance is also not rework. The definition should be written down before sampling so a familiar file does not get classified differently from an unfamiliar one.

Unit of analysis

The unit is one rework event tied to a condition. The event starts when a reviewer reopens or returns the condition and ends when the condition clears again. Record the file key, the condition type, the first clearance date, the reopen date, and the reason code. A file with three rework events contributes three units rather than one.

Keep the original condition and the rework event linked. The analyst needs to see what changed between the first clearance and the return. If the team cannot reconstruct the sequence, the event should be coded as unverifiable rather than forced into a cause. Add the reviewer names as role labels rather than personal identifiers so the pattern can be discussed without turning the study into a performance review. An honest unknown is more useful than a guessed attribution.

Coding the cause

Create a short cause list before reading the files. Include missing borrower explanation, stale document, wrong document version, reviewer error, system error, and a residual category for causes that do not fit. Define missing borrower explanation as a condition that required a written or verbal explanation from the borrower and did not have one at first clearance. A document that was simply absent belongs in a different category.

Code from the file evidence, not from memory. Look for the condition text, the document received, the reviewer note, and the message to the borrower. If the explanation was provided but stored outside the file, the event may be a recordkeeping failure rather than a missing explanation. That distinction matters because the fix is different. Keep the evidence type in the record so a later reviewer can see what supported the code.

A missing explanation can be written or verbal. A written letter that does not cover the required period is incomplete, while a phone call that is not documented is missing from the record. Use separate codes for incomplete content and absent documentation. The team can then see whether the problem is what the borrower said or how the team recorded it.

Test the cause list on events from more than one reviewer. A code that only one person can apply is not ready for team use. Ask two reviewers to code the same five files and compare the results. If they disagree, rewrite the definition with a concrete example. Keep the example in the codebook so the next reviewer applies the same rule.

Sampling and observation

Use consecutive rework events from the chosen queue, or a random sample with a documented start. Do not sample only the events that are easy to classify. Include events from different reviewers, loan types, and condition categories if the volume allows. Record the number of events screened and the number excluded, with the reason for each exclusion.

The sample should be large enough to show a pattern but small enough to code carefully. A few dozen events can be reviewed in a reasonable time and still reveal whether one cause dominates. If the volume is high, code a random subset and report the confidence interval or at least the range. The condition clearing lead should review the coding rules before the full sample begins.

Data quality checks

Have a second person code a subsample independently. Compare the results and discuss every disagreement rather than averaging them away. A low agreement rate means the cause definitions are too vague or the file evidence is incomplete. Keep a short note for each disagreement and the rule that resolved it. Revise the codebook and recode the affected events before reporting.

Check for events that were reopened for a reason unrelated to the original condition, such as a new underwriting requirement. Those events should not be counted as rework caused by the first clearance. Also check for duplicate events created when the same condition was reopened in two systems. A duplicate can make a single problem look like a pattern.

Analysis and reporting

Report the number of rework events, the share by cause, and the number of files affected. Add the median days between first clearance and reopen for each cause. A cause that dominates the count but resolves quickly may be less costly than a smaller cause that adds a week. The report should show both frequency and time.

Separate the explanation problem from the documentation problem. A borrower may have explained the issue by phone, but the file may lack a note. In that case the rework starts with a missing record, not a missing explanation. The CFPB's Regulation Z and Regulation X provide context for recordkeeping, while the internal evidence shows what actually happened.

Add a short table of the three most common cause pairs. For example, a missing explanation paired with a missing note is a different problem from a wrong document paired with a reviewer error. The pair tells the team where to intervene. A single-cause ranking can hide the combination that produces the most rework.

Show the cost in review touches, not only in minutes. A rework event that adds a second reviewer or a new borrower request costs more than a quick correction. Count the number of touches and the number that reached the borrower. That view helps the team compare causes that look similar in frequency but differ in disruption.

Limits and sources of error

The file may not contain enough information to assign a cause. Reviewers often summarize a conversation in one line, and the summary may not distinguish an explanation from a promise to provide one. The analyst should use an unknown category rather than guessing. A high unknown share is itself a finding about record quality, and it may be the most actionable result in the study.

Rework that is never logged is invisible to the study. A specialist may fix a condition quietly and never reopen it in the system. The count is therefore a lower bound when the log is known to be incomplete. State that limitation in the report and avoid presenting the share as a complete account of all rework.

Review cadence

Repeat the protocol after a change to the condition checklist, the borrower request template, or the reviewer training. Use the same cause list and sampling rule so the comparison is meaningful. If missing explanations fall but recordkeeping failures rise, the team may have improved the conversation without improving the file. Report both movements and pick one follow-up change for the next cycle. Give the follow-up an owner and a date so the next review has a starting point.

Keep the codebook, sample, and examples in one place. A later reviewer should be able to see why an event was assigned to a cause. The mortgage operations support team can use the result to decide which condition types need a required explanation field. That change is more durable than a reminder to write better notes. Review the codebook after the first full cycle and remove any category that no event used.