Getting Success CU account and transaction data into your application

Behind a Success CU login sits a Jack Henry Banno session — the digital-banking platform Akoya named as its first core-provider partner when it opened its data-access network, per Akoya's own announcement. That single fact decides almost everything about how a third party reads this app: the authentication is OAuth 2.0 with OpenID Connect on top, and the institution already sits on a consumer-permissioned data network. Success Credit Union itself is a small shop out of Blytheville, Arkansas, per the credit union's site, but the data model under the app is the same one running across hundreds of community institutions.

What a buyer usually wants from Success CU is a clean, current read of a member's money: balances, the transaction stream, statements, and the state of their cards. The path we build first is the consumer-permissioned feed through Akoya, because it is standards-based and does not break when the app gets re-skinned. Anything that feed does not carry — the member's own tags and receipt photos, the exact card-control state, the PDF statements — we reach through authorized interface integration of the member's signed-in session. Both halves get normalized into one record before they reach your code.

Member data behind the login

The app names its own surfaces fairly plainly, which makes the mapping concrete. These are the domains worth pulling and where each one originates inside Success CU.

Three authorized ways into the data

Each route reaches a different slice. We usually combine them rather than pick one.

Consumer-permissioned feed (Akoya / FDX)

Jack Henry participates in the Akoya Data Access Network, so a member can authorize their Success CU data out under the FDX data standard, with the option to revoke later. This gives the cleanest read of accounts and transactions, it carries no scraping fragility, and it is the most durable surface to build on. Onboarding to the network is arranged with you during the engagement.

Authorized interface integration of the signed-in session

For the fields the standard feed leaves out — member-added tags and notes, receipt and check images, precise card-control state, the secure-message thread — we work the app's own OIDC-authenticated traffic under the member's authorization. This is reverse engineering for interoperability: map the token exchange, the request shapes, and the field names, then wrap them. It reaches more than the feed but tracks app releases, so we version it.

Native statement export

The app already lets a member download e-statements and tax documents. Where you need history older than the live feed retains, we parse those PDFs into structured rows as a backfill. Low effort, slow cadence, useful once.

For a live balance-and-transaction feed we would stand up the Akoya path first, run the session integration alongside it for the app-only fields, and lean on statement parsing only for the historical backfill. That combination is what most teams end up wanting, even when they ask for just one.

What lands in your repo

The headline deliverable is code you can run, not a document you have to implement.

• A runnable client SDK in Python and Node.js (Go on request) that handles the OIDC consent flow, token refresh, cursor-based delta sync, and pagination — import it and start pulling.
• Webhook and poller handlers for the ingestion side, feeding the normalized mapper directly.
• An automated test suite covering auth refresh, transaction pagination, and the normalized-record mapping.
• A normalized schema and mapper that folds the FDX feed and the session-integration fields into one account/transaction shape.
• An OpenAPI / auth-flow report documenting the token chain and every endpoint touched.
• Interface documentation plus data-retention and consent-logging notes for your own records.

The pull, in code

Illustrative shape of the Python client — the auth model is Banno's OIDC, and field names are confirmed against the live surface during the build rather than guessed.

# Success CU (Banno) client — consent once, then delta-sync
from successcu_sdk import SuccessCUClient

cu = SuccessCUClient(
    issuer="https://<banno-host>/a/consumer/oidc",   # CU's OIDC issuer
    client_id=CLIENT_ID,
    scopes=["openid", "accounts:read", "transactions:read"],
)

# Member grants access via the OIDC authorization-code flow once.
# The SDK renews the access token before it lapses, so a long feed
# does not stall partway through a pull.
session = cu.connect(refresh_token=member_token)

# Pass last run's cursor; get back only what changed since.
page = session.transactions(account_id=acct, since_cursor=cursor)
for txn in page.items:
    upsert(txn.id, {
        "status": txn.status,            # "posted" | "pending"
        "amount": txn.amount,            # signed minor units
        "description": txn.description,
        "running_balance": txn.balance,
    })
cursor = page.next_cursor                 # persist for the next run

The annotations members add — tags, a free-text note, a receipt image — do not live in the standardized feed, so the mapper attaches them from the session route onto the same transaction id:

{
  "account": { "id": "acct_***", "type": "share_draft",
               "balance": 184233, "currency": "USD" },
  "transaction": {
    "id": "txn_***", "status": "posted",
    "amount": -4200, "posted_at": "2026-06-05",
    "tags": ["groceries"], "note": "split with Sam",
    "receipt": "img_***"          // from the app surface, not the feed
  }
}

Where teams wire this in

• A bookkeeping product that needs a member's posted-and-pending transactions, with the receipt images they already attached in the app, flowing straight into a ledger.
• A personal-finance dashboard that aggregates Success CU alongside accounts a member holds elsewhere, using the external-transfer links to follow money past the credit-union boundary.
• A lending or underwriting flow that reads consented balances and cash-flow history through the FDX feed, with statement PDFs parsed for the longer look-back.
• An internal back-office tool that mirrors card status (active or locked) for support staff without ever changing it.

Build details specific to Success CU

Two real wrinkles shape how this one gets built, and we handle both.

Two sources, one record

The Akoya feed gives clean balances and transactions; the app surface holds the tags, notes, receipt images, card state and statement PDFs. We reconcile both into a single per-transaction record keyed on the transaction id, so a downstream consumer reads one complete row rather than two half-rows it has to stitch together.

Card controls stay read-only on our side

Card management in the app can activate a card, set a PIN, or lock a misplaced one. Those are write actions we deliberately do not automate — we mirror the resulting status for monitoring and leave the changes to the member. It is a boundary we choose, not a limit we hit.

External-transfer links get tagged

The Transfers section can point at accounts a member holds at other institutions. We map those linked accounts so a cash-flow view does not stop at the Success CU edge, and we keep them flagged as external so an internal-to-external transfer is never counted twice during reconciliation.

Who authorizes the access, and the US rule picture

The access rests on the member's own authorization. Because Success Credit Union runs on Banno and Jack Henry sits inside the Akoya Data Access Network, a member can grant — and later revoke — permission for their data to leave under the FDX standard right now. Consent is scoped to the data domains the use case needs, recorded, and time-bound to the grant. We operate authorized, logged and data-minimized, with an NDA where the work calls for one.

On the regulatory side, the CFPB's Section 1033 Personal Financial Data Rights rule is, as of mid-2026, enjoined and back in the agency's rulemaking, per the CFPB's reconsideration docket. We treat it as where US data-rights rules may eventually settle, not as the thing the integration depends on — a Success CU member's consent through the existing network is what carries the access today.

App screens

The published screenshots, useful for confirming which surfaces map to which data. Select to enlarge.

Where these facts come from

Checked in June 2026 against primary sources: Success Credit Union's own digital-banking pages for the named features, Jack Henry's developer docs for the OAuth 2.0 / OpenID Connect model behind Banno, and the Akoya and Jack Henry announcements for the consumer-permissioned data network. The Section 1033 status comes from the CFPB's reconsideration docket.

• Success Credit Union — digital banking features
• Jack Henry docs — OpenID Connect and OAuth 2.0
• Akoya — Jack Henry joins the data-access network
• CFPB — Personal Financial Data Rights reconsideration

OpenFinance Lab — integration engineering notes, June 2026.

Comparable credit-union apps

Same category, similar data behind the login. A unified integration normalizes across them, which is why teams that start with one usually ask about several.

• SchoolsFirst FCU Mobile — share and checking balances, transaction history, mobile deposits and card lock controls for a California school-employee membership.
• Alliant Credit Union — accounts, transaction history, transfers, bill pay, card on/off and an ATM locator for a national membership.
• Connexus Credit Union — balances, transfers, bill pay and mobile deposit, with budgeting tools layered on the transaction feed.
• Suncoast Credit Union — accounts, cleared-check images, savings goals and card management for a Florida membership.
• Navy Federal Credit Union — accounts, transfers, Zelle payments, deposits and card controls at large scale.
• PenFed (Pentagon Federal) — checking, savings, loan and card data with transfers and statements.
• BECU — balances, transactions, deposits and bill pay for a Washington-state membership.
• Digital Federal Credit Union (DCU) — accounts, transfers, deposits and external-account links much like Success CU's.
• Golden 1 Credit Union — accounts, payments, deposits and card controls for a California membership.

Questions we get about Success CU

Will the SDK keep balances and transactions current, or is it a one-time export?

It runs as a delta sync. Each call passes the cursor from the previous run and returns only what changed, so balances stay near-real-time and both posted and pending transactions land as they appear, with no full re-pull each cycle.

The app lets members tag a transaction and attach a receipt photo. Can those come across too?

Those annotations live on the Banno app surface rather than in the standardized data feed. We capture them through authorized interface integration of the member's OIDC session and map each tag, note and receipt image back to the transaction id it belongs to.

US open-banking rules are in flux right now, so what is the access actually based on?

The member's own authorization. Success Credit Union runs on Jack Henry's Banno platform, which participates in the Akoya Data Access Network, so a member can permission their data out under the FDX standard today. The CFPB Section 1033 rule is enjoined and back in rulemaking as of mid-2026, so we treat it as where the rules may settle, not as the basis we rely on now.

We know our use case but not Success CU's internals. Is that enough to begin?

Yes. Give us the app name and what you want from its data; we arrange access and the compliance paperwork with you as part of the build, working against a consenting account or a sponsor sandbox.

Source-code delivery starts at $300: you get the runnable client and its docs, and you pay once it is in your hands and working. If you would rather host nothing, the same endpoints run as a metered hosted API — call them, pay per call, nothing up front. Either way the build runs in one to two weeks. Tell us it is Success CU and what you need from the data, and start a project on the contact page.