Reaching Farmers St Bank account data with member consent

Inside the FSB app the data is conventional consumer banking. Balances on checking and savings, a transactions list members can mark up with tags, notes and photographed receipts, monthly statements as PDFs, transfers between the member's own accounts, bill-pay and person-to-person payments, remote check deposit by photographing the front and back, a debit-card on/off toggle, balance-threshold alerts, and a branch / ATM locator. None of that is exotic — the substance is in how it gets pulled into another system, cleanly, on a US community bank.

The Android package is com.farmersstbank.grip per its Play Store listing, one of several small US community-bank apps in the same GRIP-style mobile family. The dependable basis for pulling FSB account data into another system is the member's own written authorization — a scoped, recorded consent on their own account. CFPB §1033 is in reconsideration and not the governing rule we plan against; the consent route is what an integration on this app builds on.

What this app actually holds

Eight surfaces are worth naming individually, because each maps to a slightly different downstream use.

Authorized routes to the data

Member-authorized account access (the spine)

The member who holds the FSB account signs a written consent and a credentialed session is opened on their behalf, scoped to the surfaces named in that consent. This is the route that actually works for a US community-bank deployment today. Effort: medium. Durability: session lifetime is short on apps of this shape, so the integration plans for token rotation rather than treating it as an exception.

Protocol mapping of the mobile app's traffic

With the customer's written authorization on their own account, we map the FSB app's request / response shapes — login, refresh, balance, transactions, statement download, transfer, card-toggle — into a stable API surface. Effort: medium-to-higher when the app does mobile-side request signing or device-binding. Durability: a fresh diff against an authorized session is part of how we cover major app releases, and that work is scoped into the engagement rather than left to the customer.

Native export

Monthly PDF statements and any CSV the online banking portal exposes can be fetched after login. Effort: low. Durability: high for what it covers, but slow-cadence — it complements the consented-session route, not replaces it.

For an FSB build we lead with the consented session, add native PDF / CSV fetch so the monthly statements are covered without polling, and use the traffic-mapping route to fill in any surface the session does not expose directly. That order puts the working integration in front of you fastest.

What goes out the door

• An OpenAPI specification for the surfaces you actually want — balances, transactions including the member-attached tag / note / photo fields, statements, transfers, RDC, card-toggle, alert rules.
• A protocol & auth-flow report covering login, token refresh, biometric sign-in interaction, session lifetime, and any mobile-side request signing the app uses.
• Runnable Python and Node.js source for each endpoint, with retries, error mapping, and a thin local-cache so polling does not hammer the bank.
• A consent-record schema — who consented, when, scope, expiry, revocation path — and the code path that enforces it.
• An automated test pack: happy-path, expired-session, low-balance edge, RDC submission, card-toggle round-trip, statement download.
• Interface documentation written for the engineer who has to keep this running, plus data-retention guidance shaped to the US picture (Reg E and GLBA expectations, applicable state privacy law).

How a typical call looks

One concrete shape, illustrative — exact wire details are confirmed during the build against an authorized member account:

import requests

class FSBSession:
    def __init__(self, base, token):
        self.base = base.rstrip('/')
        self.s = requests.Session()
        self.s.headers.update({
            "Authorization": f"Bearer {token}",
            "Accept": "application/json",
        })

    def transactions(self, account_id, since, until):
        r = self.s.get(
            f"{self.base}/accounts/{account_id}/transactions",
            params={"from": since, "to": until,
                    "include": "tags,notes,receipts"},
        )
        if r.status_code == 401:
            raise SessionExpired("token rotated — re-run the consent flow and retry")
        r.raise_for_status()
        return [self._normalize(t) for t in r.json().get("items", [])]

    def _normalize(self, t):
        # bank-authoritative line + parallel member annotations
        return {
            "id":         t["id"],
            "posted_at":  t["posted"],
            "amount":     t["amount"],           # signed; debits negative
            "merchant":   t.get("merchant_name"),
            "tags":       t.get("user_tags", []),
            "note":       t.get("user_note"),
            "receipts":   [im["url"] for im in t.get("receipt_images", [])],
        }

Card-toggle and threshold-alert rules are written through similar idempotent calls. RDC submissions go through a small state machine; see the next section.

Freshness and write surfaces

Three things are worth being honest about up front, because they shape how the integration runs more than the schema does.

First, this is poll-based. The bank does not push us a webhook on a new transaction or on RDC settlement; the consented session polls. We tune the cadence to be useful without abusing the bank's infrastructure — typically minutes for balances and transactions, hours for statements, and event-driven (after a submission) for RDC clearance.

Second, several surfaces are write-back: the debit-card on/off toggle, threshold-alert rules, and bill-pay payee management. We expose them as idempotent endpoints and round-trip them in the test pack, so the bank-side state stays observably correct after each call.

Third, freshness of the receipt-photo field depends on the member opening the FSB app and attaching the image. That is a member action, not a bank action. The integration surfaces "this transaction has a receipt" cleanly and refetches on the next poll cycle once the member adds one.

Consent and the US picture

Farmers St Bank is a US community-bank deposit-taker. There is no PSD2-equivalent for the US right now, and the CFPB Personal Financial Data Rights rule (§1033) is currently in reconsideration rather than in force — we do not treat it as the governing framework for an FSB integration, and we do not plan the build around any specific §1033 obligation as if it were settled.

What an FSB integration runs on instead is the FSB member's own written authorization. The consent names exactly which data domains may be read — for example, transactions including the member's own tags and notes, monthly statement PDFs, and the card-control state — names the duration, names a revocation path the member can use without us, and names the minimum the integration retains. We log the consent, expose it back to the member on request, and minimize the data accordingly. If something does land later that gives integrators a regulatory route into FSB-shaped banks, the consent records the integration already keeps are the audit artefact that route would ask for.

Build decisions on this one

1. Two layers of transaction data, not one. The bank's own merchant / amount / date line and the member's tags, notes and receipt photos are different in provenance and in trust. We model them as parallel fields in the integration's transaction object so a downstream system — accounting, expenses, personal-finance — can choose whether to import the member's annotations or only the bank-authoritative line.
2. RDC as a state machine, not a single call. Remote deposit submission is one call; settlement happens later, and the check images linger server-side until clearance. We model RDC as submitted → received → cleared / rejected and wire status updates into the consent-scoped polling, instead of pretending the bank emits a webhook it does not.
3. Plan the consent refresh around how short the session is. Sign-in on FSB is a 4-digit passcode or biometric on supported devices, per the app's own description — typical of a community-bank app of this shape, sessions are short and tied to device binding. We design the refresh path so the integration does not silently expire: the member gets a quiet re-prompt before a session dies, and consent expiry is a tracked event in the integration's own audit log.
4. Diff the call layer on every major FSB app release. When the app ships a meaningful version bump the request shapes can move. The engagement includes a quick run of the test pack against a current member's authorized session, with diffs and patches landed before any downstream consumer notices a change.

Adjacent community-bank apps

• Community Bank N.A. — CBNA Mobile Banking. A northeastern US community-bank deployment with transaction notes and statement access closely comparable to FSB; the integration shape is the same.
• Community Banks of Colorado — CoBnks Mobile. Small-bank app with card controls, RDC and bill pay; the consumer-consent route is identical.
• Community Bank of Mississippi — CB2GO. Adds credit-score monitoring on top of the checking / savings surfaces FSB exposes.
• The Community Bank, Liberal, Kansas. A minimal deployment limited to balances, history and transfers; the consent path is the same and the surface set is a strict subset of FSB's.
• FSB Now — Farmers State Bank (Iowa). Separate Iowa-based small-bank app with bill-pay, Zelle and RDC, on the same US regulatory picture as Farmers St Bank's FSB.
• Farmers State Bank of Parkston. Another community-bank deployment using a similar package layout (com.fsbparkston.grip); data domains overlap with FSB's almost completely.
• Farmers State Bank, Mountain City, TN. Tennessee community-bank mobile deployment with the same headline surfaces and the same consent-based integration approach.
• Farmers Savings Bank, Iowa. Another small Midwest community-bank app in the same niche; useful when an integrator is pulling data across a portfolio of small banks rather than just one.

Questions integrators ask about FSB

Can the integration capture the tags, notes and receipt photos members add inside the FSB app, or only the bank's own transaction fields?

Both. The bank-authoritative line (date, amount, merchant) and the member-supplied annotations (tags, notes, receipt images) come back as parallel structures so a downstream import can take either or both — useful when you want the receipt that the member already photographed into the app.

Is the open-banking rule that would normally govern this work — CFPB §1033 — actually in force on Farmers St Bank right now?

No. §1033 is in reconsideration and is not the working basis for an FSB integration today. The dependable basis is the member's own written consent to a scoped session, which we record and minimize the data against. If something successor-shaped lands later, the consent records the integration already keeps carry over as the audit artefact.

How does the card-control toggle behave through an integration — can we lock the debit card from outside the app?

Yes, the toggle is a write surface. We expose it as an idempotent call and round-trip it in the test pack, so disabling and re-enabling from outside the FSB app leaves the bank-side state observably correct.

What does the RDC flow look like when it's automated — does the bank send us a webhook when a deposit clears?

RDC settles asynchronously and the bank does not push us a webhook. The integration polls the deposit's state inside the consented session — submitted, received, then cleared or rejected — and surfaces those transitions to your downstream system.

Sources we checked

This brief draws on the app's own Play Store listing for the data domains and security posture, the CFPB's published material on Personal Financial Data Rights for the current §1033 status, and OpenBanking Studio's prior integration work on similarly-shaped community-bank apps in the same package family. Specific deep links used:

• Farmers St Bank - FSB on Google Play — package, app description and feature list.
• CFPB — Required Rulemaking on Personal Financial Data Rights — current bureau-side status of §1033.
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 2025) — the reconsideration ANPR.
• Congressional Research Service — Access to Consumer Financial Data: Open Banking and the CFPB's §1033 Rule — neutral overview of the rule's current status.

Reviewed May 2026 by the OpenBanking Studio integration desk.

If FSB is the app you need to pull from, give us the surfaces you care about and what you want downstream — the access arrangement and the consent paperwork are part of the project, handled with you. Source-code delivery for an FSB integration starts at $300, paid after we hand it over and you have run it against an authorized account; if you would rather not host it yourself, our hosted endpoints take per-call pricing with no upfront fee. Build cycle is one to two weeks. Start the conversation at /contact.html.

Mapping reviewed 2026-05-20.