Member-permissioned data extraction for Bank of Brookhaven Mobile+

Founded January 2000, Bank of Brookhaven runs a single office at 411 Brookway Boulevard and remains the only locally owned bank in Lincoln County, Mississippi (per the institution's own description and the FDIC certificate 35439 record). Mobile+ is the screen most members use to reach those accounts, and it is the practical surface to pull from when an integrator needs an authorized data feed from the bank.

The integration is consented to by the account holder, scoped to what the member's own login already sees, and shaped so it survives the next Mobile+ release on either app store. No institutional sponsor is needed to start — the app name and what you need is enough; the member-side access is arranged during onboarding.

What sits behind the Mobile+ login

The app's own description and listing pages name these surfaces; a build engagement maps each to the exact request the app makes and the JSON it gets back.

Tags, notes and receipt photos make Mobile+ a richer surface than the average single-branch banking app — those fields are member-authored, sit alongside each posted transaction, and survive a JSON pull. They are usually the reason an integrator wants the app's feed instead of an aggregator-cleaned one.

Routes that actually work for a single-branch Mississippi bank

1. Member-consented session against Mobile+

The cleanest path. The member logs in with their existing credentials and 4-digit passcode under written authorization; the integration runs the same login on a server and reads the JSON the app already reads. Coverage matches what Mobile+ itself shows, latency is close to real-time, and the session is durable for months — we patch it when an app release shifts the auth or ledger shape.

2. Authorized protocol analysis of Mobile+ traffic

For everything the JSON ledger doesn't expose directly — the deposit-status flow, attachment URIs, alert webhooks — we capture the network traffic on a consenting test device, label endpoints and field shapes, and turn that into the integration's field map. This is what gives coverage parity with the human app instead of a subset.

3. Aggregator-mediated path (FDX-shaped) where the bank is plumbed in

Some community banks of this size are reachable through US data aggregators (Plaid, MX, Finicity) with a consumer-permissioned token; some are not. We check coverage for Bank of Brookhaven during onboarding and use the aggregator route for balances and posted transactions when it works. It does not return the member-attached tags, notes or receipt images — those still come from route 1 or 2.

4. PDF statement capture

The Mobile+ statements view exposes per-account monthly PDFs. We use this as the archival channel, not the working feed — pulled monthly, named with account and period, dropped into whatever document store you maintain.

The spine is route 1, with route 2 layered for coverage parity, route 3 used opportunistically when this institution is reachable that way, and route 4 reserved for archive — one blended integration, not four parallel builds.

Authorization basis and the §1033 question

The dependable basis for this integration today is the member's own written authorization to act on their accounts with Bank of Brookhaven, anchored in long-standing US privacy law for financial institutions (GLBA). Consent is scoped to named accounts, named data domains, and a stated retention window; revocation severs the session at the auth layer and zeros derived caches.

The CFPB Personal Financial Data Rights rule (12 CFR Part 1033) is where US open banking may end up — finalized in late 2024, then enjoined and reopened for reconsideration, with the Bureau's Advance Notice of Proposed Rulemaking out for comment in late 2025, per the Federal Register filing. We watch that proceeding because it will eventually shape how a small community bank like this one is required to expose data, but our build does not depend on its current text. FDX, recognized by the CFPB in January 2025 as the standards body for US open banking, sets the technical shape the industry is converging on, and any route 3 work is already FDX-shaped where possible.

Operationally: NDAs where the engagement calls for them, written member authorization for any consented credential session, data minimization to the domains the integration actually needs, and an access log retained for the engagement's audit window.

What ships at the end of the engagement

• An OpenAPI specification of the Mobile+ surfaces the integration covers, written against the field map we capture — not a guess at endpoints, the ones we confirmed during the build.
• A protocol & auth-flow report: how Mobile+ negotiates the session, where the 4-digit passcode plugs in, the headers and tokens involved, how the ledger pagination works, and what the receipt-attachment URIs look like.
• Runnable source in Python and Node.js for the endpoints in scope: login, accounts list, ledger pull (with tags/notes/attachments), transfers, statement download.
• An automated test suite covering the auth flow, the ledger schema, the statement filename pattern, and the failure modes we hit during the build.
• Interface documentation written for the integrator who will own this in production: field-by-field, with examples redacted from a consenting test member's account.
• Data-retention & consent guidance scoped to the GLBA framework and the engagement's actual storage shape.

Login and ledger fetch — illustrative shape

Paths, header names and field names below are illustrative; the exact values are pinned during the build against a consenting Mobile+ session and re-checked when the app updates.

# Member-consented Mobile+ session (illustrative; final field names
# are confirmed against a real session during the build)

import os, requests

USER  = os.environ["BOB_USER"]
PASS  = os.environ["BOB_PASS"]
PIN   = os.environ["BOB_PIN"]          # 4-digit device passcode
BASE  = "https://mobileplus.bankofbrookhaven.example/api"

def login() -> str:
    r = requests.post(
        f"{BASE}/auth/session",
        json={"username": USER, "password": PASS, "device_pin": PIN},
        headers={"User-Agent": "MobilePlus/iOS", "X-App-Id": "com.bankofbrookhaven.grip"},
        timeout=15,
    )
    r.raise_for_status()
    return r.json()["session_token"]

def list_accounts(tok: str):
    return requests.get(
        f"{BASE}/v1/accounts",
        headers={"Authorization": f"Bearer {tok}"},
        timeout=15,
    ).json()

def fetch_ledger(tok: str, account_id: str, since: str):
    # Mobile+ surfaces member-attached tags, free-text notes and
    # receipt image URIs alongside each posted transaction.
    params = {"account": account_id, "from": since,
              "include": "tags,notes,attachments"}
    return requests.get(
        f"{BASE}/v1/transactions",
        headers={"Authorization": f"Bearer {tok}"},
        params=params,
        timeout=20,
    ).json()

def download_statement(tok: str, account_id: str, year: int, month: int) -> bytes:
    r = requests.get(
        f"{BASE}/v1/statements/{account_id}/{year:04d}-{month:02d}.pdf",
        headers={"Authorization": f"Bearer {tok}", "Accept": "application/pdf"},
        timeout=30,
    )
    r.raise_for_status()
    return r.content

Build-time wrinkles we plan around

Specific to this app and this institution — accounted for as part of the engagement so the build behaves on day one and on day ninety.

• Biometric is device-local, the passcode is the server signal. Face / fingerprint on Mobile+ releases the device-side keystore; the auth call still presents the 4-digit passcode. The passcode is held as a build secret and rotated through the same channel the member uses, so a member-driven passcode change does not break the integration silently.
• Single-branch core ledger means a single-tenant cadence. A one-office bank does not have the regional staggering of bigger institutions: statement runs, posting cycles and alert deliveries happen on one schedule. The pull window is synchronized to that schedule, so balances at 6 a.m. CT line up with what the member sees on the app.
• Member-attached metadata is unique to this app. Tags, notes and receipt photos are user-authored against transactions inside Mobile+ and are not in any aggregator feed. The integration preserves the original attachment URI so a re-fetch is always possible.
• App-release drift. Auth shape and ledger fields move when Mobile+ ships an update. The build maps these into a runtime field map and patches the map after each release — not the application code.

Use cases we have scoped for banks of this shape

• Pulling a member's posted-and-pending ledger into accounting software with the receipt-image URIs intact, so the bookkeeper sees the receipt the member already uploaded.
• Mirroring a member's balance-threshold alert into Slack or an ops queue, so a small business does not depend on push notifications reaching one phone.
• Archiving monthly PDF statements into a document store with deterministic filenames and a per-account index, for audit-readiness.
• Reconciling Mobile+ mobile-deposit events against an external ERP, with the deposit images attached as audit evidence.

Other Mississippi and Southeast bank apps an integrator pairs with this one

Same-region or same-shape institutions an integrator often wants to unify with Bank of Brookhaven Mobile+. Listed for ecosystem context, not ranked.

• Community Bank's CB2GO — Mississippi-headquartered Community Bank's retail mobile app, with a comparable mix of ledger, mobile deposit, card controls and bill pay.
• Trustmark myTrustmark — Jackson, Mississippi-based Trustmark's retail banking app, broader footprint, similar consumer data surfaces.
• BankPlus Mobile — Mississippi state-chartered BankPlus; balances, RDC, alerts.
• Renasant Bank Mobile — Tupelo-based Renasant; multi-state Southeast footprint with comparable data domains.
• Hancock Whitney Mobile — Gulf South regional bank, often unified with smaller community-bank feeds at the integrator side.
• Cadence Bank Mobile — Southeast retail banking; commonly bundled into a multi-bank dashboard with a smaller institution like Brookhaven.
• First Bank MS Mobile — another Mississippi community bank with member overlap in Lincoln County and the surrounding counties.
• Magnolia State Bank Mobile — Bay Springs-based community bank with a similar few-branch operational shape.
• Mississippi FCU Mobile — member-owned credit union; included because a single member may hold both a Brookhaven checking account and an MFCU share and want one integration.

Integrator questions that come up for this app

Are Mobile+ monthly statements pulled as PDFs or only JSON ledger snapshots?

Both, and they answer different questions. The JSON ledger inside Mobile+ is what the app draws from for balances, posted transactions, attached tags and the receipt-image URIs members upload — that is the working feed for reconciliation. The PDF statement is the legal artifact: month-by-month, per account, signed by the bank's statement run. We pull the JSON for everything ongoing and pull the PDFs only for the months an integrator actually needs to archive.

How do you get past the 4-digit passcode and biometric step during a consented build?

Biometric is a device-local gate, not a server check, so it does not block a server-side session. The 4-digit passcode is enrolled by the consenting member on a test device during onboarding and stored as a build secret; the integration logs in as that member, against their own accounts, with their written authorization on file. If the member rotates the passcode we get the new value through the same channel and re-enroll — that takes minutes, not a redeploy.

What changes for the integration if Bank of Brookhaven is already plumbed into Plaid or MX?

Coverage is usually a subset, not a superset. A US aggregator route — when it works for this bank — gives clean balances and posted transactions through a consumer-permissioned token, which is the easiest path for anyone who only needs that. It does not give the tags, free-text notes, or receipt images members add inside Mobile+, and aggregator coverage of small community banks is uneven enough that we check it for this institution during onboarding before scoping the rest.

What happens to the integration after a Mobile+ release?

The auth flow and the ledger shape are the two things that move when the app ships an update. We capture both at build time and re-check them on a cadence agreed with you — typically a light pass after each Mobile+ release on either store, plus a scheduled monthly health check. When a field is renamed or a header changes, the field map is patched in the runtime, not the application code.

Sources and review window

Cross-checked against the bank's own pages and FDIC's institution record on 2026-05-20, with the CFPB §1033 status read against the Federal Register filing and the standards-body recognition read from the CFPB's January 2025 newsroom note: FDIC BankFind — Bank of Brookhaven (cert 35439); Bank of Brookhaven — Online & Mobile Banking; Federal Register — Personal Financial Data Rights Reconsideration (Aug 22, 2025); CFPB — recognition of FDX as standard-setter.

OpenBanking Studio — integration mapping, 2026-05-20.

For a build against this app, what we need from you is the app name and what you need from its data — access, the consenting member, the test device, and the compliance paperwork are arranged with you during onboarding. Source-code delivery starts at $300, paid after delivery once you are satisfied, and the runnable bundle (OpenAPI spec, Python and Node.js source, tests, interface docs) lands inside one to two weeks. If you would rather not run the integration yourself, a pay-per-call hosted endpoint is available with no upfront fee — you pay only for the calls you make. Start the conversation on the contact page with the routes you care about and the cadence you need.

Mapping reviewed 2026-05-20.