Getting balances, transactions and PFM enrichments out of the Farmers Bank Spencer, IA app

Farmers Trust & Savings Bank in Spencer, Iowa runs this app on Jack Henry's Banno platform. The package id com.farmerstrust.grip puts it in the same .grip family as a long list of other community-bank apps — the suffix traces back to the original "Grip" mobile product that Jack Henry's ProfitStars division white-labeled (as "Andiamo") before it became the roots of Banno. That heritage matters for one practical reason: the integration shape is well understood, because hundreds of small banks ship the same platform under their own name.

The interesting surface here is the aggregated feed. This app does not only show Farmers Trust accounts — it pulls in accounts the user holds at other institutions and presents one merged view with balances, transaction history and merchant spending averages. On top of that sits a personal-finance layer: tags, free-text notes, receipt and check photos, and geo-information attached to individual transactions. Two distinct data planes, reached two different ways.

Where the data lives in the app

Each row below is something the app actually surfaces, where it originates, the grain you get, and the typical reason a partner ingests it.

Authorized ways in

Three routes apply to this app. We set up access for each as part of the work, with you — onboarding, consent registration and any sandbox are arranged during the engagement, not handed to you as homework.

Route A — consented aggregator data exchange

Banno has moved its outbound data sharing onto a direct, tokenized API network instead of credential scraping. A consumer grants one-time consent and an aggregator (Akoya over FDX, or Plaid registered in Banno People, with MX, Finicity and others available) receives a read-only, consent-scoped token. Per Akoya's own announcement, more than 400 banks and credit unions on the Banno platform reach this network. What's reachable: accounts, balances, transactions and account detail in an FDX shape. Durability is the strongest of the three — it is a maintained, standardized interface. This is the backbone for the balances-and-transactions plane.

Route B — authorized interface integration of the Banno session

The PFM plane is not in the aggregator feed. Tags, notes, receipt images, geo-points and the merchant-average analytics are written and stored inside the app, so we reach them through protocol analysis of the Banno mobile and web session, run under the accountholder's authorization. Effort is higher and the surface tracks app releases, but it is the only way to recover the enrichment layer that makes this app distinctive. We treat this as data extraction for interoperability, on consented accounts.

Route C — native export, for backfill

For history older than a fresh consent window, the e-statement vault holds per-statement PDFs. We parse those into the same normalized records as a one-off backfill. It is a fallback, not a live feed, and it pairs well with Route A for a complete timeline.

The sensible build leans on Route A for everything balances-and-transactions, layers Route B where a customer genuinely needs the tags-notes-geo enrichments, and runs Route C once to seed history. Most teams start with A alone and add B later.

Consuming the feed as a replayable stream

Because the feed is event-driven, the durable design is a queue in front of the pull. Aggregation refreshes land as messages; a consumer reads each one, pulls the FDX window, and advances a stored cursor. Replaying from any cursor re-reads the same window rather than starting the whole account over, which is what makes reconciliation and gap-filling cheap.

# Illustrative. Field names confirmed against an FDX/Akoya pull during the build,
# not transcribed from vendor docs. Consent is the accountholder's, via Banno.

# 1) Aggregator refresh events land on a durable queue.
event = queue.consume("ftsb.aggregation.refresh")   # {institution, consent_id, cursor}

# 2) Pull the FDX-shaped accounts + transactions for that consent.
GET /fdx/v6/accounts/{accountId}/transactions
    ?startTime=2026-01-01&offset={event.cursor}
Authorization: Bearer <consent-scoped token>

# 3) Each page advances a stored cursor; a replay from a cursor
#    re-reads that window instead of re-scanning the account.
for page in pages:
    for txn in page["transactions"]:
        emit({
          "account_id": txn["accountId"],
          "posted":     txn["postedTimestamp"],
          "amount":     txn["amount"],          # signed, account currency (USD)
          "merchant":   txn.get("merchantName"),
          "category":   txn.get("category"),    # PFM tag layer arrives via route B
        })
    store_cursor(event.consent_id, page["nextCursor"])
      

What we hand back is one normalized record per transaction, with the two planes merged on the transaction id:

// route A (feed) + route B (PFM enrichment), merged:
{
  "id": "ftsb:txn:8f12…",
  "account": { "id": "…", "type": "checking", "institution": "Farmers Trust & Savings" },
  "posted_at": "2026-05-30T14:02:00Z",
  "amount": -42.18,
  "merchant": { "name": "Hy-Vee", "mcc": "5411" },
  "enrichment": { "tags": ["groceries"], "note": "weekly run", "geo": {"lat": 43.14, "lng": -95.14}, "receipt": "img-ref-…" }
}
      

What ships at the end

The deliverable is code that runs, not a slide deck. In order of what teams use first:

• Runnable connector source in Python or Node.js: the queue consumer, the FDX pull with cursor handling, the Route B session client for enrichments, and the merge into normalized records.
• Webhook / event handlers for the aggregation-refresh messages, with the replay path wired in.
• An automated test suite covering pagination, cursor replay and the A-plus-B merge against recorded fixtures.
• A batch-vs-realtime sync design: live events for new activity, a one-time Route C statement backfill for history.
• An OpenAPI / Swagger spec for the normalized surface we expose to you.
• A protocol and auth-flow report covering the consent grant, token scoping and the Banno session chain Route B depends on.
• Interface documentation and data-retention guidance, written for this app's fields.

What teams build with this

• An accounting tool that imports a Farmers Trust customer's categorized transactions nightly, with receipt images attached for expense substantiation.
• A cash-flow dashboard that watches the low-funds and upcoming-bill alerts and fires a downstream nudge.
• A lending or underwriting view that reads the aggregated cross-institution balances the user already linked, with their consent.
• A bookkeeping sync that reconciles the live feed against a Route C statement backfill so no month has a gap.

Authorization and the US data-rights picture

Every route runs on the accountholder's consent and stays read-only. Consent on the aggregator network is scoped and revocable, the token carries an expiry, and we record what was authorized and when. We minimize the pull to the fields a use case needs, log access, and sign an NDA where the work touches sensitive material. For Farmers Trust & Savings, a Jack Henry institution, that consumer authorization is the dependable legal basis today. The CFPB's Section 1033 rule — which would standardize this kind of access nationally — is currently enjoined and back in agency reconsideration, so we treat it as where the rule may go, not as settled law to build against. Nothing in the design needs 1033 to be in force.

What we handle on the way

Two things specific to this app that we account for, so you don't have to:

• Two data planes, one timeline. Balances and transactions come from the FDX feed; tags, notes, geo and receipts come from the app session. We key the merge on the transaction id and design for the case where the feed posts a transaction before the user has enriched it, so late notes attach cleanly to an already-ingested record.
• Aggregated external accounts. The dashboard mixes Farmers Trust accounts with whatever the user linked elsewhere. We tag each record with its source institution and scope the sync to the consents that actually exist, so a partially-linked profile is handled correctly rather than read as missing data.
• Consent lifecycle. We build the refresh around the token's expiry window and surface revocation as a first-class event, so a withdrawn consent stops the pull instead of erroring quietly.

Cost and how a build runs

A working transaction-ingestion connector for this app lands in one to two weeks. Source-code delivery starts at $300 — you get the runnable connector, the tests and the interface docs, and you pay after delivery once it works for you. Would rather not host it? Run it as a pay-per-call API instead: you call our endpoints, pay only for the calls, no upfront fee. The integration underneath is the same. Pick whichever your team would rather own.

Tell us what you need from the Farmers Bank Spencer data →

Screens we worked from

Store screenshots of the app, for reference. Click to enlarge.

Sources and review

This brief draws on the app's Play Store listing, Banno and Akoya's published descriptions of how data sharing works on the platform, the CFPB's own reconsideration page for Section 1033, and the bank's FDIC record (cert #12858) checked in June 2026. Primary sources:

• Google Play — Farmers Bank Spencer, IA Mobil
• Banno — data aggregators on the platform
• CFPB — Personal Financial Data Rights reconsideration
• FDIC BankFind — Farmers Trust & Savings Bank (cert #12858)

OpenFinance Lab — ingestion engineering notes, reviewed 2026-06-08.

Other apps in the same orbit

Same category, useful when a partner wants one integration across many small banks or PFM tools. Named here for context only.

• MyFarmers Mobile — another .grip / Banno community-bank app with the same aggregation feed shape.
• GoFarmers Mobile — a sibling Banno build holding balances and transactions behind a banking login.
• Farmers Bank Mobile App (Weld) — same platform family, different institution.
• Farmers St Bank — FSB — Banno-powered, same consent-and-feed model.
• Monarch Money — PFM aggregator pulling balances and transactions across many institutions via Plaid, MX and Finicity.
• Copilot Money — iOS-first PFM holding categorized transactions and budgets behind an account.
• Quicken Simplifi — multi-provider aggregation with cash-flow and spending views.
• Rocket Money — links bank and card accounts for spend tracking and subscription management.
• YNAB — budgeting app importing transactions through MX and Plaid, with file import as a fallback.

Questions integrators ask us

How fresh is the transaction feed, and can you backfill older history?

Live transactions arrive whenever the consented aggregator refresh fires for the linked accounts; we land those events on a durable queue and keep a per-consent cursor, so a replay re-reads the same window for reconciliation. For history that predates the consent, we backfill from e-statement documents through the native export route.

The app aggregates accounts from other banks too. Can those external accounts be ingested?

Yes, to the extent the accountholder has linked them. Banno's aggregation surfaces external-institution balances and transactions through the same consented network (Akoya, Plaid, MX, Finicity), so they come down the same FDX-shaped feed rather than needing a separate connector per bank.

Can you also capture the tags, notes and receipt photos users attach to transactions?

Those are app-side enrichments that the aggregator feed does not carry, so we reach them through authorized interface integration of the Banno session under the accountholder's authorization, then merge them onto the matching transaction id in the normalized output.

Does this depend on CFPB Section 1033 being in force?

No. Access today rests on the accountholder's own authorization through the consented aggregator network. For Farmers Trust & Savings, a Jack Henry institution, that is the dependable basis; Section 1033 is enjoined and back in agency reconsideration, so we treat it as where the rule may go, not as current law we build against.