Reaching Savers Bank account data through member consent

Per its Play Store listing, the app shows about ninety days of posted activity grouped by month, the cleared check images behind those entries, and a balance you can glance at before you ever sign in. That is the data a member of Savers Bank carries around — a roughly 116-year-old mutual headquartered in Southbridge, with branches across Auburn, Uxbridge, Grafton, Charlton and Sturbridge, according to the bank's own materials and Yelp branch listings. The package id is com.saversbank.imobile per the same listing. Behind the icon sits a Fiserv Mobiliti deployment with CardValet card controls, which tells us a lot about how the data is shaped before we write a line of integration code.

The bottom line for an integrator: nearly everything of value here lives behind an authenticated session, and a meaningful slice of it — cleared-check imagery, deposit history, CardValet state — is the kind of data a standardized aggregator feed quietly drops. So the route worth building first is member-consented integration against the Mobiliti session itself, with a plain statement-export path kept alongside it for the cases where reconciliation only needs transaction rows.

What the app actually stores per member

Each row below is a surface the app exposes, mapped to where it originates and what a third party tends to do with it once it is normalized.

Authorized routes into the data

Three routes genuinely apply to a Mobiliti-based bank app like this one. Each is built under the member's authorization; the access setup is something we arrange with you as part of the engagement, not a checklist you clear first.

Member-consented protocol integration

We map the app's authenticated traffic against the Mobiliti session — the login and token-refresh chain, the account and transaction calls, the image-retrieval call for cleared checks — and turn it into a clean internal API. Reach is the widest of the three: it includes the surfaces aggregators tend to skip. Effort is medium-to-high, and durability is moderate because a vendor front-end change can shift field shapes, which is exactly what the maintenance pass exists for.

Member-consented aggregation rails

Where Savers Bank is reachable through an aggregator (the Plaid / Finicity / MX pattern of OAuth tokens and consumer-authorized connections), we can stand up account and transaction sync quickly against a standardized schema. Lower effort, high durability, but the feed is limited to what those rails model — typically balances and transaction rows, not check images or card state.

Statement export under member login

The online-banking session offers downloadable statements and transaction files (OFX/QFX/CSV). Low effort, dependable, and the natural way to backfill history past the in-app ninety-day window. On its own it is reconciliation-grade rather than real-time.

For Savers Bank the route we would actually build first is the protocol integration: the data clients ask for most — cleared-check images, deposit history, CardValet state — only exists in full on the session, and an export-only or aggregator-only build would hand back a thinner picture than the member sees in the app. We keep the OFX/QFX export wired in next to it so older periods and plain ledger work do not have to round-trip the live session.

What lands in your repo

Deliverables are tied to the surfaces above, not a generic checklist:

• An OpenAPI/Swagger specification covering accounts, transactions, check-image retrieval, transfers, bill-pay and deposit endpoints as we model them.
• A protocol and auth-flow report: the Mobiliti login, token issuance and refresh chain, and how the cleared-check image call is authorized within a session.
• Runnable source for the key endpoints in Python and Node.js — authentication, paged transaction pulls, image fetch, transfer submission.
• Automated tests against recorded fixtures, including the ~90-day boundary and the export-backfill path.
• Interface documentation and compliance notes: consent records, logging, data-retention and minimization guidance for US member data.

A statement pull, sketched

Illustrative pseudocode for the protocol route — field names are placeholders confirmed during the build, not published constants.

POST /mobiliti/auth/token            # session bootstrap, member-consented
  body: { device_id, member_credential, mfa_assertion }
  -> { access_token, refresh_token, expires_in }

GET  /mobiliti/accounts              # one row per deposit/loan account
  auth: Bearer access_token
  -> [ { account_id, type, current_balance, available_balance } ]

GET  /mobiliti/accounts/{id}/transactions?window=90d
  -> [ { txn_id, posted_date, amount, description,
         check_image_ref? } ]            # ref present only on cleared checks

GET  /mobiliti/images/{check_image_ref} # binary, per cleared item
  -> image/tiff | image/png

# token nearing expiry -> POST /mobiliti/auth/refresh { refresh_token }
# 401 mid-pull        -> re-bootstrap once, then surface a consent-expired error

The image reference only appears on cleared-check rows, so the client walks transactions first and fetches imagery lazily. Older-than-90-day requests fall through to the export path rather than retrying the session call.

Consent, and where US data-rights rules sit

The work rests on one thing: the member authorizing access to their own Savers Bank data. That authorization is scoped to named data domains, time-boxed, and revocable, and we keep consent records and an access log against it. Data is minimized to what the integration needs — if a workflow only reconciles transactions, it does not also hoard check images.

On the federal side, the CFPB Personal Financial Data Rights rule (12 CFR Part 1033) is the piece everyone watches, and it is unsettled: a court has enjoined enforcement and the Bureau reopened it for reconsideration, issuing an advance notice of proposed rulemaking in August 2025. We treat §1033 as where US open banking may go, not as current governing law, and do not bind a Savers Bank integration's legal basis to obligations that may be revised or replaced. For a state-chartered Massachusetts bank, the member's consent plus standard privacy and security practice is the basis we build and document against today.

Engineering realities we plan around

Two things about this specific app shape the build, and we handle both on our side:

• Vendor-platform drift. Because the app runs on Fiserv Mobiliti rather than an in-house stack, field shapes and call paths can change on the vendor's release cadence, independent of the bank. We design the parser defensively and run a re-validation pass as part of maintenance so a platform update surfaces as a flagged diff, not a silent gap in the feed.
• The 90-day in-app horizon. The app keeps roughly three months of history; anything older has to come from statement exports. We build the sync so the live session and the OFX/QFX backfill harness write into one normalized store, deduplicating where the two overlap, so a consumer of the data sees a continuous ledger rather than a 90-day cliff.
• Image assets versus rows. Cleared-check images are large binaries fetched per item; we throttle and cache those separately from the lightweight transaction sync so an image backlog never stalls balance updates.

Access to a real account for testing is arranged with you during onboarding — a consenting member login or a sponsor sandbox — and runs under NDA.

Keeping the feed honest

Balances and transactions are polled on a schedule sized to the workflow — intraday for cash-position use, daily for reconciliation. Each pull is logged with its consent reference, and a freshness timestamp travels with every record so downstream systems can tell live data from backfilled history. When a consent nears expiry the integration warns ahead of the wall, rather than failing the next morning's sync.

Cost and how we run it

Source code lands in your repository, and you pay from $300 only after it is delivered and you have checked it against your own account — no money up front. If you would rather not host anything, the alternative is our pay-per-call hosted API: you call our endpoints for Savers Bank data and pay only for the calls you make, with no setup fee. Either way the typical cycle is one to two weeks from a confirmed scope. Tell us the app and what you need from its data, and we handle access and compliance with you from there — start at /contact.html.

Screens we mapped

Public Play Store screenshots we referenced while modelling the surfaces above.

Other Central Massachusetts banking apps

Same-category US community-bank and credit-union apps an integrator often touches in the same project. Plain context, not ranking — a unified integration usually has to span several of these.

• Rockland Trust — Massachusetts community bank app with balances, transfers and mobile deposit behind a member login.
• Cambridge Savings Bank — deposit and lending data with online bill pay and deposit capture.
• Avidia Bank — Central MA bank app covering accounts, card controls and P2P payments.
• Country Bank — accounts, transfers and mobile deposit for a neighbouring MA institution.
• Cornerstone Bank — Worcester-area bank app with balances, bill pay and alerts.
• UniBank — Whitinsville-based bank app with transaction history and transfers.
• bankHometown — community bank app spanning accounts and deposit features.
• Webster Five — Worcester-area mutual with balances, transfers and card management.
• Digital Federal Credit Union (DCU) — large MA credit union app with broad account and payment surfaces.

Questions integrators ask about this one

Can the cleared-check images be pulled, or just transaction rows?

Yes — the app exposes cleared check images alongside posted transactions, so session-level integration can retrieve the image asset per cleared item, not only the amount and date. Aggregator feeds usually stop at the transaction row, which is one reason image capture pushes us toward protocol integration here.

Does the roughly 90-day transaction window limit what we can sync?

In-app history shows about the past 90 days grouped by month, per the bank's listing. For older periods we pull statement exports in OFX or QFX from the online-banking session, so a backfill harness can stitch earlier months onto the live feed.

Which US rule governs this, given Section 1033 is in flux?

The dependable basis is the member's own authorization to reach their data. The CFPB Personal Financial Data Rights rule (12 CFR Part 1033) is where federal obligations may eventually settle, but it is currently enjoined and back in reconsideration, so we do not build against it as settled law — we build against consent, with logging and data minimization.

How do you handle access to a real Savers Bank account during the build?

Access is arranged with you during onboarding — typically a consenting member account or a sponsor sandbox — and the work runs against that under NDA. The app name and what you want from the data are enough for us to start.

How this was put together

Drawn from the app's Play Store listing, Savers Bank's own online-banking pages, Fiserv's Mobiliti platform documentation, and the CFPB's current rulemaking record, all read on 6 June 2026. Sources:

• Savers Bank Mobile Banking — Google Play listing
• Savers Bank — Online & Mobile Banking FAQ
• Fiserv — Mobiliti licensed delivery brochure (PDF)
• CFPB — Personal Financial Data Rights reconsideration

Mapping reviewed June 2026 by the OpenBanking Studio integration desk.