Building authorized access to myAUCU member accounts

Auburn University Credit Union runs its mobile channel — branded myAUCU — for members tied to Auburn, Opelika, Montgomery, and the surrounding Central Alabama counties. The app rides on the same online-branch backend members hit at online.myaucu.org, so an integration that pulls balances, transactions, transfers, bill-pay and Remote Deposit Anywhere out of a member's view does so against that one backend rather than two parallel systems. AUCU was federally chartered in 1960, per its own site, and remains NCUA-insured. None of that is exotic. What makes the integration specific is the way myAUCU layers session state across the mobile binary and the online branch, and how a small credit union's data-rights posture sits relative to a US rule that is, right now, in flux.

The recommendation we'd write up at the end of scoping is route 1 below as the basis of the build, with a thin export-driven fallback only for statement-style data where it actually helps. The rest follows from that.

Routes that fit this app's setup

Three paths actually apply to myAUCU, and they're not equivalent in durability or coverage. We pick the combination per project, but for most asks against AUCU we end up running the first one and treating the others as supports.

1. Authorized protocol analysis of myAUCU + online.myaucu.org

The mobile app and the web portal share a session backplane. We document the handshake — the login form, the token/cookie chain it issues, how the biometric or 4-digit passcode unlock on device maps to that server session, and how the app rotates session state across cold launch versus warm resume. From there the studio writes a server-side client that holds an authenticated session per consenting member and reads the surfaces in scope. Effort is moderate; durability is good as long as the maintenance pass (below) is funded. This is the path with the widest coverage of what the member actually sees in the app.

2. Member-consented credential access via a stable session

For projects that don't need the full protocol layer — say, a one-shot pull of balances and 90 days of transactions for an accounting tool — the same consent capture is used, and the client runs against the online-branch endpoints directly. Effort is lower. Coverage is narrower; RDA submission and some flow-specific surfaces aren't a fit here.

3. Native export from the online branch

Where a member can already download statements or transaction CSVs through online.myaucu.org, the studio wraps that as a fallback feed. It is the most brittle path of the three and we only build it as a supporting feed alongside one of the others; it isn't a substitute for either.

What the online branch actually holds

Consent and where US data-rights law lands today

AUCU is NCUA-supervised and federally insured. The dependable basis for the integrations we deliver against myAUCU is the member's own written authorization, captured per build, scoped to the data domains the client actually needs, and revocable at any time. That is what the build runs on.

The CFPB's Personal Financial Data Rights rule — 12 CFR Part 1033 — is the forward-looking US piece, and we track it without leaning on it. The rule was finalized, then enjoined while the Bureau reconsiders, with compliance dates stayed and an Advance Notice of Proposed Rulemaking out in August 2025 reopening representative status, fees, and data-security obligations. As of this writing it is not in force. For an AUCU member integration that means we don't assert any present-tense §1033 obligation on the credit union or the access channel; if the rule later settles into a form AUCU is required to support, the build moves to it where that's cleaner, and if it doesn't, the consent-based path is unchanged. Consent records, scope, and a revocation hook are kept in the deliverable from day one.

Where the work happens against a member's own account, we operate under NDA, log only what the client agreed to receive, and minimize what's persisted — a member-side integration should not store more than the member's downstream system actually consumes.

What's in your hands at the end of one to two weeks

• OpenAPI 3 specification covering the in-scope surfaces (balances, transactions, transfers, bill pay, RDA, alerts) as one consistent contract, regardless of which of the three routes feeds each call.
• A protocol and auth-flow report: the exact handshake against online.myaucu.org, the token/cookie chain, how cold launch and background resume differ, where the biometric or 4-digit passcode unlock sits in the session lifecycle.
• Runnable client source in Python or Node.js — your call — wired to the spec, with member-session lifecycle handled.
• A test suite covering the happy path, an auth refresh after expiry, an RDA submission and its async clear, and the FI-to-FI enrolment lookup.
• Interface documentation in Markdown — what each endpoint returns, the actual field names AUCU uses, edge cases we hit, and how each maps back to a screen in the app.
• A short compliance memo on member-consent capture and a sane data-retention default.

Client in code (illustrative — field names confirmed during the build)

import httpx
from datetime import date

class MyAucuClient:
    BASE = "https://online.myaucu.org"

    def __init__(self, session: httpx.Client):
        # session is already member-authenticated through the consent flow;
        # token refresh is wired in the lifecycle layer, not at call sites.
        self.s = session

    def accounts(self):
        r = self.s.get(f"{self.BASE}/api/accounts/summary")
        r.raise_for_status()
        return [
            {
                "id": a["accountId"],
                "label": a.get("nickname") or a["productName"],
                "available": a["availableBalance"],
                "current": a["currentBalance"],
                "as_of": a["asOfTimestamp"],
            }
            for a in r.json()["accounts"]
        ]

    def transactions(self, account_id: str, since: date):
        r = self.s.get(
            f"{self.BASE}/api/accounts/{account_id}/transactions",
            params={"from": since.isoformat()},
        )
        r.raise_for_status()
        return r.json()["items"]  # includes member-added tags and notes when present

    def submit_rda(self, account_id: str, front_jpeg: bytes, back_jpeg: bytes, amount_cents: int):
        # RDA is capture-then-async-clear; this returns a ticket, not a posted deposit.
        files = {"front": front_jpeg, "back": back_jpeg}
        r = self.s.post(
            f"{self.BASE}/api/rda/deposit",
            data={"accountId": account_id, "amount": amount_cents},
            files=files,
        )
        r.raise_for_status()
        return r.json()["ticket"]  # poll deposit_status(ticket) for cleared/declined

The wrapper around submit_rda in the shipped client either polls until terminal or, in the hosted version, fans the eventual status out through a single webhook so the caller sees one consistent shape.

Quirks we plan around on AUCU specifically

These are the things that bite if they're not accounted for at scoping — and that we handle as part of the build rather than discover at runtime.

• Two paths to the same session. The myAUCU binary and the online-branch web shell share a session backplane but re-authenticate differently on cold launch versus background resume. We map both during the build so a long-running integration doesn't quietly drop the first time a member's app sleeps overnight or the device reboots.
• RDA is capture-then-async-clear, not a synchronous post. Duplicate detection on retries, status polling, and exposing the eventual cleared or declined state through one consistent webhook are wired into the client. Clients shouldn't have to keep their own polling loop or reconcile mid-flight retries by hand.
• The online branch refreshes its front-end shell. Markup, token format and session-flow changes show up after the credit union's own maintenance windows. The studio schedules a quarterly verification run against a consenting test account so a portal-side change is caught and patched before the integration starts returning errors in production.
• Member-added metadata is real data. Tags, notes and receipt photos the member attached in the app are part of what online.myaucu.org returns. We surface that metadata in the integration rather than silently dropping it, because for most use cases (categorisation, accounting, audit) it's more useful than the bare posting.

Where this lands in practice

• A small Auburn-area business that runs its operating account at AUCU wires the balances and RDA flow into its bookkeeping stack so check deposits reconcile automatically.
• A member-facing PFM app pulls 18 months of transactions plus the member's own tags into its own UI, with the member completing one consent at sign-up.
• An accountant ingests an end-of-month transaction extract from each member-client, with FI-to-FI transfer history pulled alongside so cross-institution moves don't show up as orphan postings.

What was checked, and where

Compiled from the Google Play and App Store listings for myAUCU (package org.myaucu.grip per the Play listing), Auburn University Credit Union's own site at myaucu.org and the online-branch portal at online.myaucu.org, AUCU's published Remote Deposit Anywhere and FI-to-FI Transfer pages, and tracking of the CFPB's §1033 reconsideration. The references opened during this assessment are linked below.

• myAUCU Mobile App — Google Play listing
• Auburn University Credit Union — myaucu.org
• AUCU — Remote Deposit Anywhere
• CFPB — Personal Financial Data Rights Reconsideration

OpenBanking Studio integration desk · mapping reviewed 2026-05-24.

Similar credit-union apps where this kind of integration applies

Neutral cross-reference, not a ranking — these are real US credit-union mobile apps that sit in the same shape as myAUCU and would be integrated against the same way, against each institution's own online-branch portal under member consent.

• Alabama Credit Union Mobile — balances, mobile check deposit, transfers and bill pay against ACU's online banking.
• Redstone Federal Credit Union Mobile — accounts, activity, transfers and locators for Redstone members across Alabama and Tennessee.
• Navy Federal Credit Union Mobile — the largest US credit union, broadly similar mobile data surfaces at much higher volume.
• PenFed Mobile — balances, transfers and loan-application status for PenFed members.
• Alliant Mobile — Chicago-based digital-first credit union, deposit and transfer-led mobile feature set.
• SECU (Maryland) Mobile — full digital-banking surfaces across SECU's online banking.
• PSECU Mobile — Pennsylvania State Employees Credit Union's digital-first stack.
• Connexus Credit Union Mobile — large multi-state credit union with the standard balances, transfers, bill pay set.
• Logix Federal Credit Union Mobile — Southern California credit union with comparable account and deposit surfaces.

FAQ on AUCU work specifically

Which parts of an AUCU member's account can be reached without pushing the member back into the mobile app every time?

After the initial member-consented login, the build holds a refreshable session against online.myaucu.org. Balances, transaction history, transfer endpoints, scheduled bill payments and alert settings are reachable in the background; the member is only prompted when AUCU itself forces a re-auth — for example after a long idle or a password change. That refresh logic is part of what we ship.

What happens to the integration if CFPB §1033 shifts after the current reconsideration?

The build is structured so the member's own written authorization is the basis for access. If §1033 settles into a form AUCU is later required to support, the integration moves over to that channel where it makes the build cleaner; if it does not, the consent-based path keeps working as-is. Neither outcome forces a rebuild.

Does the integration have to be done once per AUCU member, or once per project?

The reverse-engineering and client code are built once. Each member then completes a one-time consent and login through the flow we provide; that yields a per-member session the client maintains. New members onboard through the same flow without changing the codebase.

Is Remote Deposit Anywhere reachable from the integration, and what does its return shape look like?

Yes. RDA is a capture-then-async-clear flow: the build submits front and back images plus the amount, gets a deposit ticket back, then polls (or, in the hosted version, exposes a webhook) for the cleared/declined state. The shipped client wraps that and returns one consistent status object rather than leaving the caller to chase it.

$300 buys the source-code delivery — the OpenAPI spec, the runnable client, the tests and the interface notes — billed after you've signed off on what's in your hands. Or skip the upfront cost entirely and call the studio-hosted endpoints, paying per call. Build cycle is one to two weeks either way. Send the goal and the surfaces you actually need to /contact.html and we'll come back with the route and a date.