Mortgage file quality assurance sampling checklist

Mortgage file quality assurance sampling is a second look at a representative set of completed support work. It checks whether the agreed process produced complete, traceable and review-ready outputs without forcing the broker to redo every task. The sample should identify system and instruction problems as well as individual errors.

This checklist is for operational quality assurance of tasks such as file preparation, CRM updates, document organisation and status follow-up. It is not a statutory or aggregator compliance audit. Use your own compliance program and approved requirements for those reviews.

Define the work unit before choosing a sample

A “file” can contain weeks of work by several people, which makes a finding hard to attribute or fix. Define the unit being reviewed: a document-request pack, an application data-entry step, a lender follow-up, a settlement checklist or another named output. Record the trigger, expected inputs, review point and acceptance check.

Connect the unit to the written mortgage outsourcing SOP. If the expected step is not documented, record a process gap instead of treating the worker's interpretation as the only cause.

Build a representative sample

Do not sample only the easiest work or only files that generated a complaint. Use a mix that can reveal normal performance and higher-risk variation. Start with a manageable fixed number, then increase the sample when the workflow is new, a change has occurred or findings are rising.

• Include items from different days, staff and brokers where relevant.
• Include standard work and a small number of known exceptions.
• Include accepted work, not only reworked items.
• Add targeted items after a system, SOP or access change.
• Record the population, selection method and sample size.
• Avoid using the result as a precise population rate when the sample is small or deliberately targeted.

For routine monthly QA, a simple method is a random base sample plus targeted items from new workflows, recent corrective actions and ageing exceptions. Keep those groups visible so a targeted sample does not make the ordinary rate look worse or better.

Check evidence, not memory

Review the source material, output, timestamps and recorded handoffs. Do not ask the person who completed the work to reconstruct what happened before identifying the evidence gap. A process that depends on memory cannot be independently reviewed or handed over safely.

Review area	Operational check	Evidence to inspect
Identity and assignment	The work belongs to the correct customer, entity, queue and owner.	Record identifier, assignment and source link.
Input completeness	Required inputs were present or missing items were recorded.	Intake checklist and blocker entry.
Accurate transfer	Factual values match the approved source and are placed in the correct field.	Source document and saved record.
Output completeness	The SOP steps and acceptance items are visibly complete.	Output, checklist and reviewer state.
Exception handling	Conflicts, uncertainty and out-of-scope work were escalated rather than guessed.	Issue log, message and decision owner.
Traceability	A reviewer can see who acted, when and what changed.	Activity history and dated notes.
Handover	The next action, owner and due point are clear.	Queue state or handover record.
Access boundary	The task was completed through approved accounts and locations.	Access record or system log available to the brokerage.

Use a small finding scale

Classify findings by effect and required response, not by how annoyed the reviewer feels. Define the scale once and give examples from the actual workflow.

1. Accepted: the output meets the written acceptance check.
2. Minor correction: a local fix that does not change the material outcome or next-stage readiness.
3. Material rework: incomplete or inaccurate work that must be corrected before the next stage.
4. Control exception: work outside the approved process, access or authority boundary.
5. Process gap: the instruction, system, source or approval design was missing or contradictory.

One item can contain more than one finding, but select one primary cause for trend reporting. Keep the detail in the review note.

Separate cause from symptom

“Wrong status” is a symptom. The cause might be an ambiguous definition, outdated SOP, field mapping error, missing source information, skipped check, access limitation or avoidable execution mistake. Ask what allowed the error and whether another competent person following the same process could repeat it.

Use cause categories that lead to different actions:

• Instruction: clarify the SOP, example or acceptance rule.
• Input: improve the intake gate or source ownership.
• System: change field labels, permissions, validation or queue design.
• Knowledge: provide targeted learning and a practice item.
• Execution: coach the missed step and resample.
• Capacity: reduce work in progress or adjust allocation.
• Approval: make the broker or decision-maker handoff explicit.

Close the loop with corrective actions

Every material or repeated finding needs an owner, action, due date and verification method. “Reminded the team” is rarely enough. Update the relevant instruction, control or training artifact, then review new work after the change. Close the action only when the follow-up sample shows the intended behaviour.

Feed recurring causes into the loan processor KPI scorecard as trends, not as a pile of isolated anecdotes. Keep personal coaching private while making shared process improvements visible to everyone who uses the workflow.

Use QA with everyday acceptance

Daily acceptance checks whether an output is ready now. QA sampling asks whether the operating system remains reliable over time. Do not replace one with the other. A broker should still approve the steps assigned to them, while periodic sampling tests accepted work and the consistency of those approvals.

Align the review with the support service-level schedule. Quality evidence belongs beside turnaround data. A fast queue with rising material rework is not performing well.

Review the file handoff as part of quality

Many defects appear at ownership changes rather than within a single task. Use the broker-to-processor handoff template to check that intent, inputs, open questions and the required review point travelled with the work. Sample both directions: broker to processor and processor back to broker.

Keep a fictional random sample separate from targeted checks

Assume 60 review packs were accepted during the period. The operations lead draws eight at random across the period, then adds four targeted packs from a newly changed workflow. These sample sizes illustrate the record format; they are not a statistical sampling rule or compliance requirement.

Group	Selection	Finding	What to report
Random base	8 of 60 accepted packs	1 material source-to-field mismatch	1 of 8 sampled packs had a material finding; a small-sample signal.
Targeted	4 packs using the changed instruction	2 missing reviewer confirmations	2 of 4 targeted packs had a finding; investigate the changed step.

Do not present the pooled three findings in 12 checks as the brokerage's defect rate. The targeted group was deliberately selected for a different reason. Record the item links, expected step and evidence for each finding. If the changed instruction omitted the confirmation field, classify that cause as an instruction or system gap, assign an owner to restore the check, and sample new work after the correction. Keep the original finding and later verification distinct; fixing one record does not demonstrate that the process is fixed.

Copy this QA review record

Field	Record
Work unit and period	Workflow, population dates and total items.
Sample method	Random, targeted or mixed; sample count and reason.
Item evidence	Record link, source link, output and reviewer.
Result	Accepted, minor, material, control exception or process gap.
Primary cause	Instruction, input, system, knowledge, execution, capacity or approval.
Immediate correction	What was fixed and who approved it.
Corrective action	Owner, due date and changed artifact.
Verification	Follow-up sample date and outcome.

A mature QA process does not aim to catch people out. It makes weak instructions, overloaded queues and recurring rework visible early enough to improve them.