Reaching the account data inside Vermont Federal's mobile app

Vermont Federal Credit Union moved its members onto the Alkami digital-banking platform, per the credit union's own online-banking conversion notice; the mobile app is the member-facing client for that back end. That single fact decides most of this brief. The data a third party wants — balances, posted transactions, transfers, bill-pay history, card-linked offers — does not live in the app. It lives in a Vermont Federal account on a hosted platform, and the app is one authenticated way to read it. Our work is to reach that account data the way the member is entitled to, and hand back code that does it on a schedule.

What sits behind a member login

The app's own description names what it carries: balances, transactions, transfers, bill pay, and cash-back offers. Mobile check deposit and eStatements show up in the help material around the conversion. Mapped to what an integrator would actually consume:

Note the bounded transaction window. The member UI serves a trailing range, not the full account life, so a first sync captures what the platform exposes and then runs forward. Older history comes from the statement documents — parseable, but a different extraction job than the live feed.

A session against the Alkami back end

This is illustrative and confirmed against the live contract during the build — field names and the exact challenge order are settled when we map the current release for a consenting member, not assumed here.

POST /auth/login
  { "username": "<member>", "password": "<secret>",
    "deviceId": "<bound-device>" }
-> 200 { "status": "MFA_REQUIRED",
         "challengeId": "...", "methods": ["sms","app"] }

POST /auth/mfa
  { "challengeId": "...", "code": "<otp>",
    "rememberDevice": true }
-> 200 { "accessToken": "<jwt>", "expiresIn": 900,
         "deviceToken": "<persist-for-next-time>" }

GET /accounts            (Bearer accessToken)
-> [ { "id": "S0", "type": "share",   "balance": ..., "available": ... },
     { "id": "C1", "type": "checking","balance": ..., "available": ... } ]

GET /accounts/C1/transactions?from=2025-11-01&to=2026-05-18
-> [ { "postedDate": "...", "amount": -42.18,
       "description": "...", "runningBalance": ... }, ... ]

# handle: token expiry (~15 min) -> refresh; MFA re-challenge
# on new device; bounded history -> page + fall back to eStatements

The device-binding and short token life are the parts that decide reliability. A poller that ignores them re-triggers MFA and gets locked out. We design around a registered, consenting session so it does not.

What lands at the end of the build

Concrete artefacts, each tied to the surfaces above:

• An OpenAPI description of the member-session endpoints we map — auth, accounts, transactions, transfers, bill pay, offers — with the real request and response fields.
• A protocol and auth-flow report: the login, MFA challenge, device-token persistence and refresh chain as the current Alkami-based app actually performs it.
• Runnable source for the key reads in Python and Node.js — session establishment, paged transaction pull, balance and transfer fetch, statement-document retrieval.
• Automated tests covering token expiry, MFA re-challenge, the bounded-window fallback to eStatements, and empty/partial account responses.
• Interface documentation plus data-retention and consent-logging guidance written for an NCUA-insured credit union's data.

Three ways into the account data

Consented member access (recommended spine)

The member authorises access to their own Vermont Federal data and the integration reads it through the app's session contract on their behalf. Reachable: everything the member sees. Effort: moderate — the MFA and device model is the main work. Durability: good while consent holds. We arrange the consenting account and the access setup with you during onboarding.

Platform aggregation / FDX-style sharing

Where the Alkami platform exposes standardised data sharing and the OFX/aggregation rail the credit union supports for Quicken and QuickBooks, that rail is a second, independent source. Reachable: balances and transactions reliably; offers and bill-pay less so. Durability: strong, since it is a supported export path. We treat it as a parallel feed, not the only one.

Statement and document export

eStatement PDFs are the fallback for history older than the live window. Narrow, but the right tool for backfill and audit. We include a parser when the account holds the documents.

Our recommendation for Vermont Federal: build the consenting member session as the working feed, mirror balances and transactions through the aggregation rail for resilience, and keep statement parsing for the backfill. One feed alone is brittle on a platform that ships updates on its own cadence.

Member consent and the US data-rights picture

Vermont Federal is an NCUA-insured credit union, so the relevant frame is the CFPB's Personal Financial Data Rights rule under section 1033 of Dodd-Frank, with the Financial Data Exchange recognised as a standard-setting body for the data format. The rule is not settled: the CFPB opened a reconsideration of it in 2025, so the tiered compliance dates and history obligations as originally finalised are now in flux and are not asserted here as present-tense fact. For a credit union of Vermont Federal's size that uncertainty matters in practice — the durable access is the consenting member's own authorization, not a regulatory deadline. We work authorized and documented: access is consent-based, every pull is logged against a consent record, data is minimised to the fields the use case needs, and an NDA is in place where the engagement calls for one.

What we plan for on this build

• Platform release cadence. Alkami pushes platform updates independently of the credit union. We build a contract-diff check the studio runs after Vermont Federal releases, so a changed field or a reordered MFA step surfaces in our monitoring before it reaches your pipeline.
• MFA and device binding. The app challenges new sessions and binds a device. We design the connection around a registered, consenting session and a persisted device token so polling does not re-prompt or trip a lockout.
• The conversion's aggregation gap. The credit union's own migration notice records that Quicken/QuickBooks aggregation was unavailable for five days during the Alkami cutover. We treat the aggregation rail and the app session as independent sources so a maintenance window on one does not blank the feed.
• Two member bases. Vermont Federal also runs a separate Credit Union of Vermont division with its own app and members. We scope the integration to the correct member set so the two are never conflated.

Where teams put this data

• A bookkeeping tool syncing a Vermont Federal business checking account into its ledger without the member re-keying transactions.
• A personal-finance app showing a member their Vermont Federal balances alongside other institutions in one consented view.
• A lender pulling a consenting applicant's recent transactions and balances for cash-flow underwriting.
• A treasury workflow watching scheduled transfers and bill-pay status so a missed payment raises an alert the same day.

App screens

Store screenshots, used here only to read the app's real surfaces. Select one to enlarge.

How this brief was built

Worked from the app's store description and the credit union's own conversion material in May 2026: the Play and App Store listings for the feature set and identifiers, the credit union's online-banking update page for the Alkami platform move and the aggregation behaviour, and the CFPB/Federal Register record for the data-rights status. Primary sources opened:

• Vermont Federal — digital banking conversion notice (Alkami)
• Vermont Fed CU Mobile Banking — Google Play listing
• CFPB — Personal Financial Data Rights (§1033)
• Federal Register — Personal Financial Data Rights reconsideration

Mapped for OpenBanking Studio's integration desk, May 2026.

Other US credit-union and bank apps with the same data shape

Named for ecosystem context — the same balances-transactions-transfers structure shows up across these, which is why a unified integration over them is feasible. No ranking implied.

• EastRise Credit Union — the Vermont credit union formed from the NEFCU and VSECU merger; comparable member account and transaction data behind its app.
• Credit Union of Vermont — the separate Vermont Federal division with its own app and the same kind of share/checking ledger.
• America First Credit Union — large US credit union app with balances, transfers, deposit and card controls.
• Suncoast SunMobile — Suncoast Credit Union's app, with statements, savings and loan-payment data.
• Banner Bank Mobile Banking — bank app exposing balances, eStatements, transfers and bill pay.
• AmFirst Digital Banking — American First Credit Union's digital banking app over similar account records.
• Alliant Credit Union — nationwide credit union app with the same account-and-transaction core.
• Navy Federal Credit Union — large-scale credit union app holding the same per-member financial records.

Questions integrators ask about this one

Does the 24-month transaction window in the app limit what an integration can backfill?

Yes. The member-facing history the app exposes is bounded, so a first sync captures roughly the trailing window the platform serves and then runs forward incrementally. Anything older has to come from archived statement documents, which we can parse if the account holds them.

Vermont Federal moved to the Alkami platform — does that change how you reach the data?

It sets the shape of the work. We map the session and JSON contract the current Alkami-based app uses for that member, rather than anything from the prior system, and design the connection around its MFA and device-binding behaviour.

Can the integration tell a Credit Union of Vermont member from a Vermont Federal member?

It has to, and we scope for it. Vermont Federal runs a separate Credit Union of Vermont division with its own app and member base; the integration is bound to the correct member set so balances and transactions are never read from the wrong side.

Is consented access still viable while the CFPB 1033 rule is being reconsidered?

Yes, because the route we build does not depend on the rule being settled. The durable path is the consenting member's own authorization plus FDX-style data sharing where the platform offers it; the rule's status changes the regulatory backdrop, not the technical access.

The runnable source for the member-session reads starts at $300, billed only after delivery once you have it working; if you would rather not run it yourself, the same integration is available as a hosted endpoint you call and pay per call, with no upfront fee. Either way the cycle is one to two weeks and you give us two things — the app name and what you want out of its data. Access, the consenting account and any compliance paperwork are arranged with you as part of the work. Start it from our contact page.