Initial Closing Disclosure

How the Initial Closing Disclosure request behaves — the five-precondition eligibility gate, the business-purpose block, what submission writes to MeridianLink versus what it only documents, and the contacts and non-obligor collections it syncs.

The Initial Closing Disclosure (ICD) request asks for a borrower's Closing Disclosure to be prepared. It is built on the Change of Circumstance form and contract — same reason categories, changed items, and fees — and adds three things COC does not have: an eligibility gate, a business-purpose block, and two collection-synced steps (Contacts and Non-Obligor Borrowers). It lives on the loan's Requests tab.

The eligibility gate

Unlike a COC, an ICD form only opens when the loan is ready. Opening a new ICD request first calls an eligibility read model, which returns one of three outcomes:

Eligible — every precondition passes and the loan is not business-purpose; the form opens.
Ineligible — at least one precondition fails; the user sees a checklist of exactly what is missing and the form stays closed.
Business-purpose — the loan is ATR-exempt; the user sees a notice that Closing Disclosures are not sent on business-purpose loans, and the form never opens.

The five preconditions are:

Precondition	Source
Loan status ∈ Approved / Clear to Close / Conditions Review / Final Underwriting / Pre-Doc QC	Hydrated vendor loan status
Loan is locked	Loan lock state
Final Hazard Insurance Policy received	Read live from MeridianLink
Initial Approval Date available	Hydrated approval date
Appraisal populated or Property Inspection Waiver	Hydrated appraisal date / valuation effective date / PIW flag

The gate is UX and a guard

The checklist is the user-facing explanation, but eligibility is re-checked on the server at submit — an ineligible or business-purpose loan is rejected with a 422 even if the form was already open. The gate can never be bypassed from the browser.

What submitting does

Submitting an ICD request has four effects, in order:

Writes three fields to MeridianLink — the Disclosure Request date (set to today), a comment ("ICD Requested"), and the Estimated CD date.
Syncs two collections to MeridianLink — the Contacts to the loan's agent/contact set, and the Non-Obligor Borrowers to the title-borrower record.
Files a PDF to MeridianLink Documents — the request form is rendered to a PDF and uploaded as the CD Request Form, with the date in the description.
Records a request in local history — a loan_requests row (request type icd) capturing the full payload, so the request is auditable in the portal.

Documentation-only change values, by design

As with COC, the per-field new values (rate, amount, fees…) are captured in the PDF and the history record — they are not pushed to MeridianLink as field edits. Only the three disclosure fields, the two collections, and the uploaded document are written.

Contacts and non-obligor borrowers

These two steps are the ICD-specific additions to the form:

Contacts capture the parties on the closing (lender, title, closing agent, buyer/listing/selling agent, loan officer, broker…). Each contact has a role that maps to a MeridianLink agent-role code, and is written to the loan's agent/contact collection — adding new rows or editing existing ones.
Non-Obligor Borrowers capture people who hold title but are not on the loan (typically a non-borrowing spouse), and are written to the loan's title-borrower record. SSN and date of birth are treated as sensitive throughout.

Reusing the Change of Circumstance form

Everything else — the reason categories, the changed-items grid, compensation, credit scores, fees, and the printable request form — is shared with the COC request, parameterized by request type. The two request forms behave identically where they overlap, so a user who knows one knows the other.

The review model

Like COC, the ICD request is manual today: it captures, files, and records the request, and an internal user prepares the disclosure in MeridianLink. The request rides the same LoanRequest lifecycle (draft → submitted → in_review → approved → completed, with reject / cancel), so a future approve/deny/apply workflow can be added without re-modelling it.