Reverse mortgage LOS integration requirements worksheet
Define integration boundaries, evidence and owners with a reusable worksheet and a fictional title-order example for lender software evaluations.
In this article
A reverse mortgage LOS integration requirements worksheet should identify what crosses each system boundary, who controls it, and what proves it arrived correctly. For your loan origination system (LOS) evaluation, start with one row per direction of travel. A vendor name alone does not define a working connection.
This focused worksheet helps lender technology and operations buyers prepare a demonstration. Its fictional title-order example describes requested behavior, not verified ReversePilot capabilities or an available connection.
Define the connection before comparing vendors
Write the business outcome first: a processor can match a returned title report to the original request and loan. Then separate the outgoing request, incoming acknowledgment, and incoming report. Each exchange can have different fields, triggers, and owners.
The Federal Reserve-hosted interagency guide for community banks discusses prospective roles, technology compatibility, access, and integration costs during planning. It is background for these questions, not a mortgage-specific technical standard or a mandate to use this worksheet.
- Source of truth: the system your team treats as authoritative for a particular field or status.
- Direction: source to destination; a return message gets its own entry.
- Trigger: the action or event that starts that exchange.
- Evidence: the receiving record or response that demonstrates the expected outcome.
Keep this purchase-stage question separate from daily vendor-order reconciliation. That workflow tracks actual requests; this worksheet defines what you need a proposed connection to do before selecting it.
Reverse mortgage LOS integration requirements worksheet
Copy these fields into your evaluation register. Complete a separate record for each exchange, even when a vendor describes the overall connection as two-way. Use synthetic file references and blank sample documents in demonstrations.
| Field | Entry to complete | Evidence to request |
|---|---|---|
| Purpose and boundary | [Outcome]; [source → destination]; [trigger] | Walkthrough of the exchange |
| Data and authority | [Fields]; [authoritative system]; [allowed changes] | Field mapping and correction example |
| Matching | [Loan reference]; [request reference]; [vendor reference] | Returned record linked to the right request |
| Exceptions | [Timeout]; [repeat request]; [unmatched response] | Observed outcome for each test |
| Owners and dependencies | [Lender owner]; [vendor owner]; [access/configuration needs] | Named contacts and written scope |
| Decision record | [Observed/described/unresolved]; [gap]; [next action/date] | Dated evidence in the intended configuration |
Keep a description separate from a demonstration. Record whether evidence comes from a mock connection, a test environment, or the proposed configuration. Ask which subscriptions, vendor agreements, credentials, setup work, and charges remain outside the quoted scope.
Worked example: a title-order connection
Assume a fictional lender wants to send request REQ-A for synthetic file DEMO-A to a title provider. The proposed return path would bring back acknowledgment REF-A and a blank sample report. These labels contain no customer information.
- Outgoing request: LOS → provider, triggered by an authorized processor. The lender proposes the LOS as the source for the file reference and submitted property details.
- Acknowledgment: provider → LOS, carrying the original request reference and vendor reference. The lender wants acceptance shown separately from report delivery.
- Report return: provider → LOS, linked to the same request. The processor reviews the delivered version before recording an internal decision.
In the fictional demonstration, sending succeeds and an acknowledgment appears. The presenter cannot show a returned report linked to REQ-A. Record the connection as partly observed, with report matching unresolved; do not turn a successful send into acceptance of the complete workflow.
- Evidence owner: vendor integration contact demonstrates the return path.
- Lender owner: operations sponsor checks the receiving processor's view.
- Next action: repeat the test before the integration selection decision.
- Decision impact: keep report matching open if it is essential to the proposed workflow.
Test the uncertain path before accepting the connection
Ask the presenter to simulate an uncertain response in a controlled test environment. If the sender times out, can the evaluator establish whether the provider already received REQ-A? A timeout should become a question to resolve, not an assumption about the remote system.
Agree on the intended result before testing. Your register should capture how the connection handles a repeated request, an unmatched report, and corrected source data. Do not assume automated retries, duplicate prevention, or automatic updates exist.
- Repeat the synthetic request and inspect whether a second order appears or the original reference returns.
- Return a sample report with an unknown reference and observe where someone can find the exception.
- Correct a synthetic field and check which system changes, who approves the change, and what history remains.
Carry these cases into your software testing record. Use the total-cost worksheet to separate connection setup and ongoing charges from functional evidence.
Use the LOS buyer guide and demo scorecard to decide which integration outcomes are essential before comparing vendors.
Key takeaways
- Define each direction, trigger, authoritative field, and receiving record.
- Keep sending, acknowledgment, delivery, and internal review distinct.
- Give unresolved evidence a named owner and a decision consequence.
Bring one completed row and one exception test to a ReversePilot demo request, and ask what can be demonstrated in your proposed configuration.