How a HomeNOW by Verity Mortgage loan file reaches your backend

Behind HomeNOW sits a SimpleNexus tenant (now operated by nCino) holding the borrower's 1003, document binder, and loan-milestone log for Verity Mortgage. The customer-facing app is the thin layer; the loan-officer console, the LOS push leg, and the per-loan event stream all live tenant-side. That is the integration surface — and the reason this brief is short on theory and long on what a working client against it looks like.

What HomeNOW actually holds on a borrower

Rows below reflect the surfaces the app's own description and the SimpleNexus platform documentation point at, plus what is visible to a borrower in-session.

Three routes to that data — and the one we would take

Route 1 — authorized lender-tenant integration. The lender (Verity Mortgage / Eustis) authorizes a tenant-scoped credential for the engagement. The client reads the loan file directly and subscribes to milestone webhooks. Most durable, fastest to put into production, and what we recommend when the buyer is the lender or a counterparty the lender has signed onto. Onboarding handles the credential conversation; the build does not wait on it.

Route 2 — borrower-consented credential access. The borrower authenticates through the app, the client carries their session, and reads what they can see — their own 1003, their own documents, their own milestones. Right shape when the buyer is a downstream borrower-facing product (a personal-finance aggregator, a competing pre-approval tool, a closing-cost comparison product) rather than the lender.

Route 3 — authorized protocol-analysis bridge. When a sponsor relationship is being arranged and tenant credentials for route 1 are still in flight, we capture the app's authenticated traffic in a documented single-instance lab and write the client against that observed shape so the engagement can start. Bridging only — it is replaced by route 1 once the credentials land.

For a Verity Mortgage-sponsored job we go straight to route 1. For an aggregator pulling against a borrower's own consent it is route 2. Route 3 only earns its keep when the credentials for route 1 are still being arranged at kickoff.

What ships at the end of the engagement

Lead deliverable, every time, is runnable code against the surfaces in the table above:

• Python and Node.js clients for the loan-application read, document-binder list / fetch, milestone subscribe, and contact-record read paths. Typed responses, structured errors, retries on transient failures.
• Webhook handler with delivery-id dedupe, signature verification, and a small replay queue so a tenant-side burst does not lose events.
• Automated test suite against recorded fixtures of the tenant's responses — when the schema drifts on the tenant side, the suite fails noisily rather than letting the consuming system pick up bad data.
• Ingestion design note covering batch backfill (initial seed of historical loans) and real-time top-up (steady-state milestones), with an idempotency key on (loan_application_id, milestone_name) so a re-run is safe.
• OpenAPI / Swagger spec for the endpoints the client wraps, plus the auth-flow report (OAuth bearer chain, token refresh, scope behaviour against the lender tenant).
• Interface documentation describing each endpoint, each field, the value ranges seen in real responses, and a one-page operations note for the team running the client.
• Compliance / data-retention guidance: minimization defaults, what to drop on read, what is safe to log, and how to handle borrower revocation against the cached binder.

An example call against this tenant

Illustrative shape, not a copy-paste. Exact field names are confirmed against the actual tenant during the build — the SimpleNexus schema and the LOS underneath both move things around a little.

from openfinlab_homenow import HomeNowClient, MilestoneEvent

client = HomeNowClient(
    tenant_id="verity-mortgage-prod",
    oauth_bearer=load_secret("VERITY_HOMENOW_BEARER"),
    consenting_borrower="<authorized loan_application_id>",
)

# 1) Read the 1003 the borrower submitted through HomeNOW
loan = client.loan_applications.fetch(loan_application_id)
# -> {
#      "loan_application_id": "...",
#      "borrower":   {"first_name": ..., "ssn_last4": ..., "employment": [...]},
#      "subject_property": {"address": ..., "occupancy": ...},
#      "milestones": [{"name": "AppSubmitted", "at": "..."}, ...]
#    }

# 2) Pull the document binder for that file
#    (photos the borrower took with the in-app camera)
for doc in client.documents.list(loan_application_id):
    if doc.status == "uploaded" and doc.bytes_url:
        # signed URL, expires; the client refreshes on 401
        binder.write(doc.bytes_url, name=doc.label)

# 3) Receive milestone updates as they fire on the tenant
@client.webhooks.on("loan.milestone.changed")
def on_milestone(evt: MilestoneEvent):
    # dedupe on delivery_id so a retried push is dropped
    if not seen.add(evt.delivery_id):
        return
    pipeline.advance(evt.loan_application_id, evt.milestone)

A Node.js equivalent ships with the same engagement. Both wrap the same surfaces; the choice is whatever the consuming system already runs on.

Authorization and US data-rights status

The basis we lean on is direct: the lender authorizes tenant access for the engagement, or the borrower authorizes the client to read on their behalf, and that authorization is what the integration carries. Consent is logged, scoped per loan_application_id, and revocable — when revocation hits, cached document bytes are dropped and the client stops reading new state for that file.

The CFPB Personal Financial Data Rights rule (12 CFR Part 1033) is where consumer-side data-access rights may eventually land in the US. As finalized in October 2024, it was set to phase in for the largest covered institutions; since stayed, the rule has been enjoined and is back in agency reconsideration through 2026, so it is not the basis any HomeNOW integration runs on today. For Verity Mortgage specifically that means the same posture as the rest of the US mortgage POS ecosystem — direct lender and borrower authorization, NDA where the lender wants one, and minimization defaults that drop anything the consuming system does not need to keep.

Two things we account for on Verity Mortgage builds specifically

Field-mapping across the LOS underneath. The SimpleNexus tenant exposes the 1003 with one schema, but the LOS Verity Mortgage pushes to (Encompass, Calyx, Byte, or Finastra's MortgagebotLOS, depending on the product) may rename a portion of those fields on its leg of the round-trip. We resolve both ends in the client and ship a stable, downstream-facing shape so a consumer is not coupled to whichever LOS happens to be sitting underneath the loan on a given day. SimpleNexus itself describes the bidirectional integration as eliminating manual entry across roughly 32 fields, per its own product page — that figure is approximate and confirmed against the live tenant during the build.

Document binder shape. Documents arrive as camera-captured photos, not as pre-parsed PDFs. We keep the raw image asset reachable for compliance review (auditors want to see what the borrower actually photographed) while also surfacing extracted text for the consuming system to read. A binder that hides one side of that usually gets reworked at audit time, so we surface both from the start.

Screens we sampled

Public store screenshots; clicking opens a larger view. Useful as a sanity check that the surfaces in the table above are the ones the borrower actually sees.

How we mapped this

Pulled the public app description and Play Store metadata (package id com.simplenexus.loans.client.s__18075, confirmed against the live listing), cross-checked against SimpleNexus / nCino product pages describing the borrower app and its LOS round-trip, and read the current CFPB postings on §1033 so the regulatory framing reflects June 2026 state, not the original October 2024 finalization. Specific deep links we opened:

• Play Store listing — HomeNOW by Verity Mortgage
• SimpleNexus / nCino — borrower experience surfaces
• CFPB — Personal Financial Data Rights (Section 1033) status
• Federal Register — §1033 Reconsideration ANPR (Aug 2025)

Engineering notes by OpenFinance Lab, 2026-06-03.

Mortgage apps that show up next to HomeNOW

Apps an integrator is likely to want covered alongside HomeNOW because they sit at the same point in the lender stack. Names are listed as factual ecosystem context, not ranking and not endorsement.

• Blend — Enterprise mortgage POS with verifications and digital closing, sitting in front of large bank and IMB lenders; data shape overlaps the 1003 / verifications / milestone axis HomeNOW exposes.
• Roostify — POS for large depositories and regional lenders, with dynamic task lists per loan product; integrators commonly need both Roostify and SimpleNexus tenants pulled through a single client.
• Floify — Borrower portal with branded application, document upload, e-sign, and real-time status — the same surface set as HomeNOW, different tenant model underneath.
• Maxwell — Digital POS aimed at small and midsize lenders; useful comparison point for shops that may run Maxwell and SimpleNexus side-by-side during a migration.
• BeSmartee — POS that pre-populates the application from third-party data, then routes it into the LOS; consuming systems often want a unified shape across BeSmartee and SimpleNexus tenants.
• Loanzify — Mobile-first POS with branded borrower and realtor apps; directly comparable to HomeNOW for shops choosing between SimpleNexus and a Loanzify-built app.
• Encompass Consumer Connect — Ellie Mae's borrower-facing front end on top of Encompass LOS; relevant when the lender's loan file lives in Encompass and the borrower-app side belongs to a separate tenant.
• Arive — Broker-focused platform combining POS, LOS, and pricing engine; turns up when a downstream system needs a unified borrower-record shape across lender-direct (HomeNOW) and broker-channel (Arive) loans.

Questions we get about HomeNOW integrations

If you build us a client, do we wire it against a sponsoring lender's tenant or the public consumer app?

Against the lender tenant. The consumer-facing HomeNOW app is a thin client on a SimpleNexus tenant owned by Verity Mortgage; the data and the milestone events live tenant-side. We arrange the tenant access with the lender during onboarding and the build runs against their sandbox or a borrower account they authorize for the engagement.

How does the webhook side hold up when a milestone fires while the loan officer is editing the file?

Each push carries a delivery id; the client we ship dedupes on it, so a retried delivery does not advance the pipeline twice. Order is kept per loan_application_id, and on read the client reconciles against the loan record so a late-arriving milestone never overwrites a newer state. This is the part we get paid to think about.

What does the 1003 actually look like when it comes out of HomeNOW?

A nested object — borrower(s), subject property, employment, declarations — plus a milestone log and an attachment list pointing at the binder. Field naming follows the SimpleNexus tenant schema and varies a little when the lender pushes to Encompass versus a non-Ellie Mae LOS underneath; the client normalizes both ends so downstream code sees one shape.

Verity Mortgage is a division of Eustis Mortgage Corp — does that change anything for the integration?

Operationally, no. The HomeNOW app under Verity Mortgage is one of several SimpleNexus tenants Eustis runs (there is a separate HomeNOW by Eustis Mortgage build), and each tenant carries its own credentials and its own loan-officer / realtor seat list. We confirm which tenant the loans live in at kickoff and scope consent and the client to that one.

The artifact at the end is a runnable Python or Node.js client against the borrower-record surfaces above, with the matching webhook handler and tests. Source-code delivery sits at three hundred US dollars and up for a single-app scope, billed only after we hand the code over and you have verified it does what we agreed; the hosted-endpoint route runs per call with nothing paid up front. Cycle is one to two weeks from the kickoff call, either way. Tell us the lender tenant and the surfaces you need and we will scope it.