Member balances, card events and alerts from Cascade Federal Credit Union

Cascade Federal Credit Union has run member accounts out of Kent, Washington since its 1952 charter, founded for employees of the Great Northern Railway's Cascade Division (per its About page and credit-union directory listings). Its app is where members watch live balances, sort transactions with their own tags and receipt photos, deposit checks, move money, flip a debit card off and on, and pull monthly statements. Most of that is event-shaped: a balance crosses a threshold, a card transaction posts, an alert fires. That real-time signal is what an integrator usually wants first, and it is where this brief leads.

The bottom line: nearly everything the member sees is reachable through their own authorization, and the freshest parts arrive as events rather than as a nightly dump. We would build the durable balance and transaction reads on a member-consented aggregation rail, and map the app's own client for the surfaces an aggregator never carries — card status, the tags and receipt images members attach, and the alert stream itself.

What the app keeps per member

Each row below is a surface the app actually exposes to a signed-in member, with where it originates and what a downstream team tends to do with it.

Three ways in

Two routes carry most of the work and a third is a backfill. Each names what it reaches and how we stand it up.

Member-consented aggregation

The member authorizes access and a consumer-permissioned aggregation rail (the Plaid / MX / Finicity family) returns balances, transactions and, where supported, statements. This is the durable spine: it survives app releases and rides a flow the member understands. We handle the data-access app registration and the OAuth-style consent handshake with the member as part of onboarding.

Authorized interface integration

For everything the aggregator does not carry — card on/off state, the member's transaction tags and receipt images, the alert configuration, and the real-time alert events — we instrument the app's own session under the member's credentials, map the token and cookie chain, and rebuild the calls as a clean client. Effort is moderate; durability tracks the app's release cadence, which we cover under maintenance.

Native export

The e-statement PDFs and any CSV the online-banking portal offers work as a backfill and an audit trail behind the two live routes.

For most teams the consented rail is the read-of-record for money movement, and the interface route fills the gaps it cannot reach. Which one leads depends on whether you care more about settled history or the live card and alert signals.

What you get

The handoff is code first. You receive:

• A runnable client in Python and Node.js wrapping the mapped surfaces — login and session handling, balance and transaction reads, statement fetch, card-status read, and the alert listener.
• An event handler that normalizes Cascade's balance-threshold and card-transaction alerts into a typed feed your services subscribe to, each event carrying a stable id and its source account.
• An automated test suite over recorded fixtures plus a small set of live smoke checks, so a future app change is caught against a known-good baseline.
• A sync design that splits the real-time alert path from the consent-scoped backfill, with cursors for delta pulls.

Behind the code sit the supporting documents: an OpenAPI description of the mapped surfaces, a protocol and auth-flow write-up covering the token and cookie chain, the interface documentation itself, and a short data-retention and minimization note. Those matter, but they are not the headline — the headline is something that runs in your repo on day one.

A look at the event and read surface

Illustrative shapes below. Exact paths and field names are confirmed against the live session during the build, not guessed here.

# Normalized alert event — Cascade's balance/transaction
# push alerts fan into one handler your services subscribe to.
POST /events/cascade-fcu
{
  "event": "card_transaction",
  "member_ref": "mbr_8f1c2a",        # opaque; never the member number or SSN
  "account": "share_draft_0041",
  "amount": -42.18,
  "currency": "USD",
  "status": "posted",
  "card_last4": "7731",
  "occurred_at": "2026-06-15T17:04:22Z"
}

# Enriched history under member consent, with the member's
# own tags, note and any attached receipt/check image.
GET /accounts/{account_id}/transactions?since=2026-05-01
-> 200 OK
{
  "items": [
    {
      "id": "txn_0a91",
      "amount": -12.40,
      "memo": "GROUNDS COFFEE KENT WA",
      "member_tags": ["coffee", "business"],
      "note": "client meeting",
      "receipt_image": "img_3c7e",    # reference to the photo the member attached
      "posted_at": "2026-05-29T15:11:08Z"
    }
  ],
  "cursor": "eyJvZmZzZXQiOjUwfQ"
}

# Auth rides the member's own login (4-digit passcode or biometric
# on supported devices); the client holds the session token and
# re-authenticates when it lapses.

Where it plugs in

• A bookkeeping tool that ingests a member's Cascade transactions with their tags and receipt images, so a sole proprietor's spend categorizes itself.
• A treasury dashboard that listens for balance-threshold alerts across a member's Cascade accounts and triggers a sweep when one trips.
• A lending workflow that pulls e-statements with member consent for income and expense verification.
• A spend-management UI that mirrors the card lock state, so a frozen card shows as frozen without a second tap.

Member consent and the US data-rights picture

Cascade is a federally chartered, NCUA-insured credit union, so the institution sits under NCUA supervision and its members' deposits are federally insured. The thing that actually authorizes a third party to reach a member's data, though, is the member — not a federal mandate. That distinction matters right now. The CFPB's Section 1033 Personal Financial Data Rights rule, which would have obliged institutions to share member data on request, is enjoined by the Eastern District of Kentucky and back with the CFPB under an advance notice of reconsideration; it is not in force. So we do not build against a §1033 obligation Cascade does not currently carry. We build against the member's explicit authorization, captured and logged, with consent scoped to the accounts and fields the use case needs, an expiry the member can revoke, and no storage of Cascade login credentials beyond establishing the connection. Where §1033 lands later, the same consent record carries forward.

What we plan around for this build

A few things about this specific app shape the design, and we handle each on our side.

• Tags, notes and receipt/check photos are member-created and held in the app's own store, not in any aggregator feed. We map that surface separately and carry the image references through the client, because dropping them would lose the part members actually curated.
• Card controls are state-changing actions, not reads. We keep turn-off, turn-on and reorder behind an explicit, logged confirmation in the integration, so an automated sync can never silently lock a member out of their own card.
• Money Management shows balances that belong to externally linked institutions alongside Cascade's own accounts. We tag each account with its true source, so downstream code does not count a linked outside balance as a Cascade balance.

Access itself is arranged with you during onboarding: the build runs against a consenting member account, or a sponsor sandbox where one is available, and the credentials and authorizations are set up together as a project step.

Pricing and how the work runs

A first working drop — login, balance and transaction reads, and a live alert listener — usually lands inside one to two weeks. From there the commercial side is simple. You can take the runnable source outright: source-code delivery starts at $300, billed only after we hand it over and you have confirmed it does what you need. Or you can skip hosting anything and call our maintained endpoints, paying per call with nothing up front. Tell us the app and what you want out of its data, and we scope the rest. Start a Cascade FCU integration

Screens we worked from

Sources and when we checked

This brief was put together on 2026-06-15 from the app's own materials and primary regulatory sources, cross-checked against the store listings. The data surfaces are read from Cascade's own online and mobile banking page and the Play listing; the rule status is read from the CFPB and a banking-press account of the October 2025 injunction. Primary sources, opened directly:

• Cascade FCU — Online & Mobile Banking
• Google Play listing — org.cascadefcu.grip
• CFPB — Personal Financial Data Rights (§1033)
• ABA Banking Journal — court halts §1033 enforcement

OpenFinance Lab — integration engineering notes, 2026-06-15.

Other credit-union apps in the same lane

Same category, useful if you are unifying member data across more than one institution. Each holds a comparable per-member record behind an authenticated session.

• BECU — large Washington credit union; its app holds member balances, transactions and card controls.
• Sound Credit Union — Tacoma-based; the app covers balances, transfers, deposits and alerts.
• Pacific Cascade Federal Credit Union — Washington credit union; app manages accounts, bill pay, transfers and deposits.
• WSECU (Washington State Employees Credit Union) — statewide; a full mobile banking app over accounts and payments.
• Salal Credit Union — Seattle-based; app holds accounts, payments and statements.
• Gesa Credit Union — eastern Washington; app covers balances, transfers and card management.
• Verity Credit Union — Seattle; app handles accounts, transfers and check deposits.
• Navy Federal Credit Union — national credit union; app holds accounts, loans, cards and transfers.

Questions integrators ask about Cascade FCU

Can we receive Cascade FCU balance and card-transaction alerts as a live event stream, or is it polling only?

The app already pushes balance-threshold and transaction alerts to the member's device, so we mirror that as a normalized event feed your services can subscribe to. Consent-scoped history pulls run alongside it to backfill and reconcile, so you get both the live signal and the settled record.

Do the receipt photos and the tags members attach to transactions come through?

Yes. Those tags, notes and receipt or check images live in the app's own store rather than in a generic aggregator feed, so we map that surface directly and carry the image references and member tags into the client we hand over.

Which data-rights rule are you relying on — is CFPB Section 1033 in force for a credit union like Cascade?

No. The Section 1033 Personal Financial Data Rights rule is currently enjoined and back with the CFPB for reconsideration, so we don't treat it as a live obligation. The dependable basis is the member's own authorization to reach their Cascade FCU data, which we capture, scope and log.

If Cascade ships an app update, does the integration break?

The consent-based aggregation route stays stable across app releases. The protocol-analysis route follows the app's own client, so when a release changes a call we re-map it under maintenance, and the shipped tests cover those calls so a change is caught by the tests rather than by your users.