Pulling account, statement and aggregator data out of Bank of Charlotte Mobile

Founded in 1912 in Phenix, Virginia, the bank behind this app runs six branches across one rural county and the surrounding belt, per the Bank Branch Locator listing we opened — and yet the app it ships covers more ground than that footprint suggests. The reason is the embedded PFM layer: the description's own “personal financial advocate” phrasing maps cleanly to Geezeo, the aggregation product Jack Henry has been folding into community-bank front ends since the 2019 acquisition, and it pulls in the enrolled member's outside accounts from a network Jack Henry has previously sized at roughly 17,000 institutions. For an integrator that turns a small Virginia bank app into a useful lever on a much wider book of account data — provided the member is in front of you and authorizes the work.

Bottom line up top: the dependable basis is the member's authorization, not a regulatory entitlement, and the cleanest production route is a session-bound API the studio wraps around the mobile front end on behalf of the consenting customer. The Personal Financial Data Rights rule the US would have leaned on (12 CFR Part 1033) is currently enjoined and back in agency reconsideration, so we design forward into it without depending on it.

Where the data actually sits

The app's screens, read against the description, map to a small number of backend surfaces. None of them are exotic — what makes this app worth integrating is that the PFM layer fans the same session out to the member's other banks.

Routes we would take for this app

Three routes apply here. We pick the mix per build rather than committing to one of them on a brochure.

1. Member-consented session integration with the mobile front end

The spine. The studio takes the customer's written authorization, walks the same auth flow the mobile app walks (digital banking credentials, second-factor, the Jack Henry-style token issuance), and from there reads the account list, transactions, statements and PFM aggregate exactly as the app does — only headlessly and into a stable API contract. Effort is low to moderate, durability is good as long as the quarterly UI-drift check we schedule against a real member account stays current, and almost every native surface in the table above is reachable this way.

2. Geezeo / PFM-level aggregator data on the member's behalf

The same consent gets you the aggregated outside-bank view that the PFM screen already shows the member. We model it as a separate stream because it has its own freshness pattern (aggregator-driven, not session-driven) and its own failure modes when an upstream institution rotates a login or a 2FA prompt. For customers who care about the cross-bank picture, this is usually the most interesting surface in the whole app.

3. Native statement export as the authoritative ledger

For backfill or audit, the monthly PDF the app already saves out is the cleanest source of truth. We parse it once per cycle and reconcile against the session-derived transaction feed; mismatches go to a review queue rather than being silently dropped.

For most consumers of this app, route 1 is the production spine, route 2 is the “value-add” layer that justifies integrating a small bank at all, and route 3 is the safety net behind both. We tell you up front which is wired and which is optional.

What a working call looks like

Illustrative, not the bank's official contract — the actual paths, headers and token lifetimes are confirmed against the live front end during the first day or two of the engagement. Shape is what we are showing.

# 1. Member session bootstrap (run once per refresh window)
POST /digital/auth/session
Host: mobile.bankofcharlotte.<suffix>
Content-Type: application/json
X-Device-Id: <pinned-uuid>
{
  "username": "<member>",
  "credential": "<passcode-or-token>",
  "mfa": { "channel": "device-biometric", "assertion": "<signed>" }
}
-> 200 { "session_token": "ey...", "ttl_s": 1800,
         "consent_id": "bocc-2026-05-20-..." }

# 2. Native account list
GET /digital/accounts?include=balances,status
Authorization: Bearer <session_token>
-> 200 [{ "account_id":"...", "type":"checking",
          "available":1234.56, "ledger":1234.56, "currency":"USD" }, ...]

# 3. Aggregated outside accounts via the PFM layer
GET /digital/pfm/links?refresh=lazy
Authorization: Bearer <session_token>
-> 200 [{ "link_id":"...", "institution":"...",
          "status":"ok|mfa_required|stale",
          "as_of":"2026-05-19T22:14Z" }, ...]

# 4. Transaction history with member annotations preserved
GET /digital/accounts/{id}/transactions?from=2026-04-01
Authorization: Bearer <session_token>
-> 200 [{ "tx_id":"...", "posted":"2026-05-12",
          "amount":-42.10, "memo":"groceries",
          "tags":["household"], "image_ids":["rcpt_..."] }, ...]

# Failure handling (sketch)
# 401 -> re-auth, do not retry blind
# 423 -> consent revoked; stop, alert the customer
# 5xx -> exponential backoff, surface upstream stall to ops

Note the consent_id: it is what we log alongside every downstream call so a revocation, an audit, or an incident-response request can be traced back to a specific authorization rather than a generic service account.

Files that change hands at the end of the cycle

Concretely, for an engagement on this app:

• An OpenAPI 3.1 spec describing the contract we expose to your side — account list, transactions, statements, PFM links, transfers, card controls — with auth, error model and pagination written out.
• A short protocol and auth-flow report: how the mobile front end authenticates, where the token lives, how the PFM session is bootstrapped, where the brittle joints are.
• Runnable source for the spine. Python (httpx or requests) by default, Node.js (undici / axios) on request, with a small CLI that exercises every endpoint against a real consenting account in dry-run mode.
• An automated test pack: contract tests against recorded fixtures and a thin live-call suite that runs nightly under your sandbox member.
• Interface documentation written for a human integrator, plus a one-page operational note on consent retention, log scope and what to do when the front end changes.
• Compliance posture artefacts: a data-minimization map (what we read vs. what we store), an NDA where the relationship calls for one, and the consent text used during member onboarding.

The US data-rights picture in 2026

For a community bank this size, the federal regime that might one day standardize the data interface is the CFPB's Personal Financial Data Rights rule, 12 CFR Part 1033 — and as of this writing it is not the basis we are integrating against. The Eastern District of Kentucky enjoined the Bureau from enforcing the rule, an Advance Notice of Proposed Rulemaking from the CFPB went out in August 2025, and the reconsideration is open with no replacement text published; smaller institutions like The Bank of Charlotte County were always in a later compliance wave under the rule as finalized, and that wave is, in any case, on hold. We treat §1033 as a forward-looking design constraint, not as present law for this bank.

What we actually rely on for this app is older and simpler: the member's own authorization, captured in writing, scoped to specific data domains and specific destinations, with an explicit expiry and a one-click revocation that drops the consent_id we log against every call. The PFM screen this app already exposes the member to operates on the same logic — Geezeo / the bank's aggregation partner pulls outside accounts on the member's consent, and our integration sits one layer over that with the same authorization shape. Data we do not need, we do not read; data we read, we keep for a stated retention window or pass through without persisting at all, depending on the build. If a successor to §1033 settles into a form that obliges this institution to expose a standardized data interface, we re-fit to it; until then, the consent record is the contract.

Things we plan around during the build

Concrete engineering items we map out at the start, framed as our side of the work:

• The two streams have different freshness patterns. Native account data refreshes on the member's session; PFM-aggregated data refreshes on the aggregator's own schedule and can sit a day stale even when the session is hot. We model this in the API contract so a downstream consumer never confuses a stale aggregator link for a transaction the bank lost.
• Front-end drift is a maintenance line, not a one-off risk. Small banks ship UI changes a few times a year as their core vendor pushes updates. We bake a re-validation routine into the contract tests and schedule a quarterly review against the live app on a consenting account so the spine does not silently break the morning after a vendor release.
• Consent expiry and the session token are not the same clock. The session token rolls every half hour or so on Jack Henry-style stacks; the member's authorization to us has its own duration and revocation surface. We tie a hard stop into the runtime so a revoked consent halts every call within one cycle, not eventually.
• PFM links can be in “MFA required” state. Outside-bank links sometimes need a fresh member challenge on the aggregator side. We surface that state to your side as a first-class status rather than a stale balance, and route the member back into the app to clear it.
• Access and sandbox setup is on us during onboarding. If a project needs a sponsoring member, a consent template, or a written test-account agreement with the bank, we run that down with the client during week one rather than asking you to clear it before we will start.

Other small-bank apps in the same shape

An integration over Bank of Charlotte Mobile sits in a familiar US neighborhood — regional and rural community-bank apps, often on the same one or two core vendors, where the value of a unified data layer comes from picking up the long tail rather than a single national brand. Names worth holding in the same mental model:

• Atlantic Union Bank — Richmond-based Virginia regional with the largest branch footprint in the state; broadly similar mobile feature set and a much wider customer book.
• Burke & Herbert Bank — long-running Alexandria-headquartered community bank spanning five states; useful for any integration that wants the DC-corridor angle alongside Charlotte County.
• Carter Bank & Trust — Martinsville, Virginia, more than 60 branches across Virginia and North Carolina, similar PFM-on-community-core profile.
• Sonabank — Southern National's brand, DC / Maryland / Virginia, often cited as one of the larger Virginia community banks by branch count.
• Benchmark Community Bank — Kenbridge, Virginia, with overlapping rural Southside Virginia and northern North Carolina geography to Charlotte County.
• Virginia National Bank — Charlottesville-based, retail and small-business focus, comparable mobile capabilities including P2P and check deposit.
• TowneBank — Hampton Roads-headquartered, one of the largest Virginia-based banks, broader product set under similar regulatory posture.
• FVCbank Mobile — First Virginia Community Bank, DC-metro commercial focus; useful as a contrast point on business-banking surfaces.
• Farmers Bank Mobiliti — rural Virginia community bank on Fiserv's Mobiliti platform, a useful counter-example for projects that need to handle both Jack Henry and Fiserv stacks.
• First Community Bank — Bluefield, Virginia / West Virginia regional, comparable scale and product mix to Bank of Charlotte County.

Questions integrators tend to ask first

This is a tiny community bank — does its app actually hold enough structured data to bother integrating?

Yes. The app describes account aggregation across the customer's other banks and credit unions, plus per-transaction tags, notes, receipt photos, statements, transfers, P2P payments, mobile deposits and card controls. Behind that sits a Jack Henry-style digital banking core. For a customer in this app, you can reach exactly the same scope they can — which is more than the bank's six branches suggest.

The bank's own description calls the app a “personal financial advocate” that aggregates outside accounts. Where does that data really come from?

The “personal financial advocate” phrasing tracks Geezeo, a PFM layer Jack Henry has been embedding into community-bank front ends since the 2019 acquisition. Aggregated balances and transactions are pulled by Geezeo's data network on behalf of the enrolled member, then surfaced inside this app. For an integrator that means two streams to model: native Bank of Charlotte data, and member-consented aggregated data fanning out to 17,000-odd US institutions per Jack Henry's own number.

Is US Section 1033 the legal hook we should be relying on?

Not as of mid-2026. The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) was finalized in late 2024 but has since been enjoined by the Eastern District of Kentucky and reopened for reconsideration; the April 2026 first-wave compliance date came and went without enforcement. The dependable basis is still the member's own authorization — written consent, scoped, revocable. Section 1033 is something to design forward into, not present-tense law to lean on.

Do you actually do mobile check deposit, card on/off and similar “write” actions, or only read?

Read is the easier half and what most clients ask for first: balances, history, statements, the PFM aggregate view. Write actions exist in the app — internal transfers, P2P payments, card lock/unlock, alert settings — and we can wire them, but each one needs its own consent text, idempotency handling and a clear audit trail. We scope the write surface explicitly per project rather than bundling it by default.

Sources opened for this brief

Worked off the app's Play Store listing and the bank's own digital banking pages, cross-checked against FDIC and routing-number references and the current CFPB position on §1033. Specific deep links opened during the assessment:

• Bank of Charlotte Mobile — Google Play listing (feature set, package id).
• The Bank of Charlotte County — Mobile Banking page (bank-side description of the app).
• CFPB — Personal Financial Data Rights Reconsideration (ANPR and current status of §1033).
• Cozen O'Connor — Section 1033 Compliance Date alert (injunction in the Eastern District of Kentucky; missed April 2026 first-wave date).

A typical build on this app lands at about a fortnight of work and produces an OpenAPI spec, a small set of Python or Node modules that genuinely run against a consenting member's session, a short protocol report and a maintenance routine for when the front end changes. Source-code delivery starts at $300, invoiced only after you have run the code on a real consenting account and signed off — nothing up front, nothing if it doesn't work. If you would rather not handle the code at all, point at our hosted endpoint and pay per call with no upfront fee, and the same authorization model carries through. Either way, send the app name and what you need pulled to /contact.html and we will take it from there; access and consent paperwork are handled with you during the first week, not asked for as a precondition.

Mapping reviewed 2026-05-20 by the OpenBanking Studio integration desk.