Getting member records out of the Radiant Credit Union app, the authorized way

Radiant Credit Union runs its member channel on Alkami's hosted digital-banking platform — confirmed by Alkami's own client write-up on the credit union. That single fact decides most of how an integration is built: the app is not talking to a one-off in-house backend but to a multi-tenant, AWS-hosted service with OAuth-style tokens, device registration and step-up MFA. The data a member sees is rich. Balances, posted and pending transactions, images of cleared checks, monthly statements, bill pay, Zelle, internal and external transfers, and a granular alert engine all sit behind one login.

Bottom line: there is plenty worth integrating here, and the route is not in doubt. We work the member-facing client and its authorized traffic to the Alkami back end, under the member's consent, and hand back runnable code plus a written interface report. The Alkami footprint actually helps — its session model is well-understood, so the unknowns are Radiant's specific tenant configuration, not the protocol family.

Member data the Radiant app exposes

Each row below is a surface the app or Radiant's own help pages describe. Granularity is what an integrator should expect to normalize, not a guess.

Routes in, and the one we'd take

Three routes genuinely apply to Radiant. We size each by what it reaches and how long it lasts.

Member-consented interface integration

The app authenticates a member to Alkami-hosted endpoints and renders the logged-in view. With the member's authorization we analyze that same traffic and reproduce the calls in code. This reaches everything in the table above, because it is exactly the member's own view. Effort is moderate; durability is good as long as a re-validation step rides along with platform updates. This is the route we recommend for Radiant — it is the only one that returns cleared-check images and pending holds, not just a stripped statement.

User-permissioned aggregation consent

Where a member explicitly authorizes ongoing access, the same data is reached on a standing consent rather than a one-off. Useful when the downstream product needs a daily refresh. We handle the consent capture, logging and renewal as part of the build.

Native statement export (fallback)

Radiant publishes monthly statements as documents inside the app. As a narrow fallback this gives clean periodic data with low effort and high durability, but it loses pending transactions, intraday balances and the alert stream. We use it to backfill history, not as the spine.

What lands at the end of the build

For Radiant specifically, the deliverable set is:

• An OpenAPI/Swagger specification covering the member surfaces above — accounts, transactions, check-image fetch, statements, bill pay, transfers, alerts.
• A protocol and auth-flow report: the Alkami-style token acquisition, device registration, step-up MFA and challenge-response path as observed for this tenant.
• Runnable source for the key endpoints in Python and Node.js — login/token refresh, paged transaction pull, the keyed check-image fetch, statement download.
• Automated tests against a consenting member account, including the pending-vs-posted and real-time-vs-batch alert cases.
• Interface documentation plus data-retention and consent-logging guidance fitted to an NCUA-insured institution.

A statement-and-transaction pull, sketched

Illustrative only; exact field names and headers are confirmed against the live tenant during the build. It shows the shape that matters here — the check image is a second call, not an embedded blob.

POST /auth/token            # member consent; Alkami-style OAuth grant
  body: { username, password, device_id }
  -> 401 + mfa_challenge   # step-up; answer, then:
  -> { access_token, refresh_token, expires_in }

GET /accounts                # bearer + registered device header
  -> [{ acct_id, type:"SHARE", available, current }, ...]

GET /accounts/{acct_id}/transactions?from=2026-01-01&status=all
  -> [{ tx_id, posted:false, amount, memo, check_no:"1042" }, ...]
     # posted:false  -> pending hold, surface separately

GET /documents/check-image?check_no=1042&acct_id=...
  -> image/tiff                 # keyed off check_no from the tx row

on 401 mid-stream: refresh_token grant, replay; do not re-prompt MFA
on 429: respect Retry-After; Alkami fronts a shared tenant

Where integrators put this

• A bookkeeping product onboarding a Radiant business member: nightly balances, transactions and statement PDFs into the ledger, with eBills feeding the payables calendar.
• A lending workflow that needs verified deposit history and cleared-check images as part of an underwriting file, pulled once under member consent.
• A treasury view for a member who also banks elsewhere, where Radiant's Zelle and external-transfer states must stay distinct from internal moves to reconcile correctly.

Member consent and an unsettled US data-access rule

Radiant is a Florida state-chartered, NCUA-insured credit union, so two things govern access. The standing baseline is member authorization under GLBA privacy and Regulation E for electronic transfers — that is what makes the consented route legitimate today. The forward-looking piece, the CFPB's Section 1033 personal financial data rights rule, is not settled: the CFPB reopened it for reconsideration and a federal court enjoined enforcement, so there is no dependable regulated feed to design against for an institution of Radiant's size right now. We do not pin the rule's eventual thresholds or timelines, because they are exactly what is being reconsidered. The practical consequence is simple: build on the member's own consent, capture and log it, and refresh it before it lapses. If a mandated channel later firms up, the same integration moves onto it without a redesign.

Things we plan around on this build

Three are specific enough to call out, all handled by us during the engagement:

• Alkami device and MFA handshake. The platform uses device registration, step-up MFA and a background challenge-response check against credential stuffing. We model the handshake so the integration presents as a registered device and the session survives that check; access is arranged with you during onboarding against a consenting member account.
• Cleared-check images are a separate fetch. The transaction feed references a check by number, not by embedding the image. We map the image retrieval as its own call keyed off the check number and stitch it back to the matching transaction so consumers get one coherent record.
• Transfer rails are not one thing. Internal share transfers, Zelle and external transfers run through different processors with different status lifecycles. We keep them as distinct objects in the normalized schema, and we tag alerts by their real-time-versus-batch class so downstream freshness expectations stay honest.

How a Radiant build is priced

Source delivery for the Radiant endpoints starts at $300, billed only after the working code is in your hands and you are satisfied with it. The alternative is the pay-per-call hosted API: we run the integration, you call our endpoints and pay per call, with no upfront fee. Either way the cycle is one to two weeks for the surfaces described here. Tell us the app and what you need from its data; access and the compliance paperwork are arranged with you as part of the work. Start the conversation at /contact.html.

Screens from the app

Store screenshots, for interface reference. Select to enlarge.

What was checked, and when

This mapping was put together from Radiant Credit Union's own mobile-banking and alerts pages, Alkami's published client testimonial naming Radiant as a platform customer, the credit union's history record of the SunState Federal conversion, and the CFPB's reconsideration docket for the Section 1033 rule. No member account was accessed; the data surfaces are taken from public product descriptions. Primary sources:

• radiantcu.org — Mobile Banking
• Alkami — Radiant Credit Union client testimonial
• radiantcu.org — Member Alerts (real-time vs batch)
• CFPB — Personal Financial Data Rights Reconsideration

Mapped by the OpenBanking Studio integration desk · May 2026.

Other credit-union apps in the same integration bucket

Same category, same shape of problem — each holds member balances, transactions and transfers behind an authenticated app, and a unified feed usually has to span more than one of them.

• CAMPUS USA Credit Union — Gainesville-based peer; member accounts, transfers and bill pay behind a login.
• Florida Credit Union — North-Central Florida member banking with statements and transaction history.
• VyStar Credit Union — large North/Central Florida footprint; balances, transfers and deposits in-app.
• Suncoast Credit Union — Florida's largest by membership; full retail and business account data.
• Alliant Credit Union — broad-membership digital credit union with balance preview and transfers.
• Delta Community Credit Union — Georgia's largest; account history, payments and deposits.
• ESL Federal Credit Union — Rochester-area institution with statements and transaction feeds.
• Bethpage Federal Credit Union — multi-account member banking with bill pay and transfers.

Questions a Radiant integrator tends to ask

Does the integration include the cleared-check images, or just the transaction list?

Both. The Alkami-style transaction feed references a cleared check by handle rather than embedding the image, so the image is a second fetch keyed off the check number. We wire that second call into the build and return the image alongside the matching transaction record.

How do you treat Radiant's Zelle and external transfers versus internal account moves?

They are modelled as separate objects. Internal share-to-share transfers post on Radiant's own ledger; Zelle and external transfers run through different processors with different status lifecycles, so the normalized schema keeps their states distinct rather than flattening them into one transfer type.

Radiant runs on Alkami now — does that affect what you can reach?

It shapes the auth handling more than the data scope. The member channel authenticates against Alkami-hosted endpoints with device registration and step-up MFA, so the integration is built to register as a known device and survive the challenge-response check. The reachable surface is still the full logged-in member view.

With the CFPB 1033 rule on hold, what keeps a Radiant feed durable?

Member-permissioned consent rather than a guaranteed regulated feed. The federal data-access mandate is in reconsideration and unenforced, so for a Florida state-chartered, NCUA-insured credit union the durable basis is the member's own authorization, captured and logged, refreshed before it lapses.