Reaching the loan data inside First State Mortgage's borrower app

Everything a borrower does in First State Mortgage that matters to an integrator runs through one shared backend: the SimpleNexus platform that nCino now operates. The app is a branded tenant of that platform — its package id, com.simplenexus.loans.client.s__5939 as listed on Google Play, marks it as one client instance among many on the same code. So the data model is well understood even though the brand on the splash screen is local. A borrower fills out an application, photographs pay stubs and bank statements, consents to electronic disclosures, and watches the loan move through stages. Each of those is server state tied to an authenticated identity. That is what an integration reaches.

We map that surface and hand back working code that pulls it under the borrower's authorization. The calculators in the app — affordability, refinance break-even, payment estimates — run locally and hold nothing on a server, so they sit outside the scope of any data integration. Below is the data, the route, what we deliver, and how the engagement runs.

What the app actually holds

These are the surfaces tied to a borrower's account. Granularity is described as the app and platform present it.

Authorized routes to that data

Two routes genuinely fit this app; a third applies only where a borrower wants their file moved out. We name the one we'd recommend at the end.

Protocol analysis of the borrower session

The app authenticates against the SimpleNexus backend and carries a bearer token through its requests — the platform's own developer materials describe an OAuth 2.0 model with token expiration, which lines up with what the client app does. We observe and document the login and token-refresh chain, then the calls that load the application, documents and disclosure status. Reachable: the full authenticated surface above. Effort: moderate, since the model is consistent across SimpleNexus tenants. Durability: good between front-end releases, with a re-check when the app updates. We set up the capture environment and a consenting test account with you during onboarding.

User-consented account access

Where the goal is a borrower pulling their own file, the integration runs inside that borrower's authenticated session with their consent recorded. Reachable: whatever that account can see. Effort: low to moderate. Durability: tracks the borrower's access. This is the cleanest basis in the US, because it rests on the account holder's own right to their data rather than on any platform-level grant. We arrange the consent capture and logging as part of the build.

Native handoff, where present

Documents already flow from the app into the lender's loan origination system. Where a lender wants a structured copy on their own side, we wire to that existing handoff rather than re-deriving it from the session. Narrower than the session route, but durable and low-friction when it covers what you need.

For most teams the user-consented session route is the one to build first: it stands on the borrower's own authorization, covers the application and disclosure data that carry the most value, and does not depend on anything outside the account. The native handoff is worth folding in when the LOS side is already in your control. We size both against your actual goal before committing.

What lands on your side

Tied to the surfaces above, not a generic kit:

• An OpenAPI/Swagger description of the session calls we document — application read, document list, disclosure status, loan milestones.
• A protocol and auth-flow report: the OAuth token acquisition, refresh timing, and the request/response shape for each surface, with the error and re-auth paths spelled out.
• Runnable source for the key endpoints in Python or Node.js — authenticate, fetch a loan, list documents, read disclosure state — that you host.
• Automated tests against a consenting test account so a front-end change that breaks a call shows up as a red test, not a silent gap.
• Interface documentation plus data-retention and consent-logging guidance written for US mortgage data.

A look at the session

Illustrative of the shape, not a published contract — the exact paths and fields are confirmed during the build against a consenting account.

# 1) Exchange borrower credentials for a bearer token (OAuth-style, token expires)
POST /auth/oauth/token
  grant_type=password & username=<borrower> & password=<secret> & tenant=s__5939
-> 200 { "access_token": "...", "expires_in": 3600, "refresh_token": "..." }

# 2) Read the loan file the borrower is authorized to see
GET /loans/{loanId}/application
  Authorization: Bearer <access_token>
-> 200 {
     "loanId": "...", "borrowers": [...],
     "urla": { "income": {...}, "assets": {...}, "property": {...} },
     "milestone": "processing"
   }

# 3) List uploaded documents and disclosure state
GET /loans/{loanId}/documents
GET /loans/{loanId}/disclosures
-> 200 { "disclosures": [ { "type": "LE", "eConsent": true,
                            "signedAt": "2026-05-20T15:04:00Z" } ] }

# On 401, refresh the token before retrying; treat a changed schema as a test failure.
      

Consent and US data law

This is US residential-mortgage data, so the framework is the lender's existing privacy and disclosure obligations under Gramm-Leach-Bliley, layered on the borrower's electronic-consent record that the app already captures for disclosures. The integration we build inherits that posture: access is authorized, every pull is logged, the data set is minimized to what the use case needs, and an NDA covers the work where the lender wants one. Consent scope, expiry and the borrower's ability to revoke are modelled explicitly, so a withdrawn consent stops the sync rather than leaving it running. The CFPB Personal Financial Data Rights rule (12 CFR Part 1033) is the direction consumer-permissioned access may eventually take in the US, but it is not currently in force, so we treat it as a forward-looking signal and build on the borrower's own authorization as the dependable basis today.

Build notes specific to this app

• One tenant on shared rails. First State Mortgage is one branded SimpleNexus instance (tenant s__5939 per its Play listing). We pin the integration to this tenant and branch so loan files from other lenders' apps on the same platform never cross into the data set.
• Disclosure events are push-driven. eConsent and disclosure activity surfaces as state changes signalled by notifications, not a static list. We build the sync around those events, capturing each disclosure with its signature timestamp instead of relying on a periodic full re-pull that could miss a short-lived state.
• Documents leave the device. Scanned files are routed to the LOS rather than stored locally, so we capture them at the upload boundary or through the consented account view, and add a re-validation pass for when the app's front end changes after a platform release.

Where teams use it

• A lender ops team mirroring application and document-checklist state into an internal dashboard so processors see completeness without logging into each borrower app.
• A compliance function pulling the disclosure-and-signature trail into an audit store keyed by loan and timestamp.
• A borrower-permissioned tool that lets a homeowner export their own loan file and document set when they move servicers or advisors.

Cost and cycle

The borrower-data endpoints land as runnable Python or Node you host yourself, from $300, paid only after delivery once the code works against your test account. If you would rather not host anything, call our endpoints instead and pay per call with nothing up front. Either way the cycle is one to two weeks from the point we have a consenting test account, and access and compliance details are arranged with you along the way. Tell us the app and what you want out of its data, and we scope it — start at /contact.html.

Keeping it current

SimpleNexus ships platform updates that can shift the front end and, occasionally, a request shape. The automated tests are the early-warning system: they run against a consenting account and flag a broken call before it reaches your data. When a release moves something, the re-validation pass re-confirms the affected surface and the source is patched — small, scoped maintenance rather than a rebuild.

App screens

Store screenshots, for reference to the surfaces named above. Select to enlarge.

How this was checked

I worked from the app's Play Store listing and description, the SimpleNexus / nCino platform documentation for the borrower app and its disclosure and document-scan flows, and the platform's published developer notes describing its OAuth token model. Checked in May 2026. Primary sources:

• First State Mortgage on Google Play
• SimpleNexus document-scan tool
• SimpleNexus integrated disclosures & eConsent
• nCino / SimpleNexus developer notes (OAuth, token expiration)

OpenBanking Studio integration desk · mapping reviewed May 2026.

Comparable apps

Other mortgage point-of-sale and borrower apps that hold a similar shape of data; a unified integration treats them as variations on the same loan-file model. Listed for context, not ranked.

• Floify — borrower portal centred on document collection and status, with per-loan file state behind a login.
• Blend — application and document-upload flow used by many banks; holds structured 1003-style application data.
• Roostify — digital application and document workflow with milestone tracking per loan.
• Maxwell — point-of-sale and borrower engagement tooling holding application and task state.
• BeSmartee — mortgage POS capturing application, credit and document data through to disclosures.
• Loanzify — branded borrower and Realtor apps with application, credit-pull and status surfaces.
• BNTouch Mortgage — originator CRM and borrower touchpoints holding lead and loan-stage records.
• Arive — broker platform combining POS and LOS, with loan-file and pipeline data.
• RealKey — document-gathering and processing workflow that sits alongside the LOS.

Questions integrators ask

Which screens in the First State Mortgage app actually hold server-side data worth pulling?

The application screens (the 1003/URLA fields), the document-scan uploads, the disclosure and eSign flow, and the per-loan status dashboard all sit on the SimpleNexus backend behind a borrower login. The in-app affordability, refinance and payment calculators run on the device and carry no server state, so we leave them out of an integration.

Does a borrower's loan file live on the phone or on the SimpleNexus backend?

On the backend. Scanned documents are pushed to the lender's loan origination system rather than kept on the device, and the application data and disclosure status are server-held. That means the integration targets the authenticated session and its traffic, not local files.

What is the legal basis for reaching a borrower's loan data in the US?

The dependable basis is the borrower's own authorization to their account, handled under Gramm-Leach-Bliley privacy obligations and the lender's existing disclosure framework. The CFPB Personal Financial Data Rights rule (12 CFR Part 1033) is where consumer-permissioned access may eventually be standardized, but it is not in force, so we do not build on it as current law.

How would disclosure and eSign events get captured without missing one?

eConsent and disclosure activity in this app arrives as push-triggered state changes rather than a static list. We design the sync around those events so a freshly issued Loan Estimate or signed Closing Disclosure is captured with its timestamp, instead of relying on a full re-pull that could miss a short-lived state.