An SDK for Blue Diamond Banking, the First National Bank of Arenzville mobile app

First National Bank of Arenzville — an 1882-vintage three-branch Illinois bank carrying FDIC certificate 3599 per BankFind — moved its retail customers onto Blue Diamond Banking in early 2025, retiring the older FNBA mobile app on both stores. The Android package is com.fnbarenzville.grip per its Play Store listing, and the iOS bundle is App Store id 6738508052. The .grip suffix is the giveaway that matters for an integrator: this is a Banno-powered app, the white-label mobile platform that Jack Henry & Associates has shipped under that package suffix to a long list of community banks (com.fnbcc.grip, com.cbna.grip, com.fnb_bank.grip, com.bankofgrainvalley.grip, bank.fnc.grip, all confirmed on Play). Anything we build against Blue Diamond Banking can — with the customer's authorization — be lifted onto the same shape at a sibling Banno bank with very little new work.

This brief leads on the SDK side because that is what is unusual about a community-bank app of this size. The data is finite and well-shaped; the work is in giving an integrator a real client library instead of a screen scrape.

Reachable data on the Blue Diamond Banking app

Every row below tracks a surface the app actually exposes to its own user, named the way the app names it where possible. None of this is hypothetical — it is the same data path the customer sees on their phone.

How we'd reach it

Three routes apply to a small US national bank on a Banno mobile surface. They are not equivalent and they do not pretend to be.

1. Consumer-consented session. The customer signs in to Blue Diamond Banking inside our build workspace, with written consent, and the SDK operates the same authenticated session the mobile app uses. Reachable: everything in the table above. Effort: short. Durability: stable across normal Banno releases, because the mobile-app contract is what Jack Henry actively maintains. This is the route we recommend for a first cut.
2. Aggregator OAuth via Plaid, MX, or Finicity. Where the bank is enrolled with one of the large aggregators (Plaid in particular publishes lists of community-bank coverage), the SDK can target the aggregator's token rather than the bank session directly. Reachable: accounts and ledger, usually not transfers or bill-pay write. Effort: medium, mostly contract and onboarding. Durability: high for read paths.
3. Bank-direct, when the bank is willing. A small bank will sometimes open a sponsored credential or a dedicated technical contact for an integrator who has the bank's customer in the loop. The SDK is shaped so this transport can drop in behind the same call sites later, without rewriting the integrator's code.

Route 1 is the spine in practice — it is what actually runs on day one. Route 2 gets added when the integrator wants a portable token they can hand to a downstream system. Route 3 is the upgrade path, not the starting point.

Things this specific app forces us to handle

Three points are worth being explicit about, because they are where a generic "wrap a banking app" job would go wrong.

• The Banno shape, not a single endpoint. The mobile app talks to a per-institution host on the Banno fabric, with auth, session, and pagination conventions that hold across the Banno-powered banks but are not identical to a Q2, Alkami, or NCR Voyix surface. We code the SDK against the Banno conventions and bind the specific FNB Arenzville host at runtime, so the same library could be aimed at a sibling com.<bank>.grip instance with a config change.
• MFA and step-up reality. Blue Diamond Banking gates first sign-in and new-device flows behind a code challenge, and gates writes (a new payee, a P2P send to a new recipient) behind a step-up. We build the SDK with first-class callback hooks for those prompts rather than papering over them — the integrator's own UI or operator handles the challenge, the SDK keeps the session.
• Pending vs posted vs scheduled. The ledger surfaces three distinct states for an entry, and a naive ingestion will double-count a card auth that later posts. The SDK normalizes to a single entry id with a status field, and the test suite has fixtures for the auth → post and the scheduled → executed transitions specifically so that a downstream sync does not treat them as separate transactions.
• Bill-pay timing. "Pay a Company" runs on an ACH or check rail depending on the payee; cut-off windows differ. The SDK exposes the rail the bank assigns per payee, so the integrator's job scheduler does not assume next-day for everything.

Access, sponsor approvals, NDAs where needed, and the consenting account itself are arranged with you as part of onboarding — not staged as a wall to clear before the work starts.

Where the consumer's right to this data stands in 2026

A 1908-chartered three-branch national bank, FNB Arenzville sits well below the asset bands that the earliest versions of the CFPB's 12 CFR Part 1033 rule aimed at first. That rule is, as of this writing, enjoined and back in agency reconsideration — there is no settled US obligation that lands on this specific bank today. The dependable basis for the build is the consumer's own written authorization to act on their account on their behalf, the same posture the mobile app itself operates under. The SDK is shaped so any future regulator-defined route — whatever Part 1033 becomes when it returns — could be picked up behind the same interface without rewriting call sites.

On the data-protection side, the build runs under standard US state-by-state consumer-data norms (the bank itself sits under OCC supervision per BankFind) and the studio's own posture is the conservative one: minimum scopes requested, consent records kept, no retention of credentials beyond the session, no fan-out to third parties without a written instruction from the customer. Where the integrator has its own privacy programme (NYDFS Part 500, a state CCPA-class obligation, a SOC 2 audit window), we slot under it rather than ask it to bend.

What lands in your repo

• A tagged Python 3.11 package (blue_diamond_sdk) and a tagged Node.js 20 module, both exposing the same surface: accounts, transactions, transfers, bill_pay, p2p, alerts.
• An examples/ directory with five end-to-end scripts that an integrator can run on day one — a balance-poll loop, a delta-sync ledger reader, a sweep transfer, a bill-pay schedule, and a P2P send (dry-run by default).
• A pytest and a Vitest suite that exercise the SDK against a live consenting account on the schedule you set; pending-vs-posted fixtures included.
• A webhook receiver template (Express and FastAPI flavours) for the integrator's own side, since the mobile surface itself is poll-shaped — we relay shaped events into your queue rather than make you re-do that work per project.
• An OpenAPI 3.1 document covering the normalized surface the SDK presents, plus an auth-flow report describing the token, refresh, and step-up chain as it actually behaves on this bank's Banno host.
• Interface documentation in Markdown — what each surface returns, the status taxonomy, the rate-limit behaviour we have measured, the rough cut-off windows for ACH bill pay.
• A short compliance memo: consent text, retention defaults, what is logged, how to revoke. Plain-language, not a regulatory artefact.

A request that actually returns something

Shape of a real call against the SDK. Endpoint paths on the Banno-side are illustrative — the exact wire format is pinned to the auth-flow report at delivery time.

# blue_diamond_sdk — illustrative use; exact paths confirmed during the build
from blue_diamond_sdk import BlueDiamondClient

# session is anchored on a consent token the customer issued via the SDK's
# enrolment flow; the SDK refreshes it ahead of expiry, transparently.
with BlueDiamondClient.from_consent(consent_token, institution='fnbarenzville') as bd:

    accounts = bd.accounts.list()
    # -> [Account(id='acct_4f…', kind='checking', current=Decimal('2841.06'),
    #             available=Decimal('2716.06'), nickname='Primary Checking'), …]

    for acct in accounts:
        page = bd.transactions.page(
            account_id=acct.id,
            since=cursor.get(acct.id),     # cursor-based delta sync
            limit=200,
        )
        for entry in page.entries:
            # entry.status in {'posted', 'pending', 'scheduled'}; normalized
            # so the auth->post transition keeps the same entry.id
            ingest(entry)
        cursor[acct.id] = page.next_cursor

    payees = bd.bill_pay.payees()
    # -> [Payee(id='pye_91…', name='Ameren Illinois', rail='ach',
    #           next_run='2026-06-10', amount=Decimal('142.18')), …]

    # book transfer between two of the user's own accounts
    bd.transfers.book(
        from_account=accounts[0].id,
        to_account=accounts[1].id,
        amount='250.00',
        memo='weekly sweep',
        idempotency_key='sweep-2026-05-31',
    )

    # P2P 'Pay a Friend' — dry-run by default; explicit confirm to actually post
    bd.p2p.send(
        recipient='friend@example.com',
        amount='40.00',
        confirm=False,
    )

The Node shape is the same names with camelCase. The test suite asserts on the response shapes above, so a wire-format drift on the bank side fails a named test rather than a downstream report.

What the app surfaces look like

The screens an integrator should look at before scoping. Click to enlarge.

Refresh cadence and what counts as fresh

Balances and ledger entries come out of the same backend Jack Henry runs for the bank's own app, so "fresh" means within roughly the cadence the customer would see by tapping the screen. In practice the SDK polls balances every 60–120 seconds during a sync window and falls back to longer intervals when idle. Posted entries land within seconds of the core booking them; pending entries are surfaced with a distinct status so a downstream pipeline does not reconcile a card hold as a settled debit. Outbound rails (ACH bill pay, book transfers, P2P) confirm synchronously with a return ticket and asynchronously when the rail acknowledges; the SDK exposes both signals so a job runner can decide which one it counts on.

Other Banno-shaped community bank apps an integrator usually pairs this with

None of the names below compete with Blue Diamond Banking — they are the apps an integrator who wants community-bank coverage tends to ship the same SDK shape against, because they sit on the same Banno fabric. Names are noted as research signposts, not endorsements.

• FNBCC (com.fnbcc.grip) — First National Bank Coastal Community's mobile app, same package suffix, same surface family.
• CBNA Mobile Banking (com.cbna.grip) — Community Bank N.A., a multi-state community bank on the same platform.
• BGV Banking (com.bankofgrainvalley.grip) — Bank of Grain Valley's Banno-powered app.
• FNBOnline (com.fnb_bank.grip) — another community bank shipping under the same shape.
• FNC Bank Mobile Banking (bank.fnc.grip) — same fabric, different institution.
• The FNB Community Bank — Vandalia, Illinois, similar size, similar product mix.
• FNBC Bank & Trust — central-Illinois community bank with a comparable retail digital footprint.
• First National Community Bank — generic name, several institutions; relevant where an integrator wants regional coverage.

Pairing two or three of these under one SDK shape is what makes the build worth more than a single-bank scrape — the data shape carries.

Questions we usually get on this one

Will the same SDK keep working if FNB Arenzville pushes a new Banno release?

Mostly. The Banno mobile surface evolves in releases, not breaking schema overhauls, so the SDK's account, ledger, and transfer call sites have stayed stable across the releases we have watched. We pin the auth-flow report to a tag, run the test suite against a live consenting account on a cadence you set, and re-cut the SDK on the rare break — that is part of the engagement, not a separate ticket.

How fresh are the balances and ledger entries the SDK returns?

Balances are read straight from the same endpoint the mobile app hits, so they are as fresh as the app's own pull. Posted entries appear within seconds of the core writing them; pending entries (card auths, scheduled ACH legs) show up under a distinct status so an ingestion job will not treat a pending hold as a settled debit.

Can the "Pay a Company" and "Pay a Friend" flows be invoked from code, or are they read-only?

Both can be invoked under the same consented session that the app itself uses. Bill-pay payee creation and outbound bill-pay schedules are write-capable; the P2P "Pay a Friend" send is also write-capable but bounded by the recipient enrolment the bank's flow already imposes. We default the SDK to dry-run for both and require an explicit flag to actually post, so a misconfigured cron does not start mailing checks.

How would a 1033-mode feed slot in if the bank ever exposes one?

The SDK keeps its public surface (Accounts, Transactions, Transfers, BillPay, P2P) decoupled from the transport behind it. Today that transport is the consented mobile-app session; if and when a CFPB-mode feed or a bank-direct API lands behind the same data, we swap the transport without touching call sites, which is the whole point of shipping a real client library instead of a one-shot script.

Get this one built

The cycle on a Blue Diamond Banking build runs one to two weeks end to end and lands a tagged Python package, a Node module, the test suite behind them, and the auth-flow report that explains why each call is shaped the way it is. Source-code delivery starts at $300, paid only after the SDK runs against your consenting account and you are satisfied with what is in the repo; the same code can also run as a hosted endpoint you pay per call, with no upfront fee. Send the app name and what you want from its data to /contact.html and we will scope it back the same week.

Sources

Engineering notes by OpenFinance Lab, 2026-05-31. Verified during this assessment by opening the following primary sources:

• FNB Arenzville — Online Banking Upgrade (January 2025), the bank's own announcement of the move onto Blue Diamond Banking.
• FDIC BankFind — The First National Bank of Arenzville (Cert 3599), for charter, holding company, and supervision facts.
• CFPB — Personal Financial Data Rights Reconsideration, for the current (unsettled) status of 12 CFR Part 1033.
• Cozen O'Connor — Section 1033 Compliance Date: Open Banking Rule Enjoined and Under Reconsideration, for the October 2025 injunction context.