Member-consented data extraction from the CECU mobile portal

Conservation Employees’ Credit Union runs out of a single Jefferson City branch and reports roughly 9,200 members against about $153M in assets — a small, single-sponsor shop on the consumer side. The mobile app it publishes (package org.cecuonline.grip, per the Play Store listing) carries the typical small-CU set: balances, transactions, mobile remote deposit, internal transfers, bill pay, statement PDFs, card lifecycle, plus an “Aggregate your financial accounts” surface that pulls in other institutions through an embedded PFM aggregator.

The dependable basis for an integration here is the member’s own authorization. Not a vendor partnership, not §1033 obligations (more on that below), not screen-scraping in the bad sense. We rebuild the same authenticated calls the app makes, against the consenting member’s session, and hand the buyer source code that runs those calls on a back-end.

What’s reachable inside the member app

Three paths in — only one is the spine

Path 1. Member-consented mobile-API access

With the consenting member’s credentials the app’s mobile endpoints become the data source. We document the OAuth chain the app uses (token issuance, refresh cadence, device-binding fields), capture the request signatures, and rebuild the calls so a back-end service can fetch the same balance, transaction, statement, and transfer surfaces a member sees in the app. The consent record sits on file — who, what data, how long, how revoked. Highest fidelity for tags, notes, and receipt photos.

Path 2. Regulated open-banking aggregator

Plaid, Finicity (Mastercard), and MX maintain coverage for thousands of US credit unions, including small state-chartered shops, via direct partnerships and screen-orchestrated paths. When the buyer wants a network-graded contract in the chain we wire the integration through the aggregator they already hold, normalize to an Akoya / FDX-style schema, and hand back the same OpenAPI on top. Lower fidelity on PFM extras, higher on contract paperwork.

Path 3. Native statement and CSV export

Monthly statements export as PDF inside the app and are retrievable programmatically inside the member-consented session. CSV transaction exports, where surfaced by the PFM layer, fill a gap when only periodic snapshots are needed for archival. Cheapest path, but only a snapshot.

For a credit union the size of CECU, path 1 carries the build. It is the only one that returns full transaction-level fidelity with the PFM tags and the receipt photos attached. Path 2 sits next to it for buyers who want a recognized US data network in the contract. Path 3 backs them both for archival. We pick the combination with the buyer during scoping; the source delivered is the same shape either way.

What a call looks like in practice

Illustrative shape of the auth and balance-fetch sequence. Exact paths, field names, and headers are confirmed during the build against a consenting member session.

# Illustrative — exact endpoints, field names and headers
# are confirmed during the build against a consenting session.
import httpx

DEVICE_ID  = "<registered-device-uuid>"
MOBILE_UA  = "CECU/<build> (Android)"
APP_VER    = "<app-version>"

def login(member_id: str, passcode: str) -> dict:
    """Mobile-style auth against the CECU member portal.
    Returns a short-lived access token plus a refresh token."""
    r = httpx.post(
        "https://m.cecuonline.org/auth/token",
        json={
            "username":  member_id,
            "password":  passcode,
            "device_id": DEVICE_ID,
        },
        headers={"User-Agent": MOBILE_UA, "X-App-Version": APP_VER},
        timeout=20,
    )
    r.raise_for_status()
    return r.json()  # { access_token, refresh_token, expires_in }

def list_accounts(access_token: str):
    r = httpx.get(
        "https://m.cecuonline.org/v1/accounts",
        headers={"Authorization": f"Bearer {access_token}"},
        timeout=20,
    )
    r.raise_for_status()
    return [{
        "account_id": a["id"],
        "product":    a["productType"],    # SHARE | CHECKING | LOAN | CD
        "available":  a["availableBalance"],
        "current":    a["currentBalance"],
        "as_of":      a["asOfTimestamp"],
    } for a in r.json()["accounts"]]

# Statement PDF for a given month:
#   GET /v1/accounts/{id}/statements/{YYYY-MM}
#   Accept: application/pdf
# Transactions:
#   GET /v1/accounts/{id}/transactions?from=YYYY-MM-DD&to=YYYY-MM-DD

The refresh path is on a tight clock — the bearer rotates several times an hour and a stale token returns a hard 401 without a graceful retry hint. Every method ships behind a refresh-on-401 wrapper with bounded backoff.

Shipped artifacts

• An OpenAPI 3.1 spec covering the live endpoints we touch: auth, accounts, transactions, statements, transfers and bill pay, RDC status, card actions.
• A protocol and auth-flow report — the OAuth/refresh chain, device-binding fields, request-signing details, lockout and error behavior, and the re-authentication cadence the app sets.
• Runnable Python (httpx) and Node.js (undici) clients for each surface, plus a small CLI for ad-hoc pulls.
• A pytest regression pack that pins both the auth flow and the JSON shape per endpoint, with replayable fixtures captured during the build.
• Interface documentation in markdown, plus a single-page diagram of the member-consent flow.
• A GLBA-aware logging template: what to retain, what to scrub before logs leave the host, and the member-notification copy if a session is ever compromised.

GLBA, NCUA, and the unsettled §1033 piece

Three things govern this build today. GLBA, applied to credit unions through NCUA’s Regulation P, sets the privacy notice, opt-out, and data-handling expectations. NCUA’s safeguards guidance (Appendix A and B to Part 748) is what we hold the logging and retention design against. Missouri state oversight via the Division of Credit Unions sits on top of that, since CECU is state-chartered.

CFPB §1033 — the Personal Financial Data Rights rule — is a separate, forward-looking piece. As of this writing the rule is not in force: the CFPB was enjoined from enforcing it in late 2024, then in August 2025 the agency itself reopened it for reconsideration with an ANPR, and signaled an accelerated rewrite that will substantially revise the framework. We do not treat §1033 as the basis for this integration. The dependable basis is the member’s own authorization, which works today, sits comfortably alongside Regulation P’s posture on member-directed sharing, and will survive whatever shape the reconsidered rule takes. We revisit the design when a final rule lands.

Consent is granular. Default scope is a 90-day rolling window the member re-confirms, with revocation wired through to the back-end so a withdrawn consent stops the next scheduled pull. NDA wherever the buyer needs one.

Engineering notes specific to this build

• The embedded aggregator is its own boundary. The “Aggregate your financial accounts” surface inside CECU is a third-party PFM aggregator running behind the credit union’s app. We treat its data as a separate authorization on the buyer side: pulling the list of linked institutions out of CECU is fine under the member’s consent, but reaching the underlying Chase or Schwab or brokerage accounts still needs its own aggregator contract or a re-consent at each institution. The OpenAPI marks that boundary in writing so the buyer doesn’t inherit a downstream obligation by accident.
• Receipt and check photos are the most fragile surface. Image attachments live on the PFM layer and rotate URLs or expire signed links faster than the rest of the API. We pull and rehost them on the buyer side at ingest, not lazily on read, and we keep a content-hash index so duplicates from re-deliveries don’t fan out into the warehouse.
• The bearer token rotates fast. Mobile sessions cycle the access token several times an hour and fail closed on staleness. The client wraps every call in a refresh-on-401 with bounded backoff, and exposes the device-binding fields so the integration stays tied to a single registered device the credit union can see in its session logs.
• The build is scoped to this app, not a generic CU template. CECU is a single-branch, single-sponsor shop; the surfaces we hit reflect what this app actually exposes, not the union of every credit union OpenAPI. When CECU pushes a new app version we run the regression pack first, triage the deltas, and ship a versioned spec rather than papering over drift.
• Access setup runs alongside the build. Onboarding — a consenting test member, a documented device registration, an NDA where the buyer wants one — is arranged with the buyer during the kickoff brief. None of it gates the engagement from starting.

Peer apps we map the same way

Same shape of integration, different US credit unions:

• Delta Community Credit Union — Atlanta-based, Georgia’s largest CU; member app uses the same PFM tagging and external-account aggregation pattern.
• Redstone Federal Credit Union — Huntsville AL; regional CU with mobile RDC and bill-pay surfaces an integrator treats almost identically.
• ESL Federal Credit Union — Rochester NY; the balance-widget and alerts model lines up closely with CECU’s surface.
• Wright-Patt Credit Union — Dayton OH; member app exposes Popmoney P2P alongside the standard CU mobile set.
• Alliant Credit Union — national-footprint CU out of Illinois; deeper surface, same authorization shape on the consumer side.
• Justice Federal Credit Union — community CU close to CECU’s size; useful comparison for sponsor-affinity builds.
• Pen Air Federal Credit Union — Pensacola FL; community CU with the same PDF-statement and transaction-tag pattern.
• Wings Financial Credit Union — Minneapolis MN, aviation-affinity charter; aggregation-feature parity with CECU.
• BECU — Washington-state CU originally serving Boeing employees; large enough that more of its mobile stack is publicly described.
• PenFed Credit Union — national CU based in Virginia; useful scale comparison for buyers planning a portfolio of CU integrations.

How this was put together

We worked the brief from the credit union’s own About and Mobile App pages and the Play Store listing for org.cecuonline.grip, then cross-checked NCUA Regulation P and the CFPB’s §1033 reconsideration record so the rules section reflects what is actually current in May 2026. Specific sources opened:

• CECU — Mobile App page
• Google Play listing for org.cecuonline.grip
• NCUA — Privacy of Consumer Financial Information (Regulation P)
• CFPB — Personal Financial Data Rights Reconsideration

Mapping reviewed 2026-05-20 by the OpenBanking Studio integration desk.

Questions integrators ask about CECU

How far back do transaction and statement pulls reach for a CECU member?

Statement PDFs in the app are exposed month by month and typically go back to the start of the member’s relationship with the credit union; the same auth gives a transaction history that runs roughly the same window. We confirm the actual cap during the build by walking back to the earliest available period and record it in the interface docs.

If the member uses CECU’s in-app aggregator to link a Chase or Schwab account, can we reach those institutions through CECU?

No, and that boundary is deliberate. The linked-accounts view inside CECU is a third-party PFM aggregator embedded in the app. The list of linked institutions is fair game under the member’s CECU consent, but the underlying Chase or Schwab data still belongs to those institutions and needs its own aggregator contract or a separate member re-consent at each. The OpenAPI we ship marks that boundary so the build doesn’t inherit it by accident.

What tends to break when CECU pushes a new app version?

The PFM front-end is the surface that moves most: receipt-image URLs and auth-header micro-shape changes are the usual culprits. Core accounts and statements endpoints are steadier. We pin the regression tests against the moving surfaces so a version push surfaces as a test failure we triage, not silent drift.

Does CECU show up in Plaid or Finicity coverage today?

Small US state-chartered credit unions of CECU’s size are typically reachable through both networks via screen-orchestrated paths, even when no direct partnership exists. We confirm during scoping whether the buyer’s chosen network actually carries CECU at the granularity the build needs, and route through the aggregator contract the buyer already holds, or build the member-consented route directly when that gives better fidelity.

Cost is the simple part. Source-code delivery starts at $300: you get the runnable client, the OpenAPI spec, the regression tests, and the interface notes, with payment landing after the build is in your hands and you have signed off. If you would rather not host any of it, the pay-per-call hosted option runs the same surfaces on our infrastructure with no upfront fee — you pay only for the calls you actually make. Either way the build cycle runs one to two weeks from the kickoff brief. Tell us what you want from CECU’s data at /contact.html; the access setup, the test member, and any compliance paperwork are arranged with you in the same week, not asked of you up front.