Member balances, transfers and deposits inside the CTFCU app

Carolina Trust Federal Credit Union runs the CTFCU app on Alkami's digital banking platform, a switch the credit union made in 2021 (per its own login-help page). That single fact decides most of the integration: the member-facing balances, transaction history, transfers, card controls and bill-pay records all sit behind an Alkami-shaped authenticated session, returned as structured JSON once a member signs in. The credit union is small and single-state — chartered in 1958 and serving roughly 39,000 members across six South Carolina branches, per NCUA's research-a-credit-union profile — which means the realistic route is one consenting member at a time, not a bulk feed.

The bottom line: there is real per-member structured data here worth syncing, and the cleanest way in is the member's own authenticated session, reconstructed from the app's traffic and normalized into stable fields. We would lead on that route and keep native statement download as a low-effort backup for the history a member can already export themselves.

What the app actually holds

Mapped from the published feature list and the in-app screens, these are the surfaces an integrator would care about.

How we'd reach it

Three routes apply to this app. They differ in effort and in how much of the table above they cover.

Member-consented authenticated session

With a member's authorization, we reconstruct the Alkami login and token exchange, then call the same JSON endpoints the app uses for balances, history, transfers and card state. This covers nearly everything in the data table and stays current. It is the heaviest to set up and the most durable once running. We arrange the consenting test account and the authorization paperwork with you during onboarding.

Protocol analysis of the app traffic

Captured against a consenting account, the request/response pairs tell us field names, auth headers, refresh behavior and error shapes. This is the groundwork the session route is built on, and it is what we hand over as the protocol report regardless of which route ships.

Native statement export

A member can already download statements and transaction files from the portal. Parsing those is low-effort and a useful backstop for historical reconciliation, though it lags the live session and skips card controls and transfer initiation.

For Carolina Trust specifically, the consented session is the route we'd recommend: the app's value is in live balances and transfer state, and only the live session reaches the card-control and external-transfer surfaces that the statement export can't see. Export rides alongside it for deep history.

What lands in your repo

Everything is tied to the CTFCU surfaces above, not a generic banking stub.

• An OpenAPI/Swagger spec covering the endpoints we reach — balances, history, transfer initiation, card state, payment records.
• A protocol and auth-flow report for the Alkami session: token issuance, refresh window, cookie/header chain, and the error codes the app returns.
• Runnable source for the key calls in Python or Node.js, with the member-session handling wired in.
• Automated tests against a consenting sandbox or test member account.
• Interface documentation plus data-retention and consent-logging guidance sized to a federal credit union.

A worked call

Illustrative shape only — exact paths and field names are confirmed during the build against a consenting account, not asserted here.

# After a member-consented Alkami session is established,
# fetch share/loan balances, then page transaction history.

POST /auth/token        # member-authorized session, MFA already cleared
  → { "access_token": "...", "expires_in": 900, "refresh_token": "..." }

GET /accounts            Authorization: Bearer <access_token>
  → [ { "id": "S0001", "type": "share",
          "available": 1842.55, "current": 1842.55, "currency": "USD" },
        { "id": "L0007", "type": "loan", "balance": -9120.00 } ]

GET /accounts/S0001/transactions?since=2026-05-01
  → { "posted": [ {"date":"2026-05-29","amount":-54.20,"desc":"..."} ],
        "pending": [ {"amount":-12.00,"desc":"..."} ] }

# Handling we build in:
#  - 401 -> silent refresh via refresh_token, retry once
#  - token TTL ~15 min, so long syncs re-issue mid-run
#  - external ACH transfers post to a different path than
#    internal member-to-member moves; never collapse the two

Consent and supervision

Carolina Trust is a federal credit union, so the NCUA supervises it and member data falls under the GLBA Safeguards regime. That is the settled ground we work on, and consent is the spine of it: every pull happens inside a session the named member authorized in writing, with the consent record and an access log kept for audit. Scope is limited to the accounts the member names, and access is revocable — pull the authorization and the session stops.

The CFPB's Section 1033 personal financial data rights rule is the forward-looking piece, not today's law. It was finalized in 2024, then enjoined and pulled back into agency reconsideration during 2025, so its specific obligations are unsettled and we don't build against them or present them as governing a credit union this size. If a reconsidered rule lands, a consented integration is already positioned for it; until then, the member's authorization is what the work depends on.

Build notes specific to this app

Two things about the CTFCU app change how we engineer the integration.

First, the white-label platform drifts. Carolina Trust last swapped digital banking platforms in 2021, and Alkami pushes UI and endpoint refreshes on its own cadence. We keep a small conformance check that flags a changed response shape before a nightly sync silently breaks, and we account for re-validation in the maintenance handover rather than assuming the surface is frozen.

Second, the app exposes two transfer rails that look similar and behave differently: internal moves between Carolina Trust accounts or members, and external ACH out to other institutions, each with its own limits and confirmation steps. We model them as separate endpoints from the start, because a single generic transfer abstraction would mis-handle the external rail. We also keep the pre-login Snapshot balance preview in its own narrow scope, distinct from the full authenticated session, so the unauthenticated view never gets conflated with consented data. Access to a consenting account and any sandbox is arranged with you during onboarding — that setup is our job, not a hurdle you clear first.

Interface evidence

Store screenshots we reviewed while mapping the surfaces. Tap to enlarge.

Provenance

Checked in June 2026 against the app's store listing, Carolina Trust's own digital-banking pages, the NCUA credit-union profile, and the CFPB's current rulemaking status. Sources opened:

• CTFCU Mobile Banking on Google Play — feature list and package ID.
• Carolina Trust login-help page — confirms the Alkami platform.
• Carolina Trust digital banking overview — transfer and card-control surfaces.
• CFPB §1033 reconsideration notice — current unsettled status.

OpenBanking Studio integration desk · mapping reviewed June 2026.

Peer apps in the same space

If you're aggregating across credit unions, these come up alongside Carolina Trust. Each holds comparable member data that a single normalized layer can sit over.

• Alliant Credit Union — large digital-first CU with balances, transfers and external account links.
• Eastman Credit Union — quick-balance preview and full transaction history behind login.
• Delta Community Credit Union — Georgia's largest CU; checking, savings and loan data per member.
• Redstone Federal Credit Union — cleared checks, card activity, bill pay and transfers.
• ESL Federal Credit Union — Rochester CU with account history and payment records.
• Teachers Federal Credit Union — multi-state CU holding balances, transfers and card controls.
• America First Credit Union — broad share and loan account data behind an authenticated app.
• SchoolsFirst FCU — California CU with member balances, history and bill pay.
• Bethpage Federal Credit Union — accounts, transfers and mobile deposit per member.

Questions an integrator usually asks

The app runs on Alkami — does that change how you reach the member data?

It shapes the work rather than blocking it. Carolina Trust moved to Alkami in 2021, so the authenticated session, token exchange and JSON responses follow Alkami's patterns. We map that session against a consenting member account and normalize the fields, so the integration does not care which white-label theme the credit union ships.

Does the CTFCU app treat external transfers differently from member-to-member moves?

Yes, and the integration has to mirror that. The app moves money between Carolina Trust accounts, to another member, and out to other institutions over ACH. Those are separate flows with different limits and confirmation steps, so we model them as distinct endpoints rather than one generic transfer call.

Which regulator covers member data from a South Carolina federal credit union like Carolina Trust?

Carolina Trust is a federal credit union supervised by the NCUA, with member data governed by the GLBA Safeguards framework. The CFPB's Section 1033 personal financial data rights rule is the forward-looking piece, finalized in 2024 but currently enjoined and back in agency reconsideration, so the dependable basis we build on is the member's own written authorization, not a rule in flux.

How do you handle the Snapshot balances the app shows before login?

The Snapshot preview exposes a narrow, opt-in balance view outside the full authenticated session, so we keep it separate in the schema. Anything beyond those previews — history, transfers, card controls — is pulled only inside a consented, logged session for the member who authorized it.

Source comes to you for review before any invoice: from $300 we deliver runnable source plus documentation for the CTFCU surfaces, and you settle once it works as described, on a one-to-two-week cycle. Prefer not to host anything? Call our endpoints instead and pay only per call, with nothing upfront. Tell us the app and what you want from its data at /contact.html and we'll scope it.