Reading Bank of Baker accounts from outside the core

The Bank of Baker has held its FDIC charter since 1924, and the app it ships today (com.bankofbaker.grip on Android, id 1490165135 on iOS) runs on a “Grip” shell that several Montana and Pacific-Northwest community banks share — the same package suffix turns up under com.bakerboyer.grip, confirmed during the build. That is good news for an integrator: the surface vocabulary is consistent across the shell even when the bank's brand theme is not. The job here is to turn what an account holder sees inside the app — balances, posted activity, statement PDFs, the bill-pay queue, card state — into something a third-party system can read on a schedule, with the customer's consent and with no dependence on owning or sitting inside the bank's core.

What data the app actually surfaces

The list below is drawn from the Play Store description and a walk-through against a consenting test account. Each row notes where the value lives, how fresh it is, and what an integrator typically does with it.

Three authorized routes to that data

For this app the practical choices fall to three. We do not need every route on every job; we pick what fits the volume and the freshness budget and arrange the necessary onboarding with you.

1. Consumer-permissioned OAuth through an FDX-aligned aggregator

This is the spine. Plaid, MX, and Finicity all carry community-bank coverage in some form; per the Financial Data Exchange's own whitepaper, direct permissioning at smaller institutions is still patchy, so a given consenting customer's connection may resolve to a token-based OAuth flow or to a credential-mediated session under the hood. We isolate that detail behind a single client surface so your code sees one shape regardless. What it reaches: account list, posted transactions, balances, statements, account-owner details. Durability: high — the aggregator absorbs vendor changes.

2. Authorized interface integration of the Grip shell traffic

Under a customer's written authorization (and against their own credentials), we map the mobile shell's network conversation: the auth handshake, the session refresh, the calls that return the account list, the call that returns a statement PDF URL, the call that fires a P2P payment. This is the route to use when you need a surface the aggregators do not expose — card-control toggles, RDC submit, the tag/note/photo metadata layer — or when you want a deterministic path that does not depend on a third-party aggregator at all. Durability: medium; the shell evolves on its own cadence and the client needs maintenance, which we scope into the engagement.

3. Native export

The internet-banking site backs the same accounts and ships monthly statement PDFs and transaction CSV downloads. For low-volume back-office work — a small business that wants its books reconciled once a month — a scripted export is cheap and stable. We treat this as a fallback rather than a spine, but it is a legitimate finish line when nothing more is needed.

For most callers, route 1 carries the daily transactional traffic and route 2 fills the surfaces route 1 cannot. The recommendation is normally a hybrid; we say so in the proposal rather than after the fact.

Where US §1033 sits, and why we don't rely on it

The CFPB finalized the Personal Financial Data Rights rule (12 CFR Part 1033) in late 2024. A federal court has since enjoined enforcement, and on 22 August 2025 the agency published an Advance Notice of Proposed Rulemaking reopening the rule for reconsideration. The comment window closed in October 2025; no replacement text has been issued. The compliance dates the rule originally contemplated are stayed. Treating §1033 as the present, settled basis for an integration would be wrong; we treat it instead as the direction of travel, and we anchor the technical work on two things that hold either way: the consumer's own written authorization, and FDX 6.0 as the data shape (the agency has consistently pointed at FDX as the technical reference). Practically, that means consent records, scope-limited tokens, and an audit log of every call; data is minimized to what the scope grants, retained no longer than the engagement requires, and deleted on revocation. If the final rule shifts the fee model, the representative definition, or the data scopes, the change lands on the consent layer rather than on your sync worker.

What ships in the source-code drop

The deliverable is code that runs on your machine the day we hand it over. Concretely:

• Python SDK (3.11+) wrapping the chosen route, with type hints, an httpx-backed transport, and a sync worker that holds per-account cursor state.
• Node.js SDK (20+) mirroring the Python surface, written for an event-loop world; published as an ESM package and pinned to the Bank of Baker institution identifier.
• Go client (1.22+) for callers that want a single static binary in their ingestion pipeline.
• Webhook handler scaffolding for the aggregator's transaction-notify and connection-event hooks, with replay against a local fixture set.
• Automated test harness — pytest and vitest suites that run against recorded fixtures in CI and against the aggregator sandbox on the nightly job.
• Idempotent sync worker — per-account cursors, dedup logic on the FDX transactionId, dead-letter queue for replayable failures.
• OpenAPI specification of the normalized client surface (FDX 6.0 dialect), useful if you want to generate clients in other languages later.
• Protocol & auth-flow report covering the route we shipped — the token chain, the refresh window, the failure modes we observed, the version of the shell we targeted.
• Interface documentation and a short data-handling memo covering retention, minimization, and the consent records you'll need to keep.

A look at the client code

This is the Python SDK's account and transaction surface, stripped to the bones. The real package adds error mapping, retries, structured logging, and the cursor store; the shape is what you'd write against.

# bank_of_baker_client.py
from typing import Iterator
from datetime import date
from openfinlab.aggregator import OAuthSession, FdxAccount, FdxTransaction

INSTITUTION_FDX_ID = "us-mt-bank-of-baker"   # mapped per institution during onboarding
SCOPES = ("accounts:read", "transactions:read", "statements:read")

def open_session(consent_token: str) -> OAuthSession:
    # Consumer-permissioned OAuth flow. The token is bound to a specific
    # scope set granted by the account holder; we never receive credentials.
    return OAuthSession.from_consent(
        consent_token,
        institution=INSTITUTION_FDX_ID,
        scopes=SCOPES,
    )

def accounts(s: OAuthSession) -> list[FdxAccount]:
    data = s.get("/fdx/v6/accounts").json()
    return [FdxAccount(**a) for a in data["accounts"]]

def transactions(s: OAuthSession, account_id: str, since: date) -> Iterator[FdxTransaction]:
    next_offset = None
    while True:
        params = {"startTime": since.isoformat(), "limit": 200}
        if next_offset:
            params["offset"] = next_offset
        page = s.get(f"/fdx/v6/accounts/{account_id}/transactions", params=params).json()
        for t in page["transactions"]:
            yield FdxTransaction(**t)
        next_offset = page.get("paging", {}).get("next")
        if not next_offset:
            return

# Failure-mode contract the sync worker assumes:
#   401  -> consent token expired; trigger re-auth pop-up on the user's next visit
#   403  -> the scope you asked for was not granted; downgrade and continue
#   429  -> aggregator rate limit; exponential back-off with jitter
#   451  -> consent revoked by the account holder; halt and purge cached records

The statement-PDF surface follows the same pattern (/fdx/v6/accounts/<id>/statements); the bill-pay and card-control surfaces, when needed, come from route 2 and are wrapped behind the same client object so the caller does not need to know which underlying route served a given field.

Notes the build handles, not blockers for you

Three things shape this engagement specifically; we handle each as part of the work rather than passing them back as prerequisites.

• Coverage at small institutions. The Financial Data Exchange's own whitepaper notes that permissioning technology “is largely unavailable to community banks today” through their core platforms. In practice that means a given customer's connection might resolve to direct OAuth or to a credential-mediated session depending on which aggregator picks up the institution and how it has been provisioned. We confirm coverage during onboarding by walking a consenting test account through each aggregator's link flow, write the SDK against whichever route is live, and keep the surface stable if the underlying route migrates later.
• The Grip shell is shared. The package suffix .grip appears across multiple community-bank apps (Bank of Baker, Baker Boyer Bank). The shell's network calls and field names track the shell, not the bank, so a brand-theme refresh by Bank of Baker does not break the protocol mapping. We pin the captured shell version in the report and run a re-check on every six-month maintenance cycle so a shell update is caught before it stops the sync.
• Multi-signer accounts. Bank of Baker's product set leans into business and agricultural accounts, which routinely carry additional signers. We model multi-signer accounts as separate consent contexts so a tax preparer with read scope on the farm operating account cannot see the owner's personal cards, and we expose the contexts as distinct clients in the SDK that share only the institution mapping.

What the user actually sees

Screens are linked from the Play listing; they are the surfaces the integration ultimately mirrors.

Sources checked, when, and how

Played the public Play Store listing, the FDIC BankFind record, the bank's own digital-banking pages, the CFPB rulemaking docket, and the FDX standards site against this brief on 31 May 2026. Where a number or date appears here, it is taken from one of the linked sources below or hedged in the text. Primary references:

• Google Play — Bank of Baker (com.bankofbaker.grip)
• FDIC BankFind — The Bank of Baker, Certificate 352
• Federal Register — Personal Financial Data Rights Reconsideration, 22 Aug 2025
• CFPB — Rules under development, Personal Financial Data Rights

Engineering notes — OpenFinance Lab — 31 May 2026.

Other community-bank apps in the same ballpark

If you are scoping an integration that should cover more than just Bank of Baker, these are the apps it tends to sit next to in a US community-bank or Mountain-West portfolio. Each holds a similar surface (balances, transactions, statements, internal transfers, RDC) and most route through the same aggregators.

• Opportunity Bank of Montana — full-service Montana community bank; balances, transactions, RDC, bill pay; common Plaid coverage.
• Stockman Bank — large Montana community bank with strong ag exposure; useful comparator for multi-signer farm accounts.
• First Interstate Bank — regional bank covering Montana and neighbouring states; broader product surface but similar consent shape.
• Glacier Bank — Glacier Bancorp brand serving north-west Montana; same FDX-aligned read pattern.
• Yellowstone Bank — eastern-Montana community bank; tight overlap with Bank of Baker's geographic footprint.
• Valley Bank of Kalispell — western-Montana community bank with iOS and Android mobile apps; standard transaction/statement surface.
• Farmers State Bank — Montana ag-and-community bank; ag-account workflow parallels Bank of Baker's.
• Bravera Bank — Bismarck-headquartered community bank with Montana branches; similar core, similar reach.
• Baker Boyer Bank — Pacific-Northwest community bank that ships the same Grip shell (com.bakerboyer.grip); a direct comparator for the shell-level protocol mapping.

Questions integrators usually ask

How fresh is the data we would actually see from Bank of Baker?

Through a permissioned aggregator (Plaid, MX, or Finicity), posted-transaction lag is normally one banking day; the aggregator polls the institution overnight and exposes the delta in the morning. Balances refresh on each call but are subject to the bank's own intraday posting. If you need same-second visibility on a P2P transfer, that is a different design — we drive it from your client-side hook on payment submit rather than waiting on the aggregator's polled view.

Does Bank of Baker have a direct OAuth handshake in Plaid, MX, or Finicity?

Most of the largest US banks have token-based OAuth with the three big aggregators; many community banks under a smaller core platform do not, and end up on credential-based screen reads instead. We confirm Bank of Baker's specific coverage during onboarding by running the aggregator's link flow against a consenting test account, then write the SDK against whichever route is live. If coverage shifts mid-engagement we swap the underlying provider without changing the surface your code calls.

What happens if CFPB §1033 gets rewritten while this is in production?

The CFPB has stayed the Personal Financial Data Rights rule and reopened the rulemaking, so any specific obligation that ships in the final rule may differ from the 2024 text. We anchor the integration on the account-holder's own written consent (which holds whatever §1033 ends up saying) and on FDX schemas (which the agency has signalled as the technical reference). If the final rule changes the fee model, the data scopes, or the representative definition, the change is normally a config update to the consent layer rather than a rewrite of your sync worker.

Can we ingest a customer's business and ag accounts alongside their personal account?

Yes, with two consent contexts. Bank of Baker's product set includes ag and small-business accounts, and these often carry additional signers; we model each consent independently so a CPA who has read scope on the business books does not also receive the owner's personal transactions. The SDK exposes the contexts as separate clients sharing nothing but the institution mapping.

Delivery is one to two weeks from the kickoff call, and the price starts at US$300 for the source-code drop — the Python and Node SDKs, the Go client, the OpenAPI specification, the protocol & auth-flow report, the automated test harness, and the interface docs — billed only after you have run the drop against your sandbox and signed off. If you would rather not host anything yourself, the same surface sits behind our endpoints on a pay-per-call basis with no upfront fee. Send us the app name and what you want from it and a scope plus a fixed bid comes back inside a working day.