Keeping MyPGSB account data synced and reconciled

Pilot Grove Savings Bank has taken deposits in southeast Iowa since 1911, per the bank's own history page, and MyPGSB is the channel its accountholders use to watch money move day to day. For a partner that wants that movement in its own systems — a bookkeeping tool, a treasury dashboard, a lending workflow — the interesting problem is not a single export. It is keeping a copy that stays correct while balances, pending check deposits and bill payments shift underneath it. That reconciliation problem is what this page is about: what MyPGSB holds, the authorized way to reach it, and the working code we hand over.

The bottom line: this is a single-institution banking app with a rich authenticated portal at mypgsb.pilotgrovesavingsbank.com and no exotic data model. The work is to model its accounts and transactions cleanly, drive the sync off what actually changed, and reconcile against the balance the app shows. We arrange access with you and the accountholder as part of the engagement, then deliver source that runs.

What MyPGSB holds, surface by surface

Every row below comes from the app's own description of what an accountholder can do. Branch and ATM lookup is included for completeness but carries little integration value — it is public reference data.

Authorized routes to the account data

Three routes apply to a bank app of this shape. We set up whichever one fits, with you and the accountholder, during onboarding.

Accountholder-consented session

The most durable route rides the member's own authorization. Where the bank can be reached through a consented, token-based connection, the token grants only what the accountholder approved and can be revoked without changing their password — the model US aggregators moved to after their 2022 settlement, per American Banker's reporting on bank-aggregator data sharing. Reachable: balances, transactions, statements. This is the footing we recommend building the spine on, because it survives app releases and revocation is clean.

Authorized interface analysis

Under the partner's written authorization, we map the traffic MyPGSB exchanges with mypgsb.pilotgrovesavingsbank.com and reproduce exactly what the app shows the user — including surfaces a generic aggregator misses, such as mobile-deposit status and card on/off state. Effort is moderate; durability tracks the app's release cadence, which we cover with a re-validation step handed over alongside the code.

Native statement export

The app already produces saveable monthly statement PDFs. As a route on its own it is coarse and lagging, but it is the cheapest way to back-fill history and a useful cross-check against the live sync. We treat it as a fallback and a reconciliation anchor, not the primary feed.

What we build for an MyPGSB connection

The headline deliverable is code you can run, not a binder. For this app that means:

• Runnable source — a Python and Node.js client covering the account list, the transaction delta pull, statement retrieval, and the reconciliation check, with a small CLI to run a sync end to end.
• A scheduled-sync worker with cursor-based delta fetching and a reconciliation pass that flags drift between cleared transactions and the app's reported balance.
• An automated test suite covering the account, transaction and statement surfaces, doubling as the re-validation pass you re-run after a bank app update.
• An OpenAPI description of the normalized endpoints we expose over the mapped surfaces, so your team codes against a stable contract rather than the raw app.
• A protocol and auth-flow write-up — the token or session chain as it actually behaves here, with data-retention and consent-logging guidance for a US deposit institution.

The hosted option skips all of that on your side: you call our endpoints and we keep the connection healthy.

Inside a transaction-sync call

The shape below is illustrative — exact endpoints and field names are confirmed during the build and not published here. It shows the delta-and-reconcile loop we design for MyPGSB: fetch only what changed, settle pending items as they post, archive statements separately.

# Illustrative MyPGSB sync against a consented session.
client = PGSBClient(
    base="https://mypgsb.pilotgrovesavingsbank.com",
    auth=ConsentedSession(token=member_token),   # revocable, scoped to approved accounts
)

for acct in client.accounts():
    # delta pull: only transactions newer than our saved cursor
    page = client.transactions(acct.id, since=cursor.get(acct.id))
    for txn in page.items:
        store.upsert(acct.id, txn)               # keyed on txn.id
    cursor.set(acct.id, page.next_cursor)

    # reconcile cleared total against the balance the app reports
    cleared = sum(t.amount for t in store.cleared(acct.id))
    if cleared != acct.available_balance:
        # pending mobile-deposit / bill-pay items live here until they post
        review(acct.id, gap=acct.available_balance - cleared)

# statements arrive monthly as PDFs — archive, then parse for reporting
stmt = client.latest_statement(acct.id)
archive.put(acct.id, stmt.period, stmt.pdf)

# transient session errors: back off and retry; a revoked token re-prompts the member
      

Keeping the synced copy fresh

A bank ledger is only useful if the copy is trustworthy at the moment someone reads it. Two things make that hard here. Mobile check deposits sit in a pending state between capture and posting, so a naive sync that books them on sight will disagree with the available balance. Bill payments and P2P sends do the same on the outbound side. We model both as their own lifecycle states and let the reconciliation pass settle them, so the gap you see is a real gap, not a timing artifact. Cadence is a dial, not a default: a balance-alert copy can refresh every few minutes, while a month-end reconciliation ledger is happier on an end-of-day pull with the statement PDF as the cross-check.

Authorization and US data-rights footing

For Pilot Grove Savings Bank there is no live federal mandate to lean on. The CFPB's Personal Financial Data Rights rule under Section 1033 — the closest thing the US has to an open-banking framework — has been enjoined and returned to the agency for reconsideration, with no enforceable compliance date for an institution this size. We treat it as where the rules may go, not as current law. The footing we actually build on is the accountholder's own authorization: explicit, scoped to named accounts, revocable, and logged. Every connection carries a consent record; access is data-minimized to the surfaces the use case needs; and we work under an NDA where the engagement touches member data. That is how the studio operates regardless of which way the §1033 reconsideration lands.

What we plan around on this build

Two specifics shape how we scope an MyPGSB connection.

First, the pending-versus-posted split. Because mobile deposits and outbound payments move through intermediate states, we design the data model with explicit pending, cleared and returned states from the start, rather than retrofitting them after the first balance mismatch. The reconciliation check is built around that split, so a deposit that has not yet posted never silently corrupts the ledger.

Second, consolidation history. Pilot Grove acquired Wayland State Bank in July 2024, per FDIC records, which is the kind of event that leaves account-numbering and statement-format seams inside a single institution. We account for that during mapping by validating against a real consenting account rather than assuming one uniform shape, and the test suite pins the surfaces we relied on so a later core change shows up as a failing check rather than a quiet drift. Access to that account is arranged with you during onboarding; the build runs against it or a sponsor-provided environment.

Screens we mapped against

Public store screenshots used while sketching the surfaces above. Select any to enlarge.

Comparable banking apps in this category

If you are aggregating more than one institution, these sit in the same shape — single-FI mobile banking with balances, transactions, deposit capture and transfers — and a normalized schema we build for MyPGSB carries across them. Listed for context, not ranked.

• GreenState CU Mobile — Iowa's largest credit union; balances, transfers, bill pay and check deposit, with a far larger member base per its Play listing.
• Hills Bank — eastern Iowa community bank; comparable deposit and transaction surfaces across personal and business accounts.
• Community State Bank Personal — Iowa community bank app with balances, transaction history, statements, transfers and mobile deposit.
• MC Mobile Banking (Midwest Community) — credit-union app on the BankJoy platform; bill pay, deposit capture and account activity.
• Midwest Members Credit Union — small-CU mobile app covering everyday account access and transfers.
• Wright-Patt Credit Union — large Ohio-Indiana credit union with a well-rated app and the same core banking surfaces.
• Consumers Credit Union — multi-state credit union; balances, transfers, deposits and statements in one app.

What was checked, and where

Surfaces were taken from the MyPGSB store listing and the bank's own pages; institution facts from the FDIC record; the data-rights status from primary regulatory and legal coverage. Checked June 2026.

• MyPGSB on Google Play — feature list and package id.
• FDIC BankFind — Pilot Grove Savings Bank — charter, certificate, and the Wayland State Bank acquisition.
• Pilot Grove Savings Bank — Mobile Banking — the bank's own description of the app and My Money Manager.
• CFPB — Personal Financial Data Rights reconsideration — current §1033 status.

Compiled by OpenFinance Lab — engineering notes, 14 June 2026.

Questions integrators ask about MyPGSB

Which MyPGSB surfaces can you reach, and how fresh is the data?

Balances and posted transactions are the freshest surfaces, pulled on demand and on a schedule against a consented session, with statements arriving monthly as PDFs. Card status, transfer and bill-pay state, and mobile-deposit items are reachable as the app exposes them. We design the cadence to the use case: a few minutes for an alerting copy, end-of-day for a reconciliation ledger.

Is any US open-banking rule forcing Pilot Grove Savings Bank to share this data?

No rule is in force today. The CFPB's Personal Financial Data Rights rule under Section 1033 has been enjoined and sent back to the agency for reconsideration, so a small Iowa community bank like this one has no live federal data-sharing obligation. The dependable basis is the accountholder's own authorization, which is how we scope every connection.

How do you keep a synced copy reconciled when MyPGSB shows pending deposits and bill-pay items?

We pull transactions with a cursor so each run only fetches what changed, then reconcile the cleared total against the available balance the app reports. Pending mobile-deposit captures and queued bill payments are tracked as their own states and settled when they post, rather than being treated as final on first sight.

What happens to the connection when the bank ships a new app version?

Interface work tracks the app, so a release can move a field or a flow. We hand over a small re-validation suite with the source and re-run it after notable updates; where the route rides a token-based consented session, that surface is more stable than a screen-scrape and tends to survive releases untouched.

Start a MyPGSB build

A working MyPGSB connection lands in one to two weeks once access is in place. You can take it as source you keep — from $300, billed only after delivery once the sync runs to your satisfaction — or as hosted endpoints you call with no upfront fee, paying per call. Either way you give us the app name and what you need from its data; we arrange access and the compliance footing with you. Tell us what you are building at /contact.html and we will scope it.