Pulling member data from Cascade FCU on the member's own authorization

Cascade FCU has stewarded a closed pool of members from its Kent, Washington home since 1952 — originally for the Cascade Division of the Great Northern Railway, per its About page. The institution is small. The shape of the data its app holds is not. Balances, share-draft (checking) transactions, monthly statements, IRA positions, loan schedules, debit-card controls, Zelle history, mobile check deposits, and the credit union's in-app account aggregation feature all live inside the same member portal — and any third party that wants a consolidated view, a daily reconciliation feed, or a member-facing budgeting layer needs a way to reach those records as data, not as screens.

That is the engagement we run. A member authorizes us, we build the consented protocol client against the Grip app's authenticated endpoints, and we hand back the runnable source, an OpenAPI shape, and the auth-flow report. A small CU is in some ways easier than a big bank: fewer product lines, fewer plan branches, a single mobile build.

Member data the Grip app actually carries

The rows below are mapped to surfaces visible in the app's published description and the credit union's online-banking docs. Granularity is what an integrator would care about — per-record fields, not screen sections.

Routes we'd take into the Grip app

1. Consented protocol integration over the member-authenticated surfaces

The route we recommend for Cascade FCU. The member onboards with us, we operate inside their session, and the Grip app's request/response shapes — login, balance read, statement list, transfer schedule, Zelle history — are mapped into a small library of typed endpoints. Reachable: every domain in the table above. Effort: about one to two weeks for the first build, including the protocol report. Durability: solid in the steady state, with the maintenance contract carrying a re-check step against Grip releases so the auth path does not silently break. Setup we run: credential intake under NDA, a sponsor member account where the customer has supplied one, scope-limited logging.

2. User-consented credential access through an aggregator hop

For customers who already pipe other US institutions through an FDX-compatible aggregator, Cascade FCU can be reached the same way if the aggregator covers the credential set. Reachable: balances, transactions, statements — fewer of the action-bearing surfaces (transfers, card controls). Effort: shorter, but recurring fees and aggregator coverage gaps tend to surface within a few months. Durability: dependent on the aggregator's own coverage stability for small Pacific-Northwest credit unions. We will integrate this if it fits the cost picture.

3. Native export (PDF statements, CSV transaction history)

The online-banking surface lets a member download statements and a CSV of activity. Workable as a fallback for one-shot data pulls, an accounting import, or member offboarding. Not a sync. Effort: trivial. Durability: stable. Reachable: statements and basic transaction lines only.

For a customer building anything live — a budgeting overlay, a treasury feed for a small business that banks here, a member-side reporting tool — the consented protocol route does the daily work, and the native export covers the first historical backfill. The aggregator hop is worth taking only when an aggregator contract is already in place for other reasons.

A worked example: pulling a member's statement list and balances

Illustrative shape — confirmed against the live app during the build, not asserted as the production wire format. The protocol report we deliver carries the exact headers, body fields, and error codes.

from cascade_grip import GripClient

client = GripClient(member_credentials=creds, mfa_handler=passcode_or_biometric)

# auth: 4-digit passcode or device-bound biometric, step-up where prompted
session = client.login()

# list share-draft and share account balances
accounts = client.accounts.list()
for a in accounts:
    print(a.account_id, a.kind, a.current_balance, a.available_balance)

# statement list — documented two-year window inside the portal
statements = client.statements.list(account_id="...", since="2024-05")
for s in statements:
    pdf_bytes = client.statements.fetch_pdf(s.id)
    archive.put(f"cfcu/{s.period}.pdf", pdf_bytes)

# transaction page with member-added tags and notes
txns = client.transactions.list(account_id="...", limit=200)
for t in txns:
    yield {
        "posted_at": t.posted_at,
        "amount":    t.amount_cents,
        "memo":      t.memo,
        "tag":       t.member_tag,        # member-added
        "note":      t.member_note,       # member-added
        "receipt":   t.receipt_image_ref, # if captured
    }

The error envelope and token-refresh path are the ones to read closely in the protocol report — they govern how the daily sync survives a quiet auth-version change on the credit union's side.

What lands in your stack

• A Python client (Node.js variant on request) covering login, accounts, transactions, statements, transfers, Zelle history, and the in-app aggregated accounts.
• An OpenAPI / Swagger spec for the normalized endpoints, written so downstream services can mock and code-gen against it.
• A protocol & auth-flow report — the headers, tokens, refresh chain, MFA branches, and the device-binding behaviour observed.
• A small test suite: live-auth canary, golden-file checks on a sample statement and transaction page, contract tests against the OpenAPI shape.
• Interface documentation an internal team can read on day one, plus a short retention/minimization note tied to the member's consent scope.

What we handle during the build

Things particular to this credit union that the build accounts for, so they don't surface six weeks in as surprises:

• Aggregated external accounts kept separate from native positions. The Grip app pulls in linked external banks inside its own UI; we keep those rows in a distinct namespace so a downstream dashboard does not double-count when the member also banks at, say, BECU.
• Two-year statement window is a real boundary. The portal documents a two-year electronic-statement retention. Anything older has to come from the member's local archive or an alternate route. The deliverable documents that line so no quarterly report silently truncates.
• Auth carries a 4-digit passcode and biometric path. We wire the credential vault and the step-up handler so token refresh stays inside the consented window; biometric unlock is treated as a device-bound branch, not a separate credential.
• Card-control endpoints are stateful. "Turn off if misplaced" is an action surface, not a read — we expose it through the client only when the customer's use-case includes it, and audit logging on those calls is on by default.
• Maintenance for Grip releases. We wire a small daily canary on login + one read endpoint; when it trips, the maintenance window covers an interface-recheck pass so the customer's sync does not go silent.

Member consent, NCUA charter, and where §1033 sits today

Cascade FCU is federally chartered and supervised by the NCUA, with member deposits insured by the NCUSIF — that is the institutional frame around any work we do here. The dependable legal basis for the data we pull on a member's behalf is the member's own written consent: scoped to specific domains (balances, transactions, statements, etc.), time-bounded, revocable, and logged on our side as a consent record the customer can audit.

The CFPB's Personal Financial Data Rights rule under Section 1033 is the federal piece a US integrator usually asks about next. As of this writing it is not a settled obligation we ride: the rule was enjoined in the Eastern District of Kentucky and the Bureau formally reopened it for reconsideration, publishing an ANPR on August 22, 2025 with a comment window that closed October 21, 2025 and no replacement rule issued since. We track the rewrite — the questions on representatives, fee assessment, data security and privacy that the Bureau put out for comment are the ones that will shape any future build — but we do not treat asset-size phase-ins or machine-readable-access mandates as in-force law. The build runs on the member's consent today; if and when §1033 is finalized in a different shape, the same client gets re-fitted to the new envelope.

Three integration scenarios this build supports

• A multi-bank PFM that wants Cascade FCU as a first-class data source. Daily balance + transaction pull, member-tag and note carry-through, statement archive on demand.
• A small business in the Puget Sound area that banks at Cascade FCU and needs a treasury view. Balances and intra-day activity into the business's accounting system, with the in-app aggregated external accounts kept distinct.
• A lender doing pre-qualification on a Cascade FCU member. A consented, time-boxed pull of statements and a transaction window — used once, then the consent expires.

Sources for this brief

Pages opened during the assessment. The data domains and retention notes are from the credit union's own documentation; the regulatory status is from CFPB and Federal Register primary sources; the FDX context is from the standards body's own pages.

• Cascade FCU — Online & Mobile Banking (statements, transfers, RDC, Zelle, aggregation)
• CFPB — Personal Financial Data Rights program page
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 22, 2025)
• Financial Data Exchange (FDX) — the standard the normalized shapes are written against

Pacific-Northwest credit-union apps that share the integration shape

Other apps a downstream system tends to want next to Cascade FCU. Plain references — neither rankings nor endorsements; named here because they widen the same multi-institution view a customer is usually building.

• BECU — Washington's largest credit union; member portal carries the same balance / transaction / statement domains at much higher volume.
• Sound Credit Union — Tacoma-area, ~170k members; very close shape to Cascade FCU's app, just larger.
• WSECU — public-employee oriented credit union for Washington state; comparable consented-route shape.
• Gesa Credit Union — Richland, WA; ~292k members; richer business banking surface than Cascade FCU but the consumer domains overlap.
• Numerica Credit Union — eastern Washington / north Idaho; similar Grip-style mobile app vendor patterns.
• Pacific Cascade Federal Credit Union — separate institution, sometimes confused by name; its own member-app integration would be a sibling brief.
• Cascade Community Credit Union — Oregon-based, again a name twin; member-portal shape is similar but the charter and regulator pages are distinct.

Questions an integrator asks about Cascade FCU

Does this depend on Cascade FCU joining a public open-banking program?

No. The route we use is the member's own authorization over the Grip app's authenticated surfaces, normalized into FDX-style shapes after the fact. A future federal data-rights regime, if and when the CFPB finishes its Section 1033 reconsideration, would change the legal scaffolding around that route, but not the day-one feasibility.

Will the integration keep working after Cascade FCU pushes a Grip app update?

Most updates leave the request shapes alone; the cases that do break tend to be auth-step changes or new device-attestation. We ship a small canary that pings login plus one read endpoint daily, and the maintenance contract carries an interface-recheck step for when the canary trips.

A credit union with about 10,900 members is tiny. Is the integration shape still worth the effort?

For an aggregator or a member-facing tool the size of the institution is largely irrelevant — the shapes of balance, transaction, statement and Zelle records normalize the same way they would for BECU or WSECU. The smaller surface area actually shortens the build: fewer product variants, fewer plan branches.

Can the build cover the in-app account aggregation feature, where members link external banks?

The brought-in external accounts are reachable as a separate row set inside the Grip portal, and we keep them distinct from the member's native CFCU positions in the normalized output so downstream systems don't double-count balances or transactions.

A first build for Cascade FCU — member credentials onboarded with the customer, a Python client around login plus the read endpoints in the table above, the OpenAPI shape, the protocol report, and a canary on the auth path — fits inside the studio's one-to-two-week cycle. Pricing is from $300 for source-code delivery, paid after the build is delivered and you are satisfied; or you skip the upfront and call a hosted endpoint we run, paying only for the calls. Start a build by sending the app name and the data domains you want first; access intake and the consent scope are arranged with you as part of onboarding.