Pulling loan-pipeline data out of 1st Source Bank's eMortgage app

1st Source Bank runs its borrower mortgage flow on SimpleNexus — the homeownership platform nCino now sells as its Mortgage Suite — so the eMortgage app on a borrower's phone is a thin client over a loan pipeline that lives on nCino-hosted servers. The data worth integrating is not in the app. It is in that pipeline: the application a borrower filled in, the document checklist, the e-signed disclosure set, and the milestone clock that runs from application to clear-to-close. The package id on the Play listing, com.simplenexus.loans.client.s__87640, is per its store listing a tenant-suffixed build — one lender's instance of a shared platform. That single fact drives every choice below.

The bottom line: this is a high-value pipeline behind one lender's skin of a widely deployed platform, and the platform's protocol is well enough defined that an authorized integration is predictable work rather than guesswork. The route we would take is a lender-authorized integration against the SimpleNexus/nCino backend the app already speaks to, with the consumer-consent path available where the buyer is an aggregator rather than the bank. The rest of this brief is the detail behind that recommendation.

What the borrower app actually holds

Every row below maps to something a borrower sees in eMortgage and something a backend stores for it. Granularity is per loan unless noted.

Routes we would take to reach it

Lender-authorized integration against the backend protocol

The app talks to the SimpleNexus/nCino backend over an OAuth 2.0 protocol with token expiration and a webhook flow that carries delivery retries and event filtering, including milestone events. With 1st Source Bank authorizing tenant credentials — arranged with the bank during onboarding, not something the buyer has to bring — this reaches loans, milestones, documents and parties directly. Most durable, lowest maintenance, and the path we recommend for a lender or a vendor working on the bank's behalf.

Borrower-consented access

Where the buyer is a consumer-facing aggregator rather than the bank, a borrower can authorize a third party to reach the loan data held about them. Scope and expiry follow the consent grant. Slower per-user, but it does not depend on a bank relationship and fits a personal-finance product.

Protocol analysis of the app's own traffic

When credential provisioning is the slow part, we map the app-to-backend calls — the token chain, request and response shapes — and build the same connector from that. We treat this as a complement to the first route while access is being set up, and as a way to validate field mappings the documentation leaves vague. Native file export of the document vault is a fallback where a tenant export is enabled.

If you only read one paragraph here: the first route is the spine of almost every build like this, the second is for consumer aggregators, and the third keeps the project moving while paperwork lands.

What ends up in your repository

Each item is scoped to the surfaces above, not a generic kit.

• An OpenAPI/Swagger spec for the loan, milestone, document and e-sign reads as the tenant exposes them.
• A protocol and auth-flow report: the OAuth 2.0 token chain, token-expiry handling, and the webhook subscription and event-filter setup as 1st Source Bank's tenant is provisioned.
• Runnable connector source in Python and Node.js for status pulls, document listing, and webhook receipt with signature verification.
• Automated tests run against a sponsor sandbox or a consenting account — that access is arranged with you during onboarding.
• Interface documentation plus a short data-retention and consent note tied to the e-sign and document surfaces.

A status pull, sketched out

Illustrative shape only; exact host, version prefix and field names are confirmed against the tenant's provisioned API version during the build.

# 1st Source Bank eMortgage is one SimpleNexus tenant (build s__87640).
import time, requests

TOKEN_URL = "https://<tenant>.ncinomortgage.com/oauth2/token"   # confirmed per tenant
API       = "https://<tenant>.ncinomortgage.com/mortgage/v1"

def token(cid, secret):
    r = requests.post(TOKEN_URL, data={
        "grant_type": "client_credentials",
        "client_id": cid, "client_secret": secret,
        "scope": "loans:read documents:read",
    }, timeout=15)
    r.raise_for_status()
    t = r.json()
    return t["access_token"], time.time() + t.get("expires_in", 3600) - 60

def loan_status(loan_id, tok):
    r = requests.get(f"{API}/loans/{loan_id}",
                     headers={"Authorization": f"Bearer {tok}"}, timeout=15)
    if r.status_code == 401:
        raise TokenExpired              # caller refreshes via token()
    if r.status_code == 429:
        time.sleep(int(r.headers.get("Retry-After", 5)))
        return loan_status(loan_id, tok)
    r.raise_for_status()
    loan = r.json()
    return {
        "loan_id": loan["id"],
        "stage":   loan["currentMilestone"]["name"],
        "updated": loan["currentMilestone"]["completedAt"],
        "docs_outstanding": [d["name"] for d in loan["documents"]
                             if d["status"] != "received"],
    }

Normalized loan record we hand back

The connector emits one stable shape regardless of which API version the tenant is on:

{
  "loan": {
    "tenant": "1st-source-bank",
    "loan_id": "string",
    "milestone": { "name": "Conditional Approval", "at": "ISO-8601" },
    "application": { "borrowers": ["..."], "property": { "address": "..." } },
    "documents": [ { "name": "...", "status": "received|reviewed|outstanding" } ],
    "esign_packages": [ { "name": "...", "executed": true, "audit_id": "..." } ]
  }
}

Borrower consent and the US data-rights picture

Two consent models apply, depending on who authorizes the access. For a lender-side build, 1st Source Bank authorizes the tenant credentials and the data stays inside its own pipeline — the cleanest path, and the one most of this work uses. For a consumer-side aggregator, the relevant US framework is the CFPB's Personal Financial Data Rights rule under Dodd-Frank section 1033, which lets a borrower authorize a third party to reach financial data a covered institution holds about them. That rule's covered-data scope and compliance schedule are still moving through rulemaking and litigation, so a consumer-side build anchors on the borrower's explicit, revocable consent rather than on a fixed regulatory date. Either way we keep access authorized and logged, take only the fields the use case needs, hold an NDA where the bank wants one, and honor revocation by stopping the feed and deleting cached records.

What we plan around on a SimpleNexus tenant

A few things about this specific build shape our design, and we handle each as part of the work:

• The package suffix s__87640 (per the Play listing) marks 1st Source Bank's instance of a shared platform. We pin the build to that tenant and its configured milestone template, because milestone names and order are lender-set — the platform itself emits milestone-reordering events.
• nCino is releasing the new Mortgage API in functionality batches while the legacy SimpleNexus API stays live. We detect which one the tenant is on and isolate the differences behind one adapter, so a later cutover is a config change instead of a re-integration.
• OAuth tokens expire. We build the sync around the token lifetime with a refresh-on-401 path, so the feed does not silently stall overnight.
• An uploaded scan and an executed e-sign package are different objects with different trust levels. We keep them as separate records with their own status fields, and schedule a mapping re-check as part of upkeep for when the lender's milestone template or the app shell changes.

Screens we looked at

Store screenshots we reviewed while mapping the surfaces above. Tap to enlarge.

Neighbouring borrower mortgage apps

Same category, useful when a buyer wants one normalized feed across several lenders' borrower apps. Listed for context, not ranked.

• Blend — enterprise borrower origination and verification platform; holds application, verification and closing data behind lender tenants, the same pipeline shape an aggregator would normalize next to this one.
• Floify — broker and small-lender POS centered on a borrower document portal with a received/reviewed/outstanding checklist, close to eMortgage's document surface.
• Maxwell — POS and fulfillment platform for community banks and credit unions, with borrower task tracking and eClose artifacts.
• Cloudvirga — loan-officer-centric POS with borrower task tracking, pricing scenarios and verification data syncing to the LOS.
• LenderLogix — borrower portal and pre-qual tooling for smaller lenders, with real-time status notifications.
• ICE Encompass Consumer Connect — the borrower-facing front of ICE Mortgage Technology's Encompass LOS, holding application and document data on a different backend.
• SimpleNexus Mortgage App — the unbranded SimpleNexus borrower app (package com.simplenexus.loans.client), the same platform without a single-lender skin.
• Home Lending Pal — consumer mortgage-readiness app holding affordability and credit-profile data a borrower could consent to share.

Questions we get about this build

Does eMortgage talk to the newer nCino Mortgage API or the legacy SimpleNexus SNAPI?

Both exist. nCino is moving tenants from the legacy SimpleNexus API (SNAPI) onto the rebuilt nCino Mortgage API in phased batches, and a given lender's build can be on either. We confirm which one 1st Source Bank's tenant is provisioned for at the start and put a thin adapter behind our connector so a later cutover does not break your callers.

Can we get real-time milestone changes, or only a polled snapshot?

Both patterns are workable. The platform documents a webhook flow with delivery retries and event filtering, including milestone events, so we can push status changes to you; where webhooks are not provisioned on the tenant we fall back to a polled status read on the loan. Most teams want the webhook for the borrower-facing clock and a poll as a reconciliation safety net.

The app handles e-signed disclosure packages — can those be pulled too?

Yes, as a separate surface. An uploaded scan and an executed e-sign package are different objects: the first is a file in the document checklist, the second is a signed PDF with signature and audit metadata. We model them apart so a consumer of the API does not treat an unsigned upload as an executed disclosure, which matters for any compliance archive built on top.

Is this specific to 1st Source Bank, or any SimpleNexus lender app?

The data model is shared across SimpleNexus tenants, but milestone names, document checklists and branding are lender-configured, and the platform even emits milestone-reordering events. We scope the build to 1st Source Bank's tenant and its milestone template; the same connector pattern then ports to another SimpleNexus lender with a re-mapping pass rather than a rewrite.

How this brief came together

This draws on the app's own store listing and feature description, the SimpleNexus / nCino platform material, the nCino Mortgage developer documentation for the protocol and auth facts, and the CFPB's data-rights pages for the US consent backdrop, checked in May 2026. Primary sources:

• 1st Source Bank eMortgage on Google Play
• nCino Mortgage developer documentation
• SimpleNexus eMortgage product page
• CFPB Personal Financial Data Rights

OpenBanking Studio · integration desk mapping, 2026-05-17.

Working with us

Delivery on a tenant like this one runs one to two weeks once we confirm which API version it is on. Source-code delivery starts at $300: you get the runnable connector, the OpenAPI spec, the auth-flow report and the tests, and you pay only after it is delivered and you have checked it works. The other option is our hosted endpoints — you call them and pay per call, with nothing up front. Tell us the app and what you want out of its data on the contact page; access and any compliance paperwork are arranged with you and the bank as part of the engagement, not a hurdle you clear first.