FNB Izard County banking data, and the route to reach it

The FNB Izard County app does two jobs at once. It carries the bank's own checking and savings ledger, and through an aggregation feature it pulls in accounts the customer holds elsewhere. That split is the whole story for anyone trying to integrate it: one feed is authoritative and lives on the bank's core, the other is a mirror of someone else's data arriving second-hand. Treat them as one blob and balances drift. Keep them apart and the integration behaves.

First National Bank of Izard County has operated out of Calico Rock, Arkansas since 1914, per the bank's own site, and is FDIC-insured under cert 11252, per the FDIC BankFind record. Small bank, ordinary retail accounts, a phone app that does the everyday work. The interesting detail sits in the package name.

The Android package is com.fnbizardcounty.grip, per its Play Store listing, and the iOS build is App Store id 1578942990. That grip suffix is not unique to this bank. The same namespace shows up on a long list of other community-bank apps (for example com.cbna.grip, com.tompkinstrust.grip, com.bankhcb.grip), which is the signature of a shared white-label client skinned per institution. For an integrator that is a gift: the protocol work done once against FNB Izard County's surface largely transfers to its siblings.

Account-by-account, what the app exposes

Each row below is something the app shows a signed-in customer, mapped to where it comes from and what an integrator would do with it. The granularity column is what matters when you size a sync.

Three ways into the ledger

Three routes genuinely apply here. They differ in what they reach and how long they hold up.

1 — Account-holder-consented protocol analysis of the app's traffic

The app talks to a grip-platform backend over an authenticated mobile session. With the account holder's consent we map that traffic, reproduce the auth handshake and the accounts, transactions and statements calls, and turn it into a client. This reaches everything the app itself shows, including the user-added tags and receipt images, which a standardized data feed would not carry. Durability is moderate: a backend change can shift a field, which is why the deliverable includes tests that catch it. Access is arranged with you during onboarding, against a consenting account.

2 — Consumer-permissioned data sharing toward the US standard

Where the bank or its core provider exposes a consumer-permissioned feed, the Financial Data Exchange (FDX) specification is the US direction of travel for that kind of sharing. It is cleaner and more durable for the structured basics (accounts, balances, transactions) but narrower, and small community banks reach it through their core provider on their own timeline. We treat this as the long-run path for the standard fields and pair it with route 1 for everything else.

3 — Native export as a fallback

The app saves monthly statements as documents. Where a customer just needs their own history out, those statements plus a transaction export are a low-effort fallback that needs no live session, at the cost of freshness and structure.

For most integrators the working answer is route 1 for breadth, with the standard-feed fields from route 2 folded in as they become available from the core. We would build it that way and say so up front.

What lands in your repo

The center of the delivery is code that runs, not a binder.

• Runnable client, Python and Node.js — session open, accounts, transaction paging, statement retrieval, against the grip-platform surface FNB Izard County uses. Real functions you can call, not stubs.
• Incremental sync worker — a cursor-based delta pull for transactions, scheduled per data tier, with upserts keyed on the bank's own transaction id so a repeated run lands the same row once.
• Automated test suite — pytest fixtures recorded against the live responses, covering the auth handshake, transaction paging and statement retrieval, so the surface stays under test as you maintain it.
• Normalized schema — accounts, transactions and statements flattened to a stable model, with the native-vs-aggregated tier carried as a field.
• OpenAPI description and an auth-flow report — the surface written up as a spec, plus the token and session chain documented step by step.
• Interface documentation and data-retention notes — how to run it, and what to keep, log and purge.

A session and a delta pull, in code

The shape below is illustrative. Paths and field names were observed during the build and are parameterized per institution; read it as the structure, not a published contract.

# grip-platform mobile surface that FNB Izard County ships on.
# Tenant host resolves from the institution id; this is a shape, not a spec.

import requests

BASE = "https://<grip-tenant-host>/mobile"

def open_session(device_token, passcode):
    # The app signs in with a 4-digit passcode or device biometric, then
    # exchanges a device-bound credential for a short-lived bearer token.
    r = requests.post(f"{BASE}/auth/session", json={
        "device_id": device_token,
        "factor": "passcode",          # or "biometric" on supported devices
        "secret": passcode,
    }, timeout=20)
    r.raise_for_status()
    return r.json()["access_token"]

def accounts(token):
    r = requests.get(f"{BASE}/accounts", headers=_auth(token), timeout=20)
    r.raise_for_status()
    # native rows carry source="internal";
    # aggregated outside accounts carry source="aggregated" + refreshed_at
    return r.json()["accounts"]

def transactions(token, account_id, cursor=None):
    params = {"limit": 200}
    if cursor:
        params["cursor"] = cursor       # delta pull: only rows after the cursor
    r = requests.get(f"{BASE}/accounts/{account_id}/transactions",
                     headers=_auth(token), params=params, timeout=30)
    if r.status_code == 401:
        raise SessionExpired            # token lifetime is short; re-open, retry
    r.raise_for_status()
    body = r.json()
    return body["transactions"], body.get("next_cursor")

def _auth(token):
    return {"Authorization": f"Bearer {token}", "Accept": "application/json"}

A normalized transaction record, the form your store would actually keep:

{
  "id": "txn_8841c0",          // bank transaction id; the upsert key
  "account_id": "acc_chk_01",
  "source": "internal",        // "internal" (native) or "aggregated"
  "posted_at": "2026-06-05",
  "amount": -42.18,
  "currency": "USD",
  "counterparty": "Calico Rock Hardware",
  "tags": ["supplies"],        // user-added in-app
  "note": "receipt attached",
  "receipt_ref": "img_5f21"    // binary fetched separately
}

Keeping two tiers of data in sync

The reconciliation problem is the heart of this app, so it gets its own design. Native ledger rows come straight off the bank's core and can refresh on a short cursor-driven loop, cheaply, because each pass only reads what posted since the last one. Aggregated external accounts are a different animal. They arrive through an upstream provider, on the provider's schedule, and may already be hours stale when the app shows them, so the mirror carries their refreshed_at stamp rather than pretending they are live. To catch a dropped row, each statement period's closing total is checked against the sum of transactions we hold for that period; a mismatch flags the gap instead of letting it sit silent. That single reconciliation check is worth more than any amount of polling.

Whose say-so this runs on

The dependable legal basis here is straightforward: the account holder authorizing access to their own data. That is what the build runs on. For the broader US picture, the CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is where consumer data access may eventually be governed, but as of this writing it is not in force — a federal court has enjoined enforcement and the Bureau has the rule back in reconsideration, per the CFPB's own reconsideration page. For a bank the size of FNB Izard County the specific obligations are doubly unsettled, since the smallest-institution tier is exactly the part being reweighed. So we do not lean on §1033 as settled law; we lean on the customer's consent, with the FDX standard as the technical target if and when a permissioned feed lands. Practically that means consent records kept with the data, scoped to the accounts the customer names, revocable, logged, with collection minimized to what the integration needs and an NDA in place where the engagement calls for one.

What a grip-platform build has to account for

Two things shape this particular job, and we plan for both rather than hand them to you as conditions.

The shared white-label client

Because com.fnbizardcounty.grip is one instance of a client that also ships as com.cbna.grip, com.tompkinstrust.grip and others, we build the protocol implementation against the common surface and keep the institution-specific parts — tenant host, branding, any per-bank toggles — as configuration. The payoff is reuse: the same core moves to a sibling community bank with a config change. We map the per-tenant differences so FNB Izard County's instance is handled correctly without forking the codebase.

Two data tiers, not one

The aggregation feature means the app blends the bank's own records with external ones it cannot vouch for at the same freshness. We separate authoritative native rows from refresh-lagged aggregated ones at ingestion, carry the tier on every record, and design the sync windows per tier. Card lock, card reorder and transfers are write actions rather than reads; we keep the integration read-first and wire those in only when you need them, with the extra consent and logging a write path deserves. Access to a consenting account or a sponsor environment is arranged with you during onboarding — it is our setup step, not a checklist you clear before we start.

Screens from the app

Store screenshots, included as interface evidence for the surfaces described above. Tap to enlarge.

Other community-bank apps in the same orbit

Same category, the kind of apps a unified integration would sit beside. Listed for context, not ranked.

• Arvest Go Mobile Banking — Arvest Bank's app across Arkansas and neighboring states; deposits, transfers and alerts on a larger regional footprint.
• Bank OZK Mobile — the Arkansas-headquartered bank's app, with balances, transaction history, Zelle transfers and mobile deposit.
• Centennial Bank Mobile — Home BancShares' retail app, covering account access, deposits and bill pay.
• CBNA Mobile Banking — Community Bank N.A., a sibling on the same grip white-label client (com.cbna.grip).
• Tompkins Community Bank — another grip-platform app (com.tompkinstrust.grip) with the same underlying client shape.
• Huron Community Bank — a smaller grip-platform institution (com.bankhcb.grip), structurally close to this one.
• First Commonwealth Banking — a grip-platform community-bank app holding the usual retail ledger and statements.
• Arkansas FCU Mobile Banking — an Arkansas credit-union app in the same consumer-banking category.

What integrators ask about FNB Izard County

FNB Izard County also aggregates outside accounts. Do you pull those too, or just the bank's own ledger?

Both, but they are handled as separate tiers. The bank's native checking and savings rows are authoritative and refresh on a tight window. The accounts the app pulls in through its aggregation feature arrive via a third-party aggregator, so they carry a provider-set freshness lag and a refreshed-at stamp. We map each tier on its own cadence rather than treating one blended balance as a single source of truth.

How often can the transaction and balance mirror refresh, and what sets the cadence?

Native ledger pulls run on a cursor, so each refresh only fetches rows posted since the last one and can run frequently without re-reading history. The aggregated outside accounts move at whatever cadence their upstream provider supports, which is usually slower. We tune the schedule per tier and reconcile each period's statement total against the running transaction tally so a missed row gets noticed.

The app is one of several community banks on the same grip codebase. Does an FNB Izard County build carry to the others?

Largely, yes. The package namespace (com.fnbizardcounty.grip, per the Play listing) is shared with other community-bank apps such as com.cbna.grip and com.tompkinstrust.grip, which points to a common white-label client. We build the protocol implementation against that shared surface and keep the per-institution pieces (host, tenant id, branding) as configuration, so the core client moves to a sibling bank with a config change rather than a rewrite.

Does the integration touch the debit-card lock and reorder actions, or is it read-only?

Read-first by default. Balances, transactions, statements and alert state are reads and make up most of what an integrator wants. Card lock, card reorder and transfers are state-changing actions; we scope those separately and only wire them in when you actually need them, with the consent and logging that write actions call for.

We run a bookkeeping product. Can we get the tagged transactions and monthly statements in a normalized shape?

Yes. The app lets a user attach tags, notes and receipt photos to transactions, and stores monthly statements as PDFs. We deliver a normalized schema that flattens the structured rows (amount, posted date, counterparty, tags, notes) and references the statement and receipt binaries separately, so your bookkeeping pipeline ingests clean records and fetches the documents on demand.

A first FNB Izard County client — session handling, accounts, transactions, and statement retrieval — usually lands within one to two weeks. Take it as runnable source for a flat fee from $300, paid only once it is delivered and you are satisfied; or call our hosted endpoints instead and pay per call, with nothing upfront. Bring the app name and what you want out of its data to our contact page, and we will come back with scope and the route we would take.

What I checked, and when

I read the app's Google Play listing for its current feature set and package name, the FDIC BankFind record for the bank's charter and insurance (cert 11252), the CFPB reconsideration page for the live status of the §1033 rule, and the Financial Data Exchange for the US data-sharing standard the route targets. Package and identifier details above are taken from those listings; where a number is unknown it is left out rather than guessed.

Protocol mapping by OpenFinance Lab, reviewed 2026-06-08.