First State Mortgage app icon

Mortgage pipeline data, kept in sync

Syncing the First State Mortgage loan file into your own systems

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 domainWhere it comes from in the appGranularityWhat you would do with it
Loan applicationThe apply flow the borrower fills inPer loan, field levelSeed or refresh a CRM / LOS record without re-keying
Milestone / stagePipeline transitions shown to borrower and agentPer loan, per stage, with change timestampsDrive status dashboards and next-step notifications
Uploaded documentsThe photo-scan upload featurePer document: type, status, owning loan, binaryRoute receipts to an underwriting queue or doc store
Loan-officer directoryIn-app LO contact and office finderPer officer, includes NMLS identifierPopulate a referral or agent CRM
Calculator scenariosAffordability, refinance, loan-comparison toolsPer session, inputs and computed resultCapture lead intent; note these compute on-device
Participant recordsBorrower, agent, and officer accountsPer user, with create / update / delete eventsKeep 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.

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.

First State Mortgage screenshot 1 First State Mortgage screenshot 2 First State Mortgage screenshot 3 First State Mortgage screenshot 4 First State Mortgage screenshot 5
First State Mortgage screenshot 1 enlarged
First State Mortgage screenshot 2 enlarged
First State Mortgage screenshot 3 enlarged
First State Mortgage screenshot 4 enlarged
First State Mortgage screenshot 5 enlarged

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.

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.

Last checked 2026-06-08