Integrating the Arsenal Credit Union member portal

What a signed-in Arsenal session actually exposes

In early 2024 Arsenal Credit Union folded three separate apps — mobile banking, the CardKey card manager, and live video banking — into one signed-in experience, per the credit union's online and mobile banking pages. That merge is the reason this integration is worth scoping as a single job: one authenticated session now returns the whole member relationship instead of three disconnected silos.

After login the app lists every account the member is associated with at Arsenal, plus any outside accounts they have linked, and each tile opens into detailed history. The reachable picture is a consumer or business member's balances and posted/pending transactions, debit and credit card state, internal and external transfers, Zelle activity, scheduled bill-pay payees, and the secure-message thread with Arsenal staff. The honest bottom line: the data is rich and consolidated, the access path is an authenticated member session, and the route we would take is user-consented interface integration that mirrors what the app itself does after sign-on.

Member data, by where it lives in the app

Getting to that data: the routes that fit a Missouri credit union app

Authorized session integration is the spine; user-consented sync layers on it; native aggregation is a backstop. We size all three and say which one we would actually build.

Authorized interface integration of the member session

We analyse the traffic the app exchanges with the digital-banking backend after a consenting member signs in, and reproduce the calls that return the account graph, history, cards, transfers and messages. This reaches everything the consolidated app shows. Effort is moderate; the early-2024 merge means the request surface is reasonably uniform across account types. Durability is good between major app releases and is the route we recommend, because it captures the full post-merge relationship from one session.

User-consented credential access for ongoing sync

For recurring pulls, the integration runs under the member's own consent with their credentials held by the consenting party, refreshing balances and history on a schedule. Reach is the same as route one; the added work is session lifecycle — biometric/MFA prompts, token expiry, and step-up challenges — which we design around so the sync does not stall.

Native aggregation as a fallback

Where a member only needs the consolidated view, the app's own account-aggregation panel already mirrors linked outside accounts. That is thinner and lags the source, so we treat it as a backstop, not the spine.

For most buyers the recommendation is the first route, with route two layered on when the use case is a standing sync rather than a one-time pull. Access to a consenting account or a sponsor sandbox is arranged with you during onboarding — that setup is part of the engagement, handled on our side with you, not something you assemble before we start.

A worked example: consolidated balances and history

The shapes below are illustrative and confirmed against the live app during the build, not published contracts. They show the single-sign-on account list and a per-account history pull with token refresh and error handling.

POST /auth/session            # member sign-on, returns short-lived access token
  body: { username, password, deviceId }
  -> 200 { accessToken, refreshToken, mfaRequired: false }
  -> 401 { error: "step_up", challenge: "otp" }   # handle MFA / biometric step-up

GET  /accounts                 # single sign-on account graph
  auth: Bearer accessToken
  -> 200 { accounts: [
       { id, type: "SHARE|CHECKING|LOAN", nickname,
         availableBalance, currentBalance, status,
         linked: false },
       { id, type: "EXTERNAL", source: "aggregation",
         currentBalance, linked: true, readOnly: true } ] }

GET  /accounts/{id}/transactions?cursor=&limit=50
  auth: Bearer accessToken
  -> 200 { items: [
       { postedAt, amount, runningBalance, status: "POSTED|PENDING",
         description, channel: "ZELLE|BILLPAY|CARD|TRANSFER|ACH" } ],
     nextCursor }

# on 401 expired -> POST /auth/refresh { refreshToken } then replay
# on 429 -> exponential backoff; never hammer the member session

The channel field is the part worth calling out: it is what lets a downstream system separate a Zelle transfer from a card purchase from a scheduled utility payment, instead of flattening everything into one ledger.

What lands at the end of the build

Everything is tied to the surfaces above, not a generic template.

• An OpenAPI specification covering session/auth, the account graph, per-account history, cards, transfers and bill-pay objects.
• A protocol and auth-flow report: the sign-on, token-refresh and step-up (MFA/biometric) chain as it behaves in this app.
• Runnable source for the key endpoints in Python and Node.js — login, account list, paginated history, card state — with the channel normalisation already wired.
• Automated tests against captured fixtures, including pending-to-posted transitions and token-expiry replay.
• Interface documentation: object models for native versus linked-aggregation accounts, plus retention and consent-logging guidance.

Member-data consent under Missouri and NCUA oversight

Arsenal is a state-chartered credit union supervised by the Missouri Division of Credit Unions, with member shares federally insured by the NCUA (the public credit-union directories list certificate 67195). Member financial data is governed by GLBA privacy obligations and the credit union's own digital-banking terms. The federal Personal Financial Data Rights rule under Section 1033 would otherwise sit over this; a federal court enjoined its enforcement in late 2025 while the Bureau reconsiders it, per the Federal Register reconsideration notice and contemporaneous reporting. We therefore do not build on that mandate. Access is user-consented through an authenticated member session, every pull is logged against a consent record with a defined scope and a revocation path, only the fields the use case needs are retained, and an NDA covers the engagement where the client requires one.

Engineering details we plan around for this app

These are specific to Arsenal and are things we handle, not hurdles put on you.

• Native versus linked accounts. The account list mixes real Arsenal shares and loans with read-only mirrors of aggregated outside accounts. We tag each account by origin so a downstream system never treats an aggregated mirror as an authoritative Arsenal balance or tries to initiate against it.
• The three-app merge precedent. The 2024 consolidation collapsed mobile banking, CardKey and video banking into one session; that history says the front end will move again. We version the captured contract and re-validate it on each major app release so a layout or auth change is caught early.
• Consumer and business members on one app. The same app serves personal and business online banking, which differ in entitlements. We scope the integration per membership type so a business multi-user relationship is mapped correctly rather than assumed to look like a single consumer login.
• Session lifecycle. Biometric and MFA step-up, token expiry and rate limits all sit on the member session; we build refresh and backoff around them so a scheduled sync does not silently expire or get throttled.

Working with us, and what it costs

The piece most buyers care about — the consolidated account-and-history view behind single sign-on — is what the source package is built around, so you receive working code against the surface that matters, not a stub. Source-code delivery starts at $300: you get the runnable integration, the spec, tests and documentation, and you pay after delivery once you have confirmed it works for you. If you would rather not run infrastructure, the hosted option lets you call our endpoints and pay per call with no upfront fee. A typical build runs one to two weeks. Tell us the app and what you need from its data and we take it from there — start at /contact.html.

Where integrators put this data to work

• A bookkeeping tool syncing a small-business member's Arsenal checking and card activity, using the channel field to auto-classify Zelle, ACH and card lines.
• A personal-finance app that wants one member's full picture, including the linked outside accounts the aggregation panel already mirrors.
• A lending or underwriting workflow pulling consented balance and transaction history with a fixed-scope, revocable consent record.
• An internal ops dashboard tracking card lock/unlock state and pending-to-posted transitions for support cases.

Screens from the current build

From the app's store listing; click to enlarge.

How this brief was put together

Checked in May 2026 against Arsenal's published online and mobile banking pages for the feature surfaces, the app's store listing for version, related apps and the data categories it collects, and primary regulatory sources for the Section 1033 status. Sources opened: Arsenal online + mobile banking features, Arsenal Credit Union on the App Store, Federal Register: Personal Financial Data Rights Reconsideration, Consumer Finance Monitor on the 1033 status.

OpenBanking Studio integration desk · mapping reviewed May 2026.

Other St. Louis-area banking apps in the same integration picture

These appear alongside Arsenal as same-category Missouri member-banking apps; an integrator building a unified view often touches several. Listed for ecosystem context only.

• Neighbors Credit Union — St. Louis credit union holding member balances, history and card data behind an authenticated app.
• Alltru Credit Union — Missouri member-banking app with accounts, transfers and bill pay under sign-on.
• Together CU (MobileAccess+) — credit union app exposing balances, transactions and payments to its members.
• Vantage Credit Union — large St. Louis credit union with consumer accounts, cards and transfer history.
• St. Louis Community Credit Union — member accounts, deposits and transaction records behind login.
• First Community Credit Union (MO) — checking, savings and loan data accessible to authenticated members.
• West Community Credit Union — member balances, payments and card controls in one app.
• Midwest BankCentre — community bank app with deposit accounts and transaction history per customer.

Questions integrators ask about Arsenal's data

Does the consolidated single sign-on mean one integration covers checking, loans and linked outside accounts?

Yes. Since the early-2024 merge, one signed-in session lists every account a member is associated with at Arsenal plus any external accounts they have linked, and each tile drills into detailed history. We model that hierarchy as one account graph: native Arsenal accounts and loans carry full transaction detail, while linked outside accounts are read-only mirrors with whatever granularity the aggregation source returns.

Is Zelle and bill-pay activity reachable, or only balances and transaction history?

Both. Zelle send/receive events and bill-pay items surface as posted and pending transactions in the same history the app renders, and scheduled bill-pay payees and automatic payments are separate objects in the session. We capture them as distinct record types so a downstream system can tell a Zelle transfer from a card purchase from a scheduled utility payment.

Arsenal is a Missouri state-chartered credit union — does the CFPB 1033 situation change how you would reach the data?

No. Our route is user-consented access through an authenticated member session, not a regulator-mandated data portal. The federal Personal Financial Data Rights rule under Section 1033 was enjoined in late 2025 pending the Bureau's reconsideration, so we do not build the integration on a mandate that may move. Member-data handling follows GLBA, the credit union's own digital banking terms, and Missouri Division of Credit Unions oversight regardless of where 1033 lands.

If Arsenal ships another big app change like the 2024 three-app merge, does the integration break?

A front-end change can shift request shapes, which is exactly what the 2024 consolidation did. We version the captured contract and re-check it whenever the app ships a major release, so a UI or auth-flow change is caught and patched rather than silently returning stale or empty data.