Member account data inside the Heartland Credit Union (WI) app

The short version

Around 34,000 to 36,000 members reach their accounts through this app, per public NCUA-linked records, and the credit union sits near $615 million in assets as of early 2025. The number that matters for an integration is none of those. It is the platform underneath: Heartland (WI) moved its digital banking onto an Alkami-hosted stack, which is what decides how balances, card state and deposits are actually reached.

For most builds the durable spine is a member-permissioned, FDX-aligned connection that returns balances and transaction history. The surfaces that only the app exposes — card freeze state, InstaCheck deposit holds, scheduled transfers — come through an authorized interface build against the Alkami session. Native statement export is the coarse fallback when a build only needs periodic history. Which of those leads depends on what you are syncing; the data domains below sort it out.

What sits behind a Heartland login

Every row here maps to a screen a member already sees in the app — balances, card activity, mobile deposit, transfers and messages — described the way Heartland presents them rather than as a generic banking checklist.

Authorized ways into the data

Three routes apply to Heartland, and a real build usually combines two of them. Each is described by what it reaches, the effort to stand it up, how well it holds over time, and what we set up on our side to run it.

Member-consented, FDX-aligned connection

The standardized path for a US credit union. A member authorizes access and the connection returns balances, transactions and identity through an aggregator (the established US players already cover much of the credit-union footprint) or directly against an FDX-conformant endpoint. Reach is balances and history; effort is low to moderate; durability is high because it tracks a published standard rather than a screen. We wire the consent hand-off, token storage and refresh, and the normalization that follows.

Authorized interface build against the Alkami session

This reaches everything the app itself shows, including the surfaces the aggregator route does not carry — card freeze toggles, InstaCheck hold status, scheduled transfers. We model the app's Alkami-hosted authentication, including its two-factor and biometric steps, and replay it against a consenting member account whose access is arranged with you during onboarding. Effort is moderate; durability tracks the app, so we version the captured surface and re-validate after notable releases.

Native statement and history export

The coarse fallback. Heartland members can pull statements and download transaction history; for a build that only needs periodic records, parsing that export is cheap and stable, though it lags real time and lacks card and deposit state. We treat it as a backstop rather than a primary feed.

The split we would actually run: lean on the consented FDX-aligned connection for the balances-and-transactions core, because it is the steadiest over years, and add the authorized interface build only for the app-only surfaces a sync genuinely needs. Export stays in reserve for history backfills.

What lands in your repository

The headline deliverable is code that runs, not a binder. For Heartland (WI) that means:

• Runnable clients in Python and Node.js for the member-session pull — balances, transaction history, card status and InstaCheck deposit state — with the auth and pagination already wired.
• A sync worker doing cursor / delta polling against the transaction feed, with the pending-vs-posted reconciliation built in so reported balances stay coherent.
• Webhook or callback handlers where a push channel is available, and a scheduled poller as the default where it is not.
• An automated test suite: recorded fixtures of the captured surface plus contract tests, so a change in a response shape is caught before it reaches your sync.
• An OpenAPI / Swagger description of the normalized endpoints we expose to you.
• A protocol and auth-flow report documenting the token, session and MFA chain as it behaves on the Alkami stack.
• Interface documentation plus data-retention and consent-logging guidance written against how the route handles member data.

A transaction pull, sketched

Illustrative shapes — confirmed during the build, not lifted from any published document. Because the app's digital banking is Alkami-hosted, the client mirrors the member's own authenticated session rather than reading some side feed.

# Renew the short-lived access token before it lapses, using a stored refresh token.
POST /session/refresh
  -> { "access_token": "...", "expires_in": 600 }

# Pull only what changed since the last cursor; ask for pending and posted together.
GET /accounts/{member_acct}/transactions?since_cursor=<opaque>&status=all
  Authorization: Bearer <access_token>
  -> {
       "next_cursor": "c_8f1a...",
       "transactions": [
         { "id": "txn_5521", "posted": true,  "amount": -42.18,
           "description": "POS PURCHASE",        "available_delta": -42.18 },
         { "id": "txn_5522", "posted": false, "amount":  300.00,
           "description": "INSTACHECK DEPOSIT HOLD", "available_delta": 0 }
       ]
     }

# A cursor can overlap on a retry, so the worker matches on transaction id
# before writing; an overlapping re-pull leaves the stored ledger unchanged.

The InstaCheck row carries a zero available-delta on purpose: a deposit on hold should not move the available balance an integration reports until it clears, and the reconciliation pass is what enforces that.

Keeping the synced ledger current

A balance is only worth syncing if it is current and it agrees with itself. The worker reconciles in two passes. Posted items move the running ledger; pending ones — card authorizations not yet settled, InstaCheck deposits still on hold — sit in a side list at zero available-delta until they clear. Freshness windows are set per account class, so a checking account with daily card use polls tighter than a share certificate that moves twice a year. Session renewal folds into that same cadence, handled on the schedule the build already runs on.

Member consent and the US data-rights picture

Heartland is a Wisconsin state-chartered, federally insured credit union — NCUA charter 66710 in public records — so the access that matters for an integration today is the member's own permission, captured and logged, not a federal mandate. The CFPB's Section 1033 data-rights rule is not in force right now: enforcement is paused and the Bureau has reopened the rulemaking, so the page treats it as the direction US access may take rather than the rule we build against. In practice that means a member-permissioned, FDX-aligned connection now, with room to move to a mandated channel if and when one settles. FDX itself is the industry's royalty-free data-sharing standard and already carries data for a large share of US consumer accounts, which is why we align to it even before any rule lands. Access is consented and minimized, consent and access records are kept, and an NDA covers the engagement where the work touches member data.

What we plan around on this build

Two details specific to Heartland (WI) shape how the work is scoped, and we handle both rather than hand them back to you.

The Alkami session and its MFA step

The app gates entry behind two-factor and biometric checks on the Alkami stack. We model that handshake so an authorized-interface pull renews its session within the same window the app uses, instead of forcing a fresh sign-in each cycle. Access for the build is arranged with you during onboarding, against a consenting member account.

InstaCheck holds and read-only card state

Mobile deposits arrive through InstaCheck with a hold before they post, so we reconcile held deposits separately and never let an uncleared check inflate the available balance a sync reports. Card freeze and activity toggles are member-controlled state; we read them for display and leave a card's status untouched unless a build explicitly asks us to act on it.

Pinning the right Heartland

Several US credit unions share the Heartland name. This build targets the Madison, Wisconsin institution — package com.heartlandwicu.heartlandwicu per its Play listing — not the similarly named Kansas app, so branding, endpoints and the member base stay pinned to the WI entity.

What the app's own screens show

The published store screenshots double as interface evidence: dashboard, card management, deposit and transfer flows. They are a useful check on the data domains above before a line of code is written.

What we checked, and when

Worked through on 14 June 2026: the app's Play Store listing for the feature set and package id; Alkami's published account of Heartland's digital banking project for the platform underneath; Heartland's own digital-banking pages for the InstaCheck and member-facing details; and the CFPB's reconsideration record for the current status of US data-rights rules. Open the primary sources directly:

• Alkami — Heartland Credit Union digital banking project
• Heartland Credit Union — Digital Banking
• CFPB — Personal Financial Data Rights Reconsideration
• Financial Data Exchange — FDX API adoption

Researched and written at OpenFinance Lab; data-surface assessment last revised 2026-06-14.

Nearby credit-union and Wisconsin banking apps

A single integration usually has to reach more than one institution. These same-category apps hold comparable member data and slot into the same normalized model — listed to map the neighborhood, not to rank it.

• Summit Credit Union — the largest Wisconsin credit union, with a full mobile stack of balances, transfers and mobile deposit.
• UW Credit Union — Madison-rooted, with account views, payments, check deposit and multi-year document access in-app.
• Landmark Credit Union — Wisconsin and Illinois, with external-account linking, transfers and credit-score tools in its digital banking app.
• Royal Credit Union — strong digital account management and transfers across western Wisconsin and Minnesota.
• Connexus Credit Union — a nationally available digital credit union with a heavily used mobile app.
• Marine Credit Union — La Crosse-based, serving members across Wisconsin, Iowa and Minnesota with standard mobile banking.
• Fox Communities Credit Union — a Fox Valley regional with everyday mobile banking and lending features.
• Dane County area credit unions — same metro as Heartland, with overlapping balance, transfer and deposit surfaces.

Questions integrators ask first

Heartland's digital banking runs on Alkami — does the integration target that platform?

Yes. Heartland (WI) moved its digital banking to an Alkami-hosted stack, per Alkami's own account of the project, so an authorized interface build mirrors the app's Alkami session rather than treating it as a separate feed. For balances and transactions we usually lean on a consented, FDX-aligned connection instead, which holds up better across app updates.

How current is the synced data, and what keeps a balance from going stale?

The sync polls on a cursor and pulls only what changed since the last marker, then reconciles pending against posted so an InstaCheck deposit still on hold does not inflate the available figure. Cadence is yours to set — minutes for an account with daily card use, hourly for a quieter one — and the reconciliation pass is what keeps a fast poll from reporting a half-settled balance.

Does any Heartland login credential ever sit on your servers?

No more than the route needs. A consented aggregator connection hands back tokens, not a password. Where an authorized interface build needs a member session, credentials are handled under the member's authorization and kept to the minimum, and we retain consent and access logs rather than long-lived secrets.

With the federal data-rights rule on hold, what is the access actually based on?

The member's own permission. The CFPB Section 1033 data-rights rule is not in force right now — enforcement is paused and the Bureau is reworking it — so we do not build against it as settled law; it is where US access may head. For a state-chartered, NCUA-insured credit union like Heartland, a member-permissioned, FDX-aligned connection is what carries the data today.

Starting the work

A first working pull of balances and transactions usually lands in one to two weeks. Source-code delivery starts at $300, billed only after the code is in your hands and you are satisfied with it; or skip the build entirely and call our hosted endpoints, paying per call with nothing upfront. Tell us the app and what you need from its data on our contact page and we will scope it back to you.