Wakota Federal Credit Union — building member-data ingestion that holds up

Roughly eighteen months of eStatement history, A2A transfers between Wakota accounts and outside banks, debit-card lock toggle, mobile check deposit and a Pay Anyone P2P channel — per Wakota FCU's own online-services page, that is the surface an authenticated member touches in this app. An integration of Wakota Federal Credit Union reaches the same surface, on the same authenticated session, scoped to a consenting member who has given a third party informed permission to read and post on their behalf.

This is a small, single-state credit union. The mobile front end is the same flow members use through a browser — the back-end is whichever digital-banking and core combination Wakota runs (not publicly disclosed and not asserted here), reached through one authenticated session per member. That shape decides the integration plan: batch ingestion against the member portal, with a separate eStatement archiver that catches every new PDF as it is published.

Where the data lives, named the way the app names it

Wakota's online-services page names eleven member-facing features. The integration only needs to address the seven that carry structured data; the rest (text-banking shortcuts, paying a loan by external card, links to a third-party credit-score widget) either touch outside systems or are presentational. The table below maps what we actually pull.

Reaching it without leaning on assumptions

Three routes apply here. We list them with the route we would actually pick first.

1. Authorized interface integration via protocol analysis of the member session (recommended)

One consenting member, one app build running through an instrumented proxy, one careful pass to enumerate the calls the mobile and web clients make. We then re-implement those calls as a clean Python and Node.js client, with the auth flow (login, biometrics fallback, session cookie, CSRF token, refresh) written down as a separate report. Durability is good — the surface is the credit union's own portal, which Wakota controls and which changes on a credit-union release cadence, not a fintech sprint cadence.

2. FDX-aligned data exchange through an aggregator

If Wakota's digital-banking partner is one of the cores that already participates in an FDX-aligned exchange (Plaid Core Exchange, MX Data Access, Akoya), the integration can ride that channel instead. This requires Wakota having signed on with the relevant aggregator, which is something we confirm during onboarding rather than assume. Where it is available, this is the lower-effort route — though it usually offers a tighter data shape than the full member portal.

3. Member-consented credential access

The classic screen-scrape pattern against the same portal. We treat this as a fallback when (1) is blocked and (2) is not in place. It works; it is more brittle because it leans on rendered HTML rather than the underlying call shapes.

For Wakota specifically we'd lead with route 1. The credit union is small enough that an FDX-aligned aggregator path may not yet be available, and protocol analysis of the member session gives the integration full access to the surfaces in the table above — not just the FDX-mandated subset.

A working call against the member session

Sketch only; exact host, parameter names, and pagination cursor format are confirmed during the build, not assumed here. The shape is what matters — a single authenticated session, a per-account cursor for transaction backfill, a separate listing endpoint for the eStatement archiver.

# Wakota FCU — member-side data pull, executed under a member-authorized session
# Auth: session cookie + CSRF token captured from the member's mobile-portal login.
# A second factor (text OTP through the credit union's own flow) is negotiated
# with the member at onboarding; biometric sign-on is mobile-device-only and not
# reusable headlessly.

import httpx

class WakotaMemberClient:
    BASE = "https://<wakota-member-portal>"   # resolved during the build

    def __init__(self, http: httpx.Client, member_id: str, csrf: str):
        self.http = http
        self.member_id = member_id
        self.csrf = csrf

    def list_estatements(self, from_month: str, to_month: str):
        # 18-month online window is the credit union's retention, not ours.
        # The archiver job calls this nightly and persists each new PDF, so the
        # local archive outlives Wakota's display window without re-fetching.
        r = self.http.get(
            f"{self.BASE}/member/{self.member_id}/estatements",
            params={"from": from_month, "to": to_month},
            headers={"X-CSRF-Token": self.csrf},
        )
        r.raise_for_status()
        return r.json()["statements"]   # [{period, ledger_balance, pdf_url}, …]

    def backfill_transactions(self, account_id: str, cursor: str | None = None):
        # Batch backfill: walk posted activity per account. The cursor is a
        # checkpoint we persist; on retry we resume from it instead of replaying
        # from zero, which keeps a re-run safe to repeat.
        params = {"account_id": account_id}
        if cursor:
            params["cursor"] = cursor
        r = self.http.get(
            f"{self.BASE}/member/{self.member_id}/transactions",
            params=params,
            headers={"X-CSRF-Token": self.csrf},
        )
        r.raise_for_status()
        body = r.json()
        return body["transactions"], body.get("next_cursor")

    def set_card_lock(self, card_id: str, locked: bool):
        # Card controls are a write surface that the integration deliberately
        # allow-lists — the same session can do this, but the deployed client
        # only exposes the explicit lock verb to its callers.
        r = self.http.post(
            f"{self.BASE}/member/{self.member_id}/cards/{card_id}/lock",
            json={"locked": locked},
            headers={"X-CSRF-Token": self.csrf},
        )
        r.raise_for_status()
        return r.json()

What the engagement actually produces

The order below is the order the work usually ships in. Spec and report exist; they are not the headline.

• Runnable client packages — Python and Node.js, with the call surface above, packaged so your team can pip install / npm install on day one. Go binding on request.
• An eStatement archiver job — cron-driven, idempotent re-run on the same period, writes PDFs to a storage target you choose (S3, GCS, or filesystem) with a sidecar JSON of the parsed header.
• A transaction-backfill job + delta cursor store — first-run bulk pull, then twice-daily deltas keyed off the per-account cursor.
• An optional webhook fan-out shim — if your stack expects events, the shim turns the delta poll into push events; if you'd rather poll us, we expose the cursor on the client.
• An automated test suite — recorded fixtures of the member-session call shapes, plus a smoke-test target that runs against a consenting test member. A field rename on Wakota's side breaks a test rather than a downstream report.
• OpenAPI specification for the surface we found, so your platform team can route, validate and document the integration alongside everything else they own.
• An auth-flow and protocol report — written down separately: login, second factor, session cookie, CSRF, refresh window, error envelopes, observed rate behavior.
• A compliance and data-retention note — what the integration logs, how consent is recorded, who can revoke and how, where the eStatement archive sits, and the disposal path on consent withdrawal.

Build notes specific to a small-CU front end

Things we account for on this kind of app, written from our side so they don't read as a wall the client has to climb.

• Single back-end, single session. A small credit union runs one digital-banking platform under the brand. Reads and the safe subset of writes (card lock, transfer initiation) live behind the same authenticated session — we design the integration so a single consent token covers both, and the write surface stays explicitly allow-listed by the client we ship rather than left open by default.
• Eighteen-month eStatement window is theirs, not ours. We treat the credit union's online retention as a feed, not a database. The archiver pulls each new monthly PDF as it lands and persists it on your side, so the historical archive grows beyond the credit union's display window without us re-fetching old months.
• Biometric sign-on is device-bound. Face ID, Touch ID and the in-app biometric option don't compose with a headless integration. We negotiate a workable second factor with the consenting member at onboarding — typically the text-OTP path the credit union itself supports — and the second-factor handler stays in the integration so the member can replace the device without rebuilding the link.
• Shared-branch and CO-OP activity is already in the feed. Those networks settle into Wakota's posted-transaction record with Wakota as the posting institution. We do not chase CO-OP's network directly; the integration takes Wakota's posted view as authoritative for the member.
• Access is arranged with you. A consenting member account to build against, a written authorization in the member's name, an NDA where the work touches anything sensitive — we set those up during onboarding, with you and the consenting member, as part of the engagement rather than as gates the reader has to clear before we'll talk.

The regulatory side, kept short

Wakota is a federally-chartered, NCUA-insured credit union supervised by the National Credit Union Administration. The member-data work sits under three pieces of law in practice: state and federal consumer protection (Gramm-Leach-Bliley Safeguards, Regulation E for electronic transfers, the NCUA's own member-data privacy regime), the credit union's own member agreement and online-banking terms, and — looking forward — the CFPB's Personal Financial Data Rights rule.

The CFPB's §1033 rule was finalized in October 2024 and would, as finalized, phase data-access obligations in by institution size. That rule is not in force. A federal court in the Eastern District of Kentucky enjoined enforcement, and the CFPB itself opened reconsideration through an Advance Notice of Proposed Rulemaking in August 2025. Whatever shape the rule eventually settles into, Wakota would likely fall on the small-credit-union side of any threshold (the smallest depository institutions were the latest in the phase-in as finalized, since stayed). Either way, the integration does not depend on §1033 — the dependable basis is the consenting member's own authorization, recorded and revocable.

Our operating posture: authorized work only, documented consent per member, access scoped to what the consent says, no shared credentials in transit or at rest, integration logs that the member can request, and a disposal path the integration enforces when consent is withdrawn.

What was checked, and where to read it

Surfaces and feature names were verified against the credit union's own pages on 2026-05-31; the regulatory status of §1033 was checked against CFPB and Federal Register sources from the past twelve months. Direct deep links:

• Wakota FCU — Online Services (feature list, eStatement window, eAlert categories)
• Wakota FCU — About (charter year, field of membership, NCUA coverage)
• CFPB — Required Rulemaking on Personal Financial Data Rights
• Federal Register — Personal Financial Data Rights Reconsideration (ANPRM, Aug 2025)

Engineering notes · OpenFinance Lab · 2026-05-31

Other small-CU and community-bank apps in the same shape

If you're integrating Wakota you are usually integrating peers alongside it. The names below are listed as ecosystem context — neutral on which the member chooses, useful for keyword reach and for the second integration your team picks up after this one. They sit in the same broad category: NCUA-insured community credit unions, member-portal back-ends, similar feature inventory.

• Affinity Plus Federal Credit Union — Minnesota-wide member CU; holds the same account-balance, transaction, eStatement and card-control surfaces, on a larger back-end.
• Mid Minnesota Federal Credit Union (MMFCU) — community CU centered on central Minnesota; comparable mobile feature inventory including mobile deposit and external A2A.
• Wings Financial Credit Union — large Twin Cities CU; deeper digital surface but the same data shape (accounts, transactions, statements, transfers, cards).
• Ideal Credit Union — Twin Cities; mobile-first member portal with similar deposit and transfer flows.
• Magnifi Financial — Minnesota community CU; comparable member surface and Member Choice / shared-branch participation.
• Hiway Federal Credit Union — St. Paul-based; similar field-of-membership-driven portal and account inventory.
• TruStone Financial Credit Union — Twin Cities and beyond; the same eStatement-archive and posted-transaction model.
• SPIRE Credit Union — Minnesota state-chartered; same surface mix on a different core, useful as a comparison build.
• St. Paul Federal Credit Union — neighboring small CU; near-identical shape to Wakota for integration purposes.

Interface evidence (Play Store screenshots)

Member-facing surfaces shown in the credit union's published store listing. Click for a larger view.

Questions an integrator asks before signing

Wakota keeps about eighteen months of eStatements online — how does the integration cover older periods?

We persist each newly published PDF as it lands, so the local archive grows past the credit union's own retention window. For history older than that at project start, we work with the consenting member to request paper statements through the South St. Paul branch and OCR them into the same store during the initial backfill. After that, the integration becomes the durable archive — the eighteen-month window on Wakota's side stops being a ceiling.

Does the integration include the CO-OP shared-branch and surcharge-free ATM activity, or only Wakota's native transactions?

Both, but indirectly. Shared-branch deposits and CO-OP ATM withdrawals settle into the same member account on Wakota's side, so the transaction feed already includes them with Wakota as the posting institution. The integration does not need to talk to CO-OP directly; it reads what Wakota has posted, which is the authoritative view from the member's perspective.

Is Wakota a covered provider under the CFPB §1033 rule when it eventually lands?

As finalized in October 2024 and since enjoined and reopened for reconsideration, §1033 phased obligations by institution size and would have exempted the smallest depository institutions for some time. Wakota would likely sit on the small-CU side of any threshold the reconsidered rule eventually settles on, but the rule is not in force and the thresholds themselves are part of the reconsideration. Either way, the integration's dependable basis is the member's own authorization — what they consent to share with you — not §1033.

Why batch ingestion rather than streaming for this app?

Wakota's member portal is a request-response surface, not an event bus. We pull on a cron — typically twice daily for balances and transactions, end-of-day for newly published eStatements — and keep a per-account cursor so a re-run picks up cleanly from the last successful point. Card-control state changes are infrequent enough that we poll them on the same schedule rather than holding a long-lived push subscription against an interactive session.

Bringing it home

For Wakota, the typical first drop is the member-portal client and the eStatement archiver — a working Python or Node.js package, an OpenAPI spec for the surface we found, and the auth-flow report behind it. One to two weeks. Source-code delivery starts at $300, payable only after you have looked at the drop and confirmed it works on your side. If you would rather not host anything, the same surface is available as a pay-per-call hosted API — no upfront fee, you pay only for the calls you make. Send the app name and what you want out of the data and we will come back with a scoped plan, a price, and a delivery date.