Integrating borrower files from NOLA Lending Group CONNECT

The Play Store package id com.simplenexus.loans.client.s__36604 reveals what the listing copy does not say outright: NOLA Lending Group CONNECT is a branded build of the SimpleNexus mortgage point-of-sale, folded into the nCino Mortgage Suite after nCino's 2022 acquisition of SimpleNexus. The operator is NOLA Lending Group, a division of Fidelity Bank that the lender lists under NMLS #488639 in Fidelity Bank's own published NMLS roster, with a Louisiana, Mississippi and Florida footprint. For an integrator that platform-plus-lender split shapes everything: borrower data lives on a multi-tenant SimpleNexus channel configured per lender, and what NOLA's tenant exposes is partly inherited from the platform and partly NOLA's own loan-program rules (Conventional, FHA, USDA Rural Development, Louisiana housing-bond programs, as the lender lists on its public site).

The bottom line for a buyer: the calculators run on the device and are not interesting; what is interesting is everything that hits the SimpleNexus tenant on the borrower's behalf. We reach that data either by mapping the consumer app's traffic to the tenant and replaying it under a consenting borrower's session, or — when the customer is a partner the lender has authorized to receive borrower files — by routing through the lender's SimpleNexus credentials. Our default is to lead with the borrower-consented route and layer in lender-credentialed pulls where the lender will sponsor them; that gets the same payload with the cleaner audit trail.

What the app actually surfaces, per borrower

Routes we use to reach this data

1 · Authorized interface integration against the SimpleNexus tenant

We model the calls the consumer app makes to the SimpleNexus channel the NOLA tenant is hosted on, capture them under a consenting borrower's session, and re-implement the subset of endpoints needed for the chosen data domains. Reach is broad — anything the borrower can see in-app is reachable. Durability is good against minor UI changes (the channel is largely back-end-stable) and gets refreshed when SimpleNexus updates its session model. Setup runs in onboarding alongside the borrower or pilot account we test against.

2 · Lender-authorized credential route

Where the customer is a vendor the lender wants to sponsor (a co-brokered CRM, a verification provider, an attorney-side closing system), the integration is routed through the lender's own credentialed access to the SimpleNexus / nCino tenant. The NOLA Lending Group / Fidelity Bank side authorizes the access scope and the borrower set; we deliver the client and the access-control glue. Reach is widest here, and the audit trail sits with the lender — clean for compliance reviews.

3 · Borrower-consented credential session

For consumer-side products (a personal-finance app, a real-estate buyer-side tool) the borrower authenticates themselves into the channel, our client refreshes the session on their behalf, and the pull is scoped to their loan only. Setup is the lightest; the durability ceiling is the platform's session-expiry policy, which we design around (see scope notes).

The native share-out flows the app provides (LO contact card, scenario summary) are useful as a last-mile fallback and we wire them where there is no other way to surface a particular field, but they do not carry the document records or the milestone history and are not the spine of a real integration.

Scenarios we have built or would build for this app

• Lender-side document ingestion. Pull each newly uploaded borrower document, classify it (1003 page, W-2, ID, bank statement), push it into the lender's vault and the downstream LOS. Drives ATR/QM and pre-underwriting checks earlier in the cycle.
• Real-estate agent milestone dashboard. Webhook on stage transitions and message thread updates so the listing or buyer's agent sees the file moving without calling the LO every two days. The LO contact card and the milestone surface are enough to power this.
• Borrower-side personal-finance sync. A consumer app the borrower has authorized reads their loan application and current milestone to forecast closing-month cash needs and prefill ID and pay-stub records the borrower has already uploaded.

What lands in your hands

• OpenAPI specification for the endpoints we re-implement (the borrower-file, document, milestone and message surfaces), with example payloads taken from the build.
• A protocol & auth-flow report describing the SimpleNexus tenant base URL pattern, the session/bearer model and refresh behaviour, and the per-lender configuration switches that matter for NOLA's tenant.
• Runnable source for the client in Python (async httpx) and Node.js (undici), with the document-streaming path separated from the metadata pulls.
• Automated tests: contract tests pinned against recorded fixtures from a consenting account, plus a small live-smoke that the operator runs against a sandbox or a sponsored sandbox borrower.
• Interface documentation written for the operator's engineers — what each field means in NOLA's loan-program context, not just the platform's generic schema.
• Consent & data-retention guidance: a written policy template for the consent record, the access logs, and the deletion path on revocation.

A pseudo-call to the borrower-file surface

Illustrative shape only — exact paths and field names are confirmed during the build against a consenting borrower account on NOLA's tenant.

import httpx

async def fetch_borrower_file(session_token: str, loan_id: str):
    async with httpx.AsyncClient(
        base_url="https://nolalending.simplenexus.com",
        headers={"Authorization": f"Bearer {session_token}"},
        timeout=20,
    ) as client:
        loan       = (await client.get(f"/api/v1/loans/{loan_id}")).json()
        docs       = (await client.get(f"/api/v1/loans/{loan_id}/documents")).json()
        milestones = (await client.get(f"/api/v1/loans/{loan_id}/milestones")).json()

        return {
            "loan_id":   loan_id,
            "program":   loan.get("program"),            # "Conventional" | "FHA" | "USDA-RD" | ...
            "property":  loan.get("subject_property"),
            "borrower":  loan.get("primary_borrower"),
            "documents": [
                {"id": d["id"], "kind": d["category"], "uploaded": d["uploaded_at"]}
                for d in docs
            ],
            "stage":     milestones[-1]["name"] if milestones else None,
        }

# Session refresh follows the platform's token model; we re-mint
# ahead of expiry and back off on 401, then re-issue the original call.

Consent, lender authorization and the paper trail

Mortgage origination in the US sits under RESPA, TILA, ECOA and the state-level licensing the lender carries through NMLS; for a borrower-facing app like this one, the practical dependable basis for any data we read is the borrower's own authorization. We treat that as load-bearing: each session is opened against an explicit, scoped consent the borrower has given, and the consent record (purpose, recipient, fields, expiry) is stored alongside the access logs. Where the lender is sponsoring the access — route 2 above — the lender's own authorization to share files with the named third party sits on top, and we keep both records joined on a loan id so an audit can answer "who saw this and why" in one query.

Where US data-rights rules around consumer financial data continue to evolve, we keep the architecture portable: consent records are versioned and revocable, and the deletion path on revocation is exercised by the test suite, not just documented.

Things we account for during the build

• Loan-program variance per lender configuration. NOLA runs Conventional, FHA, USDA Rural Development and Louisiana housing-bond programs, and SimpleNexus surfaces the per-program field set and document checklist differently for each. Our mapper carries a small per-program lookup so a Rural Development file's eligibility and document expectations are not pretended to be the same as a conventional file's. We confirm the live shape during onboarding rather than guessing.
• Session and token refresh against a long pull. A bulk milestone sweep across an active pipeline can outlast a single session; we re-mint ahead of expiry, queue per loan with a token-aware worker, and treat 401 as a re-auth signal rather than a hard failure. The borrower never sees this and the lender's logs stay readable.
• Corporate-change resilience. The January 2026 announcement of First Federal Bank's intent to acquire NOLA Lending Group from Fidelity Bank is the kind of event that, over a year, can move a tenant or rename a vanity domain. We isolate the base URL and the credential store behind a small config layer so a re-host costs an evening, not a rewrite. A periodic shape-check job re-runs the contract tests against the live tenant so silent platform changes show up before a borrower does.
• Document download URLs are short-lived. The doc surface returns metadata cleanly, but the bytes sit behind a signed URL that expires quickly; the worker streams to your vault inside the same task, not in a separate batch job, to avoid expiry races on large files.

Sources we checked while writing this

Mapping reviewed 2026-05-20 by the OpenBanking Studio integration desk. The platform identification was taken from the app's Play Store listing and its package id; the lender's NMLS number and operating footprint from Fidelity Bank's own NMLS list page; the acquisition disclosure from First Federal Bank's January 2026 PR Newswire release; the platform's role in the loan-application surface from the SimpleNexus online loan application product page; and the platform's own getting-started documentation from nCino's mortgage developer portal. Anything not pinned to one of those is hedged in the text above.

Adjacent apps in the mortgage-POS integration landscape

Other apps an integrator working in this space tends to encounter — listed for ecosystem context, not as alternatives to NOLA Lending Group CONNECT.

• Floify — borrower portal with document collection, status updates and eSign; the front-end of many independent lenders' loan flow.
• Blend Mortgage — enterprise borrower experience with verifications and digital closing, common at banks and large IMBs.
• ARIVE — broker-focused platform combining a borrower POS, an LOS and a pricing engine with a wholesale-lender marketplace.
• BeSmartee Bright POS — configurable POS with LOS integrations and automated income / employment verification, popular with IMBs and depository banks.
• Maxwell — borrower POS with eClose, often deployed to compress cycle time at smaller lenders.
• Loanzify — mobile-first lender-branded borrower app with credit pull and push-notification engagement.
• Roostify — borrower-facing POS used at large banks for purchase and refinance workflows.
• ICE Encompass Consumer Connect — the borrower-facing front end paired with the Encompass LOS, common at lenders standardized on the ICE Mortgage Technology stack.

Common questions a NOLA Lending integrator opens with

Are document uploads pulled the same way as application fields?

They share the same authenticated session and the same per-loan scoping, but documents arrive as separate records. Each file carries its own id, category (W-2, paystub, ID, bank statement), uploaded timestamp, and a short-lived download URL. Our pull fetches the metadata first, then streams the bytes through to whatever vault you point us at.

How does the announced First Federal acquisition affect ongoing integration work?

The January 2026 agreement for First Federal Bank to acquire the NOLA Lending Group business is a corporate change rather than an immediate platform migration. Existing borrower sessions and the SimpleNexus channel continue to operate during the transition. We design integrations so that a tenant rename or a re-host can be absorbed by updating the base URL and re-onboarding credentials, not rewriting the client.

What does borrower-consent recordkeeping look like for an authorized scrape?

For each borrower whose file is read, we store a timestamped consent record: what was shared, with whom, for what purpose, expiry. Access logs from the pull itself sit alongside that record. Revocation invalidates the session and triggers deletion or quarantine of the cached payload, depending on what your audit obligations require.

Source-code delivery starts at $300 and is paid only after delivery, once the client is in your hands and the tests pass; if you would rather not host the integration yourself, we run the same endpoints for you and bill per call, with no upfront. Either route ships in a one-to-two-week cycle. Send the app name and what you want from its data through our contact page — access, sponsoring credentials and the consent paperwork are arranged with you during onboarding.