NOLA Lending Group CONNECT — replaying a SimpleNexus borrower stream into your warehouse

Open the iOS App Store listing and the seller for NOLA Lending Group CONNECT is First Federal Bank of Florida; open the Android package id and the namespace com.simplenexus.loans.client gives the rest of the picture away. The borrower app is a white-label SimpleNexus build — nCino's Mortgage Suite since the September 29, 2023 rebrand — wrapped around a Gulf-Coast mortgage operation that originated roughly $464 million in 2024 across 25 branches in Louisiana, Mississippi and Florida (per National Mortgage News reporting on the recent acquisition). That tells you, before any integration code, where the loan-file data actually lives and how it reaches a borrower's phone.

The data flows from a loan origination system on the lender side, through the SimpleNexus / nCino backend, out to the app. So integrating the app is really integrating that pipeline at the borrower's authorization. Stream and replay, not periodic scrape. The rest of this brief lays out the surfaces, the route, the snippet, and what we hand over.

Where the loan file actually lives in the app

Each row below maps a data domain to where it surfaces in the borrower app, the granularity available, and what a downstream system typically does with it.

Routes to the loan file

Four routes apply for an app of this shape. We pick the one that fits the customer's downstream use, then design the receiver around it.

1. Consumer-authorized read against the SimpleNexus / nCino backend

The borrower signs an authorization, we obtain a scoped credential, the backend then delivers their loan-file events to our edge. Reaches every domain in the table above, including documents and disclosures. Durable as long as the consent and the backend access stay in place. Access setup is something we arrange with you and the lender as part of onboarding, not a precondition you bring to the kick-off.

2. LOS-side partnership at the lender

If the customer is or can co-engage the lender, the richest data lives one layer below the app: Encompass Developer Connect (REST + OAuth) and Encompass Partner Connect (EPC) for ICE shops, or the equivalent partner APIs for Calyx, LendingQB and MortgagebotLOS. ICE deprecated the legacy SDK on October 31, 2025, so we build against the current REST surface only. Highest fidelity, longest setup.

3. Authorized protocol analysis of the app's traffic

Against a consenting borrower's account, the app's network traffic is observed, the SimpleNexus call shapes are documented, and a clean client is implemented from there. Useful when the customer needs the borrower-visible view exactly and the backend partnership route is not on the table. Coupled with a re-pin run on every meaningful app release.

4. Native artefact export

The app and the borrower portal both expose PDF closing packets, signed disclosures and prequal letters. Where the customer only needs the static artefacts (compliance archive, brokerage tie-out), this is the cheapest route — we wire a pull-and-classify against the borrower's authorized session.

In practice the consumer-authorized read (route 1) carries most builds, because it follows one borrower from application to funded with no LOS-side dependency on day one. We add the LOS partnership only when iLAD-grade richness becomes a hard requirement, and we keep the protocol-analysis route as a diagnostic for the days the backend isn't returning what the app clearly receives.

Subscribing to the borrower's event stream

The whole integration is shaped around one primitive: subscribe to a borrower's loan-file events, with replay from a known cursor. The receiver is yours; we put the SDK against it. Illustrative shape — the exact field names are confirmed during the build against the live response.

# Subscribe to a borrower's loan-file event stream (consent-scoped)
# Source: SimpleNexus / nCino Mortgage Suite white-label backend
# Auth: bearer token issued against the borrower's signed authorization;
#       refreshed against the consent window so the queue doesn't fall behind.

POST /v1/loan-files/{loan_id}/events:subscribe
Authorization: Bearer ${borrower_consent_token}
Content-Type: application/json

{
  "consumer": "openfinance-lab.relay.nola",
  "deliver_to": "https://your-edge/events",
  "filters": {
    "milestone_in": [
      "application_submitted", "processing",
      "conditional_approval", "clear_to_close", "funded"
    ],
    "include_documents":  true,
    "include_disclosures": true,
    "include_prequals":   true
  },
  "replay_from": "2026-04-01T00:00:00Z",
  "delivery": { "ordered": true, "dedupe_key": "event_id" }
}

# A delivered event looks roughly like (shape confirmed during the build):
{
  "event_id":    "evt_2c8b9a1f...",
  "loan_id":     "NOLA-2026-...",
  "borrower_ref":"brw_...",
  "type":        "milestone.changed",
  "previous":    "processing",
  "current":     "conditional_approval",
  "lo_nmls":     "...",                 // mapped to the loan officer card
  "occurred_at": "2026-05-29T14:13:08Z",
  "source_los":  "<not exposed>",       // upstream LOS abstracted away
  "mismo_link":  "iLAD/v3.4/..."         // present when the LOS surfaces it
}

Three things matter in that shape. Ordering is per loan_id so a clear-to-close never lands before its conditional approval. The dedupe_key lets your receiver be replayed without double-bookkeeping. And source_los is deliberately abstracted: NOLA could be on any of the partner LOSes, and downstream code shouldn't break the day that changes.

What lands in your repo when we close

The deliverable is code that runs against your edge on day one, with the spec and the audit memo behind it.

• A runnable Python and Node.js SDK with the subscribe, replay and dedupe primitives shown above, plus a typed event model normalized to MISMO v3.4 / iLAD field names where the LOS surfaces enough data.
• A webhook receiver template (FastAPI for Python, Express for Node.js) with idempotent storage keyed on event_id and an out-of-order buffer per loan_id.
• A recorded fixture stream paired with a CI suite that replays it on every commit, so an upstream schema change becomes someone's morning ticket instead of a months-later mystery.
• A reconciliation script that polls the snapshot endpoint on a configurable cadence (default 30 min) and emits synthesized events for any gap, so a missed delivery never leaves your replica stale.
• An OpenAPI specification for the wrapper endpoints we host when you take the pay-per-call route.
• A protocol & auth-flow report covering the OAuth chain, the consent record, the token-refresh window, and the failure modes we observed.
• A short data-retention and minimization memo, written for a US mortgage operation under OCC supervision (post-acquisition) and FDIC insurance.
• Interface documentation in markdown, kept next to the code.

Authorization, the §1033 caveat, and what the integration relies on

The dependable basis for handling this data is the borrower's own written authorization. We capture it, log it, scope each token against it, and treat it as the gate every replayed event flows through.

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is the piece reasonable readers tend to ask about. It is not in force today. A federal court in the Eastern District of Kentucky entered a preliminary injunction on October 29, 2025 (Forcht Bank et al. v. CFPB) blocking enforcement, and the CFPB itself published an Advance Notice of Proposed Rulemaking on August 22, 2025 (Docket CFPB-2025-0037) opening the rule to reconsideration. Even as originally finalized in October 2024, the rule did not put mortgage loan accounts in its initial scope — mortgages were signalled only for future rulemaking. So §1033 is described here as the unsettled forward-looking piece. It is not what the integration leans on.

What the integration does lean on: MISMO v3.4 outbound shape where the LOS provides it; documented consent records with revocation hooks; data minimization (we relay only the categories the consumer's authorization names); NDA between the studio and the customer where the work touches identifiable borrower data; and a redaction step before any artefact leaves the receiver into a downstream system that didn't explicitly opt into PII.

Engineering notes specific to this loan-file

Four things about NOLA's particular shape that we account for in the build, so the receiver doesn't get fragile.

Sponsoring institution changed mid-flight. NOLA Lending moved from a division of Fidelity Bank (NMLS #488639) to a division of First Federal Bank (NMLS #408902) under the January 5, 2026 acquisition agreement, with the brand retained and a roughly 60-day post-closing transition. The integration pins each event to the NMLS company id active when it fired, so historical loan files don't mis-attribute after the cutover.

The underlying LOS is not publicly disclosed. SimpleNexus / nCino integrates with Encompass, Calyx Point, Byte, LendingQB and Finastra MortgagebotLOS, and we cannot find a public source that names which one NOLA runs (the parent — Fidelity Bank, soon First Federal Bank — could plausibly run any of them). The receiver is therefore built against the SimpleNexus event shape, not the LOS payload, so a future LOS swap on the lender side does not require a re-integration on yours.

The Encompass deprecation matters even when we don't touch it directly. ICE Mortgage Technology removed the legacy Encompass SDK on October 31, 2025. If a customer later asks us to surface the richer iLAD payload at the LOS layer (Route 2), we build against the current Encompass Developer Connect REST surface and Partner Connect — not the deprecated SDK. Older third-party recipes that still reference the SDK are not safe to copy from.

Loan-file replay is what the receiver is for. Borrower activity is bursty (five documents in an evening, then nothing, then a milestone the next morning) and LOS milestone events are batchy. We default the receiver to a queue + replay model rather than a polling cadence so the busy days don't blur into one snapshot and a downstream restart can rebuild state cleanly from any cursor.

How a NOLA build typically runs

For this app the build runs about 1–2 weeks end to end: a consumer-authorized subscription against a test borrower, a replay-capable receiver, the MISMO-aligned normalization on top, and a CI fixture so the deliverable doesn't rot. Source-code delivery starts at $300, paid after delivery once the receiver is consuming live events from your test borrower and you confirm you're satisfied. If you'd rather not host any of it yourself, our hosted endpoint fronts the same plumbing on a pay-per-call basis — no upfront fee, you pay only for the events relayed. Access onboarding and the consent paperwork are arranged with you during the project, on our side of the desk. Tell us the borrower scope you want mirrored at /contact.html and we'll line up a kick-off.

Sources we opened

This page was put together against the lender's own pages, the platform pages, primary regulator materials, and the press release confirming the January 2026 sponsoring-institution change. Deep links:

• Apple App Store — NOLA Lending Group CONNECT (publisher: First Federal Bank of Florida; borrower features list).
• First Federal Bank / Fidelity Bank acquisition release (PR Newswire) — January 2026 agreement, branch list, transition window.
• nCino — SimpleNexus rebrand to nCino's Mortgage Suite (September 29, 2023).
• ABA Banking Journal — E.D. Ky. preliminary injunction against the §1033 final rule (October 29, 2025).
• CFPB — Personal Financial Data Rights Reconsideration (August 22, 2025 ANPR, Docket CFPB-2025-0037).
• MISMO — residential dataset specifications (iLAD, ULAD, ULDD, UCD).

OpenFinance Lab · Mortgage-POS integration notes, 2026-05-31.

Peers in the US mortgage borrower-app set

If you are mirroring more than one lender, the platforms below carry most of the same data surfaces and most of the same integration shape. Knowing them up front is what makes a unified mortgage-data layer tractable.

• Rocket Mortgage — Rocket Mortgage's own app (NMLS #3030) with full mobile loan application, document upload, real-time progress and post-close servicing.
• Better Mortgage — Better Holdco's borrower app with photo document upload, in-app messaging to the loan team and mobile e-close.
• loanDepot Mobile — loanDepot's mello-platform borrower portal covering income, asset, document and payment management.
• CMG HOME — CMG Home Loans' borrower app, also built on the SimpleNexus white-label; the event shape will look familiar after this build.
• Cardinal Financial Octane — Cardinal's borrower-facing POS for document upload, e-sign and live loan-status checks.
• Guild Mortgage Customer Connect — Guild's secure borrower portal with real-time loan status and lender messaging.
• Rate — Guaranteed Rate / Rate Companies' app combining MLS browsing, application, and home-equity tracking.
• My AmeriSave — AmeriSave's web-first borrower portal; useful when integrating lenders without a dedicated mobile app.
• Encompass Consumer Connect & My Home Loans — ICE Mortgage Technology's POS and the branded mobile extension many ICE-shop lenders launch.
• nCino's Mortgage Suite (SimpleNexus white-label) — the underlying platform that powers this app and dozens of other lender-branded ones; integrating one means most of the work for the rest.

Interface evidence (Play Store screenshots)

Questions integrators usually ask first

Why a queue and event-replay design rather than a daily pull?

Loan files change in bursts — a borrower submits five documents in twenty minutes, then nothing for three days, then a milestone fires from the LOS. A queue catches the burst as it happens and lets your receiver replay from any timestamp if it was offline or if you reprocess. A daily pull blurs all of that into one snapshot and gets reconciliation wrong on the busy days.

Does the January 2026 First Federal Bank acquisition affect the integration?

At the metadata layer, yes. The sponsoring institution moved from Fidelity Bank (NMLS #488639) to First Federal Bank (NMLS #408902) under an agreement announced January 5, 2026, the NOLA Lending brand was retained, and the platform was set to transition within about 60 days of closing. The integration pins each loan file to the NMLS company id active when its events fired, so reports across the cutover stay accurate.

Which loan origination system sits behind the app?

Not publicly disclosed. SimpleNexus / nCino integrates with Encompass (ICE Mortgage Technology), Calyx Point, Byte, LendingQB and Finastra MortgagebotLOS in its documented partner set, and a lender of NOLA's size could plausibly run any of them. We build against the SimpleNexus event shape rather than an LOS-specific schema, which keeps the integration stable regardless of which one is in use today.

Is this an open-banking / CFPB 1033 read-out?

No. The CFPB's 12 CFR Part 1033 Personal Financial Data Rights rule is currently enjoined — a preliminary injunction was entered in the Eastern District of Kentucky on October 29, 2025, and the rule is back in CFPB reconsideration via the August 22, 2025 ANPR (Docket CFPB-2025-0037). Even as finalized, since stayed, that rule did not put mortgage loans in its initial scope. The dependable basis here is the borrower's own authorization, captured in the consent record kept alongside every replayed event.