Pulling member account data out of First Pioneer Mobile

First Pioneer National Bank has been a single-charter community bank in Wray since 1902, and its mobile app is one of hundreds of Banno Grip skins sitting in front of a Jack Henry core. Two facts shape the integration. The data model is rich — full posting history, eStatement PDFs, RDC deposits, P2P, scheduled bill pay, and the user-side annotations members add to transactions inside the app. And the access path is not a public developer API; it is the consenting member's own portal session, mediated through a Banno-hosted front end at my.fpnb.bank.

The integration we'd build for an FPNB consumer is a thin, member-authorized adapter against that portal: log in on the member's behalf with their credential, fetch the JSON the front end already calls under the hood, normalize it, and hand it back as a clean, documented API. Recommended in practice: lead with the portal-session adapter for the live data, and add the eStatement PDF puller as a separate component so historic-document jobs do not contend with the transaction feed.

What sits inside First Pioneer Mobile

These are the surfaces the app actually exposes to a signed-in member, as described in the Play Store listing and the bank's published Online & Mobile Banking FAQ. Granularity is what an integration can realistically read, not what is theoretically there.

Authorized routes into the data

Three routes are actually on the table for an app this size. We pick the one that matches the consumer's risk posture and what they need the data for.

1. Member-authorized portal session (the spine)

The Banno portal at my.fpnb.bank is what the mobile app talks to, and it is reachable directly with the member's credential under their written authorization. The build reproduces the login handshake (username, password, 2FA challenge, device-trust cookie), pins the resulting session, and calls the same JSON endpoints the front end uses. Coverage: every surface in the table above. Effort: roughly a sprint for the first adapter, less for each additional surface. Durability: depends on the Banno release cadence — see Scope, below.

2. Native eStatement / OFX export, parallel feed

The portal publishes monthly statement PDFs, and most Jack Henry deployments also expose an OFX/QFX download for finance-app users. Where the integration's job is bookkeeping or year-end, this is quieter than scraping the transaction feed each night — and it is what the bank's own UI hands the member. Coverage: historic transactions and statements; not real-time. Effort: small, mostly the fetch loop and a PDF / OFX parser.

3. Consumer-permissioned aggregator handoff

If the consumer is already integrated with a US aggregator that has a relationship with the Jack Henry / Banno ecosystem, the FPNB member can grant access through that aggregator and the integration consumes the normalized feed instead of building against FPNB directly. Worth considering only when an aggregator account already exists; the per-call economics are otherwise hard to justify at a single-bank scale.

For nearly every FPNB-specific build we have looked at, route 1 carries the freshness and the long tail of surfaces, route 2 carries the audit-grade documents. The two run side by side without overlap.

The session in code (illustrative)

Sketched from how Banno Grip portals typically negotiate a session — exact field names and challenge order get confirmed during the build against the member's consenting account.

# Authorized adapter against my.fpnb.bank — sketch only
import httpx

BASE = "https://my.fpnb.bank"

def open_member_session(username, password, totp_provider, device_token):
    s = httpx.Client(base_url=BASE, follow_redirects=True, timeout=20.0)
    s.get("/")  # set CSRF + device cookies
    csrf = s.cookies.get("XSRF-TOKEN")
    r1 = s.post("/api/auth/login",
                json={"username": username, "password": password,
                      "device": device_token},
                headers={"X-XSRF-TOKEN": csrf})
    if r1.json().get("state") == "challenge":
        challenge_id = r1.json()["challengeId"]
        s.post(f"/api/auth/challenge/{challenge_id}",
               json={"code": totp_provider()})
    return s

def list_accounts(s):
    return s.get("/api/accounts").json()

def fetch_transactions(s, account_id, since_iso):
    out, cursor = [], None
    while True:
        params = {"since": since_iso, "limit": 100}
        if cursor: params["cursor"] = cursor
        page = s.get(f"/api/accounts/{account_id}/transactions",
                     params=params).json()
        out.extend(page["items"])
        cursor = page.get("nextCursor")
        if not cursor: break
    return out

def fetch_estatement(s, account_id, period):
    meta = s.get(f"/api/accounts/{account_id}/statements/{period}").json()
    return s.get(meta["signedUrl"]).content  # PDF bytes

Three things to notice. The login is a state machine, not a single POST — the 2FA branch is the rule, not the exception. The transaction reader is cursor-paginated; an integration carries the last cursor or the last posted-date watermark, not an offset. And the eStatement download is a two-step handshake: the portal mints a short-lived signed URL, and the actual PDF lives behind that. Guess the URL and you get nothing.

What lands in your repo

For an FPNB build, the package we hand over is shaped to the surfaces above and to the fact that this is one bank, one charter, one portal — there is no fan-out across institutions to design around.

• An OpenAPI 3.1 specification covering accounts, transactions, transfers, payments, RDC status, statements and alerts, with every field typed and every error code listed.
• A protocol & auth-flow report covering the Banno login state machine, CSRF / device-trust cookies, the 2FA branches, session-pinning behavior, and the signed-URL handshake the eStatement viewer uses.
• Runnable source in Python (httpx) and Node.js (undici / axios) for every endpoint in the spec, with a typed client and a thin CLI for smoke tests.
• An automated test suite that runs against a consenting test account on a schedule and surfaces field-level diffs when the upstream payload shifts.
• Interface documentation: a README that names every surface, a sequence diagram for the login + first-pull, and a one-page operator note for the member-consent workflow.
• A compliance & data-retention note: what is logged, what is purged, where the consent record lives, and what to do when the member revokes.

Things the build accounts for

These are the FPNB-specific corners the studio handles inside the engagement rather than treating as the customer's problem.

• Banno release drift. Jack Henry pushes platform updates that occasionally rename a field or move a DOM hook on the Grip front end. The build includes a nightly smoke run against a known consenting account; when a payload shifts shape, the adapter is patched before the next reconciliation rather than waiting for the integration to break loudly.
• Two-phase RDC posting. Mobile check deposit returns a deposit ID synchronously, but the cleared / posted state appears asynchronously and sometimes the next business day. We model that as two events, not one, so downstream books are not pre-credited and a same-day reversal is handled cleanly.
• Card-control isolation. The on / off toggle and the reorder request hit a different subsystem inside the Jack Henry stack than the transaction feed and carry a separate auth scope. We keep that as its own adapter so a consumer who only needs read access is not forced to grant card-control permissions to the integration.
• Member-consent record. Because the dependable basis here is the consumer's own written authorization (see Regulatory frame), the build ships with a small consent service: who authorized, for which surfaces, for how long, and a one-call revoke. Access onboarding — getting the test member, the device-trust slot, and the NDA in place — is run with the customer during week one; it is part of the engagement, not a precondition.
• SMB vs personal account split. FPNB serves both personal and agricultural / small-business members; entitlements differ (Treasury features, ACH origination on the business side). The build scopes per account type so a personal-only integration does not pull dormant business endpoints.

The regulatory frame in 2026

The honest US picture, anchored to this bank. FPNB is an FDIC-insured national bank operating in Colorado; consumer financial data handled by the integration is subject to the Gramm-Leach-Bliley Act and FFIEC guidance on third-party relationships. The CFPB Personal Financial Data Rights rule under §1033 (12 CFR Part 1033) is the forward-looking piece — as finalized in October 2024 it would have layered an obligation onto larger institutions starting in 2026, with smaller community banks in later waves. In July 2025 a federal court enjoined CFPB enforcement, and in August 2025 the CFPB issued an Advance Notice of Proposed Rulemaking reopening four sections of the rule. As of this writing the rule is not in force and a community bank the size of FPNB is, in any case, well outside any near-term wave even if it returns broadly intact.

What that leaves is the dependable basis: the member's own consent. The integration runs under a written authorization from the FPNB member, narrowly scoped to the surfaces actually needed, with revocation on a single call. Credentials are held in encrypted storage at rest, never logged, and rotated on the member's password change. Session logs name the surface and the timestamp, not the payload.

What I checked

FPNB's own site for the bank's footprint, FAQ and online-banking entry point; the Play Store listing for the package ID and the feature list; the ICBA community-bank directory for the charter recap; and the CFPB / Federal Register / Cozen O'Connor pages for the §1033 status as of mid-2025 into 2026. Citations:

• FPNB — Online & Mobile Services
• First Pioneer Mobile on Google Play
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 2025)
• Cozen O'Connor — §1033 enjoined and under reconsideration

Reviewed 2026-05-30 by the OpenBanking Studio integration desk.

Interface evidence

Screenshots from the public Play Store listing, useful when scoping which surfaces a build needs to cover.

Other Grip-style community apps in the same shape

If you are integrating FPNB you are likely also integrating one or two of these. The package suffix and the portal shape repeat across Jack Henry / Banno community-bank deployments, which makes the per-app delta on each one small.

• Pioneer Mobile App (Pioneer Bank, NM — package com.pioneerbks.grip) — same Banno Grip stack, accounts / transactions / RDC / bill-pay set.
• Pioneer Bank & Trust (SD — com.pioneerbankandtrust.grip) — Grip-platform sibling; eStatement and card-control surfaces line up almost one-for-one.
• Pioneer Community Bank (WV) — same data domains, different vendor; useful comparison when scoping a multi-bank rollup.
• Pioneer Bank Mobile (TX, com.pioneerbank.mobile) — community bank app with parallel feature scope.
• Pioneer-Mobile Banking (mFoundry-hosted) — older platform shape, similar transaction-feed semantics.
• My First Bank Mobile (Belize, bz.firstbank.grip) — non-US Grip skin; useful to see how the same Banno front end handles a different jurisdiction.
• Community Banks of Colorado (NBH-owned) — same state, different core; competing brand that an aggregator-style integration often picks up alongside FPNB.
• BCBank — community-bank peer cited in FPNB's competitive set; relevant for cross-bank treasury views.
• F&M Bank — peer community bank cited in FPNB's market set; comparable mobile feature scope.
• Bellco Credit Union — Colorado credit-union side of the same consumer; pulled in when an integration covers both bank and credit-union accounts of the same member.

Questions integrators ask

Does First Pioneer Mobile carry enough surface for ongoing aggregation, or only one-shot pulls?

Enough for ongoing. The Grip portal serves a long transaction history per account, paginated; an integration tracks the last posted-date watermark per account and pulls forward. The constraint is the consenting member's session, not the data model.

Are e-statements behind the same login as the transaction feed?

Same login, separate document service. Statement PDFs come from the eStatement viewer inside the portal, which negotiates a short-lived signed URL after the main session is established. The integration follows that handshake rather than guessing the URL.

What happens to the integration when FPNB takes a Jack Henry / Banno platform update?

A few field names or DOM hooks usually shift; the auth flow rarely does. We run the integration against a known consumer account on a nightly schedule, diff the parsed payloads, and patch the adapter before the next reconciliation.

Is there a US scheme like UK Open Banking that would let us skip the consumer-credential route?

Not today. CFPB §1033 (12 CFR Part 1033) was finalized in October 2024 with an April 2026 first-wave date for the largest institutions, but in July 2025 a federal court enjoined enforcement and the CFPB reopened the rule for reconsideration. A community bank the size of FPNB is well outside any near-term wave even if §1033 returns intact. The dependable basis right now is the member's own written authorization.

Source-code delivery on an FPNB build starts at $300, paid after delivery once you are satisfied with what runs on your machine — that gets you the OpenAPI spec, the Python and Node clients, the protocol report, the test suite and the operator docs, on a one-to-two-week cycle. Pay-per-call against our hosted endpoints is the other shape, with no upfront fee, and tends to fit when the consumer just wants the data flow without owning the integration. Access onboarding, the test-member arrangement and the consent paperwork are run with you during week one; nothing to clear beforehand. Send us the surfaces you actually need and we will scope the rest.