Reaching member data inside CCU Mobile on Co-op Credit Union's Banno stack

Co-op Credit Union has been a Wisconsin state-chartered cooperative since 1938 (per the CU's "Our Story" page), and today serves roughly 22,300 members out of eight branches across Black River Falls, Fall Creek, Galesville, La Crosse, Melrose, Onalaska and Strum (counts as the CU describes itself). The member-facing app, CCU Mobile, runs on Jack Henry's Banno digital banking platform — confirmed by the Play Store listing's stated requirement of Banno Mobile v3.7 or newer on Android 8.0+. That single fact decides almost everything about how a third party reaches the data, because Banno already exposes a documented Consumer API with OpenID Connect / OAuth 2.0, consent through External Application registration in Banno People, and partner pipes to the major aggregators.

What the app actually holds, member by member

The Play Store description and the CCU eSuite mobile page line up on the same surface set. Mapped to the way an integrator would think about it:

Routes in, in the order we would actually try them

1 — Banno's consented aggregator pipe (the spine)

Because Co-op Credit Union runs on Banno, it inherits API integrations with Plaid, Akoya, Finicity, MX, Intuit, Yodlee and Visa Open Banking (per Banno's data-aggregators page). A member grants consent through whichever aggregator the consuming app uses; data leaves Banno's Consumer API under that grant, not through credentials handed to a third party. Coverage on this pipe is the standard aggregator schema — accounts, balances, transactions, identity at the institution-routing level. We arrange registration of the consuming External Application with Co-op Credit Union's back office in Banno People as part of onboarding; the client does not negotiate that themselves.

2 — Direct Banno Consumer API integration (where the consuming app is itself a fintech registered with the CU)

If what the client is building is a fintech surface the credit union itself wants to offer its members, the cleaner shape is to register a dedicated External Application in Banno People with a whitelisted scope set (openid, profile, banno, plus offline_access for refresh tokens) and call the Consumer API directly under OIDC. Public claims here include institution and account metadata with masked account numbers; full account numbers and full card PANs live behind restricted claims that the CU has to enable on a per-app basis. We design the scope request to ask only for what the use case actually needs.

3 — Authorized session-level integration for fields outside the aggregator schema

Receipt photos, member-authored tags and notes, the alert-rule definitions, the per-card freeze state — these are not in the standard aggregator payload. For consumers who need them we run a documented session-level integration of the Banno mobile traffic under the member's consent and map the extra fields onto the same transaction or account record, so downstream systems see one normalized row rather than two.

4 — PDF statement parsing as the history-depth fallback

The aggregator window is typically 12 to 24 months. For older history we parse the monthly statement PDFs Banno generates — a format we have parsers for already across other Banno-hosted CUs, which we tune once for Co-op Credit Union's exact statement layout.

Of these, route 1 is what we put in front first because it is durable, member-consented and lives on a pipe Banno already maintains; route 2 is the right pick when the consumer is itself a CU-sanctioned app; routes 3 and 4 are scoped additions, not the spine.

The auth flow we actually wire up

Banno's Consumer API speaks OpenID Connect on top of OAuth 2.0 (per Jack Henry's developer docs). The skeleton below is the shape of what ships in the runnable Node and Python clients — values shown are illustrative; the real client_id, redirect_uri and the scope whitelist are confirmed during the build against Co-op Credit Union's External Application configuration in Banno People.

# 1. Authorization request (consumer browser, PKCE)
GET https://digital.coopcu.com/a/consumer/api/v0/auth/authorize
  ?response_type=code
  &client_id=<external_application_id>
  &redirect_uri=https%3A%2F%2Fyour-app.example%2Fcallback
  &scope=openid%20profile%20banno%20https%3A%2F%2Fapi.banno.com%2Fconsumer%2Fauth%2Foffline_access
  &code_challenge=<S256>
  &code_challenge_method=S256
  &state=<csrf>

# 2. Token exchange
POST /a/consumer/api/v0/auth/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
code=<auth_code>
client_id=<external_application_id>
code_verifier=<pkce_verifier>
redirect_uri=https%3A%2F%2Fyour-app.example%2Fcallback

# 3. Pull accounts + balances using the access token
GET /a/consumer/api/v0/users/me/accounts
Authorization: Bearer <access_token>
# -> one entry per share / loan; masked account number by default,
#    full number only if the External Application has the restricted
#    accounts.read claim whitelisted by Co-op Credit Union.

# 4. Refresh ahead of expiry using offline_access
POST /a/consumer/api/v0/auth/token
grant_type=refresh_token
refresh_token=<rt>
client_id=<external_application_id>

The flow is the same shape every Banno CU exposes; what makes it specific to CCU Mobile is the whitelisted scope set, the External Application identifier issued by Co-op Credit Union's Banno People admin, and the per-domain host that the CU points its Banno tenant at.

What we hand over at the end

• An OpenAPI 3 spec covering the consented endpoints in scope — accounts, transactions, statements, RDC submission, card-state read — written against the actual responses observed from Co-op Credit Union's Banno tenant, not a generic Banno template.
• Runnable Python and Node clients: OIDC auth + PKCE + refresh, accounts list, transaction pagination, statement PDF retrieval, and the RDC submit shape.
• An auth-flow report: where the access token is acquired, refresh cadence, what masked-vs-restricted claims look like in practice, what happens at re-consent.
• A statement-parser module that turns the monthly Banno PDF into normalized transaction rows for history older than the aggregator window.
• Automated tests that exercise the auth loop and the four read paths against a recorded fixture, plus a smoke test that runs live against a consenting account.
• Interface documentation a non-author can pick up: scope rationale, error-handling matrix, retention / minimization defaults.

Consent posture for a small Wisconsin CU member app

Co-op Credit Union is NCUA-insured and supervised by Wisconsin's Department of Financial Institutions as a state-chartered CU. The CFPB Personal Financial Data Rights rule (12 CFR Part 1033) was finalized in late 2024, then enjoined by the Eastern District of Kentucky in October and reopened by the CFPB for reconsideration; for a credit union of this size the asset-tier mechanics in the rule as finalized were already at the edge, and with the rule itself in flux none of those mechanics should be treated as present-tense obligations on Co-op Credit Union right now. The basis a working integration leans on today is the member's own authorization — either delivered through Banno's aggregator partners under the consent model Jack Henry already documents, or captured in writing for a session-level pull, scoped narrowly and revocable. We log every consent, minimize claims to those the use case actually needs, and sign the standard NDAs with the client up front so the path the data travels is documented end to end. §1033 is where the rule may go, not what governs the integration today.

Engineering notes specific to a CCU Mobile build

• Scope minimization at the Banno People step. Banno separates public claims (institution routing, accounts with masked numbers) from restricted ones (full account numbers, full card PANs, customer identifiers). We default to the public-claim set and only request a restricted claim when the use case strictly needs it — so the External Application Co-op Credit Union's back office whitelists for the build asks for the smallest scope footprint the integration will actually use.
• Refresh ahead of the offline_access window. Banno issues refresh tokens only when the offline_access scope is on the External Application's whitelist; we wire the client to refresh ahead of expiry and to fail loud (not silent) if the CU later narrows the scope set — a quiet failure here is the most common reason a "working" Banno integration goes dark six months later.
• Mapping member-authored fields onto aggregator rows. Tags, notes and receipt photos are Banno transaction enrichments not present in the aggregator schema. When the client wants those alongside the aggregator feed we run a small reconciler that joins the session-route fields onto the aggregator transaction by posting date + amount + masked-account, with a confidence score on the match, instead of pretending the two feeds are interchangeable.
• Banno UI churn discipline. Banno pushes platform updates on its own cadence (the v3.7+ floor in the Play Store listing is one such marker). We schedule a short verification job after each Banno release window so any drift in the session-route fields is caught before it reaches the consuming app, rather than after.
• One tenant, not a multi-tenant gateway. Co-op Credit Union runs a single Banno tenant for one ~22,300-member CU; the build is scoped to that tenant and that core, not a generic many-FI proxy, which keeps the consent and audit trail clean.

Interface evidence

Screens from the Play Store listing — click to enlarge.

Other community CU member apps in roughly the same shape

These are the apps an integrator working on member-level CU data in Wisconsin and the upper Midwest will see alongside CCU Mobile. Listed neutrally; the point is the shared data shape, not a ranking.

• Royal Credit Union (Eau Claire, WI) — larger regional CU; same member-portal data shape (balances, transactions, statements, RDC, card controls) and a similar consented-aggregator integration path.
• Connexus Credit Union (Wausau, WI) — one of the nationally-known digital CUs; same domain set; aggregator coverage is the standard path for third-party access.
• Capital Credit Union (Green Bay, WI) — community CU with the same member-app surface; integration is again a consented data pull plus session for enrichment fields.
• Altra Federal Credit Union (Onalaska, WI) — federally-chartered CU operating in the same western-Wisconsin geography as Co-op Credit Union; the integration shape is the same.
• MCCU-Mobile (Members Cooperative Credit Union) — fellow cooperative CU app on a similar core stack; same domain mapping.
• Westconsin Credit Union — Wisconsin-headquartered CU; member-portal data routes line up the same way.
• Fort Community Credit Union — smaller Wisconsin community CU; the small-CU integration playbook applies directly.
• Brewery Credit Union (Milwaukee) — small community CU; same kind of member data, same consent posture.
• Consumers Credit Union — separate "CCU" brand; named here only because integrators search for the CCU acronym and end up cross-referencing it.

Questions a CCU Mobile integrator actually asks

Does CCU Mobile sit on the same Banno stack as larger Jack Henry credit unions?

Yes. CCU Mobile is a Banno deployment, so the underlying Consumer API, OAuth/OpenID Connect surface and scope model are the same ones documented in Banno's developer docs — only the institution-specific configuration, External Application registration and core (held in Banno People by Co-op Credit Union's back office) are different. The integration approach we use here is the same one we use against any other Banno-hosted CU.

What is the cleanest path for a third-party app that only needs a CCU Mobile member's balance and transaction history?

Have the member consent through one of the data aggregators Banno already supports — Plaid, Akoya, Finicity, MX, Intuit, Yodlee or Visa Open Banking — so the data leaves Banno's Consumer API under the member's grant, not through credentials shared with you. We set this up as part of the engagement; nothing about it is on you to arrange first.

Does CFPB §1033 give an integrator a right to CCU Mobile data today?

Not in the sense of an enforceable obligation on Co-op Credit Union right now. The CFPB Personal Financial Data Rights rule was finalized in late 2024, then enjoined by the Eastern District of Kentucky in October and pulled back into CFPB reconsideration, so any specific obligation a small Wisconsin CU might or might not have under it is unsettled. The basis a working integration leans on today is the member's own authorization plus Banno's consented aggregator pipe.

What about the receipt photos, tags and notes members add inside CCU Mobile — can those be reached?

Those are member-authored Banno transaction enrichments and are not in the aggregator schema; they sit behind the authenticated session. We pull them through the session-level route under the member's documented consent and map them onto the transaction record so the downstream consumer sees one normalized row, not two.

How this was put together

Worked from the Play Store listing for com.coopcu.grip on 2026-05-24, the Co-op Credit Union "Our Story" and eSuite mobile pages on coopcu.com, Banno's own data-aggregators and developer documentation, and the public record on CFPB §1033's enjoinment and reconsideration. Specifically:

• CCU Mobile on Google Play — package com.coopcu.grip
• Co-op Credit Union — CCU eSuite mobile banking page
• Banno — Data Aggregators (Plaid, Akoya, Finicity, MX, Intuit, Yodlee, Visa)
• Jack Henry Digital Toolkit — Banno Consumer API Getting Started
• CFPB — Personal Financial Data Rights Reconsideration

Reviewed 2026-05-24 by the OpenBanking Studio integration desk.

For a CU the size of Co-op Credit Union — eight branches, around 22,300 members, one Banno tenant — a build covering the consented balance, transaction, statement and RDC paths runs one to two weeks end to end. What lands at the end is the OpenAPI spec, the Python and Node clients you can run as-is, the auth-flow report covering token refresh and scope behavior, the automated tests, and the statement-PDF parser. Pricing is source-code delivery from $300, paid after delivery once you are satisfied; or a pay-per-call hosted API on our infrastructure with no upfront fee. Send the app name and what you want pulled from it at /contact.html.