Every loan that moves through First State Mortgage carries a live pipeline state — application fields a borrower typed in, a current milestone, and the documents that borrower has photographed and uploaded. The integration question is almost always the same: how does an outside system stay in step with that state as it changes, without re-reading everything each time? That is a delta-sync problem, and it is the shape this brief is built around.
First State Mortgage, LLC is a subsidiary of First State Bank (Member FDIC, NMLS# 172606, per the app's own in-listing disclaimer). The mobile app itself sits on nCino's SimpleNexus mortgage stack — the package namespace com.simplenexus.loans.client… on its Play Store listing gives that away. That backend matters for the work, because it sets what the loan record looks like and how its stages are named.
What sits behind a signed-in borrower
The app is a front end onto a loan file. Here is what that file exposes to a signed-in borrower or loan officer, where each piece originates, and what an integrator usually does with it.
| Data domain | Where it comes from in the app | Granularity | What you would do with it |
|---|---|---|---|
| Loan application | The apply flow the borrower fills in | Per loan, field level | Seed or refresh a CRM / LOS record without re-keying |
| Milestone / stage | Pipeline transitions shown to borrower and agent | Per loan, per stage, with change timestamps | Drive status dashboards and next-step notifications |
| Uploaded documents | The photo-scan upload feature | Per document: type, status, owning loan, binary | Route receipts to an underwriting queue or doc store |
| Loan-officer directory | In-app LO contact and office finder | Per officer, includes NMLS identifier | Populate a referral or agent CRM |
| Calculator scenarios | Affordability, refinance, loan-comparison tools | Per session, inputs and computed result | Capture lead intent; note these compute on-device |
| Participant records | Borrower, agent, and officer accounts | Per user, with create / update / delete events | Keep external identity and ownership in step |
One honesty note: the calculators run locally. Their output is a what-if, not a stored balance, so a sync captures the inputs and the scenario the user generated — useful as a lead signal, not as a financial record.
Routes we would take to that data
Three routes genuinely apply to an app like this. They are not mutually exclusive; we usually build one and keep the others in reserve.
Authorized interface integration
We analyze the traffic between the First State Mortgage client and its nCino backend under the lender's or borrower's authorization, then rebuild the loan-state and document calls as a clean, normalized client. This is durable and does not wait on anyone provisioning a feed. Effort is moderate; the bulk of it is mapping milestone names and the document model, not the transport.
Borrower-consented read
Where the integration serves the borrower directly — a personal finance tool, a buyer's agent dashboard — the borrower authorizes a read of their own loan file. Scope is narrow and revocable, which is exactly what a consent-first design wants. Lighter to stand up; bounded to one consenting user at a time.
Lender-side export channel
Many lenders already pipe milestones and documents from this platform into an LOS such as Encompass, Calyx Point, or MortgagebotLOS. Where that authorized feed exists, we tap it rather than the mobile interface — less reverse mapping, at the cost of depending on the lender's own pipe.
For most teams the first route is what we would build on: it gives a stable client you control, and the consented-read and lender-export routes slot in wherever they are already available. We arrange whichever access a route needs with you during onboarding — a consenting account or a lender sandbox — so the build runs against something real from day one.
A delta poll over milestone state
The core loop is small. It keeps a cursor, asks only for loans that moved since that cursor, and commits the cursor after the page is written — so a crash resumes instead of replaying from zero. Field names below are illustrative; the exact ones are pinned during the build, not lifted from a spec.
# First State Mortgage — authorized delta sync of loan + document state
# Auth: borrower/lender-scoped session token arranged during onboarding (bearer)
cursor = store.get("fsm:cursor") # opaque high-water mark, may be null on first run
page = client.get("/loans", params={
"changed_since": cursor, # delta window, not a full pipeline scan
"include": "milestone,documents",
"limit": 100,
})
for loan in page["loans"]:
upsert_loan(loan["loan_ref"], {
"stage": loan["milestone"]["label"], # e.g. "Conditional Approval"
"stage_at": loan["milestone"]["changed_at"],
"borrower_ref": loan["primary_borrower"]["ref"],
"officer_nmls": loan["loan_officer"]["nmls_id"],
})
for doc in loan["documents"]:
if doc["status"] == "received":
enqueue_doc(loan["loan_ref"], doc["doc_id"], doc["type"]) # metadata only here
store.set("fsm:cursor", page["next_cursor"]) # advance only after the page commits
# 429 / token expiry: back off, re-establish the session, resume from the same cursor
Document binaries are deliberately not pulled in this loop. The poll moves receipt metadata; the paystub or bank statement itself is fetched on demand, when a downstream step actually needs it.
Normalizing the loan record
Whatever the lender's LOS calls a stage, downstream code should see one vocabulary. We deliver the mapping plus a normalized record like this:
{
"loan_ref": "fsm_",
"stage": "underwriting",
"stage_history": [
{ "stage": "application", "at": "2026-05-30T14:02:00Z" },
{ "stage": "processing", "at": "2026-06-02T09:11:00Z" }
],
"borrower": { "ref": "", "role": "primary" },
"loan_officer": { "nmls_id": "", "name": "" },
"documents": [
{ "doc_id": "", "type": "paystub", "status": "received" }
],
"source": "first-state-mortgage"
}
What ships at the end
The headline is runnable code, not a slide deck. You get:
- A working client in Python and Node.js for the delta-sync loop above — cursor handling, idempotent upserts, and backoff included.
- A poller/worker runner that turns milestone transitions and document-received events into events on your side, with a stable normalized payload.
- An automated test suite built on recorded fixtures, so a change in the upstream shape shows up as a failing assertion rather than a quiet data drift.
- The normalized loan schema and the stage-name mapping for your lender's configuration.
- An OpenAPI / Swagger description of the mapped surface, and a short protocol and auth-flow report covering the session and token chain.
- Interface documentation and data-retention guidance you can hand to whoever runs it next.
Where it plugs in
- A real-estate brokerage CRM stays current with each buyer's milestone, so an agent gets nudged the moment a loan hits conditional approval.
- A lender BI warehouse ingests pipeline state on a delta cadence — intraday for active files, a fuller pass overnight.
- A document-received event routes an uploaded paystub straight into the underwriting queue, no manual file import.
- Calculator completions flow to marketing as a lead signal, separate from the loan record itself.
Authorization, and how the data may move
This is US mortgage data, and the dependable basis for moving it is the borrower's or lender's own authorization — captured, scoped, logged, and revocable. We operate authorized, documented, or user-consented access only, with NDAs where a lender requires them and data minimization built into the sync rather than bolted on.
The CFPB's Personal Financial Data Rights rule (§1033) is where consumer data access may eventually be codified, but it is not current law: it was enjoined in late 2025 and is back in agency reconsideration, with mortgage-origination data not squarely inside the version that was published. We treat it as a forward-looking signal worth designing toward, never as settled ground the integration stands on today. GLBA privacy posture and the lender's own consent records are the practical frame.
Things we account for in the build
Two wrinkles are specific enough to this app that they shape the design from the start.
Milestone names are not universal. What a borrower sees as a stage reflects the loan origination system the lender runs behind First State Mortgage — Encompass, Calyx Point, and MortgagebotLOS each label the pipeline differently. We build the stage-name mapping with you so a "Conditional Approval" in one configuration lines up with its equivalent everywhere downstream, and we keep the mapping versioned so a lender re-config does not silently shift meanings.
Documents are PII-heavy. The upload feature carries paystubs, bank statements, and IDs. We design the sync to move metadata by default and fetch a binary only on demand, with retention windows and minimization rules set with you during onboarding. Session tokens are scoped and time-limited; the client re-establishes its session inside the consent window so a long-running poll keeps reading without manual intervention.
Screens from the app
Store screenshots, useful for confirming which surfaces the front end actually presents. Tap to enlarge.
Other mortgage apps in the same orbit
If you are integrating one borrower app you are usually integrating several, and a normalized loan schema is what lets them sit side by side. Comparable platforms, named neutrally:
- Blend — digital lending suite holding application, milestone, and verification data for banks and credit unions.
- Floify — borrower point-of-sale with document collection and loan-status tracking.
- Maxwell — origination platform for local lenders, with point-of-sale and fulfillment data.
- Roostify — home-lending workflow holding application and document state across the loan journey.
- BeSmartee — mortgage POS covering application intake and conditional approvals.
- Cloudvirga — digital mortgage point-of-sale with pipeline and milestone data.
- MortgageHippo — borrower-facing origination flow with status and document records.
- BNTouch Mortgage CRM — loan-officer CRM holding borrower contacts and pipeline activity.
- LenderHomePage — lender web and POS holding lead and application data.
- Mortgage Coach — loan-comparison tool whose scenarios sit alongside live loan data.
Questions integrators ask about this one
How soon after a milestone changes in the app can an outside system see it?
It depends on the poll cadence we set, but the design is built for near-real-time: each run asks only for loans whose state moved since the last cursor, so a stage change like conditional approval propagates on the next cycle rather than waiting for a full re-scan. Cadence is a config value, from a few seconds to nightly.
Which parts of the loan file can a sync actually carry?
Application fields the borrower enters, the current milestone and its timestamp, document-receipt metadata, and loan-officer details including the NMLS number. The affordability and refinance calculators run on the device, so what is capturable there is the inputs and the resulting scenario, not a server-side record.
First State Mortgage runs on nCino's SimpleNexus platform — does that shape the work?
Yes. The package namespace places it on that mortgage stack, and the milestone vocabulary a borrower sees reflects whichever loan origination system the lender runs behind it — Encompass, Calyx Point, or MortgagebotLOS, for instance. We map those stage names to one normalized set so downstream code does not care which configuration produced them.
How do you stop borrower PII from spreading when documents sync?
The sync moves document metadata by default — type, status, which loan it belongs to — and fetches the actual paystub or bank statement only when your workflow needs the binary. Retention and minimization rules are set with you, and access is logged. Nothing is copied wholesale just because it exists.
Engagement and next step
Source for the First State Mortgage sync lands as runnable Python and Node — from $300, billed only after it is delivered and you have run it against a real loan file. Prefer not to host anything? Call our endpoints instead and pay per call, with nothing up front. Either path runs on a one-to-two-week cycle, and all you need to bring is the app name and what you want out of its loan data — access and compliance get arranged with you along the way. Tell us what you are building and we will scope it.
Start a First State Mortgage integration
What was checked, and where it came from
Reviewed over the first week of June 2026: the app's Play Store listing and its in-listing disclaimer, nCino / SimpleNexus platform material on real-time data syncing and milestone updates, and the current federal status of consumer data-rights rulemaking. Specifics here are drawn from those; the field names in the code are pinned during the build, not copied from a public document.
- First State Mortgage on Google Play — listing, description, package namespace
- SimpleNexus real-time data-transfer / webhooks announcement (NMP)
- SimpleNexus rebrands to nCino Mortgage Suite
- CFPB Personal Financial Data Rights Reconsideration (Federal Register)
OpenFinance Lab · interface mapping, June 2026
App profile — First State Mortgage, in brief
First State Mortgage is the borrower and Realtor app of First State Mortgage, LLC, a subsidiary of First State Bank (Member FDIC), distributed on Android and iOS. It supports the home-search and home-loan process: comparing lending scenarios across loan programs, estimating refinance savings, gauging affordability against income and expenses, scanning and uploading required documents, and reaching an FSM loan officer or office directly. Per its Play listing the package is com.simplenexus.loans.client.s__5939, placing it on nCino's SimpleNexus mortgage platform. The listing carries NMLS# 172606 and the standard mortgage-qualification disclaimer. This page is an independent technical write-up for integration purposes and reflects what was public when it was checked.