Bank of Brookhaven Mobile+ and the data behind its login

Behind the Bank of Brookhaven Mobile+ login sits a single-branch community bank in Brookhaven, Mississippi, chartered in 2000 and supervised by the FDIC (certificate #35439, per FDIC records). The records a customer sees inside the app are the ones an integrator usually wants out the other side: current balances, posted transactions, transfers between accounts, bill payments and person-to-person sends, mobile check deposits, and monthly statements. This page maps those surfaces, names the route we would take to reach them under the accountholder's authorization, and lists what ships when the work is done.

The scope here is narrow, and that helps. One institution, a known feature set, a per-account ledger a worker can read once the session is open. The variable for a bank this size is aggregator reach — a single branch with roughly $232M in assets (per its public call-report summary) is not guaranteed to be indexed by the big US data networks. So we treat the consented direct route as the spine and keep statement export as the slow backstop, rather than betting the build on third-party coverage.

Account surfaces you can pull

Each row below ties a data domain to where it shows up in the app, how fine-grained it is, and the typical reason an integrator reaches for it.

Routes in, for a single-branch bank

Three approaches genuinely apply. They are not mutually exclusive — most builds use one as the spine and another as a check.

1 · Accountholder-consented protocol integration

We study the Mobile+ client's own conversation with its backend under the customer's authorization, then drive the same session a person would: sign in, list accounts, page through transactions, fetch a statement. Everything the app can show is reachable this way. The effort is higher than calling an aggregator, and durability tracks the app's release cadence — when a new client version ships we re-check the field mappings before the feed drifts. For a one-branch bank where outside coverage is thin, this is the route we lean on.

2 · User-consented aggregator access

US networks such as MX, Finicity, Plaid and Yodlee broker balance, transaction and identity data with the customer's consent. If one of them already indexes Bank of Brookhaven, this is the quickest path to a clean transactions feed. We confirm that during onboarding and wire up the aggregator credentials and consent capture on your behalf; if the bank is not covered, we fall back to route 1 rather than wait.

3 · Native statement export

The app already lets a customer save monthly statements. As a feed that is coarse — one document per cycle — but it is stable and cheap, and it makes a reliable reconciliation source against the finer transaction stream. We treat it as a backstop, not a primary feed.

A transaction pull, sketched

Field names and paths below are illustrative — they are confirmed against the live client during the build, not guessed from a store listing. The shape reflects the app's real surfaces: a session opened by passcode or biometric, a paged transaction read, and the user-added tags, notes and receipt attachments that hang off each line.

# Resume a session the way the app does (4-digit passcode / biometric -> bearer)
session = client.resume("/auth/session", device_token=DEVICE_TOKEN)
cursor  = store.last_cursor("brookhaven:txns") or "0"

resp = client.get(
    "/accounts/{acct}/transactions",
    params={"since": cursor, "limit": 100},
    headers={"Authorization": f"Bearer {session.token}"},
)

if resp.status == 401:            # session lapsed -> re-establish, then retry the page
    session = client.resume("/auth/session", device_token=DEVICE_TOKEN)

for t in resp["items"]:
    emit("txn.posted", {
        "account_id":   t["accountId"],
        "posted_at":    t["postedDate"],
        "amount_cents": to_cents(t["amount"]),
        "running_bal":  to_cents(t["balanceAfter"]),
        "memo":         t.get("note"),           # user-typed note
        "tags":         t.get("tags", []),       # user tags
        "receipt_img":  t.get("attachmentUrl"),  # receipt / check photo, if attached
    })

store.save_cursor("brookhaven:txns", resp["nextCursor"])   # restart resumes from here
      

Normalizing it for a stream

Raw reads are messy; downstream systems want one shape. We map each surface onto a small, stable event so a posted transaction, a deposit and a statement land in your queue looking like siblings.

{ "type": "txn.posted",
  "account_id": "BOB-0042",
  "posted_at": "2026-06-12T14:03:00Z",
  "amount_cents": -4215,
  "running_bal": 118830,
  "memo": "hardware store",
  "tags": ["supplies"],
  "source": "mobile_plus" }

{ "type": "deposit.captured",
  "account_id": "BOB-0042",
  "item_cents": 25000,
  "status": "pending_hold",
  "captured_at": "2026-06-11T09:20:00Z" }
      

Because every event carries the cursor it was read at, a worker restart replays from the last committed offset instead of re-reading months of history — useful when a bank's backend goes quiet for a maintenance window and the queue has to catch up afterward.

What lands in your repo

The deliverable is working code first, documentation around it. Concretely, for the Brookhaven surfaces:

• Runnable clients in Python and Node.js covering session resume, the transaction page-read, transfer and payment status, deposit status, and statement fetch — packaged to drop straight into your service.
• A queue / stream worker with cursor and replay, so ingestion survives restarts and backend downtime without re-reading the full ledger.
• An alert-to-event bridge that turns the app's low-balance alerts and new-transaction signals into messages your systems subscribe to.
• An automated test suite run against recorded fixtures, so a renamed or moved field shows up as a failing assertion rather than a quiet gap in the feed.
• An OpenAPI / Swagger description of the endpoints we mapped, plus a protocol and auth-flow report covering the session, token and device-binding chain.
• Interface documentation and data-retention guidance sized to a small FDIC-supervised bank and the data you actually keep.

Consent and the US data-rights picture

This is a US deposit institution, so the consumer-data-access rule people reach for is CFPB Section 1033. As of this writing it is not something to build on: a federal court enjoined the Bureau from enforcing it, and the rule is back in reconsideration after an August 2025 advance notice, with the April 2026 compliance date passing without becoming a binding trigger. Where the rule eventually lands may change the picture for a bank this size; today it does not govern the work.

What the work does rest on is the accountholder's own authorization to access their data, captured and logged, with an NDA where the engagement calls for one and access scoped to the records the use case needs. Sessions are driven as the consenting customer, never around their authentication, and we keep consent records and request logs so the access trail is auditable.

What we plan around on a Brookhaven build

A few specifics shape the work, and we handle each as part of the engagement rather than handing them back as homework.

• Aggregator coverage is uncertain for one branch. We check whether the networks already index Bank of Brookhaven (cert #35439) at the start; if coverage is thin or missing, the build runs against a consenting live account instead of stalling on a third party.
• The session is short and device-bound. The app opens with a 4-digit passcode or biometric, so we model the session and token lifecycle — device binding and re-auth included — and the worker re-establishes a session cleanly when one lapses mid-read.
• Transactions carry user enrichments. Tags, notes and receipt or check photos sit beside the structured fields. We decide with you whether to ingest the attachment binaries or only the structured tags and memos, because pulling images changes your storage and retention footprint.
• Statements and the stream overlap. The monthly PDF and the live feed describe the same money, so we design the reconciliation to match a statement line against an already-streamed transaction rather than count it twice.

Cost and how a build runs

A first drop — the Python and Node clients, the stream worker, the test suite — lands inside one to two weeks. Source-code delivery starts at $300: you get the runnable source and its documentation, and you pay after delivery once the code does what the brief promised. Prefer not to host it yourself? Run it as a pay-per-call hosted API instead, where we operate the endpoints and you pay only for the calls you make, with nothing up front. Access, consent capture and any compliance paperwork are arranged with you as the project runs. Tell us the app and what you need from its data on the contact page and we will scope it.

Screens we mapped against

Public store screenshots used while sketching the surfaces above. Select one to enlarge.

Nearby apps in the same integration set

Same category, often the same customer's wallet — useful when a project wants one normalized feed across several Mississippi and regional bank apps. Listed for context, not ranked.

• Cadence Bank — Tupelo, Mississippi regional bank; checking, savings, transfers and mobile deposit behind a login.
• Trustmark — Jackson-based bank; balances, bill pay and mobile check deposit across a multi-state footprint.
• Renasant Bank — Mississippi-rooted regional; deposit accounts, payments and statements in-app.
• Regions Bank — large Southeast regional serving Mississippi; full retail balances, transfers and deposits.
• BankPlus — Mississippi community bank; account access, transfers and remote deposit.
• The First — Gulf South national bank; checking, payments and mobile statements.
• Citizens National Bank — Meridian, Mississippi community bank; balances, bill pay and deposit capture.
• Hope Credit Union — Jackson-based CDFI credit union; member share accounts, transfers and statements.

Sources, and when we looked

Checked on 15 June 2026 against the app's own listings and primary regulatory material. Feature claims come from the Google Play description and the bank's site; the institution profile from public FDIC/industry records; the Section 1033 status from the CFPB and a law-firm advisory. Primary references: Google Play listing, Bank of Brookhaven mobile-banking page, CFPB Personal Financial Data Rights reconsideration, and Cozen O'Connor's Section 1033 injunction note.

Compiled by OpenFinance Lab's integration engineers — engineering notes, last checked 15 June 2026.

Questions integrators ask first

Can Brookhaven transactions arrive as a live stream rather than a nightly file?

Yes. The build reads the per-account ledger and emits each posted item onto a queue, with a stored cursor so a restart resumes from the last committed point rather than re-reading the whole history. Monthly statements ride alongside as a slower reconciliation feed.

Will an aggregator like MX or Finicity already list a one-branch bank this small?

Sometimes, sometimes not — coverage of single-branch institutions is uneven. We check whether Bank of Brookhaven (FDIC cert #35439) is already indexed during onboarding; if it is not, we build the consented direct route against a live account instead of waiting on a third party.

Do the transaction tags, notes and receipt photos come through, or only the amounts?

Those user-added fields sit next to each transaction and are reachable. We decide with you whether to ingest the attachment images or just the structured tags and memos, because pulling binaries changes your storage and retention footprint.

With CFPB Section 1033 stayed, what is the basis for accessing this data now?

The 1033 rule is enjoined and back in reconsideration, so it is not the thing the work relies on. The dependable basis is the accountholder's own authorization, captured and logged, under NDA where the engagement needs one, with data kept to what the use case requires.