What an integrator can reach inside Cornerstone Bank iMobile

Eleven branches around Worcester County, Massachusetts feed one mobile login. Cornerstone Bank — formed when the institution took on Southbridge Savings Bank in 2017, per the bank's own history — runs iMobile as the front door to checking, savings, mortgage and auto-loan records, and a buyer who wants that data in their own system is asking a narrow, answerable question: which of those records reach out cleanly, and through what authorized door. This page maps the surfaces, names the route, and says what we hand over.

The bottom line is unfussy. Everything a logged-in customer sees on their phone is server-side state we can normalize into an API, and the data we would actually target first is the read-heavy core: balances and transaction history, which are the most stable surface and the easiest to verify against a consenting account. Write actions — transfers, deposits — come in as separate, clearly bounded endpoints once the read path is proven.

Behind the login

These are the surfaces the app advertises, named the way iMobile presents them. Each row is something a consenting account can confirm during the build.

Routes to the data

Three routes genuinely apply to an app like this one. They are not mutually exclusive; a real build usually leans on the first two together.

Account-holder-consented access

The customer authorizes the work and we connect to exactly what they can already see. Reachable: the full logged-in surface above. Effort: moderate, front-loaded on the auth flow. Durability: good while the login itself is stable. We set up the consent capture and the credential handling with the client during onboarding — that is our step, not a hoop you clear first.

Authorized interface integration / protocol analysis

We observe the app's own traffic under the client's authorization to map the token or cookie chain, the request shapes, and the JSON each screen consumes. Reachable: the same endpoints the app calls. Effort: this is where most of the engineering sits. Durability: tied to the app's front end, which is why we build re-validation into maintenance. The digital-banking vendor behind iMobile is not publicly disclosed and is not asserted here; we work from the live behavior, whatever the core turns out to be.

Native export, as a fallback

Where the online-banking side offers a statement or transaction download (commonly OFX, QFX or CSV through bill pay and statements), that gives a low-effort batch path for history when a near-real-time feed is not required. We confirm whether that export exists for a given account rather than assume it.

For Cornerstone Bank iMobile the route we would actually recommend is consented access wired to a protocol-analysis map of the live endpoints: consent makes it lawful and the traffic map makes it precise. Native export rides alongside as a cheap way to backfill history. That recommendation follows the app's own shape — a read-heavy retail surface with no exotic data types to chase.

What lands in your repo

Delivery is source plus the documents that let your team own it. For this app that means:

• An OpenAPI/Swagger spec covering the endpoints we map — accounts, balances, transactions, deposit status, transfers, bill-pay payees.
• A protocol and auth-flow report: the login, token or session-cookie lifecycle, refresh behavior, and the error and lockout responses we saw.
• Runnable source for the key endpoints in Python or Node.js — authenticate, list accounts, page transactions, read deposit status.
• Automated tests against recorded fixtures so a front-end change is caught as a failing test, not a silent gap.
• Interface documentation and a short compliance and data-retention note covering consent records and minimization.

Each piece is tied to a surface above; we do not ship endpoints for data the app does not hold.

A statement pull, sketched

Illustrative only — field names and the auth shape are confirmed against a consenting account during the build, not guessed from the outside.

POST /auth/session
  { "username": "...", "secret": "...", "device_id": "..." }
  -> 200 { "access_token": "...", "expires_in": 900, "refresh_token": "..." }

GET /accounts            Authorization: Bearer <access_token>
  -> 200 [ { "id": "chk-01", "type": "checking",
             "balance_current": 4182.55,
             "balance_available": 4102.55, "currency": "USD" }, ... ]

GET /accounts/chk-01/transactions?from=2026-04-01&cursor=
  -> 200 { "items": [ { "posted": "2026-04-12", "amount": -54.20,
                        "description": "...", "status": "posted" } ],
           "next_cursor": "..." }

# token nears expiry -> refresh, do not re-login
if resp.status == 401 and token.age > 840:
    token = refresh(token.refresh_token)   # else honor lockout backoff

Consent and US data rights

For a Massachusetts retail bank the dependable legal footing is the account holder's own authorization: a consenting customer can see this data, and consented access lets us reach the same data on their behalf, with consent records kept and scope held to what the integration needs. There is no federal open-banking mandate compelling Cornerstone Bank to expose a feed today. The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is where US access rules may eventually go, but it is currently enjoined and back in agency reconsideration, so we treat it as a forward-looking possibility, not present law and not the thing the build leans on. State data-protection and the bank's own customer agreements set the rest of the boundary. We work authorized, log access, minimize what we retain, and sign an NDA where the engagement needs one.

What we plan around

Two specifics for this app that shape how we build it:

• Bill pay is read-mostly here. The app's own disclosure notes that mobile bill pay is limited to payees already set up in online banking — new payees cannot be added from the phone. So we scope the bill-pay endpoint as a read and schedule-mirror surface, not a payee-creation one, which matches what the app actually permits and avoids designing a write path the backend will refuse.
• The session is short and lock-aware. Banking sessions like this one expire quickly and respond to repeated failures with lockouts, so we design the sync around the token-refresh window and a backoff that honors the lockout rather than hammering the login — the integration stays quiet and stable instead of tripping fraud controls.
• Eligibility varies by account. The disclosure flags that some features are only available to eligible account holders, so we key feature endpoints to what a given consented account exposes rather than assuming every account has every surface.

Access to a sandbox or a consenting account is arranged with you during onboarding; the build runs against whichever you provide. None of this is a checklist you have to satisfy before we start — it is the part of the job we do.

Freshness and breakage

Balances and transactions update as the app does, so a consented sync is as fresh as the customer's own view. The main thing that breaks an integration like this is a front-end change to the auth flow or a renamed response field, which is exactly what the recorded-fixture tests and a scheduled re-validation pass are for. Native export, where present, is batch and lags posted activity slightly — fine for reconciliation, not for instant deposit alerts.

App screens

Public store screenshots, useful for reading the navigation and the surfaces named above. Select to enlarge.

Sources and review

This mapping draws on the app's own Play Store and App Store listings for the feature set and the package id, the bank's site for its footprint and the 2017 Southbridge Savings Bank merger, and primary regulatory material for the US data-rights status. Checked June 2026 against:

• Cornerstone Bank iMobile on Google Play
• Cornerstone Bank iMobile on the App Store
• CFPB — Personal Financial Data Rights Reconsideration
• Section 1033 compliance date: rule enjoined and under reconsideration

Mapped by the OpenBanking Studio integration desk, June 2026.

Other US banking apps

Same-category US bank and credit-union apps an aggregation project tends to encounter alongside this one. Listed for ecosystem context — each holds account data a unified integration would normalize the same way.

• Alliant Credit Union — balances, transaction history, transfers and mobile deposit behind a member login.
• Synchrony Bank — savings and CD balances with transfers, highly rated mobile access.
• First Merchants Bank — Midwest community-bank app covering deposits, loans and bill pay.
• Bank Five Nine — Wisconsin community bank with checking, savings and mobile deposit.
• Cornerstone Bank (NE) — a separate Nebraska institution's app with its own account surface.
• Cornerstone State Bank — Minnesota community-bank mobile app with the usual retail set.
• CornerStone Bank (VA) — Virginia community bank offering mobile balances and transfers.
• Capital One Mobile — large-issuer app with deposit and card data, common in mixed portfolios.

Questions integrators ask

Which account types does the iMobile login actually expose?

As the app describes its features, a single login surfaces checking and savings balances (current and available), mortgage and auto-loan balances, transaction history, mobile check-deposit status, internal and external transfers, and the bill-pay payee list with recurring payments. Those are the surfaces we map; the exact field set is confirmed against a consenting account during the build.

There is no US open-banking mandate in force, so what legal basis would you use?

The dependable basis today is the account holder's own authorization: the customer consents, and we connect to the same data they can already see. The CFPB Personal Financial Data Rights rule under 12 CFR Part 1033 is where federal access rules may eventually land, but it is enjoined and back in reconsideration, so we do not rely on it as current law. Consent, logging and data minimization carry the work.

The Android package still reads southbridgesavingsbank — does that change anything?

Per its Play Store listing the Android package is com.southbridgesavingsbank.mobile, a holdover from the Southbridge Savings Bank merger that produced today's Cornerstone Bank. It is a naming artifact, not a separate backend; we treat iMobile as one app and key the integration off its live auth flow and endpoints, not the package string.

If we only need balances and transactions, can the build be scoped smaller?

Yes. Balances plus transaction history is the lightest surface to map and the most stable, so a read-only build that returns normalized account and transaction objects is a common first cut. Deposit status, transfers and bill-pay payees are added as separate, clearly bounded endpoints when you need them.

One pricing note, plainly: the source build starts at $300 and you pay after delivery, once it runs and you are satisfied; if you would rather not host anything, call our hosted endpoints and pay per call with no upfront fee. Typical turnaround is one to two weeks. Tell us the app and what you want out of its data at /contact.html and we set up access with you from there.