MyPeach — a two-branch community bank app and what it takes to read its data from outside

Peach State Bank & Trust runs two branches, one in Gainesville and one in Braselton, and MyPeach is the customer-facing channel for those deposit and loan accounts. The app does one less-common thing for a bank this size: it lets the customer link external accounts from other banks and credit unions, so a single screen shows Peach State balances next to balances held elsewhere. That aggregated view is the interesting integration surface. The rest is what you would expect — transactions, statements, transfers, P2P payments, mobile-deposit images, card controls — plus user-attached metadata (tags, notes, receipt photos) the listing describes.

What follows is a working brief. What is reachable, the authorized routes we use to reach it, the deliverables that come out of an engagement, and the engineering judgments specific to this bank.

What MyPeach exposes once a user is signed in

The surfaces below come from the app's own description and the bank's online-banking page; granularity reflects how a customer session presents them.

Three integration routes — what fits this bank

Route A — consent-based aggregator pull (Plaid, MX or Finicity)

For a community bank of this size, mainstream aggregators are the practical spine. The user authorizes once, an aggregator returns a token, and your service reads account-list, balance and transaction data through a normalized API. What returns is bounded — typically account metadata, balances, posted/pending transactions with descriptor and amount — but it is durable across the bank's UI changes because the aggregator absorbs that work. We confirm field coverage for this specific bank against a consenting test account at the start of the build, since aggregator coverage is institution-by-institution and shifts over time.

Route B — authorized interface integration under the customer's own session

This is how we reach the surfaces an aggregator does not carry: the user's own tags and notes on a transaction, the receipt and check photos attached to it, mobile-deposit items, the monthly statement PDFs as files, and card-status events. The build runs against the customer's session with their written authorization; we analyze the app's protocol, reproduce the auth and refresh flow in Python or Node, and expose the surfaces above as ordinary endpoints in the OpenAPI we ship. Effort is meaningfully higher than Route A, durability is lower (the app's front end changes), and the payoff is the data that only this app holds.

Route C — native export (statement PDFs, in-app save)

The app description says monthly statements can be saved. On a small build this is enough for long-horizon history when nothing real-time is needed; on a larger build it is a fallback we wire alongside Route B so statement archives keep populating even if the interface route needs a maintenance pass.

On a real build for this bank, we would lean on Route A for balances and transactions because it is the most durable surface, layer Route B on top to reach the tags, notes, receipt photos, mobile-deposit images and statement PDFs that the aggregator does not carry, and keep Route C as a slow, reliable backstop for historical statements. That bounds the brittle work to the smallest surface that needs it.

What ships at delivery

For an engagement scoped to the surfaces above, you receive:

• An OpenAPI 3.1 specification covering the Peach State session endpoints, the aggregator-side endpoints, and the unified read surface that fronts them — with the two sources clearly labeled, not blended.
• A protocol and auth-flow report: how the MyPeach session is established, how its token (and supporting cookies) is refreshed, and how mobile-deposit and statement-PDF retrieval differ from ordinary transaction reads.
• Runnable source for the key endpoints, in Python (httpx-based) or Node.js (undici/axios) — your call — including a retry-and-backoff policy and a webhook for stale-connection alerts.
• Automated tests against fixtures captured from a consenting account: unit tests for parsing, an end-to-end test for the auth-and-fetch loop, a contract test for the OpenAPI surface.
• An interface-documentation pack: field-by-field notes, known edge cases, the consent and data-retention policy as we operate it on this build.

An auth-and-fetch example, lightly redacted

Illustrative shape, confirmed during the build against the live app. The aggregator side uses one of the standard SDKs; the interface side is a session-token chain with a periodic refresh.

# Aggregator side — Route A, balances and transactions
from openbanking_studio.mypeach import session

# Item token obtained via consent flow; persisted server-side per user.
client = session.from_item_token(ITEM_TOKEN)
accounts   = client.accounts.list()              # Peach State + linked-external
balances   = client.balances.fetch(account_ids=[a.id for a in accounts])
txns       = client.transactions.range(
    account_id=accounts[0].id,
    start="2026-04-01", end="2026-04-30",
    include=["pending","posted","descriptor","amount"],
)

# Interface-integration side — Route B, the surfaces aggregators don't carry
from openbanking_studio.mypeach import portal

portal_session = portal.login(
    username=USER, password=PASS,            # held in the customer's own vault
    device_id=DEVICE_ID, mfa_callback=mfa_prompt,
)
# Per-transaction user metadata: tags, notes, receipt and check photos
extras = portal_session.transaction_extras(
    account_id=accounts[0].id,
    txn_id=txns[0].id,
)
# Returns: { "tags": [...], "note": "...", "attachments": [ {"kind": "receipt", ...} ] }

# Statement PDF — Route C / portal fallback
pdf_bytes = portal_session.statements.download(
    account_id=accounts[0].id, cycle="2026-04",
)

Things we account for on this build

Three engineering notes specific to this bank, written as how we handle them rather than as preconditions on you:

• The aggregation surface is split from the bank's own ledger. MyPeach mixes Peach State accounts with external linked balances in one view; we mirror that split rather than papering over it. Peach State's own accounts arrive from the customer session, the external ones from a parallel aggregator pull, and both are labeled in the OpenAPI so you don't end up with an opaque "all accounts" blob whose origin you can't audit.
• User-attached metadata is first-class, not a footnote. Tags, notes, receipt and check photos exist only inside the bank's session — aggregator feeds don't surface them. We wire those endpoints during the build instead of leaving them as a "maybe later" extension; if your use case doesn't need them we say so and don't bill for them, but where the use case is expense audit or receipt evidence they ship as ordinary fields beside the transaction.
• The consent and refresh window is handled in the source, not in your operations. Aggregator tokens expire and the user will eventually need to re-authorize; the interface session has its own shorter refresh cadence. The delivered source covers both with a refresh path and a webhook that fires when a connection has gone stale, so the integration tells your app it is degraded instead of silently going dark.
• UI-front-end changes are scheduled work, not a surprise. Community bank mobile apps in this size class typically run on a vendor platform whose UI gets touched on a regular cadence. On the maintenance side of an engagement we re-check the interface surfaces against a known-good fixture set on each cycle, so a vendor update lands as a known fix rather than as a production outage.

Where US data-rights law sits on this work right now

Peach State Bank & Trust is FDIC-supervised, state-chartered, Fed nonmember, per its FDIC institution record. There is no in-force federal open-banking obligation on this bank today. The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is currently enjoined and back in reconsideration at the agency; for a bank Peach State's size the rule's draft obligations would, in any case, sit in a later compliance tier even if reinstated as drafted, so we do not treat its specific provisions as settled law and do not build the integration around them.

The dependable basis is the customer's own written authorization. We back it with an NDA where the customer needs one, scoped data minimization (we read only what the use case names), and a per-authorized-account consent log. §1033 is something we watch for community banks like this one — not the framework that carries the work today.

Other community bank and credit union apps people compare

Adjacent apps in the same size class, neutral notes only — many of them carry similar data domains and similar integration routes, which is what makes a single normalized layer worth building on top:

• Peach State FCU Mobile Banking — a credit union with a similar name, separate institution; mostly the same domains plus share/loan accounting.
• 1st Source Mobile Banking — regional bank mobile app, ordinary balance/transaction surface, separate eMortgage flow.
• Abilene Teachers FCU Mobile — small credit union app, balances and transactions, mobile deposit.
• Arrowhead Mobile Banking — credit union app with card controls and external transfers similar in shape to MyPeach.
• Launch Credit Union — Florida-area credit union, deposit and loan accounts, P2P.
• Marine Credit Union — regional credit union, statements and card controls.
• Southland CU — Southern California credit union, same surface set with member-business banking on top.
• Radiant Credit Union — Florida credit union, mobile deposit and external transfer.
• Grow Mobile Banking — community-bank mobile front-end with transactions and statements.

How this brief was put together

Source material for this run: the MyPeach Google Play listing (description, package id bank.peachstate.grip); the bank's own online-banking and electronic-services pages; the FDIC BankFind institution record for certificate 57923; and primary documents on the current US data-rights position. Specific deep links checked:

• FDIC BankFind — Peach State Bank & Trust, certificate 57923
• Peach State Bank & Trust — Online Banking Services
• CFPB — Personal Financial Data Rights (current status page)
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 22, 2025)

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

Questions integrators of MyPeach actually ask

Does MyPeach expose the multi-bank aggregated view to integrators, or only its own accounts?

The aggregation is a customer-facing read inside the session: MyPeach pulls balances from the user's linked external institutions and shows them alongside Peach State accounts. On the integration side that becomes two parallel sources we mirror — Peach State's own ledger via the customer session, and a separate aggregator pull for the external ones. Both arrive in the delivered OpenAPI as labeled, separable feeds so the boundary is never ambiguous in your data model.

Is Peach State Bank & Trust reachable through Plaid, MX or Finicity?

Mainstream aggregators carry most US community banks of this size, but coverage of a specific institution and the exact fields each aggregator returns vary and change over time. We confirm reachability and the field set actually returned at the start of the build, against the user's own consenting account, rather than working from a directory entry. Where the aggregator path falls short, we layer authorized interface integration to cover the rest.

Can the user-added tags, notes and check-image attachments be pulled out programmatically?

These are unique to MyPeach — aggregator feeds do not carry them because they live inside the bank's own customer session. Reaching them is part of the authorized interface integration we run under the consenting account holder. In the delivered source they appear as ordinary fields hanging off the transaction they belong to, not as a side channel.

Where does US data-rights law sit on this work right now?

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) was published but is currently enjoined from enforcement and back in reconsideration at the agency, so the dependable basis for the work is the consumer's own written authorization — as it was before the rule — not its draft fee structure or compliance phases. We keep consent records and a scoped data-minimization log; that is what carries the build today.

From $300 buys a runnable Python or Node project for the surfaces above, an OpenAPI document, the auth-flow report, and the test suite — billed only after delivery and once you have run it. The hosted alternative is a metered endpoint we operate against the same surfaces: you pay per call, no upfront commitment. Cycle is one to two weeks for this scope. Brief us at contact with the app name and what you need from its data; access details and authorization are arranged together with you during onboarding.

Mapping updated 2026-05-21.