Reaching the loan file inside Northern Mortgage's WelcomeHome app

Northern Mortgage Services (NMLS 130662, as its own app listing states) ships WelcomeHome as a tenant build of the SimpleNexus mortgage client — the package id reads com.simplenexus.loans.client.s__70857 on the Play Store, where the trailing slug pins it to one lender's instance. SimpleNexus is the point-of-sale platform nCino bought in 2022 and folded into its Mortgage Suite, so the data a borrower sees in WelcomeHome does not live on the phone. It lives on that hosted backend, keyed to Northern Mortgage's tenant. That is the thing worth integrating, and it is the thing this brief is about.

The bottom line is short. Strip out the calculators, which run on the handset and hold nothing, and what remains is a borrower's authenticated loan file plus the documents they upload through it. We reach that by mapping the WelcomeHome client's own traffic under Northern Mortgage's authorization, and hand back runnable code that returns those records in a clean shape.

What sits behind a borrower login

The app's marketing leans on its calculators, but those are the least interesting part for an integrator. The server-side state is where the value is. Mapped against what the listing describes and how a SimpleNexus client behaves, the surfaces break down like this.

Three authorized ways to the data

All three run under the borrower's or the lender's authorization. None of them touch authentication they aren't entitled to.

Interface integration of the mobile client

We capture the HTTPS exchange between the WelcomeHome app and its SimpleNexus backend with a consenting account, document the auth handshake and the endpoints that serve the loan file, documents and milestones, then reimplement them as a tidy client library. This returns the structured record, not a screen scrape. Effort is moderate; durability is tied to the app version, so it gets re-captured when the client ships an update.

User-consented credential access

With a borrower's explicit consent we authenticate as that user and read their own file, documents and conditions. This is the right shape for a third party syncing one borrower at a time. It stays stable as long as the consent and credentials hold.

Native document retrieval

A lighter option: pull the disclosures and PDFs a borrower can already download from their file. It is the least to build and the least to break, but it returns paper, not fields.

For a lender that wants its own pipeline data back, the first route against a Northern Mortgage test tenant is what we would build — it hands back the application fields and conditions as records, where native retrieval only fetches the documents. The consented-credential route is the one we reach for when the client is a referral or settlement partner working borrower by borrower.

Where lenders actually put this

• A non-integrated CRM that needs WelcomeHome application data flowing in so marketing and follow-up fire automatically.
• A reporting layer that mirrors loan milestone events for branch managers without a manual export.
• A document store that ingests scanned condition items the moment a borrower uploads them.
• A referral-partner portal where a real-estate agent sees only their borrower's status, with that borrower's consent.

What lands in your repo

Concrete artifacts, scoped to WelcomeHome's real surfaces:

• An OpenAPI/Swagger spec covering the mapped endpoints — login, loan-file read, document list and fetch, conditions, milestone events.
• A protocol and auth-flow report: the token exchange, header set and refresh behavior observed during the build.
• Runnable source for the key calls in Python and Node.js, with the loan file normalized to plain JSON.
• Automated tests against a consenting account or the test tenant, so a client update that moves a field is caught.
• Interface documentation and a short data-retention note keyed to GLBA expectations.

On the wire — a token and a milestone pull

Illustrative, and confirmed against the live client during a build. The SimpleNexus platform authenticates with OAuth 2.0 bearer tokens that expire, so a working client refreshes and retries.

# 1. Exchange the borrower session for a bearer token (OAuth 2.0, observed)
POST /tenant/s__70857/oauth/token
  grant_type=password
  username=<borrower>  password=<consented>
-> 200 { "access_token": "...", "expires_in": 3600, "refresh_token": "..." }

# 2. Read the loan file + milestone status for the authenticated borrower
GET /loans/{loanId}/summary
  Authorization: Bearer <access_token>
-> 200 {
     "loanId": "...", "program": "FHA_203B",
     "milestone": "PROCESSING",
     "conditions": [ { "id": "...", "label": "VOE", "status": "OPEN" } ],
     "documents": [ { "docId": "...", "type": "PAYSTUB", "uploaded": "..." } ]
   }

# Error handling: 401 -> refresh with refresh_token, retry once;
# persistent 401/403 -> consent or token scope problem, surface it, never retry blindly.
      

Field names above are placeholders until they are pinned during the engagement. The pattern — short-lived bearer token, refresh, per-loan read — is the part that holds.

Consent, GLBA, and where §1033 sits

For Northern Mortgage borrower data the dependable basis is the borrower's own authorization. We work under the Gramm-Leach-Bliley Act's safeguards expectations for non-public personal information: access scoped to what the project needs, requests logged, consent recorded, and an NDA where the engagement calls for one. Consent has a scope and can be revoked, and we design the integration so a withdrawn consent stops the sync rather than failing silently.

The CFPB's Personal Financial Data Rights rule under §1033 is the forward-looking piece, not today's footing. A federal court in the Eastern District of Kentucky enjoined the CFPB from enforcing it on October 29, 2025, and the Bureau reopened it for reconsideration, with the comment window closing in October 2025. So for a mortgage servicer like Northern Mortgage, §1033 is where consumer data-access rules may land later — we watch it, we don't build on it. The borrower's consent is what the integration rides now.

What we account for on a SimpleNexus build

Three things shape how this particular integration is engineered.

• One tenant, shared codebase. WelcomeHome is the s__70857 slice of a multi-tenant SimpleNexus client. We pin the integration to Northern Mortgage's tenant so branding routing, endpoints and any tenant-specific field set resolve to the right instance rather than a sibling lender's.
• The scan-and-upload pipeline. Documents enter as phone-camera images tagged by type. We map the upload endpoint and the doc-type taxonomy so retrieved files carry the correct loan-condition labels instead of a flat blob list.
• Asynchronous milestones. Loan status arrives from the lender's system of record on a lag. We design the polling or event handling around that delay so a mirrored status is not stale, and we re-capture the auth flow as part of maintenance whenever the mobile client updates.

Access to a test login or a Northern Mortgage environment is arranged with you during onboarding — it is a step we handle, not something you supply before we begin.

The app, screen by screen

Store screenshots, for reference while reading the surfaces above.

Other mortgage portals in the same orbit

Same job, different vendors. If you are unifying borrower data across more than one of these, the mapping work rhymes.

• Floify — borrower point-of-sale and document portal; holds applications, conditions and a lender-borrower message thread.
• Blend — white-labeled application flow used by larger banks; deep loan-application and verification data.
• Maxwell — POS for independent mortgage banks with built-in VOI/VOA and credit-pull data.
• BeSmartee — origination POS holding application, pricing and document state.
• Loanzify — borrower-facing app with calculators plus application and status data.
• BNTouch Mortgage CRM — CRM side, holding contact, pipeline and campaign records tied to loans.
• Jungo — Salesforce-based mortgage CRM with contact and loan-relationship data.
• Encompass — the ICE loan-origination system many of these portals feed; the system-of-record loan file.

What we checked

Reviewed on 2026-05-31. We read the WelcomeHome Play Store listing and its package id, traced the SimpleNexus-to-nCino lineage, and confirmed the platform's OAuth 2.0 posture and its lender-side data-sync capability, plus the current §1033 enforcement status, against the sources below.

• WelcomeHome on Google Play (package id, listing)
• nCino — SimpleNexus rebrands to nCino Mortgage Suite
• SimpleNexus — real-time data transfers and webhooks
• ABA Banking Journal — court halts §1033 enforcement (Oct 2025)

OpenBanking Studio · integration desk mapping, May 2026.

Questions integrators ask us about WelcomeHome

Which backend actually holds a WelcomeHome borrower's loan data?

The package id com.simplenexus.loans.client.s__70857 marks WelcomeHome as a tenant build of the SimpleNexus mortgage client, the platform nCino acquired in 2022 and rebranded as its Mortgage Suite. The borrower's application, conditions and status live on that hosted backend keyed to Northern Mortgage's tenant, not on the phone.

Can you reach the document uploads and milestone status, or only the in-app calculators?

The calculators run locally and are not worth integrating. The value is the authenticated side: the loan file, the documents a borrower scans and uploads, the condition list, and the milestone events the lender's system of record pushes back. Those are what we map and return as structured records.

Is borrower consent enough to do this, or does GLBA get in the way?

The borrower's own authorization is the dependable basis, and we operate under GLBA's safeguards expectations: data minimized to what the project needs, access logged, and an NDA where it applies. We work from a consenting account or an environment Northern Mortgage provides; we do not bypass authentication.

How does access to a WelcomeHome test account get arranged?

We sort that out with you during onboarding. The build runs against a consenting borrower login or a Northern Mortgage test tenant, whichever fits the engagement; arranging it is our step, not a hoop you clear before we start.

Working together

Tell us the app name and what you want out of its data — that's the whole brief from your side. A WelcomeHome integration ships in one to two weeks. Source-code delivery starts at $300 — you get the runnable client, spec, tests and docs, and pay only after delivery once you're satisfied. Prefer not to host it yourself? Call our endpoints instead and pay per call, nothing upfront. The access, sandbox and compliance pieces are arranged with you as part of the work. Start the conversation on the contact page and we'll scope it.