An integration plan for Bath State Bank's GRIP app

Bath State Bank carries FDIC certificate 8035 and runs three Indiana branches with roughly $143M in assets per a public bank-directory listing — a long-tail community bank whose customer data lives behind a credentialed online-banking session reached through the Bank by Mouse portal and the GRIP app (Google Play package com.bathstatebank.grip). The bank's Mobile page and the Play listing describe the same surface: accounts and balances, cleared check images, eStatement PDFs, A2A and loan transfers, scheduled bill pay, P2P, secure messaging, debit-card enable / disable, alert management. That is enough for most aggregation, PFM and accounting-sync use cases. The build below treats it as the source of record.

What the GRIP app actually shows the customer

Surfaces, where each originates, and what an integrator would normally do with them. Wording follows the bank's own labels.

Workable routes into the data

Three routes apply at a bank of this size. We pick per customer at scoping.

Route 1 — customer-consented session against the online-banking back end

The same Bank by Mouse credentials that drive the GRIP app drive a session our build can run on the customer's behalf, with their written consent and a credential vault we set up jointly. This is the read-and-write route. It mirrors what the customer's browser or phone does, so it survives core-platform decisions the bank does not pre-announce. We handle MFA prompts, cookie chains and CSRF token refresh in code.

Route 2 — aggregator API (Plaid, MX, Finicity)

Where Bath State Bank appears in an aggregator's institution directory with usable throughput, we run that aggregator's OAuth-style consent flow and consume their normalized account / transaction shape. Coverage for community institutions rotates as cores move and as aggregator contracts cycle, so we check it live during scoping rather than promising it. When it works it is the cleanest path; when it does not, route 1 is already there.

Route 3 — native export, archival only

The customer can download eStatement PDFs and dated transaction ranges from inside the app. For a one-shot reporting or archival use case that is enough and we wire it as a scheduled fetch. It is not enough for anything real-time.

For almost every Bath State Bank build we wire route 1 first and add route 2 the moment aggregator coverage proves stable for that customer. Aggregator coverage is the variable. The customer's own session is not.

A worked example: pulling statement transactions

A trimmed sketch of what the read-side call surface looks like once the consented session is established. Field names and the auth-error shape are illustrative; the exact wire format is confirmed during the build.

POST /v1/bsb/session
Content-Type: application/json
{
  "consent_id": "bsb_2026_05_",   // from our consent ledger
  "credential_ref": "vault://bsb/" // never the plaintext
}
→ 200 { "session_token": "...", "expires_in": 540, "mfa_required": false }

GET /v1/bsb/accounts
Authorization: Bearer <session_token>
→ 200 [
  { "account_id": "DDA-****1234", "type": "checking",
    "balance_current": 4821.07, "balance_available": 4521.07,
    "as_of": "2026-05-30T14:02:11Z" },
  { "account_id": "LOAN-****8810", "type": "consumer_loan",
    "principal_balance": 12503.44, "next_due": "2026-06-15" }
]

GET /v1/bsb/accounts/DDA-****1234/transactions?from=2026-04-01&to=2026-04-30
→ 200 [
  { "posted": "2026-04-02", "amount": -42.18, "memo": "ACH KROGER #221",
    "check_image": null, "trace": "..." },
  { "posted": "2026-04-05", "amount": -180.00, "memo": "CHECK 1042",
    "check_image": "/v1/bsb/images/img_8f1c...", "trace": "..." }
]

// Errors carry both transport + bank reason
→ 401 { "error": "session_expired", "retry": "POST /v1/bsb/session" }
→ 423 { "error": "mfa_challenge",   "channel": "sms",
            "challenge_id": "mfa_..." }

Money-movement endpoints (POST /v1/bsb/transfers, POST /v1/bsb/billpay/payments) follow the same shape but require a per-instruction signed consent record from the account holder; we keep that ledger and surface it in the audit log.

What ships when you engage us

Concrete artifacts, scoped to the Bath State Bank surfaces above:

• An OpenAPI 3.1 spec for the read-side (accounts, transactions, check images, eStatement PDFs), and a separate gated spec for money movement (transfers, bill pay, P2P).
• A protocol & auth-flow report — login, MFA branches, session cookies, CSRF token rotation, and the binary fetch path for check images and statement PDFs.
• Runnable source in Python and Node.js, with route 1 (consented session) and route 2 (aggregator) behind the same caller interface.
• Automated tests against a consenting test account: per-endpoint contract tests, plus an end-to-end smoke that logs in, fetches one known account, and pulls one statement PDF.
• Interface docs a back-end engineer can follow without us in the room, including how the GRIP session's expiry and MFA challenges are handled.
• Consent-ledger schema, log-retention defaults, and a deletion-request playbook.

Engineering judgment calls we make on this build

Things we plan around for a Bath State Bank-shaped integration — work the studio accounts for so nothing breaks the first time the bank changes a UI string.

• Session lifetime is short; MFA is a branch. We size the worker pool around an authenticated window measured in minutes and let the caller submit a batch while the wrapper transparently re-authenticates underneath. SMS or push MFA surfaces as a structured response the caller satisfies out-of-band, not a 500 to reverse-engineer. For unattended workloads we run an enrolled device profile that the bank has consented to.
• Check images and eStatement PDFs are first-class. They are stored as binary blobs against the transaction or statement row that referenced them, with content-hash deduplication, so a reconciliation tool downstream does not refetch the same image twice.
• Front-end strings drift; we re-validate. Community-bank online-banking front ends get cosmetic updates on the vendor's schedule, not the bank's, and a renamed label is enough to break a scraper. The maintenance contract includes a light continuous re-check so a broken selector pages us, not you.
• Aggregator coverage is checked at scoping, not assumed. Whether the bank is currently live and stable on a given aggregator is something we test against a consenting account before recommending route 2. Aggregator availability does not get baked into the price.

Authorization and the US data-rights picture

The dependable basis for this integration is the customer's own consent — through their online-banking credentials in a vault they control, or through an aggregator's consent flow they have explicitly approved. We keep a per-customer consent record with scope, granted-at, expiry, and a revocation path that severs the session immediately on request.

The forward-looking piece is the CFPB Personal Financial Data Rights rule under §1033. It is not in force: the rule was stayed by a federal court in late 2025 and the CFPB is reconsidering it via an Advanced Notice of Proposed Rulemaking, so we do not present it as the governing US framework and we do not plan the build on it. For Bath State Bank's asset size — about $143M — the original phase-in would not have reached the institution for years if it stood. If a revised rule eventually produces a standardized US data-rights route, that route slots in behind the same caller interface without a rewrite.

How we run the engagement

Source code lands in your repository from $300, payable only after the build runs against your consenting test account and you have signed it off — that covers the read-side surfaces above; money-movement endpoints are scoped on top. If you would rather skip the build, our hosted endpoint exposes the same shape and bills per call with no upfront fee — useful for occasional pulls or before you own the integration. Cycle is one to two weeks for the read-side; access and onboarding are handled with you during scoping. Send the app name and what you want to our contact page and we reply with the route we'd recommend for your case.

Peer apps integrators run into alongside Bath State Bank

US community and credit-union mobile apps that show up in the same integration conversations. Each is a separate authenticated channel and would be scoped on its own merits.

• Centier Bank — large Indiana-based community bank, similar mobile feature set.
• Old National Bank — Evansville-headquartered regional, consumer and SMB data flows.
• Lake City Bank — Indiana mid-size community bank, retail plus treasury features.
• Horizon Bank — Indiana / Michigan regional, remote deposit and bill pay surfaces.
• STAR Financial Bank — Indiana community bank, comparable mobile-channel scope.
• 1st Source Mobile Banking — South Bend-based regional, deeper on the small-business side.
• Indiana Members Credit Union — credit-union ledger model, same kinds of consented surfaces.
• Forum Credit Union mobile — Indianapolis-area CU with a typical community-CU mobile profile.

Questions integrators ask first about Bath State Bank

Is Bath State Bank reachable through Plaid, MX or Finicity right now?

Coverage at the major aggregators rotates as institutions move cores and contracts cycle; even when a logo appears in the directory, throughput limits, MFA quirks and outage windows decide whether it is usable for your workload. We check live during scoping. A customer-credentialed fallback is built either way so the integration does not depend on one aggregator's directory.

What does the GRIP suffix in the package name tell you about the back end?

It is the bank's chosen app slug, not a public clue to the core. We confirm the actual online-banking platform during the build by watching the device's authenticated traffic against the consenting account — faster than guessing from package metadata, and matches what the integration relies on at run time.

Can the build pull cleared check images, not only transaction lines?

The app surfaces check images and signed eStatement PDFs to the logged-in customer, so the same authenticated session can fetch them. We treat images and PDFs as first-class outputs, store them as binary blobs against the transaction row that referenced them, and document the link in the OpenAPI spec.

Will the CFPB Personal Financial Data Rights rule change the integration we ship?

Probably not for the near term. The rule was stayed in late 2025 and is under agency reconsideration, and the original phase-in would not have reached an institution of this asset size for years. The dependable basis for the integration is the customer's own consent, and the build is structured so a standardized US data-rights route, if and when it lands, slots in behind the same caller interface without rewriting the application layer.

Sources we opened during this mapping

The mapping above sits on a small set of primary sources. Each is a deep link, not a homepage, so anyone reviewing the page can re-walk what we walked.

• FDIC BankFind — Bath State Bank, cert 8035 — the institution record, charter type, and supervising regulator.
• Bath State Bank — Mobile services page — the bank's own description of what the GRIP app does and how it ties back to Bank by Mouse.
• Google Play listing for com.bathstatebank.grip — package identifier and the surface inventory the app advertises.
• CFPB Personal Financial Data Rights program page and the August 2025 reconsideration notice — confirming the §1033 rule's stayed-and-reopened status.

Mapping by OpenBanking Studio's community-banks desk · May 2026.