Reverse mortgage data migration acceptance criteria

Reverse mortgage data migration acceptance criteria turn an import result into a reviewable decision. Define the population, expected reconciliation, evidence and decision owner before a rehearsal. Then record whether the tested data supports the specific work you plan to move into the new loan origination system (LOS).

This worksheet is for technology and operations owners preparing that decision. It supplies a reusable acceptance record and a fictional reconciliation example. The proposed checks are operating choices, not regulatory requirements or claims about ReversePilot capabilities.

Define reverse mortgage data migration acceptance criteria

Give each acceptance record a bounded cohort: a named group of files with explicit inclusion rules. “All active loans” is incomplete if source and destination teams define active differently. Record the source snapshot, migration run identifier and destination configuration together.

Use the data migration overview for mapping and transition principles. This worksheet adds the decision artifact: what was checked, what failed, who reviewed it and exactly which records the decision covers.

• Population: identify included file IDs, exclusions and snapshot time.
• Expected result: specify counts, relationships and field comparisons before the run.
• Evidence: name the output that lets another reviewer reproduce the check.
• Decision: identify the owner, permitted scope and conditions that reopen acceptance.

A successful transfer message establishes that a process completed. It does not establish that an attachment opens under the intended role or that a migrated task belongs to the correct file. Keep technical completion separate from business acceptance.

Copy this acceptance record for each cohort

Use the fields below in your own controlled worksheet. Create a separate record when a cohort has different mappings, evidence or business owners. Keep borrower information inside approved systems; the examples here use synthetic file labels only.

Specify a comparison rule for each important field. An imported historical event date and the new system's import date represent different events. If a transformation changes a value, link its approved rule rather than declaring every difference an error.

Write acceptance thresholds as deliberate decisions for this cohort. Avoid copying an unexplained percentage from another project. If missing attachments prevent staff from doing the intended work, a high overall record-match percentage cannot resolve that limitation.

Work through a fictional equal-count failure

Suppose rehearsal cohort DEMO-A contains eight synthetic source files, M01 through M08, with twelve expected attachments. The destination reports eight file rows. A reviewer initially records the count check as passed.

The ID-level comparison finds M07 twice and no M08. There are eight rows but only seven unique file IDs. The attachment check finds eleven documents; the missing document belongs to M08. Equal row totals concealed both a duplicate and an omission.

1. Record expected files: eight unique IDs, with the twelve-attachment manifest.
2. Record actual files: eight rows, seven unique IDs, duplicate M07, missing M08.
3. Assign finding EX-01 to the migration owner: explain and correct the identity mismatch.
4. Hold this cohort's acceptance while the missing file and attachment remain unresolved.
5. After correction, rerun ID, attachment and relationship checks using the same baseline.

The completed acceptance entry reads: “DEMO-A; run R1; hold; EX-01 unresolved; migration owner to investigate; operations reviewer to inspect corrected evidence.” That is a fictional decision record, not a claim that a particular import tool behaves this way.

A corrected run R2 can support acceptance only after review. Link its results to EX-01 and preserve R1's evidence. If a reviewer authorizes limited use instead, identify the permitted file IDs and the practical boundary; “accepted with exceptions” alone is ambiguous.

Review evidence before signing off

Pair population comparisons with tests of meaningful file content. Record which synthetic cases were opened, which role performed the test, and what was observed. A sample demonstrates those cases; it cannot prove that every untested record is correct.

The Federal Reserve's SR 24-6 announcement describes the Federal Financial Institutions Examination Council's updated technology development, acquisition and maintenance handbook. The letter applies to Federal Reserve-supervised entities and says the booklet imposes no new requirements. It provides background, not a universal mortgage-lender checklist.

• Can the receiving role locate the current attachment and its intended file?
• Do linked people retain distinct identities and relationships?
• Are unresolved tasks still open and assigned to the intended owner?
• Can the reviewer explain transformed, blank and excluded values?

Use the software testing approach to document starting state, action and expected result. Separate an unresolved mapping decision from an import defect so the correct owner can resolve it.

Define what reopens acceptance

Acceptance describes a particular baseline and run. Later source edits, changed mappings or a different destination configuration may invalidate the comparison. Record these as review triggers rather than assuming the original sign-off covers later changes.

Document who reconciles changes after the snapshot and who authorizes the working-system switch. If a fallback becomes necessary, identify new work that would need reconciliation. Reopening the source system alone does not account for later destination changes.

Key takeaways

• Bound acceptance by cohort, snapshot, mapping and run.
• Compare unique identities and relationships alongside row totals.
• Link every exception to an owner, retest and explicit decision.
• Record the permitted scope and triggers that reopen acceptance.

Use the LOS buyer guide to carry unproven migration questions into vendor evaluation, or bring a synthetic acceptance record to a ReversePilot demo and ask which checks can be demonstrated.