Pulling accounts and transactions out of the Farmers Bank Spencer, IA Mobil app

The package id com.farmerstrust.grip gives away the stack before you open the app. Grip began at Banno as a white-label PFM-plus-mobile-banking shell, was resold by Jack Henry's ProfitStars division under the name Andiamo, then was folded into Jack Henry outright when it acquired Banno. The Farmers Bank Spencer, IA Mobil app is one of those deployments. Knowing that changes how the integration is shaped — there are two ledgers behind a single screen, the issuer's own and the PFM aggregator's, and any usable client has to keep them straight.

The issuer underneath is a 1916-founded Iowa community bank — Farmers Trust and Savings Bank, Spencer, IA — operating as a state-chartered, FDIC-insured commercial bank per the FDIC BankFind record. Small institution, one charter, one digital channel. The mobile app inherits its session from Internet Banking, which the Play Store description states explicitly as a prerequisite for enrollment. That single fact carries most of the auth design.

What's actually inside the app

The Play listing describes balances, transaction history, merchant-spending averages, custom tags, notes, photos and geo annotations on transactions, alerts for low funds and upcoming bills, and an in-app ATM and branch directory. Underneath, these resolve to a handful of distinct surfaces — some issuer-side, some PFM-side.

Three routes to the same account

The surfaces above line up to three practical routes. We name the one we would actually take at the bottom.

1 · Authorized interface integration against the member's session

The mobile app authenticates against the same Internet Banking session the Play listing names as a prerequisite. With the member's permission and under NDA, we mirror the device's request shape — headers, CSRF, cookies, Banno-style bearer where present — and pull the two parallel feeds described above. Setup time is short; the auth flow needs documenting once and then re-tested whenever Banno ships a UI change. Durability is good because the underlying platform is shared across many community banks, not custom to this one charter, so the call shapes do not drift weekly. We arrange the consenting account during onboarding.

2 · User-consented aggregator access (Akoya, Finicity, MX, Plaid, Yodlee)

Banno publishes a list of supported data aggregators on its data-aggregators page: Akoya, Finicity, Intuit, MX, Plaid, Stripe, Visa Open Banking and Yodlee. Connection through one of those is the cleanest legal path when the integrator already has a relationship with that aggregator. Coverage is narrower than route 1 — typically balances, transactions and identity — but the consent flow is well-trodden. We pick the aggregator that matches your existing footprint rather than introducing a new vendor.

3 · Forward-looking FDX endpoints under §1033

If and when the Personal Financial Data Rights rule lands and a Banno-hosted bank exposes its FDX-style endpoints to consumer-authorized third parties, the same client re-points at that endpoint with the consumer's authorization token. We design routes 1 and 2 with this swap in mind, so a 1033 stabilisation does not force a rewrite.

Recommendation for this app: start on route 1 with a consenting Spencer member, ship the runnable client, and keep route 2 ready as the production migration path for customers who already buy Finicity, MX or Plaid quota.

What lands in your repo at the end

The build closes with a small, opinionated bundle written for this specific app:

• An OpenAPI 3.1 specification for the issuer-side accounts and transactions surfaces, plus the PFM-side enrichment and external-accounts feeds — each path tagged so a code generator splits the two layers cleanly.
• An auth-flow report covering the Internet Banking handshake, session-cookie scope, CSRF placement, the device-passcode local factor and the re-auth path after a password rotation.
• Runnable source for the key endpoints in Python and Node.js — list accounts, page transactions (posted and pending), fetch merchant-average enrichment, list external aggregator-sourced accounts, follow alerts.
• Automated tests against a recorded fixture of one consenting member's account, with VCR-style cassettes so the same suite runs without a live login during CI.
• Interface documentation: how the GRIP build resolves on this charter specifically, what to do when the bank changes Banno releases, and what the migration to route 2 looks like.
• Compliance and data-retention guidance scoped to a single-charter community bank: GLBA Safeguards posture, consent records, minimum-necessary fields per use case, and an §1033-ready posture for the day the rule re-emerges.

A first cut of the client

An illustrative skeleton, in the shape we'd ship for route 1. Paths, header names and field keys are confirmed during the build, not asserted here.

import httpx

class FarmersTrustGripClient:
    """Reads the issuer ledger and the PFM-side aggregator feed
    that the Banno-built Grip app surfaces under one UI."""

    UA   = "Grip/Android (com.farmerstrust.grip)"
    BASE = "https://digital.ftsbbank.example/api"   # resolved at build time

    def __init__(self, session_cookie: str, csrf: str):
        self.s = httpx.Client(
            headers={"User-Agent": self.UA,
                     "Cookie":     session_cookie,
                     "X-CSRF":     csrf},
            timeout=20.0,
        )

    def accounts(self):
        # Issuer-side ledger
        r = self.s.get(f"{self.BASE}/accounts")
        r.raise_for_status()
        return r.json()  # [{"id":..,"nickname":..,"type":..,"available":..}]

    def transactions(self, account_id, frm, to, page=1):
        r = self.s.get(
            f"{self.BASE}/accounts/{account_id}/transactions",
            params={"from": frm, "to": to, "page": page,
                    "include_pending": "true"},
        )
        if r.status_code == 401:
            raise ReauthRequired("Internet Banking session expired")
        r.raise_for_status()
        return r.json()  # {"items":[{"id":..,"amount":..,"posted":..,
                          #            "merchant":..,"category":..,"state":..}]}

    def external_accounts(self):
        # PFM/aggregator-side feed (Geezeo through Finicity/MX/Plaid/Akoya)
        r = self.s.get(f"{self.BASE}/pfm/external-accounts")
        r.raise_for_status()
        return r.json()

class ReauthRequired(Exception): pass

The split matters. Account balances and transactions go through one client method; the multi-FI feed goes through another. Mixing them produces double-counts the day a member links their primary checking account inside the PFM tab.

Consent and the §1033 question

The dependable legal basis today is the member's own authorization — credential and standing Internet Banking enrollment, captured under NDA, with consent scope, expiry and revocation recorded in the build. GLBA Safeguards govern how the resulting data is held; data minimisation means we only pull the fields the downstream use case needs, not the whole transaction stream.

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is the forward-looking piece. It was finalized in October 2024, then enjoined by the Eastern District of Kentucky on October 29 — the court found that the Bureau would suffer no harm being barred from enforcing a rule it was already reconsidering. The CFPB itself issued an advance notice of proposed rulemaking on August 22, 2025 covering representative-of-consumer scope, fee assessment, data security and data privacy. None of those obligations apply to this build as present-tense law; we therefore do not stake the architecture on 1033 timing. We design routes 1 and 2 so that whichever shape 1033 lands in, the integration re-points at an aggregator-mediated FDX endpoint without a rewrite.

Things we account for on this kind of build

A handful of decisions are specific to this app and we make them at the top of the engagement, not as the punchline.

• Two ledgers, one screen. The same UI shows issuer-core balances and PFM-aggregator-sourced balances. We tag rows in our client with their origin layer so a member's primary Farmers Trust checking account never gets counted twice when they also linked it through the aggregator feed.
• Internet Banking is the session anchor. The 4-digit device passcode the Play listing describes is a local factor; the durable session lives at the Internet Banking layer. We build the re-prompt loop against that layer from day one, so a password rotation surfaces as a typed re-auth exception rather than silent row loss.
• Aggregator pick is not ours to fix. Whether external-FI balances arrive through Finicity, MX, Plaid, Akoya or Yodlee depends on which connector the bank's Banno deployment has enabled — Banno's data-aggregators page lists all of them. We confirm the active connector during onboarding and write the client against it, not against an assumed default.
• PFM-layer fields are user-mutable. Tags, notes, receipt photos and geo annotations live in the PFM store, not the issuer core. They are reachable, but they should not be treated as the system of record for the transaction itself — only as enrichment we attach back to the core id.
• Re-validation pass in maintenance. Banno ships UI updates across its bank fleet on its own cadence. Maintenance includes a recorded-fixture replay every release so a changed call shape lights up a CI failure, not a customer-facing one.

How we put this together

Sources we checked, with what we read for:

• Google Play listing for Farmers Bank Spencer, IA Mobil — package id, feature list, enrollment prerequisite.
• FDIC BankFind entry for Farmers Trust and Savings Bank, cert 12858 — charter type, founding date, single-branch footprint.
• Banno's data-aggregators page — the supported aggregator list (Akoya, Finicity, Intuit, MX, Plaid, Stripe, Visa Open Banking, Yodlee).
• Federal Register notice on §1033 reconsideration (August 22, 2025) and the Cozen O'Connor alert summarising the Eastern District of Kentucky injunction — for the current legal posture.

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

Other Iowa community-bank apps in the same shape

Mostly small or mid-size Iowa charters with white-label mobile apps. Listed for landscape; none is endorsed or disparaged.

• Northwest Bank (Spirit Lake, IA) — a 20-branch Iowa community bank; mobile app sits on a similar white-label stack with PFM-style aggregation behind it.
• Bank Iowa — 25 branches across the state; consumer-mobile app exposes accounts, transactions and bill pay.
• Hills Bank and Trust Company — eastern Iowa community bank with a mature digital channel.
• Two Rivers Bank & Trust — Burlington-headquartered community bank, 14 branches, similar mobile shape.
• First Iowa State Bank — independent Iowa charter with a mobile app covering balances, transfers, bill pay, mobile deposit and debit-card controls.
• First Community Bank of the Heartland — community bank whose mobile app surfaces the same balance, transaction and bill-pay set.
• Farmers State Bank (Eastern Iowa, myFSBonline) — independent charter with a community-bank mobile app on a comparable platform.
• Iowa State Bank — single-charter Iowa community bank with a parallel mobile and Internet Banking pairing.

Questions integrators ask about this build

Where does the multi-account aggregation feed inside this app actually come from?

The package id, com.farmerstrust.grip, identifies the app as a deployment of the Grip platform that began at Banno and now sits inside Jack Henry. Banno's own integration documentation lists Akoya, Finicity, Intuit, MX, Plaid, Stripe, Visa Open Banking and Yodlee as supported aggregators, with the PFM layer wired through Geezeo. So a customer's other-institution accounts inside this app are reaching their home issuer through one of those layers, not directly.

If a member rotates their Internet Banking password, does the integration recover on its own?

No, and we design for that. The mobile session rides the same Internet Banking credential the bank requires for enrollment, per the Play listing's getting-started note. A rotation invalidates the session; our default build raises a typed re-auth error rather than silently dropping rows, and the re-prompt loop is part of the auth-flow report we ship in week one.

Will CFPB Section 1033 eventually do the heavy lifting here?

Possibly, but it is not the basis we rely on today. The Personal Financial Data Rights rule was finalized in October 2024, then enjoined by the Eastern District of Kentucky on October 29 and pulled back into reconsideration at the CFPB, which issued an advance notice of proposed rulemaking on August 22, 2025. We treat 1033 as the forward-looking piece. The dependable basis right now is the consumer's own authorization; if and when the rule stabilizes, the same client re-points at whichever FDX-style endpoint the bank exposes through an aggregator such as Akoya.

If our team has never opened an account at Farmers Trust and Savings, can the build still start?

Yes. Onboarding usually pairs the build against a consenting member's account under an NDA, or — for a fee-bearing pilot — against your own account once it has been opened in Spencer. Either path, we handle the access logistics with you during the first week; the engagement does not stall waiting for paperwork. Tell us what you need at /contact.html.

The deliverable for this app is a runnable accounts-and-transactions client on a one-to-two week cycle: source code from $300, billed only after you have reviewed it and the tests pass, or call the same endpoints as a hosted API and pay per request with no upfront fee. Send the brief — what you want from the data and the consenting member if there is one — to /contact.html and we will open with the auth-flow report.