Pulling accounts out of a one-branch Montana bank's portal

Bank of Baker has been chartered out of one address on South Main Street, Baker, Montana since September 1924 — per the FDIC's BankFind record for institution 352 — and the digital app on top of that single branch is what an integrator actually has to talk to. The mobile experience runs on a white-label shell whose package id is com.bankofbaker.grip (per the Google Play listing); the same shell shows up at other small US banks too, with at least Community Bank N.A. shipping com.cbna.grip on what looks like the same underlying stack.

That changes how the integration is shaped. The bank's own engineering surface is small. The mobile back end is the source of truth a third-party app actually needs, and the dependable basis for reaching it is the customer's authorization — not a US rule, not yet.

Data inside the app, by where it really lives

Routes that actually work here

1. Customer-consented session against the mobile/web portal

The Bank of Baker app sits on the customer's authenticated session — passcode plus device biometrics on supported handsets, per the app's own security copy. We map the auth handshake, the post-login JSON endpoints the portal calls for accounts and transactions, and the statement-download routes, and run the integration inside that session with the customer's explicit consent. Durability is reasonable on the bank side; the front-end shell is the part that moves on its vendor's cadence, which is something we handle in maintenance.

2. Permissioned aggregator (Plaid / Finicity / MX / Yodlee)

For a small Montana community bank, aggregator coverage is the lower-friction path — the bank's app already pools "accounts from other banks and credit unions" through the same kind of permissioned aggregator, so the customer is already familiar with consenting to it. If the use case can live with the aggregator's refresh schedule and the aggregator's coverage of Bank of Baker, we wire to the aggregator's OAuth 2.0 flow on the customer's behalf.

3. Native exports (statements, bill-pay receipts)

The portal already lets the user "view and save your monthly statements" and the debit-card / deposit screens already export receipts. For thin use cases — month-end reconciliation, statement archival, lending document collection — we deliver a small consented downloader rather than a full live integration. It is cheaper, durable, and enough for the job.

What we'd recommend for most projects against Bank of Baker is route 1 with route 2 in front of it for the external accounts the app pools — the customer authorizes both once, and the live data and the long-running history both have a home.

A sketch in code

The shape below is illustrative — exact paths and field names are confirmed during the build against a consenting test account, not asserted here.

# Illustrative only. Confirmed during the build, not asserted here.
# Customer-consented session against the Bank of Baker mobile back end
# (white-label "grip" shell; package id com.bankofbaker.grip per the Play Store).

import requests

BASE = "https://m.bankofbaker.example"      # the real host is mapped during the build
session = requests.Session()
session.headers["User-Agent"] = "BoB-Grip/Android"

# 1) Device handshake. The white-label shell issues a per-install token
#    before credentials cross the wire.
session.post(f"{BASE}/auth/device", json={
    "deviceId":  "<install-uuid>",
    "platform":  "android",
})

# 2) Customer-supplied login. We hold neither passcode nor biometric —
#    the customer authenticates into the consented session we set up.
auth = session.post(f"{BASE}/auth/login", json={
    "username":  "<customer-supplied>",
    "passcode":  "<customer-supplied>",
}).json()
session.headers["Authorization"] = f"Bearer {auth['accessToken']}"

# 3) Accounts, transactions, and the monthly statement PDF.
accounts = session.get(f"{BASE}/accounts").json()
for acct in accounts:
    txns = session.get(
        f"{BASE}/accounts/{acct['id']}/transactions",
        params={"from": "2026-04-01", "to": "2026-04-30"},
    ).json()
    stmt = session.get(
        f"{BASE}/accounts/{acct['id']}/statements/2026-04.pdf"
    ).content

What ships at the end

• An OpenAPI 3.1 spec covering the auth handshake, account listing, transaction range query, statement-PDF fetch, and the two write endpoints the brief actually needs (internal transfer, debit-card status).
• A protocol & auth-flow report — device token, bearer issuance, refresh, and session timeout — written against the live shell, not against the white-label vendor's marketing.
• Runnable Python and Node.js source for the endpoints above, with the consent-capture screen the customer sees.
• Automated tests against a consenting account, including a re-validation suite that re-runs when the front-end shell changes.
• Interface documentation an integrator can hand to a developer who has never seen the app before.
• Compliance & retention guidance: NDA, consent record schema, what we log and what we deliberately do not.

Consent, and where US data-rights rules currently sit

The Bank of Baker is a state-chartered Montana commercial bank, FDIC-insured, supervised by the FDIC as a Fed non-member institution (per the FDIC BankFind record). The bank itself is small; the regulatory regime around the data is the part to read carefully, and right now it is unsettled.

CFPB Section 1033 (12 CFR Part 1033) was finalized in October 2024 — that much is on the public record at the Federal Register and at the CFPB. A federal court has since enjoined the CFPB from enforcing the rule, and the agency has reopened it for reconsideration; an Advance Notice of Proposed Rulemaking went out on 22 August 2025 (per the Federal Register). The compliance dates that were drafted into the rule (phased starting with the largest data providers) are not operative while that reconsideration runs, and they were never going to land first on a single-branch Montana bank in any case. The dependable basis for our integration is the customer's own authorization, captured in writing, scoped to the data domains we actually pull, revocable on request, and logged.

Where the eventual settled US framework lands — whether Section 1033 returns in its 2024 form, is narrowed, or is replaced — we revise the consent flow rather than the data path. The customer-consented path is what works today and what continues to work if the rule is reissued.

What we plan for during the build

This is where the project's real cost lives, and these are the items we cost in up front rather than discovering on the customer's time.

• White-label release cadence. The "grip" shell (com.bankofbaker.grip on Android, with the same shell visible on at least com.cbna.grip) pushes field-name and route changes on the vendor's schedule, not the bank's. The maintenance contract has a scheduled re-check on the vendor's release cadence built in, so the integration is verified against the new build before any production call sees it; the cost lives in the maintenance line, not in an emergency call.
• Aggregator overlap with the in-app pooled view. The app already aggregates external accounts. Our integration plans which accounts come direct from Bank of Baker and which come from the aggregator the customer already authorized, so the customer is not asked to consent twice for the same data and so we do not double-count balances on the downstream side.
• One-branch IT change windows. A community bank of this size (it ranks low among Montana institutions on the public bank-locator listings) does not run a 24/7 release tunnel. We schedule live cutover and any sandbox coordination around the bank's actual operating hours and assume conservative latencies on anything that requires bank-side action; the customer does not pay for our wait.
• Consent scope vs. statement history. Monthly statements are long-lived; transaction live-pulls are short-lived. We design the consent record so a customer revoking live access does not invalidate the statement archive they have already downloaded — and the reverse, so a re-consent does not silently broaden the scope. Specific to a banking app this size, that distinction tends to come up the day before the integration goes to production, and we want it written down before then.

Where these notes come from

The institution facts above were checked against the FDIC's BankFind record for institution 352 and an independent branch-locator entry, and the CFPB Section 1033 status against the CFPB's own rule landing page and the Federal Register reconsideration notice. The app package was checked against the Google Play listing. Specific deep links:

• FDIC BankFind — The Bank of Baker (cert 352)
• Federal Register — Personal Financial Data Rights Reconsideration (22 Aug 2025)
• CFPB — Required Rulemaking on Personal Financial Data Rights
• Google Play — Bank of Baker (com.bankofbaker.grip)

Mapping reviewed by the OpenBanking Studio integration desk — 20 May 2026.

Adjacent apps in the same data shape

The integration problem at Bank of Baker — small US bank, authenticated portal, customer-consented access — is the same shape as a long tail of other apps. Listed here as orientation, not as a ranking:

• Stockman Bank Mobile Banking — larger Montana franchise, multi-branch, similar account/statement/transfer surface.
• Yellowstone Bank — Montana community bank with its own mobile app and similar self-service controls.
• Baker Boyer Mobile App — Pacific Northwest community bank, similar size class and data shape.
• CBNA Mobile Banking (Community Bank N.A.) — runs on the same "grip" white-label shell (com.cbna.grip), so the integration shape transfers almost directly.
• First Interstate Bank — regional bank covering Montana and neighbours, broader surface and aggregator coverage.
• Quontic — digital-only US bank, similar account data, different stack.
• Axos Bank — fully digital US bank, account / statement / transfer surface.
• Alliant Credit Union — US credit union, account-aggregation-friendly.
• Ally Bank — large US digital bank, the standard reference point for "what a polished US retail integration looks like".

Names are plain text; cross-links between briefs on this site are added by the build only where the sibling page actually exists.

Interface evidence

Screens from the Play Store listing, useful for sanity-checking the data surfaces the brief refers to.

Questions integrators ask about a bank this size

The mobile app pools accounts from other banks — can our integration reuse that pooled view?

That pooled view is a UI convenience the bank surfaces through a permissioned aggregator under the customer's consent on the Bank of Baker side; the aggregated dataset lives inside the app session and is not republished for downstream consumption. Our integration sits on the customer side of the same consent — pulling the bank's own accounts directly, and the external ones via the aggregator the customer already authorized.

Routing number 092105104 — is that the right anchor for ACH and statement matching?

It is the bank's published ABA routing per the public bank-locator listings (the bank itself is FDIC certificate 352). It is the correct anchor for ACH counterparty matching and for joining downloaded statements to external transaction logs. Account-level identifiers inside the app are scoped to the customer's session and not visible until they consent.

Front-end re-skins from the white-label vendor — how often do those break a parser?

The shared "grip" mobile stack (the Bank of Baker app ships as com.bankofbaker.grip per the Play Store listing, and at least CBNA's app uses com.cbna.grip on the same shell) tends to push field-name and route changes on the vendor's cadence rather than the bank's. The maintenance contract has a scheduled re-check on the vendor's release cadence built in, so the integration is verified against the new build before any production call sees it.

Is there a real open-banking obligation in the US we can lean on for a single-branch bank like this?

Not today. Section 1033 of the Dodd-Frank Act was finalized as a CFPB rule in October 2024 and has since been enjoined while the agency reconsiders it — the rule is not in force, and even as drafted its phased dates start with the largest data providers, not a single-branch Montana bank. The dependable basis is the customer's own authorization, with a permissioned aggregator (Plaid / Finicity / MX / Yodlee) or direct mobile-app session as the actual transport.

Delivery on a brief this size runs one to two weeks against a consenting test account. The same work ships either as a one-time source-code package starting at $300, paid only after the source is delivered and you are satisfied with it, or as a pay-per-call hosted endpoint with no upfront fee, where you call our API and pay only for the calls you actually make. The conversation starts at /contact.html.