Reaching account data inside the Panhandle First Bank app

Panhandle First Bank is the brand that came out of the 1 May 2024 merger of First National Bank in Spearman, Texas and Bank of the Panhandle in Guymon, Oklahoma — two small institutions that had partnered for nearly four decades before they consolidated, per the merger announcement in Bankers Digest. The combined bank serves agricultural and small-business customers across four towns (Spearman, Guymon, Dumas, Perryton) and ships one mobile app — Android package bank.mypfb.grip, iOS App Store listing id 6498960700 — that sits in front of the secure.mypfb.bank portal. The integration question for a third party is narrow and the surface is small. That is good news; it makes the work tractable.

Where the account data actually lives

Panhandle First Bank's app surfaces the same record set most small US community banks expose to their customers: it is small but it is the real ledger view. The table below is what an integrator can plan against, in the words the app itself uses where possible.

Locator data (branches and ATMs) is also in the app, but it is reference, not the integration target. What people pay us to reach is the first six rows.

Routes we'd use to reach it

1. Consenting-account integration through the secure.mypfb.bank session

The reliable route is the one the account holder already uses. We map the sign-in flow (4-digit passcode or biometric on the device; username and password to the web portal), the token or cookie lifetime, and the read endpoints the app and web client call after authentication. The holder authorizes the studio in writing to act as their agent against their own data; the studio runs scoped reads against the same back-end. This works whether or not a vendor publishes anything externally, because the consumer's own access right is the basis.

2. Native PDF statement export

The app already lets the holder "view and save monthly statements" and offers e-statement enrollment in Settings — both confirmed against the bank's Digital Banking page and the listing copy. For workflows that only need closed-cycle data (lending, audits, year-end), we automate the consenting download and parse the PDFs into normalized JSON. Lower-touch, lower-frequency, very durable.

3. Aggregator-style refresh wrapper

Where an AP system or accounting platform needs continuous balance and transaction pulls, we wrap the consenting session in a refresh wrapper with consent-renewal timing built in. This is mostly for one customer at a time — Panhandle First Bank serves a couple of small Texas/Oklahoma counties, so volume planning is per-account, not per-million.

Route 1 is what we'd ship for almost any practical request involving this app. Route 2 is the cleanest fallback when only statements matter. Route 3 only earns its keep when there is a real polling SLA on the other side.

What you get back from us

• An OpenAPI 3.1 specification covering balances, transactions, the statement archive, scheduled bill payments and transfers — written against Panhandle First Bank's actual fields, not a generic template.
• A protocol & auth-flow report: the sign-in handshake, token or cookie chain, MFA stepping, refresh boundaries, and the specific failure modes (locked-account responses, MFA challenges, session timeouts).
• Runnable source in Python and Node.js for each read endpoint, with a small CLI to dump a consenting account's recent statements to disk.
• An automated test suite that targets a sponsor sandbox or a consenting test account; the test harness is yours to keep so the integration can be re-validated after a UI change.
• Interface documentation aimed at the team that will run this in production, not just the team that will accept it.
• A short consent & retention guide: what the studio asks the account holder to sign, how long tokens are kept, what is logged, and how revocation works.

A worked example: pulling a statement for a consenting account

Illustrative shape, finalized during the build against a real consenting session — endpoint paths and headers are confirmed at that point, not guessed:

# Illustrative — exact paths confirmed during the build, not asserted here.
POST https://secure.mypfb.bank/auth/login
Content-Type: application/json
{ "username": "<holder>", "password": "<holder>", "device_id": "<persisted>" }
=> 200 { "session_token": "...", "mfa_required": true, "mfa_channel": "sms" }

POST /auth/mfa/verify
{ "session_token": "...", "code": "######" }
=> 200 { "access_token": "...", "expires_in": 1800 }

GET /accounts                              # list of holder accounts (acct_id, type, mask)
GET /accounts/{acct_id}/statements         # cycle list with cycle_start, cycle_end, doc_id
GET /accounts/{acct_id}/statements/{doc_id}/pdf
    Accept: application/pdf
=> 200 <PDF bytes>

# Studio side: PDF -> normalized JSON
{
  "account_id": "...", "cycle_start": "2026-04-01", "cycle_end": "2026-04-30",
  "opening_balance": 12480.55, "closing_balance": 13902.10,
  "transactions": [
    {"posted": "2026-04-03", "amount": -42.18, "desc": "...", "running_balance": 12438.37},
    ...
  ]
}

Error handling is the unglamorous half of the build: the locked-account state, the soft MFA timeout, the silently re-issued session cookie after a refresh. The test harness exists so those don't become 2 a.m. surprises.

Practical things this build has to account for

• The Android package bank.mypfb.grip shares a .grip suffix with several other small community-bank apps — Community Bank N.A. (com.cbna.grip), Tompkins Community Bank (com.tompkinstrust.grip), Key Community Bank, Our Community Bank, and others, per their Play Store listings. That points to a shared white-label mobile platform under the hood. We confirm during the build whether the same surface idioms apply here, and we never reuse another bank's parser without verifying — the back-end and the front-end can both differ even when the package suffix doesn't.
• The bank only completed its post-merger rebrand and app migration in mid-2024; customers were asked to upgrade to the new app to pick up the new branding and features. Front-end revisions in the eighteen months after a merger are normal, so the build plans for a periodic re-check against a consenting test account, with the parser patched and the spec republished when a screen shape moves.
• Customer mix is concentrated in agricultural and small-business borrowers across the Texas/Oklahoma panhandle. Integrations are usually for an accountant, an AP system, or a lending workflow serving one customer at a time, not a national aggregator. The build is scoped per consenting holder, with notes on how to add more, rather than designed for fan-out from day one.
• Legacy account numbers from FNB Spearman and Bank of the Panhandle were re-pointed during the merger cutover; the build maps to the unified Panhandle First Bank account identifiers, not the predecessor ones, and we keep a small translation table where a customer is mid-handover on paper systems.

Authorization, and where Section 1033 sits right now

The dependable basis for this work is the account holder's own authorization — a signed agreement naming the studio as their agent for the agreed read endpoints, a recorded sign-in that the holder performs, time-bounded tokens, full logging, and a one-line revocation. That is what the build runs on. It is also what underlies every other AIS-style integration in the United States today, regardless of where federal rulemaking ends up.

The CFPB's Personal Financial Data Rights rule (Section 1033) is currently not the governing framework. The Bureau is enjoined from enforcing it, and as the CFPB's own Personal Financial Data Rights Reconsideration page documents, the rule is back in reconsideration with an Advance Notice of Proposed Rulemaking issued in August 2025. Even under the originally finalized text, since stayed, a depository institution of Panhandle First Bank's size would not have had a near-term compliance date — the original phase-in pushed the smallest community banks out by years. None of that is settled present-tense law to plan against. The page does not assume otherwise. Consent is the load-bearing piece.

For records, the studio operates under NDA where the integrating party requests one, keeps consent artefacts on file, minimizes stored data to what the agreed endpoints actually return, and documents retention so the holder can revoke and walk away cleanly.

How we'd run the engagement and what it costs

$300 buys the runnable source for a Panhandle First Bank integration covering the core read set — balances, transactions, the statement archive, scheduled payments — and you pay only after we hand it over and you've run it against the consenting account you've named. Delivery is one to two weeks from the point the consenting account and a working test login are in place; we arrange that with you during onboarding, it isn't homework you do before we'll begin. Alternatively, you skip the build entirely and call our hosted endpoints on a pay-per-call basis — no upfront fee, you only pay for traffic. To start a conversation about either, reach the studio through the contact page with the account holder's situation and what you'd like to ingest.

Screens we worked from

App store screenshots, used here as evidence of the surfaces named above:

Other Texas Panhandle and small-bank apps we hear about

If you're integrating Panhandle First Bank for a customer, you're often integrating one or two of these alongside it. Each holds a comparable record set behind its own consenting-session surface, and a unified integration usually means normalizing them into one schema:

• FirstBank Southwest (FBSW) — Amarillo-based community bank serving the Texas Panhandle and the DFW/Austin/San Antonio metros; personal, business, and treasury accounts.
• Happy State Bank Mobile — now a division of Centennial Bank with locations across the Panhandle into DFW; the same retail data set behind a refreshed app.
• Texas First Bank — Galveston-County community bank with online and mobile personal banking; comparable surface, different vendor under the hood.
• Texas Bank and Trust — East Texas bank with Zelle, bill pay, and statement archives accessible through the consenting-customer session.
• Texas Regional Bank — South Texas and Rio Grande Valley footprint; the integration looks structurally similar to PFB's.
• First Convenience Bank (First National Bank Texas) — Killeen-based; widely distributed app with retail balances and transactions.
• Community Bank N.A. (CBNA Mobile) — northeast US community bank using the same .grip Android package suffix as Panhandle First Bank; useful as a comparison point on the shared platform pattern.
• Tompkins Community Bank — another .grip package neighbour, with retail and trust account data.
• Our Community Bank (Marshall) — small .grip app with check-deposit, transfers, and statement download.

Questions integrators of this app tend to ask

Does it matter that Panhandle First Bank is a small community bank without a published developer program?

Not for the work we do. The route we ship is the consenting account holder authorizing the studio to reach their own data through the same secure.mypfb.bank session they already use; whether a vendor maintains a public program is independent of that.

What does the consenting-account authorization actually look like in practice?

A signed authorization from the account holder naming the studio as their agent, a recorded sign-in that the holder performs (so credentials stay with them when that is the preference), and a token-handling protocol that keeps the session scoped to the agreed read endpoints. The whole thing is logged, time-bounded, and revocable.

We have customers on both the legacy First National Bank and Bank of the Panhandle accounts — does the integration reach both the same way?

All accounts now live behind the unified Panhandle First Bank app and the secure.mypfb.bank portal after the 1 May 2024 cutover, so the surface is one. Legacy account numbers were re-issued or re-pointed during the merger; the build maps the customer's current account identifiers, not the predecessor ones.

How do we keep the integration working after the next mobile app update?

A small periodic re-check runs against a consenting test account; when a screen or endpoint shape changes, the parser is patched and the OpenAPI spec is republished. The build includes the harness so it does not become a black box on day 31.

How this brief was put together

Sources opened for this page: the bank's own Digital Banking page and Mobile App FAQ; the Google Play listing for bank.mypfb.grip and the App Store listing; the merger announcement in Bankers Digest; and the CFPB's Personal Financial Data Rights Reconsideration page. Reviewed May 2026 by the OpenBanking Studio integration desk; rerun against a consenting account before quoting hard, not after.

Mapping reviewed 2026-05-20.