Reaching member data behind Community Savings of Caldwell, Ohio

Community Savings of Caldwell, Ohio has run its consumer mobile and web banking on Narmi — a digital-banking platform that powers community banks and credit unions across the US. That single architectural fact reshapes how an outside integration is built. Narmi's own platform materials describe an Open Banking API speaking OAuth 2.0 and OpenID Connect, plus a public SDK and integration framework. Whether the scopes you want are provisioned for this specific bank is a project-time question, but the platform layer is the right anchor for everything else: the route, the auth chain, the failure modes, and the maintenance discipline.

The integration the studio would actually ship for this app starts from one consenting member account, runs against the Narmi-backed surface the iOS and Android apps already use, and is shaped around the data domains a real Community Savings member sees on log-in — checking, savings, mortgage, auto loan, transfers, bill pay, and mobile check deposit. The Narmi API is preferred where its scope covers what you want; an authorized session integration covers the rest.

What a member actually sees, mapped to integration surfaces

The Play Store description and the bank's digital-banking page line up cleanly on what the app exposes. Each row below is something a logged-in member can already do; the third column is where a build attaches.

Four routes worth ranking for this build

1. Member-consented access through Narmi's Open Banking API

Reachable: most balance, transaction and statement data, where the bank has provisioned the relevant scopes through Narmi. Auth chain: OAuth 2.0 with PKCE plus OpenID Connect, per Narmi's published platform description. Effort: medium — the friction lives in scope provisioning, not in client code. Durability: high; a tokenized API surface is the most stable thing in this stack. How we set it up: a consenting member acts as the access principal during the build; the studio negotiates scope with the bank as part of onboarding so you do not have to.

2. Authorized session integration against the bank's own portal

Reachable: anything a logged-in member can see — balances, transactions, loan and mortgage detail, RDC posting, transfers, bill pay, alerts, card controls. Effort: medium-low; this is the studio's day-to-day work for bank apps. Durability: medium — a Narmi front-end revision can move endpoints or selectors. The maintenance contract includes a scheduled re-check against a consenting account so a UI shift surfaces before it can quietly break the feed.

3. Aggregator route via Plaid, MX, Finicity or Yodlee

Reachable: balances and transactions, usually not statements, RDC outcome, or loan-extension fields. Effort: low; durability: high; cost: priced per call by the aggregator on top of any studio work. Narmi's own help materials note that aggregator support is determined by the aggregator, not by Narmi, so a buyer-side check against the aggregator's institution list comes first. We integrate the aggregator client and the consent UX.

4. Native export — eStatement PDFs and transaction download

Reachable: historical PDFs and the CSV/QFX export the web banking typically exposes. Effort: low; durability: medium. Useful as an audit backstop and as the first thing that works on day one. We wire scheduled retrieval, OFX/QFX and CSV parsing, and a normalized output that lines up with the other routes.

For most asks, the operational shape we build pairs route 1 where Narmi scope is granted with route 2 covering the gaps. Route 3 is a sensible bridge if you already have Plaid or MX in production. Route 4 is the audit backstop.

What ships at the end of this build

• OpenAPI 3.1 specification covering the normalized endpoints we ship: accounts, transactions, statements, transfers, payees, RDC submit/status.
• Auth-flow report — the OAuth 2.0 / PKCE chain where Narmi's open API is reachable, plus the mobile session and token chain the app itself uses (login, MFA, biometric re-auth, session refresh).
• Runnable source in Python and Node.js for the surfaces above, written against a consenting member account.
• A pytest suite hitting the real surface, plus contract tests against the normalized OpenAPI, plus a mock server for CI.
• Interface documentation: error codes, rate posture, and the bank-specific fields (loan payoff-with-per-diem, escrow split, RDC outcome codes) the generic banking schemas drop.
• Compliance pack: consent record schema, retention defaults, log-redaction rules, and a revocation hook.

A look at the client code

Illustrative shape of the Python client the studio ships; real headers, host and field names are confirmed during the build against a consenting member account.

# community_savings_client.py — illustrative shape
# Host, headers and field names are confirmed during the build
# against a consenting Community Savings member account.

from datetime import date
import httpx

BASE = "https://api.mycommunitysavings.example"   # platform host;
                                                  # confirmed during onboarding

class CommunitySavingsClient:
    def __init__(self, access_token: str):
        self._http = httpx.Client(
            base_url=BASE,
            headers={
                "Authorization": f"Bearer {access_token}",
                "Accept": "application/json",
                "X-Channel": "imobile",     # platform tag matching the Android build
            },
            timeout=15.0,
        )

    def accounts(self):
        r = self._http.get("/v1/accounts")
        r.raise_for_status()
        return [
            {
                "id": a["accountId"],
                "kind": a["type"],              # CHECKING | SAVINGS | LOAN | MORTGAGE
                "balance_current": a["balance"]["current"],
                "balance_available": a["balance"]["available"],
                "currency": a.get("currency", "USD"),
                # loan/mortgage extras kept next to the generic balance:
                "next_due": a.get("loan", {}).get("nextDueDate"),
                "payoff": a.get("loan", {}).get("payoffWithPerDiem"),
            }
            for a in r.json()["accounts"]
        ]

    def transactions(self, account_id: str, since: date):
        cursor = None
        while True:
            r = self._http.get(
                f"/v1/accounts/{account_id}/transactions",
                params={"since": since.isoformat(),
                        "cursor": cursor, "limit": 200},
            )
            r.raise_for_status()
            payload = r.json()
            yield from payload["transactions"]
            cursor = payload.get("nextCursor")
            if not cursor:
                return

Engineering judgment we apply to this specific app

• Narmi front-end revisions move things. The platform ships UI and endpoint changes on its own cadence. The studio builds the maintenance cycle so that a revision triggers an automated re-test against a consenting account before it can silently affect the feed.
• Loan and mortgage fields do not fit the generic schemas. Next-due date, payoff-with-per-diem, escrow split and the bank's fixed-rate label drop out of plain open-banking models. We extend the OpenAPI with named extras and keep the generic mapping alongside, so tools that only know the standard schema keep working.
• RDC outcome codes are not standardized. Community-bank cores name deposit states differently. The integration ships an explicit state machine — submitted, accepted, on-hold, rejected, returned-with-reason — so the integrator never has to guess.
• iOS and Android behave differently. Per the public listings the Android build is com.mycommunitysavings.imobile and the iOS app id is 1018399792; session-token lifetimes and biometric re-auth behave differently across the two, so the CI matrix exercises both.

Member consent and the US data-rights frame

The dependable basis this integration runs on today is the member's own authorization — written consent from the account holder, scoped to the domains in the brief, with a documented retention window and a revocation path. The bank is FDIC-insured per its own materials, and member-consented access carries the Reg E and Reg DD posture the member already has on the account.

The forward-looking piece this market is watching is the CFPB's Personal Financial Data Rights rule (12 CFR Part 1033). As of mid-2026 it is enjoined; compliance dates were stayed by court order and the Bureau opened an advance notice of proposed rulemaking in August 2025 to reconsider scope, fees, security and privacy — per the CFPB's own reconsideration page and the Federal Register notice. For a community bank of this size in particular, treating §1033 as an in-force obligation today would be wrong; the consent path above is what we build against, and the §1033 timeline is something the studio tracks so the design does not have to change later if the rule lands close to where the original text sat.

Where data is shared with a third party for the integrator's benefit, the studio runs an NDA, redacts member identifiers in logs by default, and timestamps each consent grant against each pull.

From the live app

The screen captures below are from the public Play Store listing for com.mycommunitysavings.imobile and are used here only to indicate which surfaces the integration attaches to. Click to enlarge.

Comparable Ohio and US community-bank apps

Buyers who integrate Community Savings usually have a small portfolio of similar institutions to cover. The names below are independent banks and credit unions whose mobile apps hold comparable member data; an integration unified across them tends to share the same auth-chain and loan-field problems described above.

• Belmont Savings Bank — Bellaire, Ohio. Checking, savings, RDC, transfers, eStatements; comparable community-bank profile.
• Killbuck Savings Bank — Ohio. Account activity, mobile deposit, transfers and bill pay; same data shape.
• Vinton County National Bank (VCNB) — southern and central Ohio. Balances, transfers, mobile deposits and bill pay across personal and small-business accounts.
• Hocking Valley Bank — southern Ohio. Account access, transfers, RDC and bill pay through its mobile app.
• Buckeye Community Bank — Lorain, Ohio. Account alerts, transfers, RDC for eligible customers; smaller still than Caldwell.
• The Community Bank — Zanesville, Ohio. Personal and business banking with the same headline mobile features.
• Community Savings Bank — Bethel, Ohio. Note the name overlap: a separate institution from Caldwell's Community Savings.
• CommunityAmerica Credit Union — Kansas City. Materially larger but with the same consumer-banking data domains a unified integration must cover.
• Community Service Credit Union — Huntsville, Texas. Member-side data shape closely matches small-bank apps.
• Community Credit Union of Maine — Lewiston/Auburn. Useful as a credit-union counterpart in the same unified feed.

Questions a Community Savings integrator asks us

Can a member export statements and transactions from the app today?

Members can download monthly eStatement PDFs from the statements area, and the web banking typically exposes a transaction history export in CSV or QFX. Both are useful backstops; neither carries RDC outcome detail, alert state, or mortgage payoff-with-per-diem, which is why a real build still needs route 1 or route 2 underneath.

Does Community Savings running on Narmi change what we can integrate?

It is the most useful single fact about the build. Narmi's own materials describe a public Open Banking API with OAuth 2.0 and OpenID Connect; whether the scopes you want are provisioned for this specific bank is something the studio confirms with you and with the bank during onboarding. Where they are, route 1 carries the bulk of the feed. Where they are not, an authorized session integration covers the same domains.

How are loan and mortgage balances handled differently from checking?

The bank's loan and mortgage records carry fields the generic open-banking schemas drop: next-due date, payoff-with-per-diem, escrow split, fixed rate. The studio ships those as named extension fields next to the generic balance object so tools that only understand the standard schema keep working and tools that need the extras can pick them up.

What is realistic for a first delivery against this app?

A first delivery against Community Savings typically covers accounts, transactions and statement PDF retrieval as a runnable client, with a consent capture flow and a small test rig against a member account you arrange with us. Loan-specific fields and the RDC submit/status loop follow once that backbone is stable.

How we arrived at this

Sources checked for this brief, May 2026: the Google Play listing for com.mycommunitysavings.imobile, the bank's own digital-banking page, Narmi's Open Platform description, and the CFPB's Personal Financial Data Rights reconsideration page. The Caldwell, Ohio location, the FDIC-member status, and the bank's founding year are taken from those materials; identifiers and dates were not assumed where they could not be confirmed there.

Mapping reviewed by the OpenBanking Studio integration desk · May 2026.

To start, tell us the app and what you want from its data — access arrangements, sandbox or consenting-member setup, and compliance paperwork are handled with you during onboarding, not asked for upfront. Source-code delivery for this app starts at $300 and is paid only after the working integration is in your hands and you are satisfied; a pay-per-call hosted endpoint is also available, billed only for the calls you make, with no upfront fee. Typical cycle is one to two weeks. Get in touch.

Last checked 2026-05-20.