CLEAR Home Loans · Confidential

NACHO — Software Requirements

The version-controlled specification for the POS, the LOS, and how they connect.

POS v1.0.1 · LOS v1.0.1 · Integration v1.0.1 · baselined 1 September 2026, current to 21 September

Send all three together. Each product document is complete about its own half and deliberately does not restate the other's internals. The integration document is where the two halves become one system — a team handed only two of the three will invent the seam themselves, which is the most expensive thing that can go wrong on a build like this.

POS — the borrower side Updated · v1.0.1

For the team building the borrower-facing product

The front door: what a borrower, a referral partner and a loan officer touch. The mortgage primer written from zero, numbered functional requirements with acceptance criteria, and the full non-functional set. §3 lists exactly what changed since 1 September, each row citing the review-queue item it came from.

70 pages228 functional73 non-functional9 new · 29 changed

LOS — the lender side Updated · v1.0.1

For the team building the operations product

The manufacturing line: processing, underwriting, closing, funding and post-close. The role and capability model, the three compliance gates, and 286 numbered functional requirements. §3 lists exactly what changed since 1 September, each row citing the review-queue item it came from — including the 2026-09-21 permissions lane, which is built and gated on named tests.

72 pages286 functional72 non-functional11 new · 13 changed

Integration layer — the seam Verified · v1.0.1

For both teams, together

How the two halves become one system: the ownership matrix, the published stage table, the push and event contracts, and the four compliance boundaries that cross between them. v1.0.1 changes no seam rule. It records that SM-01SM-12 were re-verified against LOS v1.0.1 and the 21 September permissions lane and found unchanged — §3 lists exactly what was checked. A no-change that has been checked and dated is a finding; one that is assumed is not.

19 pages12 seam requirements — unchangedstage table 11.4.1

Read §3 of each document first — and §8 of the LOS

It is the Change Detail Log: every requirement that is new, updated or clarified since 1 September, each citing the review-queue item behind it — plus, deliberately, what shipped that changed no requirement, what was internal tooling, and what is parked. Nothing already issued was renumbered or removed. Every earlier version stays available and frozen so you can diff.

The LOS document has a §8: “Not built, and what is required to build it.” Read it before estimating — a requirement appearing in §4 is not a claim that it is live. Every row there is waiting on an input that has not been supplied, not on developer time.

What changed from the September 1 set

Two different things, and it matters which is which. First, the version-control apparatus — Document Control, a Revision History, a Change Detail Log and per-requirement tracking (Introduced · Last Updated · Status), so every revision is auditable inside the document itself. Part II of each file is the complete 1 September specification, verbatim.

Second, real requirement change, recorded in §3 of each document: the POS moved on 6 September, and the LOS moved again on 21 September when the permissions lane landed — D-01 roles resolve per window, D-02 a second standing backup, D-04 the wire second control. Those three are built and gated on named acceptance tests, not proposals. ⛔ No ID was ever renumbered or removed — every identifier issued on 1 September still means what it meant then.

Requirement IDs are unchanged, deliberately

A1, B10, CO-06, SEC-09, DEN-05 mean what they have always meant. They were not renumbered into FR-nn form, because they are the IDs already in the reference build, the test suites and every prior conversation. Traceability outranks tidiness.