The Bank of Billings — community banking on Jack Henry’s Banno stack

The Bank of Billings has served Christian County, Missouri since 1889 (per its own website) and runs a two-branch operation out of 104 N E Elm Street, Billings, MO. The Android package id is com.thebankofbillings.grip, and the .grip tail is a clean signal — Banno started life as a mobile app literally called Grip before Jack Henry acquired it in March 2014, and other known Banno white-label builds (MVB Banking at com.mvbbanking.grip, Old Second’s O2 at com.oldsecond.grip) keep the same suffix. We treat that as a working hypothesis on day one and verify it the first time we open the running session. For an integrator the practical implication is large: a Banno-shaped surface means a small, well-mapped set of endpoints rather than a one-off vendor build.

What the mobile app actually shows

Working from the app’s own Play Store copy and the visible screens, the surface is small enough to map on one page and useful enough to be worth integrating against. Nothing here is exotic; everything is the staple of a community-bank customer’s monthly use.

Reaching the data — three honest paths

There are three routes that fit this institution. We pick one as the spine for the build and keep one as the maintenance fallback.

1. Member-consented session against the mobile auth path

The cleanest route here. The member supplies their internet-banking credentials and any second-factor prompt (the platform leans on Authy-style flows per the public Banno write-ups), and we drive the same session the mobile app drives. Reachable surfaces match the table above. Effort: low to medium — the bulk of the work is the auth state machine, not the read endpoints. Durability: good while the bank keeps the existing platform; if Jack Henry rolls a major mobile redesign we re-validate paths. The studio arranges the consent record with you and the member during onboarding; it is not a checklist you hand us.

2. Aggregator-mediated read (Plaid, Akoya, Finicity, MX)

For a US community bank this is often viable because the major aggregators have all built Banno-aware connectors, and Jack Henry itself announced direct integrations with Akoya, Finicity and Plaid through the Banno Digital Toolkit. We can wrap an aggregator behind a thin facade that hands you the schema you want, hiding the per-aggregator quirks. Effort: low if the data you need is on the aggregator’s covered list; useful when you want the same client code to work for many small US banks at once. Durability: tracks the aggregator’s coverage.

3. Native export — statement PDFs and exports

The fallback. Members can save the monthly statement PDFs the app shows; for some accounts the portal also exposes a CSV/QFX export. We parse those into the same normalized schema so a missed live fetch never gates the customer’s downstream reporting.

For most engagements on this institution we recommend route 1 as the build target and route 3 as the safety net. Route 2 enters the picture when the customer’s real ask is “all our US community-bank accounts in one schema”, not just this one bank.

Member consent and the §1033 question

The working basis for The Bank of Billings is plain: the member who logs in authorizes the read. The same credential pair that drives the mobile app and the internet-banking site is what the integration uses; the member is in the loop, and the institution’s own session controls (passcode, biometrics, second factor) still apply.

On the rule side: the CFPB’s 12 CFR Part 1033 Personal Financial Data Rights work is enjoined and back in reconsideration (the Bureau’s August 2025 ANPRM is the current state of the record), so nothing in §1033 currently obliges The Bank of Billings to do anything. For a two-branch Christian County bank this matters in a specific way: even under the original phasing the smallest US institutions would have been last in line, and the form a final rule eventually takes is genuinely open. We do not present §1033 as the framework that governs this integration today — it does not. The dependable basis here stays the member’s own login authorization, the same one that drives the app each morning.

Compliance posture on our side: authorized reads only, scoped to what the member approves, with consent records logged for the cadence the engagement specifies and an NDA where the institution or the member asks for one before we hand source over.

What lands in your repo

For a build on The Bank of Billings the deliverable shape is concrete:

• An OpenAPI 3 specification of the wrapper we ship — the same schema your client code calls, regardless of which underlying route is active.
• A protocol & auth-flow report covering the login state machine: credential POST, CSRF and session cookies, second-factor prompts (Authy-style), session refresh, and the exact failure shapes for locked accounts, expired sessions, and changed passwords.
• Runnable source for the working endpoints in Python and Node.js: accounts, balances, transactions, statements (list + PDF fetch), and card-freeze. Tests included.
• A pytest suite that runs against a recorded fixture set plus a live-mode that the member can drive themselves once a quarter to revalidate paths.
• Interface documentation for the integrator: what each endpoint returns, what the normalized schema looks like, what to do when a session 401s mid-fetch.
• Retention guidance: how long to keep raw responses, what to redact, and how to handle a consent revocation cleanly.

A worked example: pulling a monthly statement

Illustrative request/response sketch (confirmed against the running app during the build, not asserted as the final endpoint shape):

POST /a/consumer/api/v0/auth/login HTTP/1.1
Host: secure.thebankofbillings.com
Content-Type: application/json

{
  "username":  "<member username>",
  "password":  "<member password>",
  "deviceId":  "<persistent device id>"
}

200 OK
{
  "sessionId":  "...",
  "csrfToken":  "...",
  "challenge":  null            // or { "type":"otp", "channels":["sms","authy"] }
}

GET /a/consumer/api/v0/accounts
Cookie: jsession=<sessionId>
X-CSRF-Token: <csrfToken>

200 OK
[
  { "id":"acc_chk_01", "name":"Hometown Checking",
    "balance":{ "available":1284.07, "current":1340.55, "currency":"USD" } },
  ...
]

GET /a/consumer/api/v0/accounts/acc_chk_01/statements?year=2026
GET /a/consumer/api/v0/accounts/acc_chk_01/statements/<stmtId>.pdf
GET /a/consumer/api/v0/accounts/acc_chk_01/transactions?from=2026-04-01&to=2026-04-30

Two things to call out. First, the second-factor challenge is a normal response shape, not an error — the client treats it as a branch in the state machine, not an exception. Second, the statements endpoint returns metadata for the year; the PDF lives behind a second GET that we stream rather than buffer, because monthly statements on business accounts can run to dozens of pages.

Things this build needs to handle

Three notes that matter for this specific institution:

• Session lifecycle and 2FA prompts. Banno-shaped builds rotate session tokens aggressively and re-prompt for a second factor on a per-device, per-window basis. We design the refresh loop around the institution’s actual window (which we measure during the build) so the integration does not silently expire at 3 a.m.
• Statement pagination and image payloads. Statements are page-based per month, and the mobile check-deposit flow includes base64 image bodies that are large by API standards. We stream both, set the rate limit to a value the bank’s edge will accept, and chunk image uploads so a flaky cellular connection does not corrupt a deposit.
• Front-end revalidation on platform redesigns. Jack Henry pushes design-system changes to Banno (Liquid Glass on iOS 26 and the Material 3 refresh on Android are public). When the institution rolls one of those updates we re-run the path-validation pass as part of maintenance; the wrapper schema stays stable so your client code does not move.
• Two-branch operational reality. A small bank does not have a 24×7 platform-engineering team. We schedule any high-volume reruns outside business hours and route incident comms through a single named contact at the institution — arranged with you during onboarding.

How the work runs and what it costs

Source delivery for a Banno-shaped community bank like this one starts at $300, paid only after the build runs against a sponsoring or member-consenting account and you have signed off on the output. The deliverable is the runnable wrapper, the OpenAPI spec, the protocol report, the tests, and the interface documentation. The alternative is the hosted version: you call our endpoints, we run the integration on our side, and you pay per call with no upfront fee. The cycle for a first build is one to two weeks depending on how quickly we can drive a live login during the auth-flow capture.

If you want to talk through which model fits, the next step is a short note via /contact.html with the app name and what you actually need out of it.

Sources we opened

The brief above leans on the bank’s own listings, FDIC and CFPB primary documents, and Jack Henry’s own Banno material. The most load-bearing references:

• FDIC BankFind — The Bank of Billings, cert 16959
• The Bank of Billings official site
• Federal Register — Personal Financial Data Rights Reconsideration (ANPRM, 22 Aug 2025)
• Jack Henry & Associates Acquires Banno (March 2014 release)
• Banno Digital Banking platform overview

Mapped by the OpenBanking Studio integration desk · May 2026.

Other Missouri community banks and Banno peers

For context on where this build sits in the wider US community-bank field, the apps below sit close to The Bank of Billings either by geography or by platform pattern. They are listed here for ecosystem context, not as endorsements or rankings.

• MVB Banking — another .grip-suffixed Banno-shaped community-bank build, with the same statement + transfer + bill-pay surface.
• O2 Digital Banking (Old Second) — Illinois community bank on the same digital-platform pattern; the integration shape would carry over with minimal change.
• FSCB Banking (First State Community Bank) — Missouri-based; balances, eStatements, mobile deposit, external transfers.
• FMB Ozarks Mobile Banking (First Midwest Bank of the Ozarks) — Missouri Ozarks footprint; balances, transfers, bill pay, deposit.
• Community State Bank of MO — Missouri community bank with the standard balance + transfer + bill-pay set.
• First Community Bank Mobile — Arkansas + Southern Missouri; mobile deposit and the standard portal mirror.
• Heritage Bank of the Ozarks — Lebanon, MO neighbour; similar single-state community-bank footprint.
• Simmons Bank — a much larger regional that has publicly run on the Banno Digital Platform; useful as a scale comparison for the same platform shape.
• The Bank of Missouri — separate Missouri community bank; another close peer for the “all my Missouri community-bank accounts in one schema” ask.

The app as the customer sees it

The screens below come from the public listing. Click any thumbnail for a larger view.

Questions integrators ask about this build

Does the .grip package suffix mean this app sits on Jack Henry’s Banno platform?

It is a strong signal, not a confirmation we will put in the contract. Banno was originally an app called Grip, acquired by Jack Henry in March 2014, and several known Banno white-label builds keep a .grip suffix in the Android package id. For The Bank of Billings we treat the signal as a working assumption and verify it against the running app in the first hours of the build.

Can we read transaction history older than what the mobile app screen shows?

Depth depends on what the institution retains in the consumer portal. The app screen typically shows a rolling window, but monthly statements give a separate, deeper trail. We pull both: the live transaction feed at the depth the portal returns, plus the statement PDFs and their parsed line items where the member has them.

What happens to this integration when the CFPB 1033 reconsideration concludes?

If a final rule comes back resembling the original phasing, a two-branch community bank like The Bank of Billings would be far from the front of the queue and the member-consent build we hand you keeps working unchanged. If the rule lands somewhere else entirely, the consent basis still holds: the member authorizes the fetch in the channel they already use.

Does the mobile app share a login with the internet-banking site?

Yes. The bank states on its own listing that members enroll once in internet banking and use the same credentials in the app. The integration keys off that single credential pair plus any second-factor step the institution enforces.

Mapping reviewed 2026-05-20.