Ingesting Panhandle First Bank balances and transactions, member-consented

Spearman, Texas — Panhandle First Bank serves farmers, ranchers and small business in the Texas Panhandle. ICBA-member, FDIC-insured per the bank's own site, formed from the May 2024 merger of First National Bank and Bank of the Panhandle (per the bank's customer FAQ). The mobile app at bank.mypfb.grip sits on the Banno (Jack Henry) digital-banking platform, the same stack behind a few hundred US community banks — and that platform reality, not the bank's size, drives most of the integration choices below.

The route question, answered for this bank

Three routes apply here in practice, and the choice is mostly about how much of the app's surface the downstream product needs to reach.

Route A — Consumer-permissioned, via aggregator

Plaid, Finicity and Akoya have all integrated to the Banno Digital Platform under Jack Henry, so a downstream product reaches Panhandle First Bank the same way Mint or Copilot reaches it — on a per-member consent token, member-driven OAuth screen, returning balances, posted transactions and statement metadata. What we set up: the aggregator account, the consent screen wiring, and the consent-refresh hook so the token does not silently lapse.

Route B — Authorized mobile-interface integration

With a consenting member's account and a written engagement letter, we map the Banno-stack traffic from the app — TLS-pinned, OAuth on top, device-bound session, MFA challenge surface — and recover the request/response shapes the aggregator route does not return. Bill-pay scheduling, mobile-deposit history, and intra-account transfer initiation live here. Same legal posture as a member scripting against their own account; we deliver it as a clean wrapper.

Route C — Native export

The web portal at secure.mypfb.bank emits statement PDFs and CSV transaction exports. A scheduled download bot is the simplest fallback when the rollout is one member feeding one downstream system and the rest of the integration effort is not worth it.

For most read-only ingestion Route A carries the load. Route B fills in what the aggregator surface does not reach — bill-pay schedule, mobile-deposit metadata, transfer initiation. Route C earns its place only when the scope is one member and one consumer system; we will say so when that is the honest answer.

Data the app actually exposes

The delta-sync surface, as we hand it over

Polling against an aggregator-issued member token, with a cursor we persist between runs so the same window is never replayed for free. Illustrative shape; the exact field names track the chosen aggregator at build time.

# delta-sync against a consenting member's Panhandle First Bank account.
# member token is obtained on the aggregator OAuth screen (Route A);
# the cursor is persisted per (member_id, account_id) on our side.

POST /panhandle-first-bank/v1/sync/transactions
Authorization: Bearer <aggregator-member-token>
{
  "account_id":  "act_7f8c…",                  # opaque, consent-scoped
  "cursor":      "tx_2026_05_30T19:42:11Z",     # last cursor we stored
  "limit":       200,
  "include":     ["posted", "pending"]
}

200 OK
{
  "account_id":  "act_7f8c…",
  "items": [
    {
      "tx_id":         "tx_2026_05_30T19:50:11Z",
      "posted_at":     "2026-05-30T19:50:11Z",     # null while pending
      "auth_at":       "2026-05-30T19:48:02Z",     # swipe-time
      "amount_minor":  -4287,                      # USD cents, signed
      "currency":      "USD",
      "counterparty":  "UTILITY CO #4411",
      "mcc":           "4900",
      "status":        "posted",                   # posted | pending
      "settlement_id": "stl_3b…f9"                 # idempotency key
    }
  ],
  "next_cursor":   "tx_2026_05_30T19:50:11Z",
  "consent": {
    "expires_at":  "2026-08-28T00:00:00Z",         # ~90 day default
    "refresh_url": "https://…/consent/refresh"
  }
}

Two practical details from running this against the Banno stack on a small community bank. First, auth_at and posted_at often differ by a calendar day — end-of-day batching at a small institution shifts the posting time forward, and books that key on swipe-time need both. Second, settlement_id is the idempotency anchor: replaying any sync window against it is safe.

What ships, in order of what runs first

• Python and Node.js client modules with the cursor / delta-sync loop already wired against the chosen aggregator (Plaid, Finicity, or Akoya), plus a thin pluggable layer so swapping providers is a config change.
• A test harness that runs against a live member-consented account on a cron and surfaces shape drift on the next CI run when the Banno platform pushes a release.
• A webhook receiver, signed and replay-safe, for the aggregators that push transaction notifications instead of expecting a pull.
• A consent-refresh worker that watches the consent window and triggers the in-product renewal prompt before the token stops returning data.
• Settlement-id keyed posting writes — replays of the same sync window do not double-enter rows on your ledger.
• An OpenAPI / Swagger spec for the wrapped surface (balances, transactions, bill-pay where in scope, transfers, statements) so the downstream team has typed clients without writing the YAML.
• An auth-flow report covering the Banno-stack OAuth + device-binding + MFA challenge surface, mapped to whichever route we delivered.
• A short data-retention and consent-record note, ready to attach to your internal compliance file.

Build notes for this bank

• The Banno stack is the lever. Once we map the session model (OAuth + device binding + MFA challenge) for one Banno-platform community bank, the same skeleton reuses across other Banno-stack issuers — we keep that internal so the per-bank build is mostly mapping work, not re-discovering the auth chain. The trade-off the integrator should know: when Jack Henry pushes a Banno release, surfaces can shift; we treat that as the spec we ship, with the CI harness above as the early-warning channel.
• Aggregator surface vs mobile surface. Read-only balance and transaction flows ride Route A cleanly. Bill-pay schedule, mobile-deposit metadata, and intra-account transfer initiation are not on the three aggregators' surfaces; we either pick them up on Route B or scope them out of v1. We make that call with you during the first conversation, against your actual downstream system.
• Consent and the 90-day cliff. Aggregator consent defaults to about a quarter; we wire the renewal prompt into the downstream system's own user flow so the cron sees the new token before the old one starts returning empty.
• Small-institution batching. Posting time at a community bank is end-of-day, not card-network-real-time. Anything that needs a "real" swipe time stores both auth_at and posted_at; reconciliation jobs key on posted_at.

Consent and the §1033 question

The dependable basis for this integration today is the member's own authorization — Reg E for the bill-pay and transfer surfaces, GLBA on the data side, state UDAP, and Panhandle First Bank's own deposit-agreement language on what the member is permitted to share. CFPB §1033 (the Personal Financial Data Rights rule) is tracked but not relied on: the rule was finalized in October 2024, then enjoined by the Eastern District of Kentucky in October 2025, and the Bureau opened a reconsideration ANPRM in August 2025 (per the CFPB's rulemaking page and ICBA's coverage of the stay). If the reconsidered rule lands with a community-bank exemption — which ICBA has been pushing for at the smaller end of the asset range — banks the size of Panhandle First Bank may sit outside the obligation; if it lands without one, the same data shapes shift onto a regulated permissioned-data path. Either outcome, the member's consent record stays the audit trail. Data-minimization defaults on our side: the lowest aggregator scope that returns what the downstream system actually queries, no PII stored that is not in scope, and member-deletable on request.

Freshness, drift, and what breaks first

Consent expiry is silent on the bank side, not silent on yours — the aggregator simply starts returning empty paginations once the token lapses, and the renewal worker prompts the member from inside your own product before that happens. Surface drift is the other failure mode: the Banno stack ships releases on Jack Henry's cadence, field names can move, and the CI harness against a live consenting account catches the change on the next nightly run rather than on your customer's screen. Latency on the polled path is a function of the aggregator, not the bank — we have seen ~30–90 second end-to-end delivery on Plaid-mediated transactions during the build, and we publish that observed range in the deliverable.

Normalized money shape, for downstream sanity

The wrapper standardises onto a small shared shape regardless of which aggregator answered the call, so the downstream schema does not care.

// account
{
  "id":              "act_7f8c…",
  "issuer":          "panhandle-first-bank",
  "type":            "checking",          // checking | savings | money-market | loan
  "currency":        "USD",
  "balance_minor":   1284200,             // available balance, USD cents
  "as_of":           "2026-05-31T13:00:00Z",
  "consent_id":      "csn_…"
}

// transaction (subset — see snippet above for the full record)
{
  "id":              "tx_…",
  "account_id":      "act_…",
  "amount_minor":    -4287,               // signed, debit negative
  "posted_at":       "2026-05-30T19:50:11Z",
  "settlement_id":   "stl_3b…f9"
}

What was checked, and where

For this write-up we read the bank's own customer site (mobile-app FAQ, merger notice, services pages), the Google Play listing for bank.mypfb.grip, the CFPB's published rulemaking-status pages on the §1033 reconsideration, and ICBA's coverage of the rule stay and of Jack Henry's open-banking aggregator integrations. We did not interview anyone at the bank; the technical claims about the Banno stack are based on Jack Henry's public material and the package-naming convention shared across Banno deployments, and would be confirmed against a consenting member's traffic during a build.

• Panhandle First Bank — Mobile App FAQ (mypfb.bank)
• Google Play — Panhandle First Bank (bank.mypfb.grip)
• CFPB — Personal Financial Data Rights Reconsideration
• ICBA — Jack Henry partners with open-banking providers

Mapping by OpenFinance Lab's banking-integration team — May 2026.

Peer apps in the same shape

Other US community-bank apps an integrator is likely to bundle into the same data-ingest layer. Each holds the same broad data shape — accounts, transactions, statements, bill-pay, transfers — and several sit on the same Jack Henry / Banno platform.

• Texas First Bank Mobile — Texas City community bank with checking, savings, transfers and bill-pay; a natural neighbour for a Texas-focused rollout.
• First Financial Bank (Texas) — 79-branch regional bank from the Panhandle to the Gulf, similar consumer + small-business mix.
• Stellar Bank Mobile — Houston-area community bank, comparable account and bill-pay surfaces.
• TX Community Bank — small Texas community bank covering checking, savings, time deposits and loans.
• State National Bank Mobile — multi-state community bank with mobile check deposit and a similar deposit-product line.
• Frost Bank Mobile — larger Texas regional, often the brand-recognised comparison for buyer due diligence.
• Texas Capital Bank Mobile — Texas-headquartered, mobile banking for retail and commercial customers.
• Independent Financial — Texas-headquartered community/regional bank; overlap on small-business surfaces.
• CBNA Mobile Banking — Community Bank N.A.; runs on the same Grip-derived Banno stack (com.cbna.grip) and so shares the auth-flow shape almost verbatim.

Questions integrators ask first

Engagement and the one-line next step

Delivery cycle for a first drop runs one to two weeks against a consenting member account. Source-code delivery starts at $300, paid only after the build is in your hands and runs cleanly. The hosted-API alternative is pay-per-call with no upfront fee — you call our endpoints and pay for what you actually consumed. Either way the next step is the same: a one-line note via /contact.html describing what you want from Panhandle First Bank's data, and we come back with the route, the surfaces in scope, and a date.