AFN App on SimpleNexus: loan milestones, document uploads, and the SNAPI webhook surface

The package id com.simplenexus.loans.client.s__54526 gives the integration away on the first line: the AFN App is American Financial Network, Inc.'s skinned borrower portal on the SimpleNexus (now nCino Mortgage) stack. That matters because the borrower data sits behind a documented webhook plus REST surface — SNAPI, with its successor in the nCino Mortgage API — not behind a screen-only flow that has to be replayed pixel by pixel. The integration question for AFN is therefore an ingestion question: which events to subscribe to, how to normalize the lender-side milestones the LOS pushes through, and how to make the receiver replay-safe.

American Financial Network, Inc. is the lender of record (NMLS #237341, per its public license page). It is a Brea, California direct lender, licensed in all 50 states, with delegated underwriting on Fannie Mae, Freddie Mac, FHA, USDA, VA and jumbo programs. The AFN App — also published under the AFN SNAP / AFN Borrower Portal brand — is the consumer-facing surface for application intake, document upload, e-sign disclosures and milestone status. Nothing on this page describes the lender's internal systems; we work the borrower-portal surface and the connector layer the platform itself exposes.

Data surfaces inside the AFN borrower portal

These are the surfaces an integrator will actually touch when the work is the AFN App rather than the lender's back-office systems. Granularities reflect what SNAPI emits per event, as confirmed in the nCino developer portal during the build.

How we'd reach the AFN App data

Three routes fit this app. Effort below is the studio's planning estimate, not the lender's number.

1. Authorized SNAPI / nCino Mortgage integration (lender-side consent)

The dependable route. SNAPI tokens are issued per-tenant by the lender; the integration runs against a sandbox tenant first, then is repointed to live keys. Reachable: full event stream, document handles, application snapshots, org tree. Effort: roughly the bulk of a 1–2 week cycle. Durability: high, because the surface is the platform's published one.

2. User-consented borrower flow

Where the integration is scoped to a single consumer's view (a real-estate agent dashboard, a financial planner reading one client's loan), the borrower's own SNAP login under their consent gives the same shape of data narrowed to one loan. We arrange the consent capture and rotation as part of the build.

3. Authorized interface integration / protocol analysis of SNAP traffic

A fallback we keep on the bench, only when the first two are not available for a given engagement — for example, when the consumer of the data sits outside the lender's tenant arrangement. Same data shape; we mirror the SNAP mobile and web traffic under the customer's authorization, with logging and minimization. Lower durability than route 1 because the platform owns the surface and can change it; we re-validate on a cadence agreed at the start.

For an AFN engagement we would lead with route 1, fall back to route 2 for single-borrower scope, and only reach for route 3 where the other two genuinely cannot be arranged.

What lands on your servers

• A typed Python or Node.js webhook receiver. Signature verification, event-id deduplication, retry replay, structured logs. This is the centre of the delivery, not an afterthought.
• An SDK wrapping the SNAPI / nCino Mortgage endpoints we need — loan, milestones, documents, users — generated from the live API and pinned to a version.
• A milestone normalization layer. The SN events (SN Borrower Linked, SN Loan Application Started, SN Loan Application Submitted) plus the lender-specific milestones the LOS pushes through SimpleNexus all land on one canonical pipeline state.
• A sync designer covering both modes — real-time delta via webhook plus a periodic pull pass for reconciliation against a borrower's loan record.
• An automated test harness that replays captured payload fixtures against the receiver before it is pointed at a live tenant.
• An OpenAPI/Swagger spec for the endpoints we expose to your side.
• An auth-flow report covering the OAuth client-credentials exchange for SNAPI, token rotation cadence, and the retention windows the lender's licence work requires.
• Interface documentation a successor engineer can read without us in the room.

Receiver sketch — what the webhook endpoint looks like

Illustrative; the production version is verified against the nCino Mortgage developer portal during the build and is replayed against captured fixtures before it sees live traffic.

# FastAPI receiver for SimpleNexus / nCino Mortgage webhooks on the AFN tenant.
# Event names below are drawn from the SN milestone vocabulary plus the
# lender-side milestones that flow through SimpleNexus from the LOS.

from fastapi import FastAPI, Header, HTTPException, Request
import hmac, hashlib

app = FastAPI()
TENANT_SECRETS = {
    "afn":      b"<rotated per environment>",
    # additional lender tenants slot in here; signature is keyed per tenant.
}

def verify(tenant: str, sig_header: str, body: bytes) -> bool:
    secret = TENANT_SECRETS.get(tenant)
    if not secret:
        return False
    mac = hmac.new(secret, body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(sig_header, mac)

@app.post("/snapi/{tenant}/event")
async def snapi_event(tenant: str, req: Request,
                      x_signature: str = Header(...),
                      x_event_id:  str = Header(...)):
    body = await req.body()
    if not verify(tenant, x_signature, body):
        raise HTTPException(401, "bad signature")
    if already_processed(x_event_id):       # idempotent on the event id
        return {"ok": True, "duplicate": True}
    event = await req.json()
    match event.get("type"):
        case "borrower.linked":              # SN Borrower Linked
            link_contact(tenant, event)
        case "loan.application.started":     # SN Loan Application Started
            open_pipeline(tenant, event)
        case "loan.application.submitted":   # SN Loan Application Submitted
            persist_application(tenant, event)
        case "loan.milestone.updated":       # LOS-side milestone pushed through SN
            advance_pipeline(tenant, event)
        case "loan.document.uploaded":
            mirror_document(tenant, event)
        case _:
            log_unknown(tenant, event)       # quiet for forward compatibility
    record_processed(x_event_id)
    return {"ok": True}

Consent posture and the US data-rights backdrop

The dependable basis is consent. For the AFN engagement that means the lender authorizing SNAPI access to its tenant, plus — where the scope reaches a single borrower's view — that borrower's own SNAP login. Tokens are environment-scoped, rotated on a fixed cadence, and revocable; logs of what was read and when sit in the receiver alongside the events themselves.

The CFPB's Personal Financial Data Rights rule under §1033 of Dodd-Frank is the forward-looking piece. As finalized in October 2024 it would have started phasing in obligations on data providers, but the rule has been enjoined and reopened for reconsideration; the comment period on the Advance Notice closed in late 2025 and the Bureau has not issued a revised rule. None of the AFN App integration today rides on §1033, and the page does not assume it as present law. If a successor rule settles, the same plumbing can be repointed to the data-provider interface it ends up defining — the auth-flow report flags that migration step explicitly so it does not become a surprise later. State mortgage-licensing requirements and the standard TILA/RESPA disclosure rules continue to bear on what the lender does with the data the receiver feeds it; the data-retention memo covers those.

Things the build accounts for

Concrete engineering notes specific to this app — written as the work we do, not a list of preconditions the reader has to clear before we will engage.

• Tenant scoping. SNAPI credentials are tenant-scoped per lender. We arrange the credential exchange and the sandbox tenant with you during onboarding, replay captured payloads against the receiver in the sandbox, and only swap to live keys once the deduplication and signature checks are quiet on the fixture set.
• Two milestone vocabularies, one pipeline state. SN's own milestones (Borrower Linked, Application Started, Application Submitted) arrive alongside lender-defined milestone names the LOS pushes through SimpleNexus. The normalization layer maps both onto a canonical pipeline state machine, so the consumer side does not have to know whether a state change came from SN or from the LOS underneath.
• Document fidelity preserved. SNAP documents arrive as PDF or image. The receiver stores the original asset alongside any OCR or field extraction, so a later audit pack always resolves back to the source upload the borrower made.
• Token rotation handling. SNAPI access tokens rotate on a fixed cadence. The receiver follows the published cadence and treats the token-issuance call as part of its normal request loop, rather than as a special-case error path.

Where this gets used in practice

Three concrete shapes of engagement we have planned against for SimpleNexus-style portals:

• CRM mirror for a lender adding AFN-style sources. Webhook receiver lands borrower contacts, applications, and milestones in the CRM that the originator already lives in, with deduplication on borrower email plus loan id.
• Real-estate agent dashboard. Per-borrower SNAP login feeds the agent a read-only view of milestone and document status for clients who consent, so the agent does not have to ask the loan officer for updates.
• Ops command centre. The milestone stream drives a stall-detector — any task that sits in "Open" or "In Progress" past an agreed SLA pings the right desk, with the original task and document context attached.

Reliability notes

Webhook surfaces fail in predictable ways and the receiver is built for them. Event-id deduplication means a retried delivery does not double-advance the pipeline. Signature verification is per-tenant, so a leak in one lender's secret does not cross into another tenant the same receiver serves. Unknown event types are logged quietly rather than 500'd, so the platform can add new milestone types without breaking the consumer side. The reconciliation pull pass — daily by default, tuneable — is the safety net that catches anything the webhook missed during an outage window.

Pricing and how the work runs

An AFN App receiver scopes to roughly a 1–2 week cycle: a sandbox tenant arranged with you, a captured payload set, a typed receiver and SDK, the milestone normalization layer, the auth-flow and retention memo. Source-code delivery starts at $300, billed only after the receiver is running against your stack and you have signed off. The hosted option keeps the same surface on our side — you call our endpoints, you pay per call, no upfront fee. Either path begins the same way: send the app name and what you want the data to do over at /contact.html, and we scope the build from there.

Other mortgage portals in the same shape

Apps an integrator might evaluate next to AFN — neutral notes, not rankings.

• Blend — Enterprise-scale mortgage POS used by many large US lenders; broad LOS connector library.
• Roostify — Cloud mortgage POS with LOS connectors including Encompass and LoanDepot's stack.
• Maxwell — POS aimed at community lenders and credit unions; bundles POS plus fulfillment.
• Floify — POS oriented to broker workflows and document collection.
• BeSmartee — POS with embedded credit pull, asset/income verification and pricing-engine ties.
• CloudVirga — Enterprise mortgage POS used by large bank lenders.
• Blue Sage — Cloud-native POS and LOS in one platform.
• Arive — Broker-focused origination platform with embedded LOS.
• Loanzify — Mobile-first POS used by independent brokers and small shops.
• ICE Mortgage Technology Encompass — The LOS the platforms above frequently feed into.

Questions integrators ask about AFN App

Is the AFN App's data actually behind SNAPI, or do we have to deal with the lender's LOS too?

Both, and that is a feature rather than a snag. SNAPI exposes the borrower-portal side — application fields, milestones, documents, tasks. The LOS underneath drives lender-side milestones that flow into SimpleNexus, so the receiver normalizes both into a single pipeline state. The consumer side does not need to know which side of the integration emitted what.

How fresh is the milestone stream and what happens on retry?

Real-time push on SNAPI webhook events (per the nCino Mortgage developer portal), with a periodic pull pass for reconciliation against the borrower's loan record. The receiver is idempotent on the event id, so a replay on retry does not double-fire downstream side-effects.

Does the §1033 reconsideration change anything for an AFN integration today?

Not for this work. The integration rides the lender's SNAPI consent and — where it touches a single borrower's view — the borrower's own SNAP login. The CFPB's Personal Financial Data Rights rule was finalized in late 2024, then enjoined and reopened for reconsideration; it is not in force, so it is not the basis the receiver leans on. If the rule (or its successor) settles, the auth-flow report flags the migration path.

Can one receiver handle several SimpleNexus-based lenders, not just AFN?

Yes. SNAPI credentials are tenant-scoped per lender; the receiver is multi-tenant by design — one webhook endpoint, signature verification keyed per tenant, and a milestone normalization layer per LOS profile so different lenders' custom milestones land on the same canonical states.

How this page was assembled

Checked against the AFN corporate site, the firm's license disclosure, the SimpleNexus / nCino developer portal, and the CFPB's current rulemaking status. Where a fact is not on a public page, the page says so rather than guessing.

• American Financial Network, Inc. — license disclosure (NMLS, state list)
• nCino Mortgage developer portal — Getting Started with SNAPI
• SimpleNexus — real-time data transfers via the SimpleNexus API
• CFPB — Personal Financial Data Rights Reconsideration

OpenFinance Lab · assessment, 2026-06-03.