Integrating Everglades Federal CU, a CU*BASE-cored credit union

Everglades Federal Credit Union runs its mobile and online banking on the CU*BASE core operated through CU*SOUTH, a contract it signed in August 2023 according to CU*SOUTH's own press release. That single fact shapes the whole integration: the member data sits in a well-understood CUSO core, surfaced through the mobile app and the NetBranch online-banking session, with e-statements parked in a CU*Spy document vault. It is a small institution — roughly $55 million in assets and about 5,200 members, per public credit-union directories — so the work is less about scale and more about reaching one member's accounts cleanly and keeping them in sync.

The route we would actually take is consent-based interface integration: a member authorizes access, we map the authenticated session the way the app does, and we hand back code that pulls accounts, transactions and statements on a schedule. The lead concern is the feed itself — how far back the first load reaches, and how new postings arrive afterward.

What member data the app exposes

The Play Store and App Store listings describe a fairly standard credit-union feature set: check balances, review activity, move money, pay bills and deposit checks from the phone. Mapped to the underlying CU*BASE structures, those features back the following surfaces.

Three ways into the data, and the one we'd pick

Three routes genuinely fit this credit union. They differ in reach, in how much engineering they take, and in how well they hold up over time.

1 — Member-consented interface integration

A consenting member's session is mapped the way the mobile app and NetBranch present it, and the integration reads exactly what that member can see: every share and loan balance, full transaction history, transfers, bill-pay items and deposit status. Reach is the widest of the three. Effort is moderate, mostly in the login and multi-factor handling. Durability tracks the app's own release cadence, so a screen change is a parser update, not a rebuild. Access is arranged with you during onboarding, against a consenting member account.

2 — Aggregator-backed connection

US data aggregators — MX in particular, which has long-standing credit-union connectivity — can return normalized balances and transactions where they cover an institution this size. Effort is low to moderate, durability is high where coverage exists, but the field set is narrower than the live session and statement documents are out of scope. This is a good fit when balances and transactions are all a project needs.

3 — Statement and document retrieval

The CU*Spy vault holds monthly statement PDFs and member documents. Pulling and parsing them gives clean, period-anchored history that is ideal for backfill and for verification use cases, though the granularity is coarser than the live ledger and it lags the current day.

For most asks we would build on route 1 as the backbone, use the statement vault from route 3 to fill the deep history, and reach for an aggregator only when a project's needs stop at balances and transactions. That combination gives both reach and a clean long backfill.

What a transaction pull looks like in practice

The shape below is the backfill path: authenticate the member session, list the CU*BASE accounts, then page each account's history into a normalized ledger. Paths and field names are illustrative here — the exact ones are confirmed against the authenticated session during the build, not guessed.

# Illustrative. Exact paths/fields are pinned against the live
# member session during the build, then frozen as test fixtures.

session = MemberSession.login(username, password, mfa=otp_callback)

# CU*BASE surfaces share/loan "accounts" first; page history per account.
accounts = session.get("/online/accounts").json()["accounts"]

def backfill(acct_id, since):
    cursor, rows = None, []
    while True:
        page = session.get(
            "/online/accounts/%s/transactions" % acct_id,
            params={"from": since, "cursor": cursor},
        ).json()
        rows += page["items"]
        cursor = page.get("next_cursor")
        if not cursor:
            return rows

ledger = {a["id"]: backfill(a["id"], "2023-01-01") for a in accounts}

# normalize -> posted_at, amount_cents, description,
#              running_balance, share_id, source="cubase"

Statement PDFs from the vault are parsed on a parallel path and reconciled against this ledger, so the deep history and the live feed agree on amounts and dates rather than drifting apart.

What lands in your repo

The headline deliverable is code you can run, not a document set:

• A runnable Python client that handles member login and the multi-factor step, lists accounts, pages transactions, and downloads statement PDFs — with a Node.js client as an alternative target.
• The batch backfill plus a scheduled delta-sync job, writing new postings to each share and loan account keyed on the transaction id.
• A normalized schema across accounts, transactions, transfers and statements, with the field mapping from CU*BASE labels documented.
• An automated test suite running against fixtures recorded from a consenting member account, covering the login flow and each parsed surface.

Alongside the code: an OpenAPI/Swagger description of the surfaces we wired, a protocol and auth-flow write-up covering the session, cookie and MFA chain as it actually behaves, the interface documentation, and a short note on consent logging and data retention. The code leads; the specs and reports back it up.

Member consent, NCUA oversight, and where the federal rule sits

The dependable basis for this work is the member's own authorization to reach their accounts — not a regulatory mandate. Everglades Federal is an NCUA-insured federal credit union, so the institution sits under NCUA supervision, and we treat the member's consent, with records of what was authorized and the ability to revoke it, as the thing the integration stands on. We keep access authorized and logged, pull only the fields a project needs, and work under an NDA where the engagement calls for one.

The CFPB Personal Financial Data Rights rule, the federal piece people associate with US open banking, is not something this integration leans on. It is currently enjoined and has gone back into the agency's own reconsideration, so we do not treat it as live law for a small credit union like this one. If a settled version eventually lands, the consented integration we build carries forward into it; nothing here is staked on a rule that is still being rewritten.

Things we plan around on a CU*BASE core

Two specifics about this credit union shape how we build, and we account for both inside the project rather than handing them to you as conditions.

Share-suffix and loan structure

CU*BASE organizes a membership into share suffixes and loan accounts under one member number. We map that structure explicitly so a member with several shares and a loan comes back as distinct accounts with their own balances and histories, instead of being flattened into a single number that quietly hides sub-account detail.

Statement vault reconciliation

Because deep history comes from PDF statements in the CU*Spy vault while recent activity comes from the live session, the two have to be made to agree. We extract the statement lines, match them against the ledger on date and amount, and resolve overlaps so a backfilled period and an ongoing sync do not double-count or disagree.

Login and multi-factor handling

The app and NetBranch gate access behind member login and a verification step. We build that flow with a callback for the one-time code, and the scheduled sync re-authenticates whenever the session lapses instead of waiting on a fresh challenge.

Where teams actually use this

• A budgeting or personal-finance app folding a member's Everglades FCU shares and loan into one dashboard next to their other institutions.
• A lender pulling twelve to twenty-four months of statements and transactions for income and asset verification, sourced from the vault PDFs and the live ledger together.
• A small-business member syncing their credit-union transactions into bookkeeping so reconciliation stops being a manual export.
• An internal analytics build, backfilling member activity into a warehouse for reporting without re-keying anything by hand.

Screens we mapped

The Play Store screenshots we worked from, for reference on the surfaces named above.

What we checked

This mapping draws on the app's store listings for the feature set, CU*SOUTH's press release for the core platform, the NCUA credit-union register for the charter and location, and the CFPB's own reconsideration page for the current status of the federal data-rights rule. Engineering notes compiled by OpenFinance Lab on 2026-06-08, after reading the sources below.

• Everglades Federal CU on Google Play — described feature set and package id.
• CU*SOUTH press release — CU*BASE core, remote deposit, SMS banking, CU*Spy vault.
• CFPB Personal Financial Data Rights reconsideration — current status of the §1033 rule.

Other credit-union apps in the same integration class

The same consent-based approach applies across community and member-owned institutions. A few US credit-union apps in the same bracket, each holding member balances, transaction history and statements behind an authenticated app:

• Alliant Credit Union — deposit, transfer and card-control data behind a widely used member app.
• Eastman Credit Union — balances, transactions and quick-balance features for a Tennessee-based membership.
• Delta Community Credit Union — Georgia's largest CU, with deep account and activity history.
• Pentagon Federal Credit Union (PenFed) — nationwide membership with broad deposit and loan data.
• Lake Michigan Credit Union — regional CU with full mobile banking and deposit accounts.
• NASA Federal Credit Union — member accounts, transfers and statement history.
• Service Credit Union — balances and transactions across a multi-state membership.
• Andrews Federal Credit Union — deposit and loan accounts behind an authenticated mobile app.

Holding several of these to one normalized schema is the usual reason a team comes to us: one consent flow and one field mapping across many small institutions.

Questions integrators ask

Can you pull more than balances and recent transactions from a CU*BASE-cored credit union like this one?

Yes. The member session also reaches transfer history, bill-pay payees and paid items, remote-deposit status, and the e-statement PDFs held in the CU*Spy vault. We map each surface to a field-level schema so a downstream system gets posted dates, signed amounts, descriptions and running balances rather than a single headline figure.

How far back can the first Everglades FCU backfill go, and how do you keep it current afterwards?

Live transaction history reaches as far as the online-banking session returns, and older periods are filled from the statement PDFs in the vault. After the one-time backfill, a scheduled delta job pulls new postings against each share and loan account, keyed on the transaction id.

Does this integration depend on the CFPB open-banking rule being in force?

No. The basis we work from is the member's own authorization to reach their accounts. The CFPB Personal Financial Data Rights rule is enjoined and back inside the agency's own rulemaking, so we do not treat it as live law; if and when it settles, the same consented integration carries forward without a rebuild.

What happens when Everglades FCU updates the app or its NetBranch screens?

Field names and paths can shift between releases. We ship the parser with fixtures recorded from a consenting member account, so a changed response shows up as a failed assertion in the test suite, and the fix is a small parser update rather than a re-architecture.

Working with us

A first working client for Everglades FCU's member data lands inside one to two weeks. Source-code delivery starts at $300: you get the runnable client, the normalized schema, the tests and the docs, and you pay once it is in your hands and you are satisfied with it. If you would rather not host anything, the same integration is available as a pay-per-call hosted API with nothing upfront — you are billed only for the calls you make. Tell us the app and what you need from its data at /contact.html and we will scope it; access and any compliance paperwork are arranged with you as part of the build.

Start an Everglades FCU integration