How much processor time goes to re-keying data between mortgage systems?

A processor copies a borrower's employer name from the loan origination system into a vendor portal, then copies the vendor's response back into the file. The task feels small in the moment and disappears into the day's total. Measuring it requires a definition, a sample, and a rule for separating necessary entry from duplicate entry. This protocol gives a mortgage operations team a repeatable way to estimate that cost without pretending the result is a national benchmark.

Question and scope

The question is how much processor time in a defined period is spent entering information that already exists in another approved system. The scope should name the files, the systems, the roles, and the date range. A team might study one branch's purchase files during a four-week window, or one queue's refinance files during a month. Broad scope produces a vague answer, while narrow scope produces a result the team can act on.

Exclude time spent making a lending decision, reviewing a document for accuracy, or speaking with a borrower. Those activities matter, but they are not re-keying. Include the lookup, the copy, the paste, the correction of a rejected field, and the second check that confirms the value landed. The boundary should be written before observation begins so the sample cannot drift toward the easiest tasks.

Unit of analysis

The unit is one re-keying event, not one file or one processor shift. An event starts when the processor opens the source record to retrieve a value and ends when the value is saved in the destination system. A single condition may produce several events if it requires a vendor portal, a document system, and a status field. Counting events rather than files shows where repetition concentrates.

Record the file, the role, the source system, the destination system, the field, and the duration. Use a pseudonymous file key and keep the crosswalk in an approved location. The event record should not include borrower names or account numbers in the analysis file. That separation protects privacy while preserving the operational detail the team needs.

Building the time categories

Create categories before the first observation so the team does not invent labels after seeing the data. Useful categories include initial entry, duplicate entry, correction after a failed validation, and confirmation of a transferred value. Add a category for re-entry caused by a system outage or a vendor rejection. Each category should have a plain description and one example.

Keep the number of categories small enough to remember. Six to eight is usually workable for a single queue. If a category has only one event after two weeks, merge it or explain why it remains. Add a short note field for cases where the processor had to leave one system to find a value in another, because that movement is part of the cost. The loan processing support lead should approve the final list and the definition of duplicate entry, because that definition drives the headline result.

A useful category list also separates a first entry from a correction. A processor who types a new value into an empty field is doing necessary work, while one who retypes a value already present is doing duplicate work. A correction after a failed validation is a third case, because the system rejected the value and forced a re-entry. These distinctions matter when the team decides whether to fix a training issue, a data quality rule, or an integration.

The category definitions should survive a change in staff. Write each one in plain language and add a boundary case that explains what does not count. A new analyst should be able to read the list and classify a sample without asking the original designer. If the list requires a weekly meeting to interpret, it is too complicated for routine use.

Sampling and observation

Use consecutive files from the chosen queue rather than a convenience sample of the files that happen to be open. If the queue is large, take every nth file after a random start. Record the sampling rule and the number of files excluded, with the reason for each exclusion. A sample built only from easy files will understate the time spent on exceptions.

Observation can be direct or reconstructed from system logs, but the method must be consistent. A trained observer can time events with a simple start and stop rule, while a log review can use timestamps for field edits. Do not mix methods within the same reported total unless the report separates them. A mixed method needs a clear note about the difference in accuracy.

Build the sample frame before the first observation day. List the files or work items that are eligible, the ones that are out of scope, and the rule for replacing an item that cannot be observed. A replacement rule prevents the analyst from quietly choosing a similar but easier file. Record every replacement with the original reason so the final sample can be audited.

If the sample spans several processors, give each person the same observation instructions. Differences in how one person starts the clock can create a false pattern. A short calibration session with two practice events is usually enough. The goal is a shared definition, not a perfect stopwatch. Write the calibration examples into the study notes so a later analyst can repeat them.

Data quality checks

Check for events with impossible durations, such as a negative time or a value longer than the shift. Look for the same event recorded twice by two observers, and for files that appear in the sample but not in the source queue. A short daily review catches most recording errors before they reach the analysis. Waiting until the end of the month makes corrections harder to trace.

Compare a small subsample with a second observer or a system log. Report the disagreement rate rather than hiding it inside an average. If the disagreement is high, refine the event definition before continuing. Keep the comparison notes with the sample so a later reader can see how the estimate was tested. The CFPB's supervision and examination resources emphasize documented controls, and a measurement with an unexplained gap is difficult to defend.

Analysis and reporting

Report total events, total observed time, median time per event, and the share of time by category. A median is more useful than a mean when a few long corrections pull the average upward. Add the number of files and the number of processors in the sample so a reader can judge the base. Do not report a percentage without the denominator.

Separate the cost of necessary entry from the cost of duplicate entry. The first is part of the work, while the second is a candidate for automation or a process change. Show the result by source and destination system so the team can see where the handoff is weakest. A simple table with counts and medians is enough for a management review.

Add one qualitative note for each system pair. A pair may have a high median because the destination requires many fields, or because the source is difficult to search. The note explains what the number cannot. Keep the note short and tie it to a specific observation rather than a general impression. The note should also say whether the team has a planned change for that pair.

Before publishing the result, check whether the headline changes if the three longest events are removed. If one file drives the conclusion, report the result with and without that file. A stable finding should survive a small change in the sample. A fragile finding is still useful, but it needs a caveat. State the rule for removing outliers before looking at the data so the choice is not made after the fact.

Limits and sources of error

Observation changes behavior, especially during the first week. Tell the team that the purpose is to improve the workflow, not to grade individual speed. Exclude the first few days if the observer effect is obvious, and say so in the report. Small samples are sensitive to one complex file, so report the count and the range alongside the median.

System logs may miss manual lookups that never produce an edit. Direct observation may miss work that happens in a personal window. Neither method captures the mental cost of switching between systems. A third limitation is that the sample may include a week with unusual staffing or a vendor outage. The report should name these limits rather than implying that the measured minutes are the whole cost.

Review cadence

Repeat the protocol after a process change, using the same categories and sampling rule. Compare the median, the category mix, and the number of duplicate events. If the change moved work from one system to another without reducing the total, the report should say so. A lower total with a higher error rate is not automatically an improvement.

Keep the event definitions, the sample list, and the analysis notes in one place. A later reviewer should be able to repeat the method without reconstructing the decisions. The mortgage operations support team can use the result to decide whether a field should be integrated, eliminated, or left alone. That decision is more useful than a one-time number.