Account access through the Libertyville Savings Mobile portal

Libertyville Savings Bank runs roughly six branches across southeast Iowa out of its Fairfield head office, per the institution's own site, and its mobile front end pulls together accounts the depositor holds inside and outside the bank into one balance view. The app's package id, com.libertyvillesavingsbank.grip, lines up with a small family of community-bank apps on the same grip-style PFM stack — the same package stem turns up at GCB and CBNA — which is the practical tell for how the data actually behaves once you're inside the session.

That matters for an integration because the bank-core balance feed and the PFM-side enrichments (the tags, the receipt photos, the bill detection, the geo tuple) sit on different layers. Read one and you have a posted-transaction list. Read both and you have what the depositor actually sees.

What the app holds

The surfaces below are what the Play Store listing and the app's own copy describe, mapped to where they actually originate in the stack.

Reaching the data

Authorized integration of the Internet Banking session

This is the spine. The mobile app authenticates a depositor against the same Internet Banking credentials the desktop site uses, then exchanges them for a session the app carries through its calls. We sit on the consenting depositor's session, mirror its transport, and stream the same surfaces the app renders. Effort is light to medium for one institution; durability is good because the session shape changes only when the bank refreshes its online-banking front end.

PFM-layer endpoints on the same session

The aggregation, the tag and note enrichments, the bill detection — these come from a separate PFM endpoint set the app calls with the same bearer. We treat them as a second route inside the same build. It is what makes Libertyville's mobile data more than a plain balance feed.

User-consented credential access through an aggregator

If the buyer already runs an aggregator relationship and just needs Libertyville's accounts inside that pipeline, we can also wire the consent on the aggregator side and write the bank-specific normalization that closes the gaps between what the aggregator returns and what the app actually shows.

For this bank, the first two routes used together are what we would recommend — they cover the full surface the depositor sees, with one auth path to maintain.

A pull from the depositor's session

Illustrative — exact paths and field names are confirmed during the build, against the depositor's own session, on a sandbox or a consenting account.

# Authenticate against the same flow the mobile app uses
POST /auth/portal/login
{
  "username": "depositor",
  "password": "***",
  "device_id": "ob-studio-client/1.0"
}
-> { "session": "...", "refresh": "...", "expires_in": 600 }

# Pull enriched transactions for one internal account
GET /api/v1/pfm/transactions?account_id={core_acct_id}
   &from=2026-04-01&to=2026-04-30&cursor=
Authorization: Bearer {session}

-> {
  "transactions": [
    {
      "id": "T-7C1A9",
      "account_id": "0123-456789",
      "posted_at": "2026-04-12T13:42:00-05:00",
      "amount_cents": -4287,
      "merchant_raw": "ACE HRDWR FAIRFIELD IA",
      "merchant_normalized": "Ace Hardware",
      "category": "Home Improvement",
      "tags": ["home"],
      "note": "deck stain",
      "is_bill": false,
      "geo": { "lat": 41.0064, "lng": -91.9627 }
    }
  ],
  "next_cursor": "eyJjIjoxMjN9"
}

# Refresh when the bearer drops on a 401
POST /auth/portal/refresh
{ "refresh": "..." }

That is the shape: a short-lived bearer in front of a longer refresh handle, a cursor on the transaction read, and the PFM enrichments riding the same response object as the core fields. The client we ship handles the 401, the cursor and the join into a normalized schema.

What lands in your repo

• A runnable Python or Node client for the surfaces above — login, refresh, account list, balance read, paginated transaction pull, bill list, tag write-back where the app permits it.
• An OpenAPI document covering the endpoints we touched, with the auth flow described as a security scheme and the PFM layer split from the core layer so consumers can choose what to subscribe to.
• A protocol and auth-flow report: how the login is exchanged for a session, where the refresh handle lives, what the session cookie or bearer looks like, and how the PFM tokens are scoped.
• A normalized schema and a mapping note from Libertyville's field names into it, so the integration drops cleanly next to other community-bank feeds you already process.
• Automated tests that hit a consenting depositor's account or a sandbox, including a 401-and-refresh test and a cursor-resume test.
• An interface documentation pack — the calls, the fields, the rate behaviour we observed, the failure modes — written for an engineer who will operate it after handoff.
• A short compliance and data-retention note: what data is being moved, who consented to what, what's logged, what's purged.

Authorization, and where §1033 fits

Authorization runs through the depositor. Libertyville is a FDIC-insured state-charter community bank supervised by the FDIC, and the integration's footing is the depositor's own permission to read and pull their account data — granted during onboarding, scoped to the surfaces the buyer needs, and recorded with the consent metadata our build produces. We use the same access the depositor already has, on their behalf, with their record of authorization in the file.

A federal data-rights overlay (12 CFR Part 1033) is in reconsideration and currently unenforceable; the agency has reopened it through an Advanced Notice of Proposed Rulemaking and we treat any specific obligations as unsettled. For a six-branch Iowa community bank, that overlay is not the dependable basis we engineer against, and we do not represent it as one. Depositor consent is. If the rule eventually returns in a form that reaches a community bank of Libertyville's size, the client we hand you keeps working on that same consent footing, and the normalized schema we ship is straightforward to redirect at whatever standardized endpoint the bank ends up exposing.

Things we plan around

• Two layers, one session. The bank-core read and the PFM-layer read look like one app to the user but are two endpoint families on the same bearer. We map them separately and join on the transaction id so a sync pulling balances doesn't silently drop tags, photos or bill detections.
• External-account refresh isn't ours to drive. The aggregated outside-bank rows refresh on the upstream aggregator's cadence, not on Libertyville's. We make that visible in the normalized schema — a source and a source_refreshed_at field — so a downstream consumer knows whether a balance is fresh from the core or a few hours behind from an aggregator pass.
• Six-branch numbering. A community bank with a shared core typically scopes account identifiers by branch and customer number; for a household with accounts at two branches, that turns up as two distinct customer records. We confirm the scheme during onboarding and resolve households correctly so a multi-account depositor isn't split into two integrations.
• Front-end churn on the portal. Community-bank mobile front ends get refreshed every couple of release cycles. Our build ships with a schema-shape contract test that fails loudly when an upstream field renames or moves layers, so the upkeep is a tightening of the same client rather than a rewrite.

Freshness and quiet periods

Internal-account reads are live against the portal session — a balance pull reflects the state the depositor would see if they opened the app at that instant. Posted transactions roll in as the core settles them, which for a community bank running standard ACH and card rails means same-day posting on most flows and an end-of-day catch-up for the rest. Bank holiday windows do show up as quiet periods. We surface the last-successful-pull timestamp on each entity so a consumer can tell a real gap from a holiday.

How an engagement runs

A build for Libertyville's portal lands inside a week or two — a runnable client for the surfaces above, an OpenAPI document, a protocol report covering session, refresh and the PFM layer, a normalized-schema mapping, and tests that run against a consenting depositor's account. Source-code delivery starts at $300 and is paid only after we hand it over and you've signed off on what we shipped. If you'd rather not host the integration yourself, point your code at our hosted endpoints and pay per call, with nothing up front. The client tells us the app name and what they want from its data; we handle access onboarding, sandbox arrangement and the compliance paperwork as part of the build. Start a conversation at /contact.html.

Portal evidence

Screens we used while mapping the surfaces — tap to enlarge.

Where this came from

Mapped against the Play Store listing for com.libertyvillesavingsbank.grip, the institution's own website (lsbia.bank), the CFPB's reconsideration page for the Personal Financial Data Rights rule, and the Federal Register notice of reconsideration. References below open in a new tab.

• Google Play — Libertyville Savings Mobile listing
• Libertyville Savings Bank — institutional site
• CFPB — Personal Financial Data Rights Reconsideration
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 2025)

Notes by the OpenBanking Studio integration desk, May 2026.

Community-bank apps in the same shape

Other US community-bank apps that hold a similar shape of data and that buyers commonly pull in alongside Libertyville's feed. Listed as ecosystem context, not a ranking.

• Hills Bank Mobile — another Iowa community bank, Q2-platform front end, balances and transactions on a depositor session.
• Iowa Trust and Savings Bank Mobile — small Iowa community-bank app, same general shape of internal-account access plus aggregation.
• Two Rivers Bank Mobile — Des Moines and eastern Iowa community bank that uses a Geezeo-style PFM layer for tags and spending categories.
• Bankers Trust Mobile (Iowa) — larger Iowa institution; mobile deposit and account history alongside the standard balance view.
• Community Bank Iowa Mobile — smaller Iowa community-bank app with the same internal-account read surface.
• CBNA Mobile Banking — uses the same grip package stem as Libertyville's app, so the integration shape transfers with minor field-name changes.
• GCB Mobile (Georgia Community Bank) — also on the grip-style stack; useful as a reference when normalizing across the family.
• First Interstate Bank Mobile — regional bank with a depositor-session model and an aggregation-style PFM overlay.

Questions integrators tend to ask

Do the PFM enrichments — tags, notes, photos, geo — come through with the transaction feed, or do they live somewhere else?

They live on a separate layer from the core ledger. The bank's core supplies the posted amount, date and counterparty string; the PFM layer that the mobile app sits on holds the merchant normalization, the tag list, the user-added note, the receipt photo reference and the geo tuple. A clean integration reads both and joins them on the transaction id, which is what we hand over.

If a depositor has linked external accounts inside the app, can we read those too, or only the bank's own accounts?

Both, within the scope of what the depositor has linked and authorized. Libertyville's app aggregates outside accounts into the same balance view, so the integration sees them once consent covers them. External-account data is sourced through whatever aggregator the bank's PFM uses, so refresh cadence on those records is set by that upstream feed, not by Libertyville.

What happens when the Internet Banking session times out mid-sync?

We wire the token-refresh path into the client up front. The session that the mobile app uses has a short lived bearer plus a longer refresh handle behind it; on a 401 the client re-authenticates against the same flow the app uses, resumes from the last cursor and writes a structured event so a monitor can spot a real auth failure versus a routine rotation.

Does §1033, if it comes back in some form, change what we're buying here?

Not the deliverable. The integration's footing is the depositor's authorization, which works regardless of where the federal rule lands. If §1033 returns with phased obligations that ultimately cover a bank of Libertyville's size, the same client can be pointed at any standardized endpoint that appears, and the data shape we normalize to is already aligned with the categories the original rule called out.