Working with SBF Mobile data for a small Minnesota community bank

State Bank of Faribault holds approximately $320 million in assets across a small Minnesota footprint (per FDIC BankFind, certificate #1610). Its retail mobile front end is SBF Mobile — Android package com.tsbf.grip, iOS bundle id1237482885 — and unlike most community-bank apps of this size it carries an explicit multi-account aggregation feature. The customer pulls balances, transactions and merchant-spending averages from accounts at other banks into the same SBF Mobile view, and decorates individual postings with tags, notes, receipt photos and geo information. That stack of native bank data plus aggregated external data plus user-added enrichments is what an integration against this app is almost always after.

The bottom line: an integrator gets the cleanest, most durable view of an SBF Mobile customer by working with the consumer's own authenticated session against the bank's portal — the same surface SBF Mobile itself talks to. That route reaches every native State Bank of Faribault deposit, loan and statement account, plus the PFM overlay that holds tags, notes and the aggregated external-bank rows. We treat it as one integration with two clearly-labelled domains so the consuming side never has to guess which posting came from where.

Where the account data lives inside SBF Mobile

The app is a PFM-flavoured banking front end, so the data is layered. Native bank records sit underneath; PFM enrichments and aggregated external accounts sit on top of the same posting keys.

A sample request against the bank's portal session

This is illustrative — the exact endpoint paths and parameters are confirmed during the build against a consenting test login. The shape, though, is what an authorized integration against an SBF Mobile session looks like in practice.

# Authorized session against SBF Mobile / tsbf.com online banking.
# All calls run under the consumer's own credentials with their consent;
# session_token never leaves the build environment.

import requests

s = requests.Session()
s.headers["User-Agent"] = "SBFMobile/3.x (com.tsbf.grip; Android)"

# 1. Sign in. The 4-digit passcode the app sets locally is a device
#    convenience; the server side still wants the internet-banking
#    username and password to mint a session.
auth = s.post(
    "https://m.tsbf.com/api/session",
    json={"username": USER, "password": PWD, "device_token": DEVICE_ID},
    timeout=15,
).json()
session_token = auth["token"]

# 2. List linked accounts. Two clusters come back: native State Bank of
#    Faribault accounts, and the external rows aggregated through the
#    bank's PFM layer. We label each row with its origin.
accounts = s.get(
    "https://m.tsbf.com/api/accounts",
    headers={"Authorization": f"Bearer {session_token}"},
).json()["accounts"]

# 3. Paged transactions for one account, with PFM enrichments alongside.
for a in accounts:
    txns = s.get(
        f"https://m.tsbf.com/api/accounts/{a['id']}/transactions",
        params={"from": "2026-01-01", "to": "2026-05-24", "limit": 200},
        headers={"Authorization": f"Bearer {session_token}"},
    ).json()
    for t in txns["items"]:
        emit({
            "account_id": a["id"],
            "origin": "sbf" if a["native"] else a["external_institution"],
            "posted_at": t["postedAt"],
            "amount": t["amount"],
            "merchant": t["description"],
            "tags": t.get("tags", []),
            "note": t.get("note"),
            "geo": t.get("geo"),
            "receipt_url": t.get("attachment", {}).get("url"),
        })

A small normalized envelope sits on top of that so downstream consumers see the same shape for native and aggregated rows:

{
  "account": { "id": "...", "origin": "sbf|external", "institution": "..." },
  "posting": { "id": "...", "posted_at": "...", "amount": -42.13, "currency": "USD" },
  "merchant":  "TARGET T-2741 FARIBAULT MN",
  "enrichment": { "tags": ["groceries"], "note": null, "geo": {"lat": 44.29, "lng": -93.27} }
}

What ships back from this engagement

• OpenAPI 3.1 spec covering the four domains above — sessions, accounts, transactions, and the PFM enrichment fetch — with the native/aggregated split modelled as an explicit origin on every row.
• Auth-flow report documenting the login handshake, the device-token / session-token chain, the way the 4-digit local passcode interacts (or does not) with the server session, and the refresh / re-auth behaviour seen during the build.
• Runnable Python source for the snippet above plus a Node.js variant, both exercising a consenting test login end-to-end — not a stub.
• Automated tests against a consented account, including a small re-validation harness that catches a field-name or path change without re-running the whole discovery pass.
• Interface documentation describing each domain in customer-language, the field-by-field origin of every value, and the way receipt-image fetches are paged separately.
• Compliance and retention guidance — consent record format, log-line minimum, data-minimization defaults — sized for a community bank's posture, not a large-bank policy stack.

The authorized paths into SBF Mobile data

Route A — consumer-permissioned authorized integration against the bank's portal

The customer signs in to their own SBF Mobile / State Bank of Faribault internet banking and authorizes the integration. We map the same session calls the app itself makes, run them under that consent, and bring back the four domains. This is the route we would actually recommend for a State Bank of Faribault engagement: it reaches everything the app shows the customer, it is anchored in the customer's own authorization (which is the dependable legal basis today), and it covers both the native bank accounts and the PFM aggregated rows. Effort is modest because the surface is one portal; durability is medium — small portal changes are handled by the re-validation step.

Route B — routing through a regulated US data aggregator

Plaid, MX and Finicity already cover thousands of US community banks under bilateral access agreements, and a State Bank of Faribault customer can authorize their account into one of those aggregators. We can deliver the integration as a thin layer over the aggregator's connection rather than directly against the portal, which trades off a little granularity (PFM enrichments and image attachments are not always carried through) for the aggregator's own connectivity SLA. We pick this when the consuming side already runs on an aggregator stack and wants one auth surface for all institutions.

Route C — the customer's native export

SBF Mobile and the State Bank of Faribault internet banking site allow the customer to download statements and transaction CSV/QFX exports. For a one-shot pull or a tax-cycle handoff, that route is genuinely useful. It does not deliver enrichments and is not a live integration, so we recommend it only as a fallback or alongside route A for a small historical backfill.

For a recurring read of this app we would build directly against the portal session, and only fold an aggregator in when the consuming side has already standardized on one. The route choice is made during scoping against the actual consumer base, not by template.

Engineering judgment we account for during the build

• Native vs. aggregated rows are labelled at ingest, not after. The aggregated external-bank accounts that flow through the PFM layer have different freshness, different reconciliation behaviour, and different consent semantics than the native State Bank of Faribault deposit and loan accounts. We tag the origin on the way in so a downstream payment-decisioning consumer can decide what to trust per row, instead of mixing them and discovering the mismatch later.
• The 4-digit passcode is a device convenience, not the server auth. The local passcode the app exposes guards the on-device launch; the bank's session is still minted from the internet-banking credentials. We document that separation explicitly so an integrator does not build the consent UX around a 4-digit prompt that has no server-side weight.
• We design around the portal-refresh cycle. A small Minnesota community bank typically refreshes its online banking front end on the vendor's release cadence rather than on its own. The delivered code ships with a small probe that exercises the auth and transaction endpoints against a consenting test login, so a field rename or a path move shows up as a one-line diff next time you run it — not as a customer-visible outage.
• The aggregated layer can change institutions silently. If the bank swaps the underlying aggregation provider, the external-row shape can change without an SBF Mobile version bump. The origin labelling above is what makes that recoverable — we re-point the aggregated-row parser without touching native-row code.
• Access onboarding is handled with you, not before you. A consenting test login (an employee or pilot customer of State Bank of Faribault), an NDA where one is requested, and a written consent record — we set those up together at kickoff so the build can run.

The compliance posture for a small FDIC-supervised bank

State Bank of Faribault is a state-chartered commercial bank, FDIC-supervised (Fed nonmember), with FDIC insurance going back to 1934 per FDIC BankFind. The integration sits within US consumer financial law: the customer's own authorization is the basis we rely on, the data is held with deposit-secrecy-style care, and access events are logged into a consent record we hand back with the delivery.

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is the open-banking piece that might apply here later. As of this writing it is not in force: enforcement is enjoined and the rule is back in agency reconsideration following an August 2025 advance notice. For a community bank of State Bank of Faribault's size, the rule's eventual asset-tiered obligations and timelines are unsettled, so we do not anchor the integration to §1033. We anchor it to the customer's consent today and re-point to a §1033 endpoint if and when the bank's tier is obliged to expose one.

Sources checked while writing this

Primary sources reviewed for this brief: the bank's own mobile-banking page tsbf.com/resources/mobile-banking, the SBF Mobile listing on Google Play play.google.com (com.tsbf.grip), the FDIC's BankFind record for certificate #1610 banks.data.fdic.gov/...details/1610, and the CFPB's Personal Financial Data Rights page covering the current reconsideration status consumerfinance.gov/personal-financial-data-rights. Where this brief carries a numeric fact (asset size, FDIC cert, package ID, App Store ID), it is sourced inline.

Reviewed 2026-05-24 by the OpenBanking Studio integration desk.

Other community-bank apps with the same integration shape

These are apps an integrator working with SBF Mobile is likely to encounter alongside it — small US community banks with PFM-style mobile front ends, where the integration story is the same. Plain references, not endorsements.

• CBNA Mobile Banking (Community Bank N.A., com.cbna.grip) — same Android package suffix as SBF Mobile, suggesting a shared white-label platform; deposit, transaction and PFM data shape lines up closely.
• CCFBank Mobile — Citizens Community Federal, a Wisconsin and Minnesota community bank with native mobile and online banking.
• CFBank of WI — Community First Bank (Wisconsin) retail mobile app for deposit and transaction data.
• First National Bank — the Iowa / Illinois / Minnesota / South Dakota community bank's mobile app, with check deposit, transfers, statements and alerts.
• Premier Banks of MN — a Minnesota community-bank mobile app for retail deposit accounts.
• Rivers Edge Bank — a small upper-Midwest community bank with a comparable retail mobile surface.
• Community First Bank Minnesota — another Minnesota community-bank mobile front end with native deposit-account data.
• Bremer Bank — now a division of Old National Bank as of 2025; historically a regional Minnesota community-bank mobile app at a larger asset tier.

Questions integrators have asked about SBF Mobile

Source-code delivery for the SBF Mobile integration starts at $300, paid only after a runnable build lands on your machine and you are satisfied with it; if call volume is light or unpredictable, you can instead call the hosted endpoint and pay per call with no upfront fee. The cycle from kickoff to first usable artifact is 1–2 weeks either way. Both paths route through /contact.html.