How to automate mortgage loan manufacturing from application to post-closing

Start by making the loan file reliable. Give every document and loan event a stable ID, run the lender's approved checklist against those records, and put ambiguous items in a named review queue. Once that works, use the same evidence to prepare underwriting packets, track conditions, and reconcile the signed file after closing.

For an originate-to-sell lender, the workflow starts with a submitted application and ends with a reviewed, indexed post-closing file ready for its next handoff, or a hold that identifies the unresolved item and its owner. The underwriter makes credit decisions. Authorized staff retain disclosure, funding, and quality-control approvals according to lender policy.

Map the work before connecting the systems

What to automate

Set up intake, disclosures, and document collection

Give the intake lead one queue for portal submissions, approved inbox attachments, and loan origination system (LOS) events. On receipt, match each application to a durable LOS identifier and copy only fields on the approved mapping. Send a file with two plausible matches to intake for assignment. When an assigned file reaches the lender-defined disclosure milestone, prepare the versioned input packet for the disclosure desk. Write back the authorized delivery receipt and record which items are still missing, who will request them, and when to follow up. Use the source submission ID to avoid assigning the same work twice.

Classify documents and compare them with the loan file

As an attachment arrives, save its checksum, source ID, page count, and version. Extract text, propose a type from the processor’s allowed taxonomy, and keep the page reference with every proposed field. Compare accepted fields with the authorized LOS values using explicit rules for dates, names, and amounts. Put conflicting values, illegible scans, and unsupported types in the processor’s review queue. Only index the accepted version against the checklist and keep earlier versions for replay.

Track credit, income, assets, and third-party evidence

For each authorized credit, verification, appraisal, title, or settlement request, record the loan ID, provider request ID, expected evidence, and owner. Match each provider response to its original request, validate the required fields, and track ordered, received, failed, and stale statuses. Route identity, date, or amount discrepancies to the processor with both source references. Confirm the provider’s current status before reissuing a failed order. The processor’s evidence view should show what was received and exactly what is still open.

Prepare underwriting submissions and index findings

When the loan team requests submission, assemble the current approved evidence and the exact values the authorized underwriting system expects. Save the submitted payload, policy version, submission ID, and the findings returned for that version. Create a review packet that cites each finding and lists unresolved conditions. If data changed after submission, flag the difference and prepare a review task for the authorized team. A reviewer records the decision and any approved resubmission through the lender’s normal workflow.

Manage conditions, changes, and closing readiness

Give each condition an owner, due date, and link to its evidence. Compare new evidence and settlement inputs with the version the closing team previously accepted. Send material changes to the lender’s designated reviewer under the current policy. Before marking the file ready, reconcile the approved closing figures and check signatures and required pages against the release checklist. The closer receives either a reconciled packet to approve or a hold with the failed check and named owner.

Hand off funding and review the returned file

Generate the funding packet from the approved closing version and send it to the funding desk through the existing authorization path. Match the returned funding confirmation to the packet ID, loan ID, amount, and approved instruction. If the payment status is uncertain, reconcile with the funding desk before any retry. For post-closing, compare returned documents with the packet checklist and route missing or corrected items to the assigned specialist. Preserve the original packet and the corrected versions under the same loan ID.

Track investor delivery, cures, and independent quality control

Build the delivery package from the accepted post-closing version and save the receipt against the package ID. Convert rejected or incomplete delivery items into owned cure tasks with due dates and retained evidence. When a corrected item goes out, link the new package and receipt to the original exception. Apply the lender’s approved retention schedule and prepare the designated quality-control sample for independent review. Reconcile every delivery attempt to an acceptance, a rejection, or an open status with an owner.

Build document intake as the first working slice

1. Read from a supported source. Pull authorized attachments from the LOS, approved mailbox, or portal. Record the connector, source event ID, loan identifier, document hash, received time, and access class before processing the file. ICE's Encompass Developer Connect documentation describes its eFolder document and attachment APIs and the V3 attachment workflow. Confirm the API and permissions enabled for the specific tenant. Encompass V3 attachment APIs
2. Extract candidate evidence. Use native PDF text when available and OCR when the input is scanned. A classifier can suggest a document type and fields such as pay period or borrower name. Retain the page reference, extraction confidence, and original object. A candidate field becomes a verified field only after it passes the approved checks or an authorized reviewer accepts it.
3. Apply the lender's rules in code. Verify loan and borrower associations, expected evidence types, and approved date or completeness checks. Use a versioned policy configuration keyed to the relevant product and workflow. Leave ambiguous files on hold. Reapply the rules when a newer document or approved policy changes the result.
4. Write the result once. Deduplicate retries by source event ID. For identical files delivered in different events, apply an approved deduplication rule using the loan ID and document hash, while retaining each receipt. Before retrying a write after a timeout, reconcile the destination against its write receipt. Replaying a batch should neither duplicate an attachment nor clear an outstanding condition without evidence.

Test on a synthetic loan file

Use a synthetic file named L-100 and a checklist that expects two pay statements. One statement matches the loan and has a readable pay period. The second scan has an ambiguous borrower match. Run the batch twice.

Fannie Mae documents the submission and findings workflows for Desktop Underwriter, and Freddie Mac publishes the Loan Product Advisor feedback and documentation workflow. Treat the returned findings as versioned source records tied to the exact submission. Desktop Underwriter submission · Loan Product Advisor

Measure the work the automation changes

Run the first slice alongside the current process. Count all eligible incoming files, including those with unavailable source data, ambiguous matches, late documents, and manual fallback. Compare active minutes by role, packets accepted by the next team, missed or duplicate writes, and review time per exception. Keep elapsed time separate from staff effort. Expand into conditions, closing, or post-closing once the operations owner accepts the output and its exception path.

Implement the loan-event and evidence ledger

Keep the LOS as the system of record. Put an append-only event store in front of each integration so you can replay a portal submission, disclosure receipt, or funding confirmation without creating a second loan, sending a second package, or moving a milestone backward.

1. Ingest before mutating. Verify the webhook signature or pull from a scoped connector, persist raw bytes, then acknowledge. Partition work by LOS loan ID. Record both the business-effective timestamp and the observed timestamp so a backdated correction can be distinguished from a late feed.
2. Recompute by dependency. When a corrected pay statement arrives, re-run identity, coverage and approved freshness checks on that evidence. Reopen any pending condition that referenced the superseded record. A reviewer can accept the new evidence, but a new scan alone never clears a condition.
3. Separate queue states from milestones. Use received → classified → verified for evidence, open → submitted → accepted/reopened for a condition, and independently track signed, funded and settled milestones. A late event may update evidence without changing a later authoritative milestone.
4. Gate external effects. Prepare disclosure or closing artifacts from a frozen field snapshot. Have the authorized system or role release them. For covered US transactions, configure product scope, business-day definitions, receipt evidence and the circumstances that restart a waiting period from lender-approved policy. In funding, separately reconcile the bank trace and actual ledger posting. CFPB Regulation Z § 1026.19 · Fannie Mae quality-control guide
5. Operate a shadow queue first. Import a deliberately varied batch including a duplicate intake, withdrawn loan, split borrower evidence, corrected documents, signed-but-unfunded loan and unresolved post-close item. Compare the owner, reason, evidence links and milestone for every file against the current process. The system can be released by capability, starting with indexing and internal alerts before any approved writebacks.

Run a local idempotency and correction fixture

Run this with Python 3 and SQLite. It exercises the evidence checkpoint for one loan. A real integration also needs scoped access, immutable raw storage, a policy evaluator and review UI.

import sqlite3

db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE receipts (
    event_id TEXT PRIMARY KEY,
    digest TEXT NOT NULL
);
CREATE TABLE evidence (
    loan_id TEXT, document_id TEXT, revision INTEGER, status TEXT,
    PRIMARY KEY (loan_id, document_id, revision)
);
""")

def receive(event_id, digest, document_id, revision, status):
    with db:
        prior = db.execute(
            "SELECT digest FROM receipts WHERE event_id = ?", (event_id,)
        ).fetchone()
        if prior:
            if prior[0] != digest:
                raise ValueError("Conflicting source event")
            return
        db.execute("INSERT INTO receipts VALUES (?, ?)", (event_id, digest))
        db.execute("INSERT INTO evidence VALUES (?, ?, ?, ?)",
                   ("L-100", document_id, revision, status))

def readiness():
    rows = db.execute("""
        SELECT e.status FROM evidence e
        JOIN (
            SELECT loan_id, document_id, MAX(revision) AS revision
            FROM evidence GROUP BY loan_id, document_id
        ) latest USING (loan_id, document_id, revision)
        WHERE e.loan_id = 'L-100'
    """).fetchall()
    return "ready for review" if sorted(rows) == [("verified",)] * 2 else "hold"

receive("e1", "sha-a", "pay-a", 1, "verified")
receive("e2", "sha-b", "pay-b", 1, "ambiguous")
receive("e2", "sha-b", "pay-b", 1, "ambiguous")
assert readiness() == "hold"
assert db.execute("SELECT COUNT(*) FROM receipts").fetchone() == (2,)
receive("e3", "sha-c", "pay-b", 2, "verified")
assert readiness() == "ready for review"
assert db.execute("SELECT COUNT(*) FROM evidence").fetchone() == (3,)

Before rollout, add a test where the approved revision arrives out of order and one where a document is replaced after a packet has been prepared. The release snapshot must still identify precisely what was reviewed and why the replacement triggered a hold.

Implement the work step by step

Jump to a stage

• Application intake and loan setup
• Initial disclosures and receipt tracking
• Borrower document collection
• Document classification and data entry
• Credit and liability reconciliation
• Income, employment and asset preparation
• Third-party service ordering and tracking
• Appraisal and collateral review preparation
• Title, insurance and settlement readiness
• Automated underwriting submission and findings preparation
• Underwriting review and decision
• Condition collection, follow-up and resubmission
• Changed circumstances, redisclosures and lock administration
• Final readiness checks and refreshed evidence
• Closing Disclosure, fee balancing and document preparation
• Signing coordination and completion checks
• Funding and warehouse request preparation
• Post-closing document completeness and corrections
• Investor/custodian delivery
• Investor suspense and purchase reconciliation
• Servicing handoff and file archive
• Cross-process status reporting and escalation

Start at application receipt and advance on confirmed handoffs. Each worker consumes a versioned loan or document event, checks the approved policy, and records its output and evidence before the next worker starts. A changed input creates a new version. Queue unresolved work with an owner, due time and evidence. Poll open provider and delivery requests as a backstop, including after an ambiguous timeout.

The LM-11.3 exception-analysis parent covers LM-11.3.1 through LM-11.3.12. The LM-11.4 disposition parent covers LM-11.4.1 through LM-11.4.10. Use the child tasks as the checklist for each parent.

Confirm permitted events and tenant access with ICE's Encompass webhook reference. For disclosures, use the CFPB's integrated disclosure resources and the lender's approved requirements. Fannie Mae documents prefunding quality control and post-closing quality control for its seller program.

LM-01 · Application intake and loan setup

Resolve ambiguous loan matches before creating another LOS record.

• LM-1.1 Receive the application. Subscribe to submitted-application events or poll the approved inbox. Save the original payload/attachments. Deduplicate on source submission ID. Create an intake event with the original receipt time. Read Borrower application portal. The LOS. Secure document inbox for submitted application and attachments, source/channel, submission time and application identifier. Record Recorded submission linked to its original information. Owner Intake / loan assistant. Check Replaying the same submission produces one intake record and retains all source attachments.
• LM-1.2 Match borrower and transaction. Search exact transaction/application IDs first. Compare normalized borrower identifiers, property and transaction purpose. Score candidate matches using approved rules. Update a confirmed match or create a separate pending/new transaction. Read The LOS search. Application portal. CRM if used for stable application/borrower identifiers, property, prior transaction records and active-file status. Record Confirmed existing-file match or a new-transaction instruction. Owner Intake / loan assistant. Check Known duplicates map to one transaction. Similar names with different identity evidence never auto-merge.
• LM-1.3 Map application fields. Load the source-to-LOS field map. Parse types, units, dates and borrower associations. Resolve source priority explicitly. Emit a validated loan payload with provenance per field. Read The LOS application screens. Source application. Approved field mapping for borrower, property, employment and requested-loan fields. Field definitions. Source-priority rules. Record Structured field values with links to their source. Owner Intake / loan assistant. Check Required fields preserve their source values and unsupported/missing mappings remain explicit.
• LM-1.4 Create or update the loan. Build the supported create/import/update request. Select the approved template/folder. Compare destination values before overwriting. Submit once. Read the loan back and compare intended values. Read The LOS and its supported import/update access for confirmed transaction match, approved template/folder, mapped values and field-update permissions. Record Loan ID and verified record creation/update. Owner Intake / loan assistant. Check A retry cannot create a second loan. Conflicting template values are detected. Written fields match the accepted payload.
• LM-1.5 Check completeness and application triggers. Evaluate a versioned completeness schema and transaction-specific application-trigger rules. Compute deadlines using the correct calendar. Emit disclosure/tasks events without waiting for unrelated verification documents. Read The LOS. Approved application and disclosure-trigger rules for submitted fields and timestamps, transaction type, submission status and applicable requirements. Record Missing-field list plus required task/deadline events. Owner Intake / loan assistant. Check Test applications trigger exactly the required tasks at the correct receipt time, including incomplete supporting-document packages.
• LM-1.6 Assign owners and initialize tasks. Load permitted users, existing ownership and branch/channel routing rules. Allocate the file by specialization and capacity. Create the prescribed task graph. Verify assignments and permissions. Read The LOS assignment/task screens. Approved team roster and routing rules for branch, channel, existing ownership, permissions, availability and workflow selection rules. Record Assigned file with initial task owners. Owner Intake / loan assistant. Check Every created task has a valid authorized owner and duplicate events do not create duplicate tasks.
• LM-1.7 Request missing application answers. Generate a question only for the missing field. Check connected sources first. Send via an approved channel. Parse the borrower response. Ask a targeted follow-up if ambiguous. Write the supported answer and stop reminders. Read Borrower portal. Approved email/SMS. The LOS for missing-field list, prior requests, contact permissions and borrower responses. Record Recorded answers or an assigned unresolved question. Owner Intake / loan assistant. Check A self-employed answer selects the correct branch. A completed answer stops chasing. Nonresponse follows a configured reminder/hold path with the unresolved requirement still assigned.
• LM-1.8 Verify setup and hand off. Run setup assertions against the saved loan, assignments and initial task graph. Reconcile API acknowledgments. Emit a ready event only when required outputs exist. Record unresolved setup defects separately. Read The LOS. Task queue. Internal notifications for saved record, setup checklist, assignment acknowledgments and outstanding issues. Record Ready file or a precise setup exception with an owner. Owner Intake / loan assistant. Check Missing writes or tasks cannot mark setup complete. Recovered failures resume once without duplicate work.

LM-02 · Initial disclosures and receipt tracking

Retain the exact delivered version and receipt. The policy owner supplies deadlines, consent and revision rules.

• LM-2.1 Determine the required initial package. Evaluate product, jurisdiction, channel and transaction flags against a versioned disclosure-package matrix. Select forms/recipients and calculate the applicable due date. Read The LOS disclosure engine. Approved compliance rules for application receipt event, product/channel, property/state, borrower and transaction characteristics. Record Required package type and due date. Owner Disclosure specialist. Check Representative product/state cases select expected forms and deadlines. Unknown combinations are not guessed.
• LM-2.2 Collect and reconcile initial terms and fees. Join approved pricing terms, fee tables and settlement estimates by loan and effective date. Compare amounts/source precedence. Request missing figures electronically. Track unresolved discrepancies by fee line. Read The LOS. Product/pricing source. Approved fee tables. Settlement estimate channel for requested amount, selected terms, approved fee estimates, service-provider information and current versions. Record Reconciled disclosure inputs and unresolved fee exceptions. Owner Disclosure specialist. Check The package uses one traceable version of each term/fee. Inconsistent or missing amounts remain visible.
• LM-2.3 Generate the package. Send the validated snapshot to the approved document/disclosure generator. Store returned files, template/version IDs and input hashes. Compare populated key fields with the input snapshot. Read Approved disclosure/document-generation system connected to the LOS for validated inputs, approved templates, version and required recipients. Record Versioned draft disclosure package. Owner Disclosure specialist. Check Generated names, amounts, fees and dates agree with the authorized source snapshot.
• LM-2.4 Validate release conditions. Execute content, field-consistency, deadline and recipient checks. Combine results into a release gate. Re-run only affected tests after corrections. Retain rule versions and evidence. Read Disclosure/compliance checks. The LOS. Exception queue for generated package, source terms, applicable rules, required permissions and checks. Record Passed release checks or a blocked package with specific findings. Owner Disclosure specialist. Check Injected missing fields and changed fees block only the affected release until corrected. An authorized clean package passes.
• LM-2.5 Deliver through the approved channel. Check the recorded delivery prerequisites. Choose the approved e-delivery or print/mail route. Submit the exact authorized package with an idempotency key. Store provider receipt and recipient routing. Read Approved disclosure/e-sign or mail service. The LOS for release authorization, recipient details, delivery preferences/consents and package version. Record Delivery transaction and timestamp. Owner Disclosure specialist. Check Wrong recipients, superseded packages and duplicate sends are prevented. Delivery acceptance is evidenced.
• LM-2.6 Track receipt and follow up. Consume delivery, receipt and consent events. Apply the applicable receipt/timing rules. Schedule reminders or alternate delivery. Update status and stop completed follow-ups. Read Disclosure provider status. The LOS tasks. Permitted communication channels for delivery events, receipt evidence, applicable timing rules and prior reminders. Record Receipt status, evidence and any unresolved delivery task. Owner Disclosure specialist. Check A send event is not incorrectly treated as every required receipt event. Completed items stop reminders.

LM-03 · Borrower document collection

An item stays missing until accepted evidence matches the exact request.

• LM-3.1 Build the initial document checklist. Select evidence requirements by borrower/income/product/transaction. Subtract usable evidence already on file. Emit requirements with exact document periods, owners and reason codes. Read The LOS checklist. Approved product/investor requirements for application, borrower/income types, property/transaction characteristics and currently available documents. Record Borrower-specific initial document requirements. Owner Processor. Check A borrower is not asked for documents already satisfied by current accepted evidence. Different income types get different checklists.
• LM-3.2 Send clear document requests. Render each open requirement into a specific request. Group related items per recipient. Send through the secure approved channel. Attach requirement IDs and upload instructions. Read Borrower portal. Approved messaging. The LOS task list for checklist, recipients, language/access needs and communication permissions. Record Delivered request linked to each requirement. Owner Processor. Check Each requested item links back to a real open requirement. Messages reveal no unrelated borrower information.
• LM-3.3 Receive and associate uploads. Receive portal/provider events. Match submission/loan/borrower identifiers. Store source files. Enqueue classification. Link provisional receipt to the outstanding requirement. Read Portal/inbox. The LOS eFolder. Step 4 document service for submission identifiers, borrower/file association and open checklist. Record Received documents routed to classification with provisional requirement links. Owner Document specialist. Check The correct file receives the upload once. Receipt does not automatically imply substantive acceptance.
• LM-3.4 Refresh what is still missing. Join requirement definitions with processed-document type, dates, acceptance and version. Mark supported requirements satisfied. Create precise gaps for inadequate or stale evidence. Read The LOS checklist. Document classification results for accepted/rejected document statuses, required periods, versions and checklist definitions. Record Current missing-document list. Owner Processor. Check Wrong periods, wrong borrowers and rejected versions do not satisfy the checklist. Accepted replacements stop duplicate requests.
• LM-3.5 Follow up and stop resolved reminders. Schedule reminders from requirement state and last contact. Suppress resolved/revoked channels. Vary cadence under approved rules. Apply automatic pause/hold states for nonresponse. Read Task scheduler. Portal/email/SMS. The LOS for outstanding requirements, last contact, response status, cadence and escalation rules. Record Timed follow-ups and a stopped reminder for each resolved item. Owner Intake / loan assistant. Check Response events cancel queued reminders. Repeated scheduler runs cannot spam the borrower or lose the open requirement.
• LM-3.6 Resolve collection exceptions and hand off. Classify the collection problem. Retrieve permitted alternatives. Ask the borrower/provider for the precise missing fact. Compare the response with the selected requirement. Update the package or retain an explicit hold. Read The LOS. Borrower communication. Exception/underwriting queue for missing or rejected evidence, borrower explanation and acceptable alternative-document rules. Record Collected package or documented exception with an owner. Owner Processor. Check Route unresolved evidence to its owner and preserve the failed requirement.

LM-04 · Document classification and data entry

Index only readable, classified evidence linked to the original. Review uncertain OCR and identity matches.

• LM-4.1 Ingest and version each document. Hash the incoming bytes, detect duplicates, store an immutable source copy and link replacement versions without deleting history. Create one processing record per source/version. Read Document inbox/portal. The LOS eFolder. Controlled document storage for file bytes, submission metadata, existing versions and loan/borrower identifier. Record Stored source document with a version and processing status. Owner Document specialist. Check A replacement preserves its predecessor and replays do not duplicate extraction work.
• LM-4.2 Classify and index the document. Classify pages against the document taxonomy. Separate combined packets. Identify borrower/date range. Attach type, confidence and source page spans to the index. Read Document viewer. The LOS eFolder. Approved document taxonomy for document content, supported types, borrower identifiers and indexing rules. Record Indexed document and classification confidence. Owner Document specialist. Check Mixed packets are split correctly. Borrower identity and document date checks catch misleading filenames.
• LM-4.3 Extract the required fields. OCR or parse the source, then extract only declared fields into typed JSON. Retain page/region citations and raw values. Normalize units and dates in Python. Read Document extraction/OCR. Source viewer. The LOS for readable content, field schema, expected formats and source-page locations. Record Extracted values with source references. Owner Document specialist. Check Numeric values, dates and identifiers reconcile to the source. No source-less values pass the schema.
• LM-4.4 Validate extraction and cross-check critical fields. Apply field-level type/range checks and cross-document comparisons. Reconcile critical identities/amounts using source-priority rules. Reparse uncertain regions or request a better source. Read Validation rules. Document viewer. The LOS comparison screen for extracted values, source evidence, current loan fields, tolerances and source-priority rules. Record Accepted field set or explicit conflicts. Owner Document specialist. Check Injected OCR errors and conflicting amounts are detected. Accepted values retain a traceable resolution.
• LM-4.5 Write accepted values and update document status. Calculate the minimal permitted field/document update. Use record-version checks. Write accepted values to the LOS and the document index. Read back. Emit downstream events only after confirmed success. Read The LOS update access. Document index. Task/status integration for accepted values, permitted destinations, current record version and processing identifier. Record Confirmed field updates and requirement/status events. Owner Document specialist. Check Partial write failures cannot mark the document processed. The destination and evidence index agree.

LM-05 · Credit and liability reconciliation

Use entitled credit provider access and retain report version and hold reason.

• LM-5.1 Confirm authorization and request credit. Evaluate purpose/authorization prerequisites and report freshness. Reuse a valid permitted report when appropriate. Build and submit the correct provider request. Record request/consent evidence. Read The LOS credit integration. Credit-report provider for borrower identifiers, permitted purpose/authorization records, report type and prior reports. Record Ordered or retrieved report tied to the correct borrower. Owner Processor. Check Unauthorized/duplicate report pulls are prevented. Each request has the correct borrower and purpose.
• LM-5.2 Import and organize report information. Parse the credit response into borrower-specific tradelines, alerts and report dates. Preserve account IDs and original report evidence. Import the supported fields. Read Credit provider report. The LOS. Report viewer for report, borrower associations, tradeline identifiers and current application liabilities. Record Structured liabilities and alert list. Owner Processor. Check Account totals and borrower attribution reconcile to the original report. Unresolved parsing errors are explicit.
• LM-5.3 Match liabilities and identify differences. Match declared debts and reported tradelines using account identity, amounts and ownership. Detect duplicates and missing obligations. Produce a difference ledger before applying changes. Read The LOS liability screens. Comparison worksheet for account identifiers, balances, payment amounts, liability ownership and application declarations. Record Reconciled matches plus unresolved differences. Owner Processor. Check Joint/duplicate accounts are not counted twice. Disputed ownership is not silently assigned.
• LM-5.4 Determine nonstandard debt treatment. Retrieve the applicable treatment rules by debt/product/context. Assemble supporting documents. Apply deterministic treatments where defined. Use an agent to investigate and propose an evidence-backed treatment for remaining supported cases. Read Approved underwriting policies. Credit supplements. The LOS for debt details, supporting evidence, borrower explanation and applicable rules. Record Supported liability treatment or a request for more evidence. Owner Processor, Qualified underwriter. Check The final treatment names the rule and evidence. Unresolved eligibility/authority remains a specific gap, not a generic judgment handoff.
• LM-5.5 Calculate and publish reconciled liabilities. Write accepted liabilities, calculate monthly totals and relevant ratios from authoritative inputs, validate against the agreed formulas, and publish a versioned result to underwriting. Read The LOS calculations. Underwriting queue for accepted debt treatment, monthly payments, qualifying-income inputs and current loan version. Record Updated liabilities/ratios and assigned exceptions. Owner Processor. Check Ratios reproduce independently. Unresolved material debt inputs cannot masquerade as zero.

LM-06 · Income, employment and asset preparation

Recalculate approved income and asset rules from the same evidence version. Review material conflicts and unsupported interpretations.

• LM-6.1 Identify income sources and evidence requirements. Classify each borrower’s income streams and ownership/employment relationships. Select the applicable policy branches and calculation templates. Produce a source/evidence map. Read The LOS. Approved income guidelines and worksheets for application, borrower/employment relationships, income types, ownership and product requirements. Record Income-source map and evidence requirements. Owner Income and asset analyst. Check Multiple income sources and business ownership select the intended methods without treating every borrower as salaried.
• LM-6.2 Assemble and reconcile the evidence. Join indexed paystubs, tax returns, W-2s and verification reports by borrower/employer/period. Detect overlaps and gaps. Reconcile totals across evidence versions. Read The LOS eFolder. Verification provider. Income worksheet for indexed documents, tax/verification reports, pay periods and employer identifiers. Record Complete evidence set with discrepancies identified. Owner Income and asset analyst. Check All included income components link to current source evidence and duplicate periods are not counted twice.
• LM-6.3 Prepare qualifying-income calculations. Execute approved income formulas in Python using typed source components. Apply allowed adjustments and history periods. Store intermediate calculations and policy versions. Read Approved income calculator. The LOS. Source documents for current/historical income components, allowed adjustments, applicable method and document references. Record Income calculation with assumptions and evidence. Owner Income and asset analyst. Check A second calculation reconciles the result. Unsupported adjustments cannot enter qualifying income without evidence and an applicable rule.
• LM-6.4 Check employment evidence and validity. Import employment verification results. Match borrower/employer and dates. Evaluate validity for this stage. Request permitted refreshes and compare new facts with prior information. Read Employment verification provider. The LOS. Approved evidence rules for employer/borrower match, report date, current status and applicable validity requirements. Record Employment evidence status and any discrepancy. Owner Processor. Check Wrong-person and stale reports fail. Late-stage verification requirements remain separately scheduled in step 14.
• LM-6.5 Prepare asset and funds analysis. Parse account ownership, balances and transactions. Reconcile transfers without double counting. Calculate eligible available funds and reserves under applicable rules. Flag deposits needing support. Read Asset verification tool. Statement viewer. The LOS for balances, statement dates, transaction history, ownership, cash-to-close/reserve inputs and rules. Record Asset/funds worksheet and flagged transactions. Owner Income and asset analyst. Check Transfer chains preserve total available funds. Unexplained amounts do not automatically become eligible assets.
• LM-6.6 Assess complex cases and publish the worksheet. Build a case graph of unusual income/assets, competing interpretations and supporting policies. Run candidate calculations. Obtain missing facts. Produce a selected interpretation and a machine-checkable worksheet. Read Approved policies. Evidence viewer. The LOS underwriting queue for prepared calculations, exceptions, borrower explanations and program/investor requirements. Record Traceable income/asset package with unresolved items and reviewer disposition. Owner Income and asset analyst, Qualified underwriter. Check A complete evidence-backed package is produced rather than an ungrounded recommendation. Any program-required human underwriting occurs explicitly in step 11, not as a blanket analyst task here.

LM-07 · Third-party service ordering and tracking

Keep provider order IDs and check status before retrying a billable request.

• LM-7.1 Determine required services and prerequisites. Evaluate service requirements and permitted alternatives against current loan facts. Check existing orders and prerequisites. Create only the missing authorized requests. Read The LOS. Service-order rules. Existing order history for product/property, applicable alternatives, prior orders, permissions and payment/consent prerequisites. Record Authorized service-order list. Owner Processor. Check No unnecessary duplicate appraisal/title/flood order or unauthorized spend is generated.
• LM-7.2 Prepare and submit each order. Map verified borrower/property facts into the selected provider’s request schema. Apply routing/billing rules. Submit using supported access and store the provider order ID. Read Approved vendor integrations or portals. The LOS for borrower/property identifiers, service specifications, approved provider and billing instructions. Record Order IDs and accepted submissions. Owner Processor. Check Each order is accepted for the correct property and retrying cannot duplicate a paid order.
• LM-7.3 Track status and deadlines. Poll or consume provider status events. Normalize status/due-date codes. Compare against expected delivery and task dependencies. Publish current order state. Read Vendor status interfaces. The LOS tasks for order IDs, provider status, expected delivery and SLA/escalation rules. Record Current order status and due-date tracking. Owner Processor. Check Status freshness is visible and missing provider data is not interpreted as completion.
• LM-7.4 Follow up on delays or order issues. Detect overdue/missing/incorrect responses. Send targeted provider queries. Parse replies. Request corrected evidence. Reschedule or hold according to approved rules. Read Vendor portal. Approved email/phone workflow. Exception queue for status history, due dates, provider messages and responsible owner. Record Follow-up, corrected order or escalated issue. Owner Processor. Check The system can chase without an the lender employee. It cannot fabricate an inspection/report that the external provider has not performed.
• LM-7.5 Receive and route the result. Fetch the completed report, verify order/property identity, archive the original and attach it to the loan. Create the next review task only after the transfer is confirmed. Read Provider delivery integration. The LOS eFolder. Task queue for completed report, order ID, borrower/property association and destination task. Record Linked report and ready review task. Owner Processor. Check Correct report, property and loan match. Failed transfers cannot mark the downstream review ready.

LM-08 · Appraisal and collateral review preparation

Tie collateral clearance to the property identity, report revision and material exceptions.

• LM-8.1 Confirm the applicable collateral path. Read current product/engine/investor findings. Evaluate appraisal/alternative eligibility using the appropriate rule version. Select evidence requirements and record the reason. Read The LOS. Applicable agency/investor findings. Approved collateral rules for property/product, agency findings, alternative eligibility and lender overlays. Record Recorded collateral path and evidence requirements. Owner Income and asset analyst. Check A waiver/alternative is never generalized across programs or applied outside its conditions.
• LM-8.2 Check report completeness and identity. Parse the report and exhibits. Verify address, legal identifiers, report version, required sections and signatures. Request missing or inconsistent material automatically. Read Appraisal viewer. The LOS. Completeness checklist for report, property identifiers, required sections and prior versions. Record Complete report or a missing/incorrect-item list. Owner Income and asset analyst. Check Wrong-property, missing-exhibit and superseded-report tests fail before substantive assessment.
• LM-8.3 Cross-check collateral facts and flags. Compare collateral facts with application/contract/title information and external collateral findings. Classify flags and retrieve their supporting evidence. Read Appraisal/collateral tools. The LOS. Supporting property documents for report fields, contract/loan details, collateral-tool outputs and lender checks. Record Evidence-backed discrepancy and flag list. Owner Income and asset analyst. Check Every discrepancy is traceable. No warning is discarded merely because another model produces a confident answer.
• LM-8.4 Assess valuation and property eligibility issues. Represent collateral requirements as testable rules. Extract the value/condition/supporting facts. Calculate relevant relationships. Have an agent evaluate narrative inconsistencies and assemble evidence supporting the assessment. Read Appraisal viewer. Collateral findings. Approved policies for comparable/property evidence, findings, repairs and applicable program/investor requirements. Record Supported collateral assessment or additional requirements. Owner Income and asset analyst, Qualified underwriter. Check Software can perform the internal report assessment. Any required licensed appraisal opinion or physical inspection is explicitly a provider deliverable, not invented by the workflow.
• LM-8.5 Coordinate corrections and record disposition. Open a correction case keyed by property, provider order, report version and unmet rule. Draft the request with the source page and required evidence. Send through the approved channel. Poll for acknowledgment and a revised report. Verify identity, version and evidence before updating the condition and checking the LOS write. Read Appraisal management company or appraiser communication. The LOS conditions for findings, correction requests, replies and approved disposition. Record Final collateral status with linked evidence. Owner Processor, Income and asset analyst. Check An incomplete, stale or wrong-property reply leaves the condition open. Replaying the response creates one reviewed version.

LM-09 · Title, insurance and settlement readiness

Reconcile title, coverage and settlement information before handoff.

• LM-9.1 Match title and vesting information. Extract title names, vesting and property/legal identifiers. Match them against borrower/transaction facts. Analyze trust/entity authority documents when applicable. Read Title portal/report viewer. The LOS for title commitment, vesting, legal/property identifiers, borrower names and transaction structure. Record Matched title record or specific discrepancies. Owner Processor. Check Similar names and different properties do not auto-match. Unsupported authority is reported explicitly.
• LM-9.2 Identify liens and title requirements. Parse title exceptions, liens and requirements into typed obligations. Match payoff/clearance evidence. Create ordered cure tasks with owners and due dates. Read Title commitment. Settlement communication. The LOS checklist for recorded liens, exceptions, payoff requirements and approved clearance rules. Record Title-condition checklist and owners. Owner Processor. Check Every clearance requirement has evidence or an open task. Software does not pretend it has discharged a lien.
• LM-9.3 Check property-insurance evidence. Extract insured names/property, dates, coverage and mortgagee details. Evaluate the applicable coverage checklist. Request corrected evidence and repeat the affected checks. Read Insurance evidence. The LOS. Approved coverage rules for policy/binder, insured property, dates, coverage, lender details and product requirements. Record Insurance checklist status and requested corrections. Owner Processor. Check Wrong-property, expired-policy and required-coverage tests are caught. Issued evidence remains attributable to the insurer.
• LM-9.4 Check flood and other applicable evidence. Import flood/other property determinations. Match identity. Evaluate the product-specific evidence and notice rules. Create required tasks and validate responses. Read Flood determination provider. The LOS. Approved requirements for determination, property identity, applicable insurance/notice requirements and existing evidence. Record Required tasks and documented evidence status. Owner Processor. Check Each determination and required follow-up is tied to the correct property and rule version.
• LM-9.5 Resolve exceptions and confirm settlement readiness. Maintain an exception ledger. Request the exact title/insurance correction. Parse and validate responses. Apply supported dispositions. Emit closing-readiness only when the required evidence is present. Read Settlement/insurance communication. The LOS exception queue for outstanding conditions, supporting responses, approved dispositions and settlement contacts. Record Readiness status or an assigned blocker. Owner Processor, Closer / signing coordinator. Check A legal/title cure requiring an external act remains an external dependency. It does not require an employee to repeatedly chase and update status.

LM-10 · Automated underwriting submission and findings preparation

Treat underwriting findings as evidence tied to a submitted payload. Version material revisions.

• LM-10.1 Select the applicable underwriting engine/path. Evaluate product/channel/investor eligibility. Select the applicable AUS/program interface and lender configuration. Reject unsupported route assumptions. Read The LOS. DU/LPA or the applicable program/investor tools for product, investor/program eligibility, channel and lender rules. Record Selected submission path. Owner Underwriting assistant. Check Conventional, FHA, VA and other supported branches select the intended route rather than one universal engine.
• LM-10.2 Validate the submission data. Validate required schema fields and compare submitted qualifying values with the accepted evidence/calculations. Block only the actual invalid inputs. Read The LOS validation. Applicable submission schema for current loan data, verified-source inputs, required fields and submission rules. Record Validated submission payload or explicit errors. Owner Underwriting assistant. Check Missing or source-less qualifying values cannot be submitted as valid. All payload fields have traceable origins.
• LM-10.3 Submit and retain the response. Send the validated payload through the authorized existing AUS/program interface. Retain case ID, input version, response and timestamps. Reconcile uncertain submission results. Read Supported AUS/program integration. The LOS for validated payload, authorized credentials, case identity and submission version. Record Findings report and submission receipt. Owner Underwriting assistant. Check Retries do not create inconsistent cases. The stored response matches the submitted input version.
• LM-10.4 Translate findings into requirements. Parse current findings into typed requirements with evidence tests. Reconcile to existing conditions. Assign only genuinely new or changed work. Read Findings viewer. The LOS condition/task management for current findings, lender rules, existing evidence and previously open conditions. Record Versioned requirements checklist with owners. Owner Underwriting assistant. Check Repeated findings do not duplicate tasks. Ambiguous requirements are investigated rather than silently marked satisfied.
• LM-10.5 Resubmit on qualifying changes and reconcile versions. Detect material data changes. Apply resubmission/tolerance rules. Run the authorized interface. Compare recommendation and condition changes. Update downstream dependency state. Read The LOS change events. Applicable engine. Version history for material data changes, resubmission rules, prior/current case IDs and reports. Record Current findings and updated requirements. Owner Underwriting assistant. Check The final findings reflect the current loan. Outdated recommendations cannot remain active after a material change.

LM-11 · Underwriting review and decision

Use approved rules and evidence to prepare the case. Decision authority stays with the lender's authorized process. A qualified underwriter performs any required manual review and disposition.

• LM-11.1 Assemble the underwriting package. Build an evidence manifest from current income/assets/credit/collateral/findings. Verify identity, version and completeness. Generate a navigable underwriting case record. Read The LOS underwriting workspace. Indexed evidence and worksheets for current evidence versions, prior analysis, applicable findings and loan history. Record Traceable review package with known gaps. Owner Underwriting assistant. Check Every material conclusion links to source evidence and the package contains current versions only.
• LM-11.2 Run approved eligibility and consistency checks. Load a versioned rule pack for the actual product/investor/lender. Execute eligibility, calculations, document-validity and consistency checks. Produce a requirement-to-evidence matrix. Read Approved policy/rule checks. The LOS. Source evidence for verified inputs, product/investor rules, lender overlays and calculation support. Record Passed checks and an evidence-backed exception list. Owner Qualified underwriter. Check All applicable requirements have a passed, failed or unresolved result. The absence of an AUS warning is not treated as validation of every fact.
• LM-11.3.1 Identify the exception and applicable underwriting path. Python creates exception_case(loan_id, issue_id, input_version). Imports current product/findings and evaluates the configured routing requirements. A policy agent retrieves the relevant route rule and explains the classification. Persist whether the case belongs to a supported automated path or a qualified-human path. Validate against known Accept, Refer and downgrade examples. Do not let the agent invent the route. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Underwriting assistant. Check Known Accept, Refer and downgrade cases route under the corresponding approved rule.
• LM-11.3.2 Retrieve the actual governing rules and lender overlays. Maintain an approved versioned policy registry by program, investor, jurisdiction and effective date. Retrieval tools return complete relevant clauses and referenced definitions. An agent maps those clauses to the case and produces requirement IDs, citations and candidate tests. Python checks applicability, precedence and version. Missing or conflicting policy stays an explicit unresolved input until the authoritative owner/source supplies it. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Underwriting assistant. Check A superseded overlay or unrecognized policy version leaves the case blocked.
• LM-11.3.3 Assemble the current evidence and facts. Join the indexed loan/document/verification records using stable loan and borrower IDs. Select current versions and retain source page/field locations. An evidence agent retrieves only material facts and marks statements versus verified records. Code checks completeness, identity and age. Emit a case fact table whose values link to the source. Do not treat an absent fact as zero or favorable. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Underwriting assistant. Check Each cited fact points to the exact borrower, page and approved evidence revision.
• LM-11.3.4 Investigate conflicting facts. Build a typed difference ledger from source records. Apply explicit source-priority rules only where they cover the conflict. An investigation agent reopens source pages, queries authoritative systems and requests targeted clarification. Rerun the affected extraction/calculation after new evidence. Validate that every selected fact has an actual resolution. Model confidence alone cannot resolve conflicting evidence. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Underwriting assistant. Check Contradictory sources outside an approved precedence rule create an unresolved evidence conflict.
• LM-11.3.5 Obtain missing facts or supporting evidence. Code creates requirement-linked requests and a response state machine. A conversation agent asks, follows up, parses responses and asks the next targeted question through approved channels. Document tools index and validate returned material. The case resumes automatically when required evidence is present. Stop reminders on resolution and apply an agreed wait/hold path on nonresponse. No employee must perform the chasing. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Underwriting assistant. Check An unrelated response leaves the evidence request open and replay creates one request item.
• LM-11.3.6 Recalculate the affected financial measures. Run approved formulas in Python against the versioned accepted inputs. Store every material adjustment and intermediate result. An analysis agent identifies which supported scenario/method applies and explains differences. A separate calculation block reproduces the result. Test boundary values, duplicate income/debt treatment and changed source versions. Numeric conclusions cannot depend solely on agent prose. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Underwriting assistant. Check Recomputed measures reproduce the approved fixture using the recorded intermediate values.
• LM-11.3.7 Evaluate supported treatments and alternatives. Generate candidate treatments from the applicable documented branches. Code tests each candidate against eligibility, arithmetic and required evidence. A policy agent evaluates narrative evidence against the retrieved criteria and explains support/conflicts. Reject options needing unsupported assumptions or authority. Preserve the candidate matrix and the selected proposed treatment. Program-required final manual underwriting is not claimed complete by this calculation. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Income and asset analyst. Check A candidate missing mandatory evidence remains ineligible and explains the rule it failed.
• LM-11.3.8 Independently validate the proposed analysis. Run deterministic completeness, calculation, version and consistency checks. A separate verifier agent challenges the proposal against source evidence and searches for omitted contradictory facts. Compare its findings with the executable test matrix. Return issues to the owning investigation/calculation step. Store passed/failed/unresolved tests. A mandatory qualified human underwriting review remains separately identified rather than hidden in this automated quality check. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Income and asset analyst. Check Inject one outdated document and one calculation error. Both appear in the verifier output.
• LM-11.3.9 Produce the exception analysis and proposed treatment. Generate a structured proposal from accepted facts and test results. Render the explanation with citations, calculations, scenario comparisons and unresolved items. An agent writes the narrative only from the supported case record. Code verifies referenced evidence and reason/condition codes exist. Persist this as a proposal, not an authorized final decision where a required human has not performed underwriting. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Income and asset analyst. Check An unsupported narrative statement cannot enter the proposal without a source link or an explicit gap.
• LM-11.3.10 Present the qualified reviewer with the exact case. Build a review view/task containing the issue, rule citations, calculations and direct links to original evidence, with clear passed/failed/unresolved checks. Assign a qualified authorized reviewer only on the applicable required path, notify them and track the case state automatically. Do not require manual assembly, copying or repeated status inquiries. Verify that all supporting evidence is reachable and current. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Underwriting assistant. Check The reviewer opens the exact evidence and unresolved check for the assigned case version.
• LM-11.3.11 Perform required manual underwriting. Route the case to the qualified underwriter with the governing rule and source evidence. Record the underwriter's substantive assessment before resuming. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Qualified underwriter. Check The designated underwriter's assessment unlocks only the reviewed version.
• LM-11.3.12 Record findings and resume the automated process. Ingest authenticated reviewer actions/comments. An agent structures narrative findings into proposed facts, conditions and requests without changing their meaning. Code retains original comments, validates mappings, writes the accepted assessment and routes the result to decisioning or the exact evidence/calculation loop. Confirm LOS writeback and prevent duplicate tasks. The reviewer’s substantive action is already counted at 11.3.11. Read Underwriting workspace. Policies. Borrower/processor clarification for prepared checks, contradictory evidence, borrower explanations and exception authority. Record Supported exception assessment and additional conditions if necessary. Owner Underwriting assistant. Check An authenticated reviewer update applies to the correct version and resumes once.
• LM-11.4.1 Assemble the decision-ready case state. Code assembles a versioned decision_snapshot referencing accepted facts, current findings, check results and any required completed review. An agent highlights material changes since the prior snapshot. Validate that source versions agree and required upstream work is not merely pending or proposed. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Underwriting assistant. Check The snapshot references the accepted facts, current findings and required reviews at one cutoff.
• LM-11.4.2 Verify decision prerequisites and consistency. Execute requirement-level gates over the snapshot: missing facts, stale findings, conflicting values, unresolved mandatory issues and required reviewer completion. Produce a pass/fail/unresolved matrix and automatically return failed items to their owning workflow. A verification agent investigates supported discrepancies. It cannot convert an unresolved requirement into a pass. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Underwriting assistant. Check An expired finding or open mandatory check leaves the decision path blocked.
• LM-11.4.3 Select the permitted decision and authority path. Evaluate versioned program, investor and lender authority rules against the actual product/findings. Reuse the established route from 11.3.1 where valid. Detect changes. The policy agent supplies rule citations and code enforces actor/credential requirements. A missing rule is an explicit configuration input, not proof every loan needs a manual approval. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Underwriting assistant. Check A program change invalidates the prior authority route and requires reevaluation.
• LM-11.4.4 Prepare proposed disposition, reasons and conditions. Assemble a proposed disposition, reasons and conditions from approved findings and applicable rules. Send it to the authorized decision maker and record its input version. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Underwriting assistant. Check Every proposed condition cites its underlying evidence or rule.
• LM-11.4.5 Evaluate the authorized automated underwriting route. Record approved automated underwriting findings and evaluate the configured authority route. Advance only with an authorized decision record for the same version. Route unsupported, conflicting or out-of-policy cases to the designated reviewer. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Underwriting assistant. Check A case without decision authority stays held even when its engine findings were accepted.
• LM-11.4.6 Record the qualified underwriter's disposition. Wait for the qualified underwriter to enter the disposition. Capture actor, role, reason codes, conditions and evidence snapshot. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Qualified underwriter. Check A reviewer without decision authority cannot advance the loan.
• LM-11.4.7 Validate and preserve the authorized decision record. Code validates the selected route, actor identity/authority, completed checks, actual disposition and required reasons/conditions. Store the source snapshot, policy version and authenticated actor/event evidence. Reject a proposal mistakenly presented as authorized. Verify that any manual-required case has the actual required reviewer record. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Underwriting assistant. Check Actor, role, decision, reason and case revision match the current authority and evidence.
• LM-11.4.8 Write and reconcile the decision in the LOS. Map the authoritative decision record to the permitted LOS fields using a minimal version-checked update. Write idempotently, read back and compare status/reasons/conditions. On conflict, retrieve current state and reconcile before retrying. An agent diagnoses supported field errors without changing the authorized decision. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Underwriting assistant. Check A stale expected version fails the write and an accepted write reads back exactly.
• LM-11.4.9 Hand off the authorized disposition to execution. Publish one authorized-decision event with version and reason/condition IDs. Step 11.5 consumes it to create tasks and initiate permitted notices. Subsequent conditions go to step 12. Track acknowledgments and suppress duplicate downstream work. This row is the handoff, not a second charge for the communications already mapped in 11.5. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Underwriting assistant. Check Replaying the disposition emits one downstream event for its authorized revision.
• LM-11.4.10 Reassess material changes without losing decision history. Watch relevant source/term changes, evaluate impact rules and invalidate only affected checks/dispositions. Rerun automated investigation/calculation and the applicable decision route. Return to a required qualified reviewer when that actual path requires it. Preserve the prior decision/version and prove the current outcome matches current evidence. Do not silently reuse a stale authorization. Read The LOS decision controls. Approved decision policy and authority matrix for complete review, engine findings, exception disposition and decision authority. Record Authorized decision with reasons and conditions. Owner Underwriting assistant. Check A material change creates a new review basis while the prior signed version remains retrievable.
• LM-11.5 Publish conditions and route required communications. Generate tasks and draft communications from the authorized disposition and conditions. Route regulated or external communications through the designated approval and delivery workflow. Read The LOS. Approved borrower/notice communication process for authorized decision, reason/condition codes, recipients and applicable notice requirements. Record Recorded disposition, task list and controlled communication handoff. Owner Underwriting assistant. Check A delivery receipt and exact version reconcile to the approved record.

LM-12 · Condition collection, follow-up and resubmission

Tie each condition clearance to the reviewed evidence. Reopen dependent checks when later evidence changes their inputs.

• LM-12.1 Translate conditions into specific requests. Parse each current condition into evidence type, period, acceptance test and owner. Match previously supplied evidence before generating a request. Read The LOS conditions. Approved request templates for current condition text, evidence requirements, owner and prior responses. Record Condition-specific request with required evidence. Owner Processor. Check Each request maps to an actual unmet condition. No already-cleared requirement is requested again.
• LM-12.2 Send and track condition requests. Bundle recipient-specific requests, use approved secure channels and track each request/condition ID through delivery and response. Read Borrower portal. Approved messaging. The LOS tasks for condition requests, recipients, contact permissions and due dates. Record Tracked requests linked to each condition. Owner Processor. Check Recipients receive only their relevant requests and all follow-ups preserve the condition context.
• LM-12.3 Match responses to conditions. Consume processed-document events. Match evidence to condition identity, type and period. Evaluate objective sufficiency checks. Produce a proposed clearance or exact remaining gap. Read Document processing results. The LOS conditions. Source viewer for incoming evidence, condition identifiers, required periods and existing responses. Record Condition-evidence links and obvious missing-item flags. Owner Processor. Check A document’s arrival alone cannot clear a condition. Wrong periods/people/versions are rejected by tests.
• LM-12.4 Follow up and escalate stalled conditions. Drive reminders/escalations from actual condition states and deadlines. Stop satisfied requests. Issue targeted next questions. Apply nonresponse hold paths without an employee monitoring the queue. Read Task scheduler. Portal/messaging. Team escalation channel for open statuses, last contact, deadlines, prior reminders and escalation rules. Record Follow-ups, stopped reminders and assigned escalations. Owner Processor. Check Cleared conditions stop all reminders and unresolved cases retain a precise current status.
• LM-12.5 Clear supported conditions and resubmit the rest. Evaluate approved clearance criteria using linked evidence. Update only administrative conditions that the approved authority matrix permits this worker to clear. Aggregate remaining decision-relevant items into the correct program/authority path. Read The LOS. Approved clearance rules. Underwriting queue for matched evidence, condition criteria, clearance authority and current file state. Record Cleared routine conditions or a concise review package. Owner Processor, Qualified underwriter. Check No generic human reviewer is mandatory merely because the document is unusual. Any specific required qualified decision is handled explicitly.
• LM-12.6 Reconcile changes and publish readiness. Compare current decision/condition/evidence versions. Recalculate affected requirements after changes. Preserve clearance history. Emit readiness only for supported current conditions. Read The LOS condition history. Workflow rules for current disposition, evidence versions, cleared/reopened items and dependency rules. Record Current condition status and handoff signal. Owner Processor. Check Old evidence cannot keep a changed requirement falsely cleared. Duplicate updates do not reopen resolved work unnecessarily.

LM-13 · Changed circumstances, redisclosures and lock administration

Check disclosure and change requirements before using revised terms, fees, dates or evidence.

• LM-13.1 Detect relevant changes and approaching expiries. Consume field, document and lock events. Diff old/new values. Identify material changes and expiring terms under configured rules. Emit one change case per event/version. Read The LOS change history. Lock/pricing system. Calendar rules for old/new values, lock terms, expiry dates and affected document versions. Record Candidate change/expiry events. Owner Disclosure specialist. Check Replayed events do not create duplicate changes. Effective dates and previous versions are preserved.
• LM-13.2 Determine the required response. Load current transaction-specific disclosure/lock rules. Evaluate the actual change, prior disclosures and timing. Calculate the required response and any affected calendar events. Read Approved disclosure/lock rules. Compliance queue for change event, timing, prior disclosures, transaction facts and current rules. Record Required action, deadline and supporting reason. Owner Disclosure specialist. Check Test cases distinguish a necessary revision from unnecessary redisclosure and do not restart every waiting period indiscriminately.
• LM-13.3 Prepare revised data or extension request. Build revised terms/fees or extension payload from the supported change. Calculate amounts and consequences. Generate a versioned proposed action with authority/spend limits. Read The LOS. Disclosure generator. Approved lock interface for validated change, approved terms, fee/extension inputs and reason. Record Prepared update or request. Owner Disclosure specialist. Check Prepared changes reconcile to the original event and approved source inputs. No hidden financial commitment is made.
• LM-13.4 Apply an authorized change. Compare the requested change with the exact prior lock, fee and disclosure values. Validate effective date, authority, limits and downstream requirements. Submit the approved update once and compare the provider acknowledgment with the saved LOS values. Hold the action until an authorized disposition exists. Read Lock/pricing approval controls. Disclosure delivery. The LOS for prepared action, authority limits, approver decision and recipients. Record Accepted lock update and/or delivered revised package. Owner Disclosure specialist, Operations manager. Check An out-of-policy change remains held. Reconcile an uncertain provider acknowledgment before retrying.
• LM-13.5 Reconcile completion and downstream effects. Consume lock/disclosure acknowledgments. Reconcile revised values and receipt evidence. Recompute only affected dates/tasks. Confirm final state in the LOS. Read The LOS. Delivery/lock acknowledgments. Workflow calendar for execution receipts, updated versions, receipt evidence and dependency rules. Record Verified completion with revised task/timing state. Owner Disclosure specialist. Check Partial or rejected changes cannot be marked complete. Downstream timing follows the accepted current state.

LM-14 · Final readiness checks and refreshed evidence

One unresolved mandatory hold blocks handoff. Record any override under the approved authority policy.

• LM-14.1 Evaluate final readiness. Run the product-specific final checklist over current conditions, documents and findings. Produce a blocker ledger with evidence and responsible source. Read The LOS. Approved final-readiness checklist for current conditions, findings, document versions, deadlines and planned closing. Record Readiness checklist with explicit blockers. Owner Processor. Check A mandatory unresolved prerequisite cannot disappear into a generic ready status.
• LM-14.2 Check evidence validity and order permitted refreshes. Evaluate report/document age against the planned dates and applicable product/income rules. Request permitted refreshes. Track fulfillment and update expiry timers. Read The LOS. Approved credit/verification providers for evidence dates, planned note/closing dates, findings and product-specific validity rules. Record Required refresh orders and validity status. Owner Processor. Check Wrong timing rules are not generalized across every borrower/product. Completed refreshes replace only the appropriate stale evidence.
• LM-14.3 Compare refreshed results with the prior file. Diff refreshed credit/employment/evidence against accepted prior facts. Recalculate affected values. Determine whether supported change rules require new analysis or submission. Read Verification/credit results. The LOS comparison view for old/new results, borrower association, relevant tolerances and loan calculations. Record Material-change findings or confirmation of consistency. Owner Processor, Qualified underwriter. Check Material adverse or inconsistent changes cannot be ignored. Unchanged refreshes do not create unnecessary work.
• LM-14.4 Resolve blockers and authorize readiness. Resolve objective blockers through the owning workflows. Evaluate readiness under the approved product/authority rules. Route only an actual required authorization to its authorized actor. Persist the resulting status. Read The LOS. Underwriting/compliance exception workflow for blocker list, corrective evidence, current decision and authority requirements. Record Authorized readiness/clear-to-close status or a documented hold. Owner Processor, Qualified underwriter. Check The system can clear a supported delegated path. It must preserve any real program/counterparty decision requirement.
• LM-14.5 Publish the closing handoff. Build a final handoff snapshot with current terms, dates, conditions and evidence IDs. Confirm ownership and required tasks. Publish a closing-ready event with an auditable version. Read The LOS milestone/task workflow. Internal notification for authorized readiness state, approved terms, current deadlines and handoff checklist. Record Closing-ready handoff with remaining responsibilities identified. Owner Processor. Check Closing receives the exact authorized current state. No stale or incomplete handoff advances silently.

LM-15 · Closing Disclosure, fee balancing and document preparation

Tie the figures, generated disclosure, closing packet and delivery evidence to the same version.

• LM-15.1 Assemble approved terms and settlement figures. Join approved terms, lock status, fee tables and settlement inputs by effective version. Normalize fee categories and identify missing figures before generation. Read The LOS. Settlement portal. Approved pricing/fee sources for approved terms, settlement estimates, lock data, lender fees and current versions. Record Versioned closing-input set. Owner Closer / signing coordinator. Check Each amount has a source/version. Conflicting figures remain an explicit reconciliation item.
• LM-15.2 Balance fees and cash to close. Calculate line-item fees, credits, payoffs, prorations and cash-to-close in Python. Compare lender/settlement versions. Exchange targeted correction requests and rerun the reconciliation. Read The LOS closing calculations. Settlement statements. Comparison worksheet for fee lines, credits, deposits, payoffs, prorations and approved tolerances. Record Balanced figures or a line-item discrepancy list. Owner Closer / signing coordinator, Funder. Check Independent totals reconcile and no unexplained difference is hidden by a balancing plug.
• LM-15.3 Generate the Closing Disclosure and closing package. Call the approved closing/document provider with a validated snapshot and correct templates. Retain generated documents and input/template versions. Compare critical populated fields. Read Approved disclosure/document-generation system. The LOS for balanced figures, loan/borrower data, program/state templates and required recipients. Record Versioned draft package. Owner Closer / signing coordinator. Check Generated terms/fees/recipients match the approved snapshot and obsolete templates are not silently reused.
• LM-15.4 Validate timing, consistency and release conditions. Execute current content, consistency, delivery/receipt and timing checks. Compute the applicable calendar. Test revision consequences before release or closing progression. Read Closing/disclosure checks. The LOS calendar. Compliance rules for draft package, prior disclosures, receipt events, planned closing and applicable rules. Record Release readiness or specific timing/content findings. Owner Closer / signing coordinator. Check Required waiting/receipt conditions are preserved. A generated file alone does not imply release/closing eligibility.
• LM-15.5 Deliver and retain evidence. Send only the authorized document version via the permitted provider/channel. Record receipts and acknowledgments. Run automated reminders/alternate-route handling where allowed. Read Approved disclosure/e-sign/mail provider. The LOS for authorized document version, recipients, delivery prerequisites and timing. Record Delivered package and recorded delivery/receipt evidence. Owner Closer / signing coordinator. Check The correct recipient/version is evidenced and failed delivery cannot satisfy the release gate.
• LM-15.6 Control revisions and hand off for signing. Diff requested revisions, regenerate affected documents, rerun content/timing checks, supersede old versions and confirm receipt of the correct signing package. Read The LOS. Settlement/eClose platform. Version control for approved revisions, current package, timing consequences and recipient acknowledgments. Record Current authorized signing package with obsolete versions identified. Owner Closer / signing coordinator. Check All parties use the same authorized current package. A material revision triggers its actual required checks.

LM-16 · Signing coordination and completion checks

Use confirmed signing and notarization evidence as applicable. Distinguish corrected and superseded packets.

• LM-16.1 Choose the signing route and participants. Evaluate signer identities/authority, jurisdiction, product and provider capability. Select a permitted signing route and participants. Create a versioned execution plan. Read The LOS. Settlement/eClose platform. Approved signing rules for borrower/ownership authority, document requirements, jurisdiction/product eligibility and party preferences. Record Signing plan and participant list. Owner Closer / signing coordinator. Check Supported electronic/physical routes are selected from actual eligibility, not a blanket assumption that everything must be wet-signed.
• LM-16.2 Schedule and distribute instructions. Collect participant availability, reserve the approved provider/appointment, distribute secure instructions and the current package, and reconcile confirmation/change events. Read Settlement/calendar tools. Approved messaging. EClose portal for signing plan, availability, delivery requirements and authorized document version. Record Confirmed appointment and controlled document distribution. Owner Closer / signing coordinator. Check Changed appointments update all parties and superseded document versions are not sent.
• LM-16.3 Verify assent, signing and notarial evidence. Capture provider evidence of actual signer assent and required notarial acts. Reconcile identity and signature events to the specific package version. Read Eligible e-sign/eClose/notary system or physical signing process for authorized documents, identity/authority evidence and applicable execution requirements. Record Executed documents and associated evidence. Owner Closer / signing coordinator. Check A signing invitation or delivery receipt alone leaves the signing gate open.
• LM-16.4 Check completeness and route defects. Compare executed-package pages, signatures and required evidence with the authorized manifest. Identify exact defects. Send correction requests to the signer/provider. Recheck returned material. Read Executed-package viewer. Document checks. The LOS for executed package, signature/page requirements, document versions and recipients. Record Completion checklist and targeted correction requests. Owner Closer / signing coordinator. Check A missing required signature stays unresolved until actual corrected evidence arrives. Internal checking and chasing do not require staff.
• LM-16.5 Record completion and notify funding. Reconcile execution-provider completion with package checks and funding prerequisites. Update the LOS and notify funding only when the defined conditions pass. Read The LOS. Settlement acknowledgments. Workflow notifications for completion checks, executed documents, unresolved items and funding prerequisites. Record Recorded signing completion or a funding hold with reasons. Owner Closer / signing coordinator. Check Signing completion is never inferred solely from an appointment ending or an email saying it is done.

LM-17 · Funding and warehouse request preparation

When payment status is uncertain, reconcile with the funding desk before issuing another instruction.

• LM-17.1 Check funding prerequisites. Evaluate the current funding checklist and applicable timing/condition rules. Verify required execution/authorization evidence and expected funding date. Create an explicit hold ledger if needed. Read The LOS. Approved funding checklist and calendar for executed documents, authorized conditions, receipt/rescission/timing status where applicable and funding date. Record Funding-ready status or explicit hold. Owner Funder. Check The request cannot proceed on stale conditions or unsupported assumptions about required dates.
• LM-17.2 Prepare funding figures and warehouse package. Calculate the supported request amount, map verified data into the selected warehouse schema, assemble the required documents and reconcile the request against approved closing figures. Read The LOS. Warehouse portal/integration. Approved funding worksheet for approved amounts, closing figures, warehouse assignment, dates and required documents. Record Validated request and supporting package. Owner Funder. Check The request amount, date, loan and documents agree. Incomplete packages do not submit.
• LM-17.3 Validate instructions and obtain authorization. Match trusted instructions to beneficiary, loan, amount and approved packet. Verify changed instructions independently through the approved channel. Apply the lender and bank separation-of-duties rules. Release only through the existing authorization path and save the transaction reference for status reconciliation. Read Banking/warehouse authorization workflow. Approved instruction-verification process for trusted payment details, changes, limits, supporting evidence and approver identity. Record Verified instructions and authorized funding decision. Owner Funder, Operations manager. Check A changed instruction in an email alone stays held. An uncertain acknowledgment triggers reconciliation before any retry.
• LM-17.4 Submit supported requests and track acceptance. Submit the authorized request through supported banking/warehouse access. Persist a unique request key. Reconcile a timeout with provider status before retrying. Monitor rejection codes. Read Supported warehouse/banking interface. The LOS for authorized package, request identifier, destination and required credentials. Record Accepted request or a specific rejection. Owner Funder. Check An uncertain response never causes an unverified duplicate payment/request.
• LM-17.5 Reconcile confirmation and update the loan. Compare actual confirmation, transaction ID, amount and date with the request. Reconcile reversals/partial results. Update funded status and handoff only after verified evidence. Read Warehouse/bank confirmations. The LOS. Exception queue for accepted request, actual funding confirmation, amount/date and transaction identifiers. Record Reconciled funded status or assigned discrepancy. Owner Funder. Check Actual funded state is distinguished from request acceptance. Unresolved cash differences remain visible.

LM-18 · Post-closing document completeness and corrections

Index the signed file, track missing artifacts, and preserve originals and accepted corrections.

• LM-18.1 Receive and index the executed package. Receive final files through the approved provider connection. Confirm loan identity. Hash/version each source. Index final records and preserve previous versions. Read Settlement delivery. The LOS eFolder. Document index for executed package, loan identifier, document versions and settlement metadata. Record Indexed executed package. Owner Post-closing / delivery. Check No wrong-loan attachment or accidental loss of a prior executed version.
• LM-18.2 Check required pages, signatures and data. Run a required-package manifest and cross-document field/signature checks against the authorized terms. Produce page-level defect evidence and an issue code. Read Document viewer/checks. The LOS. Approved package checklist for required document list, executed contents, approved terms and completion rules. Record Document-defect checklist with evidence. Owner Post-closing / delivery. Check Injected missing pages/signatures and mismatched terms are found without treating routine checks as independent QC.
• LM-18.3 Create and route correction requests. Map each defect to the required cure and responsible provider/signer. Generate a specific secure request. Track due dates and prevent duplicate messages. Read The LOS tasks. Approved settlement communication for defect details, responsible party, permitted correction route and due dates. Record Tracked correction requests. Owner Post-closing / delivery, Closer / signing coordinator. Check Each request corresponds to a real defect and no unsupported material change is requested automatically.
• LM-18.4 Review corrections and close supported defects. Ingest corrected versions. Compare the exact defect and affected fields. Rerun necessary tests. Close only the satisfied issue and preserve the original/corrected evidence chain. Read Document comparison. The LOS defect tracking for original defect, corrected document, version and acceptance criteria. Record Resolved defect or a precise remaining issue. Owner Post-closing / delivery. Check One corrected page cannot accidentally close unrelated defects or replace an entire loan package incorrectly.
• LM-18.5 Publish the final operational file status. Evaluate delivery prerequisites against current defect/evidence state. Build the final manifest. Record approved exceptions and publish ready/hold status with reasons. Read The LOS. Investor-delivery queue for corrected documents, open defects, delivery requirements and approved exceptions. Record Delivery-ready package or identified hold. Owner Post-closing / delivery. Check Any required unresolved defect blocks readiness. No blanket employee signoff is added without an actual requirement.

LM-19 · Investor/custodian delivery

Wait for recipient acceptance or an assigned rejection after transmission.

• LM-19.1 Identify investor/custodian delivery requirements. Read the assigned investor/custodian and commitment/product details. Select the current delivery specification. Generate the exact field/document checklist. Read The LOS. Investor/custodian requirements and portal for assignment, product/channel, commitment details and current delivery specifications. Record Required data/document checklist. Owner Post-closing / delivery. Check The package specification matches the actual assigned destination and effective version.
• LM-19.2 Assemble and map the package. Export the current supported loan data, map into the destination schema and assemble the required executed documents from their indexed versions. Read The LOS. Delivery integration. Document index for current loan data, executed documents, mapping rules and destination checklist. Record Prepared investor/custodian package. Owner Post-closing / delivery. Check All included files belong to the correct loan and required fields preserve their authoritative source.
• LM-19.3 Validate the package before submission. Validate schema, required documents, closed terms and relevant findings. Calculate a package fingerprint. Resolve fixable errors through source correction and regeneration. Read Delivery validation. The LOS. Destination schema/checklist for prepared package, closed terms, current findings where applicable and validation rules. Record Validated package or specific errors. Owner Post-closing / delivery. Check Missing/wrong-version evidence fails with a specific reason. Validations do not substitute guessed values.
• LM-19.4 Deliver supported data/documents. Transmit the validated package through supported portal/API access. Retain payload/version IDs and acknowledgments. Reconcile uncertain submissions before retrying. Read Supported investor/custodian portal or integration for validated package, credentials, destination and unique submission identifier. Record Submission receipt and delivered version. Owner Post-closing / delivery. Check The correct package is submitted once and receiver acknowledgment is recorded.
• LM-19.5 Reconcile acknowledgment and route rejections. Parse acceptance/rejection messages. Map routine errors to corrected payload/data actions. Rerun checks. Resubmit permitted corrections and publish accepted or precise pending state. Read Investor/custodian status. The LOS delivery history for submission receipt, acknowledgments, rejection codes and current loan state. Record Accepted delivery or assigned corrective task. Owner Post-closing / delivery. Check A submitted package is not labeled accepted until supported acknowledgment. Unresolved custody issues remain explicit.

LM-20 · Investor suspense and purchase reconciliation

Link responses, cures and final acceptance to the original suspense. Escalate disputed terms and concessions.

• LM-20.1 Receive and classify investor suspense. Consume investor notices and match them to loan/commitment IDs. Parse each defect into required evidence, owner and deadline. Deduplicate repeated notices. Read Investor portal/messages. The LOS for notice, loan/commitment identifier, defect codes, requirements and deadlines. Record Structured suspense list with owners. Owner Post-closing / delivery. Check No notice is lost, attached to another loan or counted as multiple distinct defects due to retries.
• LM-20.2 Retrieve evidence and prepare routine cures. Retrieve the exact requested evidence from indexed sources. Identify whether it exists, is stale or needs correction. Build a supported cure payload and source manifest. Read The LOS eFolder. Source systems. Approved response templates for suspense requirement, existing evidence, allowed correction route and current versions. Record Evidence-backed cure response. Owner Post-closing / delivery. Check The response answers the actual defect and does not invent missing evidence or assume a concession is authorized.
• LM-20.3 Route nonstandard disputes and concessions. Collect the suspense, contract reference and evidence. Prepare the supported cure or concession for the authority holder under contract and policy. Read Investor communication. Approved pricing/exception authority for contract/commitment, investor claim, supporting facts and approval limits. Record Agreed disposition and authorized financial adjustment if any. Owner Post-closing / delivery, Operations manager. Check A disputed amount or concession stays open until authorized.
• LM-20.4 Submit cures and track purchase readiness. Submit the authorized cure once, track acceptance and unresolved items, send timed follow-ups and rerun supported correction actions after rejection. Read Supported investor portal. The LOS suspense tracking for authorized response, evidence, deadlines and investor acknowledgments. Record Cure acceptance or a remaining task. Owner Post-closing / delivery. Check Accepted cures close only the matched defects. Pending external responses remain pending rather than generating fake completion.
• LM-20.5 Reconcile purchase advice and warehouse payoff. Calculate expected proceeds/payoff from supported commitments and approved adjustments. Compare purchase advice and warehouse records. Match transactions and investigate differences. Read Purchase advice. Warehouse reports. The LOS. Accounting handoff for expected proceeds, approved adjustments, purchase details, payoff figures and transaction identifiers. Record Reconciled purchase/payoff record or exception. Owner Purchase / payoff reconciliation. Check Proceeds/payoff reconcile without plugs. Hedge attribution and separate P&L work are not counted again.

LM-21 · Servicing handoff and file archive

Confirm servicing boarding and preserve versioned retention and access evidence.

• LM-21.1 Determine servicing destination and handoff requirements. Evaluate actual servicing-retained/released arrangement, recipient and dates. Select the applicable handoff/notice/record requirements. Read The LOS. Servicing arrangement and boarding specifications for loan assignment, servicing rights/path, destination, transfer dates and requirements. Record Servicing handoff checklist. Owner Post-closing / delivery. Check The correct recipient and path are selected. Unresolved servicing arrangements do not default silently.
• LM-21.2 Prepare boarding data and documents. Map current closed/funded loan fields and payment/escrow terms into the boarding schema. Assemble supporting records and retain source-to-destination field lineage. Read The LOS. Servicing interface. Document store for closed/funded loan data, payment/escrow fields, destination mapping and required documents. Record Prepared boarding package. Owner Post-closing / delivery. Check Balances, dates, terms and ownership reconcile to the final loan rather than an obsolete intermediate snapshot.
• LM-21.3 Validate and transmit the package. Run recipient schema/consistency tests, submit the package using authorized access, store a unique transfer reference and reconcile acknowledgments. Read Boarding validation. Supported servicing interface for prepared package, current balances/terms, recipient schema and submission identifier. Record Accepted transmission or clear errors. Owner Post-closing / delivery. Check Partial failures or timeouts do not produce duplicate boarding or a false accepted status.
• LM-21.4 Reconcile acceptance and coordinate required notices. Consume boarding exceptions and acceptance messages. Reconcile them to submitted records. Issue applicable communications via the approved notice workflow. Track unresolved replies. Read Servicer acknowledgment. Approved notice process. The LOS for submission, boarding results, transfer facts, recipient details and notice requirements. Record Confirmed handoff and tracked communications. Owner Post-closing / delivery. Check Acceptance is evidenced and required communications are separately tracked. No employee must monitor every successful handoff.
• LM-21.5 Archive the final record and preserve access. Build the final record manifest, enforce access/retention policy, preserve holds, archive immutable versions and perform retrieval checks. Read The LOS/eFolder. Approved archive and access controls for final documents/data, retention schedule, permissions and record index. Record Archived record with verified access and retention status. Owner Post-closing / delivery. Check The record remains retrievable with correct permissions. No held record is deleted by a routine retention job.

LM-22 · Cross-process status reporting and escalation

Route production exceptions to owners and keep designated independent QC separate from production readiness checks.

• LM-22.1 Collect authoritative workflow events. Subscribe/poll authoritative source events, normalize IDs/status/timestamps, deduplicate and store an ordered loan event history with freshness indicators. Read The LOS events. Approved connected-system status sources for loan IDs, milestones, timestamps, task ownership and acknowledgments. Record Normalized event history for each loan. Owner Processor. Check Missing feeds or uncertain associations are explicit. Status is never inferred from an absent event.
• LM-22.2 Calculate status and detect stalled work. Compute state from actual completed prerequisites, calculate age/deadlines using the applicable calendar and detect blocked/overdue tasks with exact cause and owner. Read Workflow rules. Operational dashboard. Task queue for event history, dependency rules, deadlines, business calendar and unresolved exceptions. Record Current status and precise blocker/overdue signals. Owner Operations manager. Check The model distinguishes waiting, working, completed and failed states. Stale or contradictory signals cannot masquerade as ready.
• LM-22.3 Route notifications and escalations. Evaluate notification/escalation rules against state changes and ownership. Send only actionable updates. Create/update tasks idempotently and stop superseded alerts. Read The LOS tasks. Approved email/internal messaging for status changes, owner roster, authority, notification cadence and escalation rules. Record Assigned action/notification with delivery evidence. Owner Processor. Check Duplicate events do not spam users. The actual task work remains in its owning step rather than counted again.
• LM-22.4 Prepare operating reports. Calculate agreed metrics from normalized events and measured touch-time data. Reconcile counts/denominators. Publish current reports and explain material differences. Read The LOS reports. Approved dashboard/report output for validated status, volume, touch-time, defects and agreed metric definitions. Record Current report with source timestamps and exception detail. Owner Operations manager. Check Every headline traces to source records. Missing source coverage is visible and the report cannot create unsupported savings claims.
• LM-22.5 Support staffing and policy decisions. Produce queue, quality and service evidence by stage. Send staffing or policy changes to the responsible decision owner. Read Management report. Staffing schedule. Approved decision workflow for current workload, service levels, cost, constraints and unresolved issues. Record Approved resource/prioritization decisions. Owner Operations manager. Check A policy or staffing proposal is recorded separately from its approval.
• LM-22.6 Test and release an approved rule change. Compare the proposal with the prior approved rules using synthetic and historical fixtures. Obtain any reserved approval, record the new configuration version and prepare rollback. Read Execution history. Test environment. Versioned rule/change approval for measured outcomes, defects, approved objectives, proposed changes and acceptance tests. Record Tested approved change, rollback path and subsequent measurement. Owner Operations manager. Check Replaying prior fixtures under the previous policy still reproduces the previous outcomes.

Build it yourself with AI

Start with one document intake queue

Use a local folder with loans.csv, synthetic PDF pages or text fixtures, and policy.yml. Give each fixture a stable source ID. Write the policy with your processor before prompting. It should list the allowed document types, required fields, accepted match conditions, and the cases that go to a reviewer. Use fabricated application and document data while developing. Handle borrower data only in the approved environment.

Prompt 1. Design the intake contract

Read policy.yml and the synthetic files. Propose a CSV contract for indexed evidence and a separate review queue. Include source ID, loan ID when known, page, field, policy version, and reason code. Cite the rule behind each routing decision. List any missing policy as an open question for the processor.

Prompt 2. Build and replay a local prototype

Implement a Python command that reads the fixtures and writes evidence.csv and review_queue.csv. Use the rules in policy.yml for acceptance. For proposed text extractions preserve the exact quotation and page. Route an ambiguous match to review. A second run on the same files must create no extra rows. Use fake file IDs in logs and add no portal, email, or LOS write access.

Prompt 3. Draft the processor’s review playbook

From review_queue.csv, draft a one-page checklist showing how the reviewer confirms loan identity, records an evidence correction, and clears a hold. Identify which cases require a second reviewer or escalation according to policy.yml. Treat unspecified approvals as questions. Return a sample handoff for an ambiguous document and show the audit record it leaves.

Try it. Use a statement with a unique reference to L-100 and a second statement with references that could match two files. Expect one indexed attachment, one owned review item, and a held packet. Replay the batch and verify both counts stay at one. Approve a corrected replacement in a fixture and verify the previous evidence stays visible. Review the results with a processor, then shadow the current intake queue before adding the next handoff.

Need help automating this?

See how Mage helps lenders connect loan records, verify documents and prepare files for the next handoff. See Mage's loan manufacturing automation.