How often do post-closing document requests reopen a closed file?

A file closes, the final package is archived, and three weeks later an investor asks for a missing page. The request may be routine, or it may reopen work the team thought was finished. Teams often track post-closing volume without separating requests that change the file's status. This protocol defines a reopen event and gives a mortgage operations team a way to measure how often closed files come back into active work.

Question and scope

The question is how many closed files receive a post-closing document request that reopens the file within a defined window. The scope should name the closing period, the investor or program, and the team that handles the request. A team might study files closed in one quarter and follow them for sixty days. The window matters because a request at day ten and a request at day ninety have different operational meaning.

Define "closed" using the team's own system status, not the closing date alone. A file may close on the calendar while the final documents are still being assembled. The protocol should record both the closing date and the date the file reached its closed status. The difference explains why some requests arrive before the team considers the file finished.

Unit of analysis

The unit is one closed file followed through the observation window. A file with several document requests counts once for the reopen rate, but each request is recorded as a separate event. That structure lets the team report both the share of files affected and the number of requests per affected file. A single file with five requests is a different problem from five files with one each.

Record the file key, the closing date, the closed status date, the request date, the document requested, and the outcome. Keep the borrower identity out of the analysis file. If a request is later withdrawn, keep it in the data with an outcome code rather than deleting it. Removing withdrawn requests can make the process look cleaner than it was.

Defining a reopen event

A reopen event should mean the file returned to an active work queue because of the request. A request that is answered from the archive without changing the file status is not a reopen. A request that requires a new borrower signature, a corrected disclosure, or a new investor condition is a reopen. The distinction keeps the measure focused on work that consumed capacity.

Write the rule with examples from the team's own files. A missing trailing page that the team uploads from its archive may be a records request, while a missing signature requires borrower contact and a new document. Both matter, but they belong in different categories. Add a category for a request that arrives before the file reaches closed status, because that is a closing handoff problem rather than a post-closing one. The post-closing support lead should approve the examples before sampling begins.

A reopen can also be caused by a document that was present but unreadable or stored in the wrong file. The request looks like a missing document, but the root cause is indexing. Code the event by the reason the team had to reopen the file, not only by the document named in the request. That distinction helps the team choose between a checklist change and an archive cleanup.

Test the rule on a small set of files before the full sample. Give two reviewers the same five files and compare their categories. Discuss the disagreements and adjust the wording. A rule that cannot be applied consistently in a small test will not survive a larger sample. Keep the test files out of the main sample if they influenced the final rule.

Sampling and observation

Use consecutive closed files from a defined period, or a random sample with a recorded start. Include files from every investor or program in the scope, not only the ones with known problems. Record the number excluded and the reason, such as a missing closing date or an inaccessible archive. A sample that excludes the hardest files will understate the reopen rate.

Set a minimum follow-up period and apply it to every file. A file closed near the end of the study may not have had enough time to receive a late request. Exclude it or mark it as incomplete instead of counting it as a clean file. The report should show how many files reached the full window.

If the request log is maintained by more than one person, compare their entry habits before combining the data. One person may log every phone call, while another logs only portal tasks. A short review of five entries from each person can show the difference. Note any inconsistency rather than assuming the log is uniform.

Follow each file through the full observation window. Use the document request log, the investor portal, and the file notes to identify events. If a request arrives by phone and is never logged, the team may need a short interview with the post-closing specialist. Document the source for each event so a reviewer can verify it.

Data quality checks

Check for duplicate requests recorded under different names. The same missing page may appear as a condition, an email, and a portal task. Match events by file, document type, and date before counting. A duplicate that survives will inflate the request count and make one file look like several. Keep the raw request list so a reviewer can see how the match was made.

Look for files that were reopened for reasons unrelated to a document request, such as a pricing correction or a servicing transfer. Keep those events in a separate category. The report should also distinguish a request from the investor from a request from an internal quality review. The two have different causes and different fixes.

Analysis and reporting

Report the number of closed files, the number with at least one reopen, the total reopen events, and the median days from closing to the first event. Add the distribution by document type and by investor. A median alone can hide a long tail, so include the number of events after thirty days. The reader should be able to see both the common case and the late cases.

Separate the rate from the cost. A reopen rate of a few percent can still consume significant time if each event requires borrower contact and a new disclosure. Record the estimated minutes per event and the number that required a new signature. The CFPB's Regulation X recordkeeping expectations support a clear trail, but the operational question is whether the file should have been complete at closing.

Add a file-level table for the cases with more than one request. The table should show the document, the request date, and the reason. A single file with several requests may reveal a pattern that the aggregate rate hides. It also gives the team a concrete case for the next review. Remove the borrower identifiers before sharing the table outside the operations team.

Report the result with a clear denominator and a note about the observation window. A reader should not have to infer whether the rate is per closed file, per document, or per request. Use the same unit in the text and the table. Consistency prevents a reader from comparing two numbers that measure different things.

Limits and sources of error

A short observation window will miss late requests, while a long window will capture events caused by later servicing changes. State the window and avoid comparing results from different windows without adjustment. Files that are still in the archive may be inaccessible to the analyst, which can bias the sample toward recent closings. Report the age of the files and the share that could not be reviewed.

The request log may be incomplete, especially for phone calls and informal emails. The team should treat the count as a lower bound when the log is known to be partial. A file that was reopened but never recorded is invisible to the measure. The report should say so rather than presenting the count as exact.

Review cadence

Repeat the protocol after a change to the closing checklist, the document indexing rule, or the investor submission process. Use the same window and definitions so the comparison is meaningful. If reopens fall but the time per event rises, the team may have shifted work rather than removed it. Report both the count and the effort.

Keep the sample list, the event definitions, and the examples in one place. A later reviewer should be able to reproduce the count without guessing which request belonged in which category. The loan processing support team can use the result to decide which closing documents need a second check. A short review with the post-closing specialist will usually explain the largest category.