Loan Product Advisor (LPA)

How the portal runs Freddie Mac's Loan Product Advisor through MeridianLink's asynchronous SubmitToLpa flow, imports the findings, and serves the findings PDF.

Loan Product Advisor (LPA) is Freddie Mac's Automated Underwriting System (AUS). The portal lets a user pick a credit provider, submit a loan to LPA, watch the asynchronous run complete, review the verdict, findings, and errors, view the findings PDF, and see the history of past LPA runs.

The user-facing surface is the Loan Product Advisor panel inside the Connect Services hub (?service=lpa), a sibling to the Desktop Underwriter panel.

A separate, asynchronous vendor seam

LPA is a different capability from Desktop Underwriter. DU is a synchronous call over the LendingQB SOAP bridge; LPA is a genuinely asynchronous flow over MeridianLink's SubmitToLpa.asmx SOAP service. They share the AusSubmission model, history endpoints, and aus.* permissions, but nothing else.

Capability	Driver env	Transport	Adapters
`lpa`	`LPA_DRIVER` (`mlm` \| `null`)	MLM SOAP `SubmitToLpa.asmx` (`webservices.mortgage.meridianlink.com`)	`MlmLpaAdapter` (`mlm`), `NullLpaAdapter` (`null`)

The LpaProvider port models the async lifecycle directly: creditProviders(), submit() (returns a job id), poll(), and import(). Auth reuses the same service-account Bearer ticket as the e-doc seam (MlmServiceTicket). The driver defaults to null, so local and CI boot without MeridianLink credentials.

The run lifecycle

POST /api/v1/loans/{loan}/lpa is asynchronous: it authorizes (aus.run), creates a pending AusSubmission (provider = loan_product_advisor), queues RunLpaSubmission, and returns 202. The queued job owns the whole multi-phase lifecycle:

Submit — SubmitRequest once, persisting the returned job_id so a later re-run (queue release) never double-submits.
Poll — PollLpaSubmissionResults; while the job is not ready the worker releases itself back onto the queue with a short delay (bounded by retryUntil()).
Import — ImportLpaResults writes the findings back onto the MLM loan file (findings only by default), and the normalised recommendation, findings, and the findings PDF doc id are persisted; the submission is marked completed.

The findings PDF is not stored: GET /api/v1/loans/{loan}/aus/{submission}/findings-pdf streams it live from MeridianLink's e-docs (DownloadEdocsPdfById) by the run's findings_doc_id, inline, never written to disk.

Choosing a credit provider

GET /api/v1/loans/{loan}/lpa/credit-providers lists the providers via the live GetCreditProviders operation. When no service ticket is available it degrades to an empty list so the run panel still renders rather than erroring.

History

Past LPA runs are read through the shared AUS history endpoint, filtered by provider: GET /api/v1/loans/{loan}/aus?provider=loan_product_advisor. Runs placed directly in MeridianLink are mirrored by the same aus_orders freshness-gate sync that backs Desktop Underwriter, so the history reflects MLM as the source of truth.

Provisional MLM codes — confirm before relying on them

The SubmitRequest codes CaseStateType and CreditReportOption (Postman sample values 4 and 3), the job-id and poll-status response shapes, and the location of the findings PDF doc id are all provisional — sourced from the SP-217 Postman collection, not a live probe. MlmLpaAdapter parses tolerantly and the codes default from config (LPA_CASE_STATE_TYPE / LPA_CREDIT_REPORT_OPTION). Confirm against the MLM knowledge base and a live probe (test borrower Patrick Purchaser / CTDPATPTEST) before treating them as fact.

Permissions

aus.view gates listing and reading runs and the findings PDF; aus.run gates submitting a new run. Both are data-scoped through the per-user visibility scope like every other loan resource.