Reaching the loan file behind Southwest Funding's app

Every borrower who signs into the SWF Mobile App lands on a loan file that SimpleNexus builds and serves — not a static brochure, but a live record with their 1003 application fields, the documents they scanned in, and a milestone timeline that moves as underwriting moves. That is the part worth integrating. The marketing copy calls the app a way to simplify home buying; under the hood it is a thin mobile client talking to a well-structured backend, and that backend is where an integrator's interest sits.

Southwest Funding says it has originated home loans since 1993 out of Dallas. The app itself — package com.simplenexus.loans.client.s__117433 per its Play Store listing — is one lender-branded instance of the shared SimpleNexus client, which matters more than it first looks: the data shapes are consistent across these builds, so a client we write for the SWF tenant draws on patterns we can reason about up front.

What the borrower file actually holds

Mapping the app surface by surface, here is where the data lives and what an integrator does with each piece.

The two domains that carry the most weight are the application fields and the documents. A status feed is nice; a clean pull of the structured 1003 data plus the document set is what lets a downstream system actually do work.

Authorized ways into the loan file

Three routes apply to this app. None of them depends on the others, and which one fits is mostly a question of who is asking and how often.

Protocol analysis of the borrower session

We run the app against a consenting test account and map the calls it makes — the token exchange, the JSON loan payloads, the document endpoints. The output is a reconstructed interface for status, application fields and documents that a small client can call repeatedly. Effort is moderate; durability is medium, since a front-end refresh can shift things, which is exactly what the maintenance pass below is for.

User-consented session access

A borrower authorizes us to act on their behalf, and we drive their authenticated session to retrieve their own file and documents. This is the right fit for one-off pulls or per-borrower sync where the data subject is in the loop and granting access directly.

Native export as a fallback

The app's own document download and share behaviour gives a manual export path. For low volumes it can be scripted, and it is a useful backstop when a full programmatic feed is more than the job needs.

For a reusable feed here, the protocol-analysis route is the one I would build first: the SWF session returns structured JSON, so a mapped client stays small, and the consented-access route then reuses that same client for live per-borrower pulls. Access — a sponsor sandbox or a consenting account — is arranged with you during onboarding; it is part of how we start, not something to line up beforehand.

A status pull, sketched

Shapes below are illustrative and were confirmed during the build against a consenting test account — they are not copied from any published SWF or SimpleNexus contract.

# 1. Authenticate. SimpleNexus enforces MFA, which we build into the flow.
POST /mobile/auth/token
  { "username": "<borrower>", "password": "<secret>", "device_id": "<uuid>" }
-> 200 { "access_token": "...", "expires_in": 3600, "mfa_required": true }

# 2. After the MFA challenge clears, read the loan file.
GET /mobile/loans/{loanId}/status
  Authorization: Bearer <access_token>
-> 200 {
     "loanId": "...",
     "milestone": "Conditional Approval",
     "updatedAt": "2026-05-20T14:02:00Z",
     "borrower": { "name": "...", "loanOfficer": "..." },
     "documents": [ { "id": "...", "type": "W-2", "status": "received" } ]
   }

# Token refresh is wired in so a long document sync does not drop mid-run,
# and 401s are caught to re-auth rather than fail the batch.
      

What lands in your repository

The deliverable is working code and the documents around it, scoped to this app's surfaces:

• An OpenAPI/Swagger spec for the reconstructed loan endpoints — auth, status, application fields, documents.
• A protocol and auth-flow report covering the token exchange, the MFA step and refresh handling as they behave on the SWF tenant.
• Runnable source in Python or Node.js for the key paths: log in, pull a loan file, list and fetch documents.
• Automated tests that exercise those paths against a consenting account.
• Interface documentation plus data-retention and minimization guidance written for borrower financial data.

Borrower consent and the US data-rights picture

This is US consumer-finance data, so the operative rules are GLBA Regulation P, which governs how nonpublic personal information is handled and shared, and the FTC Safeguards Rule, which sets the security floor — multi-factor authentication and encryption among them. Our builds inherit those: access is authorized and logged, data is minimized to what the integration needs, and an NDA covers the work where the client wants one.

The basis we rely on is the borrower's own documented authorization, or the lender's where it operates the tenant for its own records. The CFPB's Section 1033 Personal Financial Data Rights rule — the would-be US open-banking framework — is not the thing to lean on today: it was enjoined in late 2024 and is back under the agency's reconsideration, so where it lands for mortgage data is unsettled. We treat it as the direction the rules may take, not current obligation, and design the consent record so it holds up on the basis that actually applies now.

Engineering around the SimpleNexus tenant

Two things about this specific app shape how we build:

Because the SWF app is one tenant of a shared SimpleNexus codebase, the endpoint shapes are common but the configuration is not — field labels and which loan programs surface are set per lender. We map against the Southwest Funding tenant directly rather than assuming a generic schema, so the client matches what SWF borrowers actually see. And because SimpleNexus ships front-end updates on its own cadence, we account for that with a re-validation pass in maintenance: a quick check that the mapped calls still line up after a platform release, so a quiet change does not silently break a running sync.

A third detail worth calling out: documents arrive as scanned images and PDFs with metadata attached, so we handle the file-plus-metadata pairing and chunk large uploads rather than assuming small payloads. None of this is a precondition on your side — it is the part of the job we own.

Inside the SWF app

Store screenshots, for reference on what the borrower-facing surfaces look like. Select to enlarge.

What I checked

I read the app's Play Store listing and description for its feature set and package id, confirmed the SimpleNexus / nCino platform underneath it, and reviewed the current US data-rights position — GLBA guidance plus the live status of the CFPB Section 1033 reconsideration — before writing the route and consent sections. Sources opened:

• Southwest Funding on Google Play
• SimpleNexus (nCino) digital mortgage platform
• CFPB Personal Financial Data Rights Reconsideration
• FTC guidance on the GLBA Privacy Rule

Mapping reviewed 2026-05-31 by the OpenBanking Studio integration desk.

Other mortgage point-of-sale apps in the same orbit

Apps that hold a similar shape of borrower data, useful context if you're standardizing across more than one lender's stack:

• Blend — a borrower point-of-sale used by many banks and lenders, holding application data and document uploads behind a consumer login.
• Floify — a mortgage POS centered on the document portal, with status and conditions tracked per loan.
• Maxwell — a digital mortgage platform for local lenders, carrying application and pipeline data much like SimpleNexus.
• nCino Mortgage Suite — the broader product family SimpleNexus now sits inside, spanning origination data end to end.
• Rocket Mortgage — a direct-lender app holding the full application, approval and servicing record for its own borrowers.
• Better Mortgage — an app-first lender whose borrower file covers application through closing.
• loanDepot mello — a consumer portal and mobile POS holding application and loan-status data.
• BeSmartee — a mortgage POS with the application, document and milestone surfaces lenders embed.
• Roostify — a borrower-facing origination platform with comparable loan-file data.

Each is its own backend; a unified integration normalizes their loan-file data into one shape so a downstream system doesn't care which lender's app it came from.

Questions SWF integrators ask

Is the SWF app running the same backend as other SimpleNexus lender apps?

Yes. Southwest Funding's app is one lender-branded build of the shared SimpleNexus (now nCino) mortgage client — the package id s__117433 per its Play Store listing marks the tenant. Endpoint shapes are common across these builds, but field labels and which loan programs appear are configured per tenant, so we map against the SWF tenant specifically rather than assuming a generic schema.

Can you retrieve the documents a borrower scanned in, not just loan status?

Yes. The app's document scan-and-upload surface is one of the richer data sources — each file carries metadata like document type and received state. We reconstruct both the file retrieval and the metadata pairing so an integration can pull a borrower's W-2s, pay stubs and disclosures alongside the milestone timeline.

What gives us the legal basis to pull a borrower's SWF data right now?

The borrower's own authorization. US open-banking rulemaking under CFPB Section 1033 is enjoined and back in reconsideration, so it is not the basis to rely on today. We build on documented consent from the account holder, or from the lender operating the tenant for its own records, with GLBA Regulation P and the FTC Safeguards Rule shaping how the data is secured and retained.

We run the Southwest Funding tenant ourselves — do pulls have to go through the borrower app?

No. When you operate the tenant the loan records are your own data, and access is arranged through your existing platform entitlements during onboarding rather than by driving the borrower session. Tell us which records and events you need and we build against that.

Most SWF builds I scope settle inside a one-to-two-week cycle, the reconstructed-interface route taking the bulk of it. Source-code delivery starts at $300, billed only after you have the runnable client and tests in hand and are satisfied with them; the alternative is our hosted endpoints, billed per call with nothing upfront. Send the app name and what you want out of its loan data through our contact page and we'll come back with a scoped plan.