Bfirst Banking: integrating the FSB Middlebury aggregator

Bottom line: the build is straightforward. The mobile front-end speaks a recognisable JSON dialect, the data the account holder sees on screen is reachable to an integration that holds their consent, and the regulatory picture in the US right now points us back to that consent rather than at any settled federal rule.

Data domains we can put on the wire

The app's description and online-banking pages enumerate the surfaces. Below is how we'd map them — domain, where it originates inside the FSB tenant, the granularity the screen exposes, and what an integrator would do with it.

The routes that actually apply here

Consumer-consented interface integration against the FSB tenant

This is the route we would recommend. With the FSB account holder's written authority, we work the same JSON request layer the mobile app uses, authenticate as the consumer through their own credentials and second factor, and pull the surfaces in the table above. The build returns a clean object model rather than HTML scraping. Effort is moderate, durability is good — the vendor platform changes the request shape rarely, and the maintenance pass we run catches drift.

Direct consumer-consented links to external institutions

Where the integration genuinely needs the external bank / credit-union accounts that the user has linked inside Bfirst's aggregation view, the right path is a direct AIS-style consent to each one of those institutions, not a re-derivation from the Bfirst tenant. We handle the orchestration. Effort scales with how many upstream institutions matter; durability depends on each of them.

Native statement export, as a fallback

The PDFs sitting in the statement archive are an honest fallback if all the integration ever needs is monthly history. Lowest effort, lowest fidelity (no transaction-level structure beyond OCR), and durable because statement formats change slowly. We use it when the use case really is "give me last twelve months as PDFs" and nothing more.

For most callers asking about Bfirst Banking, route one is what gets built and route three is what gets quoted as a cheap historical-data add-on.

What ships on this build

• An OpenAPI 3.1 specification covering the FSB tenant surfaces we extract — accounts, transactions, statements, transfers, card state, alerts — with each field annotated to the source screen.
• A short protocol and auth-flow report: the handshake, the second-factor branch, the cookie / token lifetime we observed, and the re-authentication trigger.
• Runnable source for the key endpoints, in Python and Node.js. Idiomatic, with retries, backoff, and a session-store interface so credentials never sit in the client process longer than they need to.
• An automated test suite that runs against either a consenting test account on the FSB tenant or a recorded fixture; CI-friendly.
• Interface documentation a non-author can pick up: setup, auth, the request layer, error model, and what to do when a screen the integration depends on changes.
• A compliance note: how the consumer's authorization is captured, where the audit log lives, retention defaults, and the revocation path.

A look at the request layer

The exact field names get confirmed against your tenant during the build — vendor platforms vary minor details by tenant. The pattern we recover when we work the .grip family looks like this:

POST /api/auth/session
Content-Type: application/json

{
  "username": "...",
  "credential": "...",
  "deviceId": "...",
  "deviceProfile": { /* fingerprint values the app sends */ }
}

200 OK
Set-Cookie: GRIPSESSION=...; HttpOnly; Secure; SameSite=Strict
{
  "sessionToken": "...",
  "mfaRequired": true,
  "mfaChannels": ["sms", "biometric"]
}

# Account list, once MFA is satisfied
GET /api/v1/accounts
Cookie: GRIPSESSION=...
X-CSRF-Token: ...

200 OK
{
  "accounts": [
    { "id": "...", "type": "checking",
      "displayName": "Checking ...1234",
      "balance": { "available": 1234.56, "current": 1287.91, "currency": "USD" },
      "lastUpdated": "2026-05-23T18:42:11Z" },
    { "id": "...", "type": "loan",
      "principal": 47210.00, "nextPaymentDue": "2026-06-15",
      "rate": 0.0625 }
  ]
}

# Statement archive for one account
GET /api/v1/accounts/{id}/statements?from=2025-11&to=2026-04
200 OK
{ "statements": [
    { "cycle": "2026-04", "downloadUrl": "https://.../signed?...",
      "expires": "2026-05-24T19:11:00Z" }
] }

Two practical points. The signed download URLs are short-lived, so the integration fetches and re-stores the PDF instead of handing the URL onward. The session cookie rotates on a short cadence — the integration treats a 401 mid-sync as "re-handshake silently" rather than a fatal error.

Engineering notes we account for on this build

• Consent-refresh window. Session tokens on these vendor digital-banking tenants rotate frequently. We wire the integration to detect the expiry and re-handshake using the stored consent material, so a long sync does not silently drop halfway through and so the calling system never sees a stale 401.
• Scoping to FSB Middlebury's own data. The in-app aggregation pulls the user's other banks and credit unions into the Bfirst view, but those links live in the consumer's hands. We extract the FSB-held accounts (deposits, loans, statements, transfers, card state) on this build; when the caller needs the upstream institutions too, we take the cleaner path of direct consented connections to each of them rather than republishing the aggregation layer.
• Re-validation against tenant releases. Vendor platforms ship UI updates that occasionally shift endpoint shape or rename a field. The maintenance pass we attach to the integration runs a small synthetic transaction sequence after each tenant release and surfaces any drift before the calling app sees it.
• Per-tenant secrets. The .grip family shares a recognisable platform skeleton, but session secrets, the second-factor branching, and a few endpoint paths are per-tenant. We re-verify every assumption against the live FSB tenant rather than copying values forward from another build.

Consent and the rule picture

First State Bank is a single-state community bank with five branches; it is on the long-tail end of any §1033 phase-in tiers as they were last drafted. We don't ride that rule for this build. The CFPB Personal Financial Data Rights rule sits in reconsideration with enforcement enjoined, so we treat it as the forward-looking piece, not as current law. The dependable basis is the FSB account holder's own written authorization — captured in our onboarding, scoped to the data domains the integration actually touches, dated, revocable on request, and stored with the audit log. If and when a final §1033 rule lands and Crystal Valley's asset profile puts FSB in scope, the consent capture and audit log are shaped so they can swap onto the regulator's format without rewriting the data layer underneath.

Standard companion controls: data minimisation (we extract the domains the use case actually needs, not the full graph), NDA between us and you where the use case warrants it, and a documented retention default that you can shorten.

Freshness and reliability

Balance and transaction freshness on this tenant track the screen — what the consumer sees is what the integration sees, within seconds. Statement availability follows the bank's monthly cycle; expect a new statement within a few business days of cycle close. The honest soft spot is the second-factor flow on first login: any account holder who has biometric-only set up needs to step through SMS once for the integration to establish itself, and we cover that handoff in the onboarding script we ship.

Where these notes come from

This brief draws on the Bfirst Banking Google Play listing for the feature set and the description, the bank's own online-banking FAQ for the customer-facing surface, the CFPB Personal Financial Data Rights Reconsideration page for the current US rule status, and Cozen O'Connor's 2026 alert on the injunction and the reopened compliance timeline. Counts and dates that are not attributed inline are not asserted as fact and would be re-confirmed against the live tenant during the build.

Mapped by the OpenBanking Studio integration desk, May 2026.

Community banking apps in the same shape

If a Bfirst Banking integration is on the table, the same engagement pattern usually applies to other small US community banks and to the wider northern-Indiana set. None of the following are endorsements or rankings — they are listed so the keyword shape of the ecosystem is on the page, and to flag where a unified integration across several of them is sensible.

• CBNA Mobile Banking (Community Bank N.A.) — another .grip-suffix tenant; balances, transactions, transfers, mobile deposit.
• Our Community Bank (Community Bank of Marshall) — also on the .grip platform; the same data surfaces apply.
• Lake City Bank — northern and central Indiana; standard consumer banking app, branch network across the region.
• Centier Bank — family-owned Indiana bank, retail mobile banking with P2P and mobile deposit.
• Horizon Bank — northern Indiana / southwestern Michigan; Q2-fronted consumer app.
• 1st Source Bank — the largest locally controlled bank in the area; deposits, lending, wealth lines.
• Community First Bank of Indiana — central Indiana community bank with a consumer mobile app on a similar tenant model.
• BankFirst Financial Services — Mississippi community bank, named similarly but unrelated to FSB Middlebury; included because the name often gets searched alongside.

Interface evidence

The Play Store screenshots; click to enlarge.

Questions integrators have asked us

Does the in-app aggregation — external banks pulled into the Bfirst view — come through to an integration?

That feature is consumed by the user interface, not republished as a separate feed on the FSB tenant. For an integration that needs upstream institutions as well, the cleaner pattern is a direct consumer-consented link to each one; the Bfirst surface itself is what we extract for the First State Bank-held accounts (deposits, loans, statements, transfers, card state).

Is the 'grip' suffix in the package id meaningful for how you reach the data?

Yes, in a useful way. The same suffix shows up across several small US community-bank apps (for example bank.ourcommunity.grip, com.cbna.grip), which indicates a shared vendor digital-banking front-end. The auth handshake and endpoint shape we recover are recognisable across that family — but session secrets and routing are per-tenant, so we still scope the build to FSB Middlebury and re-verify everything against the live tenant.

How does the CFPB §1033 reconsideration change a build started in 2026?

It does not change the foundation. We anchor the build to the FSB account holder's own written authorization, which is the dependable basis today. §1033 is in CFPB reconsideration with enforcement enjoined, so we don't treat it as the operative law for this work; we leave the consent capture and audit log shaped so they can swap onto the regulator's format if and when a final rule lands and Crystal Valley is in scope.

Can you cover the Crystal Valley side as well, or only the Bfirst Banking app surface?

The mobile and bfirst.bank web front-ends share the same digital-banking tenant, so the surfaces overlap and we usually build against both — the mobile traffic is often the cleaner JSON path. Anything that sits inside the bank's core (loan origination back-office, internal trust accounting) is not on this surface and is not in this kind of build.

Closing — how this gets built and what it costs

From the requirements end this is small: send us the app name (Bfirst Banking — FSB Middlebury), what surfaces matter, and whether you need a one-shot historical pull or a running sync. Access, consent capture, and any sponsor sandbox or consenting test account are arranged with you during onboarding. Pricing starts at $300 for source-code delivery, paid only after delivery once the build is in your hands and working; the same scope is also available as pay-per-call against our hosted endpoints, no upfront fee. Either runs a one to two week cycle. Send the brief to /contact.html.