Getting borrower loan data out of the Cambria Mortgage app

The package ID on this build, com.simplenexus.loans.client.s__56949 per its Play listing, names what the app actually is: a lender-branded instance of SimpleNexus (now part of nCino) running for Cambria Mortgage. Cambria is a Minnesota lender, NMLS 322798 as stated in the app's own listing, licensed across CO, FL, IA, MN, ND, SD, TX and WI. That matters for integration because the borrower screens — apply, upload, track, compare — are not custom Cambria code. They are the Nexus Origination point-of-sale surface, so the data shapes are well understood and shared across many lenders running the same platform.

Bottom line: this is a rich authenticated portal, and because it is a known platform shape rather than a one-off app, the route is predictable. We map the borrower (and, where authorized, the loan-officer) surface, normalize it, and hand back a runnable integration. The route we would actually take is described below — protocol analysis of the app's own traffic is the backbone, with the lender-side platform sync layered in when Cambria authorizes it.

Data it carries

Everything here originates server-side and is keyed to an authenticated borrower or loan-officer session. The display labels are Cambria's; the objects underneath are SimpleNexus's.

Routes

Three apply here. They are not mutually exclusive and most builds use the first plus one other.

Protocol analysis of the borrower app's traffic

The widest coverage. Whatever the borrower app renders — loan record, milestone, needs-list, scenario output — is reachable by observing and reimplementing the calls the app makes to the SimpleNexus-hosted backend. Effort is moderate because the platform is consistent across lenders, so prior knowledge of the Nexus Origination shape carries over. Durability is good while the app shell is stable; front-end revisions are handled in maintenance. We arrange the capture against a consenting account or a Cambria-authorized test tenant during onboarding.

User-consented credential access

Narrower and per-borrower: a borrower authorizes us to act on their session and we pull only their loan, documents and milestones. This fits single-borrower products — a financial app importing one user's mortgage status — and keeps the data footprint minimal.

Lender-side platform sync

Cambria's tenant runs on SimpleNexus/nCino, which exposes OAuth 2.0 endpoints with token expiration plus webhooks, per nCino's developer portal. With Cambria's authorization this gives organization-scale, event-driven data. The published objects roll out in batches and currently center on organization, user and milestone management, so we cover any loan- or document-level gaps through the first route. The recommendation in practice: stand the build on protocol analysis for full coverage, then add the platform sync where Cambria signs off on tenant access for the org-wide, push-driven pieces.

GLBA frame

The borrower data in this app is nonpublic personal information under the Gramm-Leach-Bliley Act: Social Security numbers, income, account balances and loan terms collected in the application flow. The FTC Safeguards Rule governs how a mortgage entity stores and transmits it, and Regulation P governs sharing and the consumer opt-out. There is no open-banking aggregation scheme that covers US mortgage origination data the way one covers deposit accounts, so the lawful basis here is concrete and narrow: the consenting borrower, or Cambria's own authorization for tenant-scoped access. We hold consent or authorization records, minimize what we pull to the fields the use case names, and set retention to match. NDA where the engagement needs one. This stays specific to Cambria as the licensed lender and SimpleNexus as the processor — it is not a general data-rights commentary.

Deliverables

What you receive is tied to the surfaces above, not a generic kit:

• An OpenAPI/Swagger specification covering the borrower session, loan and milestone reads, and the document needs-list.
• A protocol and auth-flow report: the OAuth-style token grant, short-lived bearer token, silent refresh, and the loan/document call chain as observed during the build.
• Runnable source for the key endpoints in Python and Node.js — login, loan list, milestone fetch, needs-list reconciliation.
• Automated tests against those calls, including token-refresh and empty-pipeline cases.
• Interface documentation mapping each SimpleNexus object to the Cambria display label.
• Compliance and data-retention guidance written for NPI handling under the Safeguards Rule.

On the wire

Illustrative shape of the borrower session and a status pull. Exact paths are confirmed during the build, not asserted here.

# 1. Borrower session against the SimpleNexus-hosted backend
POST /oauth2/token
  grant_type=password
  username=<borrower email>
  password=<borrower secret>
  client_id=<mobile client, captured from the app build>
-> 200 { "access_token":"...", "token_type":"Bearer", "expires_in":3600 }

# 2. Loans tied to that borrower
GET /api/v1/borrower/loans
  Authorization: Bearer <access_token>
-> 200 [ { "loanId":"...", "milestone":"Processing",
           "rateLockExpires":"2026-06-01", "docsOutstanding":2 } ]

# 3. Outstanding document checklist (drives the upload screen)
GET /api/v1/loans/<loanId>/needs-list
  Authorization: Bearer <access_token>
-> 200 [ { "docType":"PAYSTUB",        "status":"REQUESTED" },
         { "docType":"BANK_STATEMENT", "status":"RECEIVED"  } ]

# Token TTL is short and the app refreshes silently; the integration
# mirrors that refresh so a long sync does not drop mid-run.
# 401 -> re-grant; 409 on needs-list -> re-read, the LOS sync moved.
      

Build notes

Two things shape this build specifically, and we handle both:

It is a shared white-label surface. The same Nexus Origination backend serves many lenders, so we pin the integration to Cambria's tenant and branch scoping — another lender's loans never enter the result set, even though the API shape is common. Tenant isolation is part of the delivered code, not an afterthought.

Milestones come from an LOS, not from the app. The progress screen mirrors whatever loan origination system Cambria runs, so the milestone vocabulary originates there and can lag the display by a sync cycle. We map to the platform milestone objects rather than the on-screen wording, design the sync around that lag, and when the SimpleNexus app shell updates, the maintenance step re-checks the captured calls before the next run so a front-end change does not silently corrupt a pull. Access — a consenting account or a Cambria-authorized test tenant — is set up with you during onboarding.

Where it goes

• A servicing or CRM platform importing live Cambria loan milestones to drive borrower communications and closing-date forecasting.
• A document-management tool reconciling the needs-list against what has actually been collected, flagging stalled conditions.
• A personal-finance app pulling one consenting borrower's mortgage status and rate-lock expiry into a wider money view.
• A referral or co-marketing system reading loan-officer and Realtor contact links to route borrowers correctly.

Staying current

Loan state moves daily near closing, so freshness is part of the design, not a nice-to-have. The sync polls on a cadence tuned to milestone velocity and subscribes to platform webhooks where the lender-side route is authorized, so a milestone change or new document request propagates within minutes rather than on a slow batch. The re-validation step noted above keeps the captured calls honest across app updates.

Screens

From the public store listing — the application, tracking, document and scenario surfaces named above.

Peer apps

Cambria's app sits in a crowded mortgage point-of-sale field. Mapping these to one normalized schema is the common reason teams come to us, since each lender app is a different skin over a similar workflow.

• Blend — bank and lender-branded application and document portals; per-borrower loan and condition data behind login.
• Maxwell — POS used by community lenders; borrower application, status and document state.
• Floify — loan originator portal with borrower document collection and milestone tracking.
• BeSmartee — application with embedded credit, income and asset verification per loan.
• Cloudvirga — POS centered on the initial disclosure and application data set.
• Roostify — depository-scale POS with multi-product loan and verification data.
• LenderLogix — pre-qualification and borrower-engagement tooling around loan status.
• Encompass Consumer Connect — the Ellie Mae/ICE borrower front end tied directly to Encompass loan records.
• Loanzify — branded borrower and Realtor mobile app with status and pre-approval data.

Questions

This is a SimpleNexus white-label build — does the integration survive if Cambria switches its loan origination system?

Mostly yes. The borrower-facing surface stays SimpleNexus/nCino-shaped; what changes underneath is the milestone and field vocabulary that flows up from whichever LOS Cambria runs. We map to the platform objects rather than the on-screen labels, so an LOS change is a remap, not a rebuild.

Can you separate borrower-facing loan data from the loan-officer pipeline view?

Yes. The app exposes a borrower scope (their own loans, documents, milestones) and a separate loan-officer scope (the full pipeline, pricing, pre-approval issuance). We scope the integration to whichever one your use case authorizes and keep them isolated in the delivered code.

Which regulator governs the borrower data this app holds?

In the United States this is nonpublic personal information under the Gramm-Leach-Bliley Act, with the FTC Safeguards Rule and Regulation P setting how it is protected and shared. We treat the data as NPI end to end: authorized access, data minimization, retention limits, and consent or lender authorization on record.

Do you need a live Cambria loan in progress before you can build this?

Not as a hurdle you clear first. Access — a consenting borrower account, a Cambria-authorized test tenant, or a sponsor sandbox — is arranged with you during onboarding; the app name and what you want from the data are enough to begin scoping.

How this was put together

Checked in May 2026 against the app's store listing, SimpleNexus/nCino platform documentation, the nCino Mortgage developer portal, and the US financial-privacy framework. Primary sources opened:

• SimpleNexus — Nexus Origination / LOS integration
• nCino Mortgage developer portal — OAuth 2.0, objects, webhooks
• FTC — complying with the GLBA Privacy Rule
• Cambria Mortgage — licensing and disclosure

Compiled by the OpenBanking Studio integration desk · May 2026.

Working with us

For this app a first build is typically the borrower session plus loan, milestone and needs-list reads, returned inside one to two weeks. From there you choose how to take it. Source-code delivery starts at $300: you get the runnable build, the spec, tests and the interface docs, and you pay only after delivery once it works for you. Or run it as a pay-per-call hosted API — no upfront fee, you call our endpoints and pay for what you use. You bring the app name and what you need from its data; access and the GLBA paperwork are arranged with you as part of the work. Start the conversation at /contact.html.