Connecting to the Members Choice mobile app for member-permissioned account data

One member login at Members Choice sits in front of a wide ledger: checking, savings, the credit card, the mortgage, auto and personal loans, and any business accounts the same person holds. The app then layers budgeting trackers and outside accounts connected from other institutions on top of that. For a team that needs this member's balances and transaction history in their own system, that breadth is the whole point and also the thing an integration has to get right. This brief covers what the app holds, the authorized way to reach it, and the code that lands at the end.

What member data the app actually holds

Every domain below is named the way the app and the credit union present it. Granularity is what a single authenticated member can see, not anything privileged.

Bottom line: the data worth integrating is the per-member account and transaction set behind login, and the route that holds up is the member's own session, run with consent. The aggregation feature is useful context but works inward — it brings a member's outside accounts into the Members Choice view, and the data a third party wants still resolves through the member's own session.

Reaching the data: the routes that fit a credit-union app

Authorized analysis of the app session

The app authenticates a member, refreshes a token, then requests an account list and per-account transactions. Documenting that exchange under the customer's authorization is the most complete route here, because it reaches every product the member can see in one place. Effort is moderate; durability depends on how often the digital banking front end changes, which we plan for in maintenance. We arrange the working access — a consenting member account or a sponsor environment — with you during onboarding.

User-consented credential access

A consenting member can authorize ongoing access, which is the path aggregators use in the US market. It is durable and sanctioned, but mediated, so the field set is narrower than the native session. Good as the long-lived spine when continuity matters more than completeness.

Native export as a fallback

Where the member-facing surface allows transaction or statement export, that output is a low-effort supplement for backfill or reconciliation. It is periodic, not real-time, so it supports rather than replaces the session route.

For Members Choice, build the core on the authorized session: it is the only route that resolves the full account list — deposits, card, loans, business and aggregated entries — and keep a consented-access path warm for the durability that route cannot guarantee on its own.

A look at the session a build would automate

Illustrative shape of the exchange. Endpoint paths and field names are confirmed during the build, not published by the credit union.

POST /auth/login        { username, password, deviceId }
  -> 200 { sessionToken, mfaRequired: true,
           mfaChannels: ["sms","biometric"] }

POST /auth/mfa          { sessionToken, otp }        # biometric path
  -> 200 { accessToken, refreshToken, expiresIn: 900 }

GET  /accounts          Authorization: Bearer <accessToken>
  -> 200 [ { accountId, type:
             "checking|savings|creditCard|loan|external",
             nickname, maskedNumber,
             available, current, currency } ]

GET  /accounts/{id}/transactions?from=&to=
  -> 200 [ { postedDate, description, amount,
             runningBalance, category,
             status: "posted|pending" } ]

# refresh keeps a consented session alive without
# re-triggering the username-use login alert
POST /auth/refresh      { refreshToken }
  -> 200 { accessToken, expiresIn: 900 }
      

Errors matter as much as the happy path: a stale token, an MFA re-challenge, and a locked-account response each need distinct handling so the sync degrades cleanly instead of looping.

What lands at the end of the build

Each deliverable maps to a real Members Choice surface, not a generic checklist:

• An OpenAPI specification covering the auth handshake, account list, transaction query and refresh as observed for this app.
• A protocol and auth-flow report: the login, MFA channel, token lifetime and refresh chain written out step by step.
• Runnable source in Python or Node for login, token refresh, account enumeration and dated transaction pulls, with the account-type mapping included.
• Automated tests against recorded responses, including the MFA-rechallenge and locked-account paths.
• Interface documentation and data-retention guidance keyed to member-permissioned, NCUA-context handling.

Things a Members Choice build has to get right

These are the parts we plan for, not hurdles put on the reader:

• The account list mixes retail, business and externally aggregated entries under one member. We type each entry on the way out so a business sub-account, the credit card and a linked outside account stay distinct rather than collapsing into one shape.
• Login uses an MFA step and the credit union sends an alert whenever the username is used to sign in. We design the flow around token refresh so a consented sync stays alive without re-tripping that alert, and we arrange the consenting account with you at onboarding.
• Zelle moves through the Early Warning network, not the core posting ledger. We reconcile Zelle items against posted account transactions so a downstream consumer does not double-count the same dollar.
• The digital banking front end changes on its own release cadence. Maintenance includes scheduled checks of the auth and account calls, so an endpoint or schema move is caught and the client patched before it reaches the feed.

Where teams actually use this

• A personal-finance product pulling a consenting member's full balance and transaction set into a single dashboard alongside their other institutions.
• An accounting tool reconciling a small business's Members Choice checking and loan activity into its books on a nightly sync.
• A lending or affordability check reading verified deposit history straight from the member session instead of uploaded statements.
• An internal treasury view that needs loan balances and payment-due data normalized next to deposit cash flow.

Member consent and the US data-rights picture

Members Choice is an NCUA-chartered credit union, so access here rests on the member's own authorization for their own data. Federally, the CFPB's Section 1033 personal financial data rights rule is in reconsideration — the Bureau has reopened it and a court has paused enforcement — so its specific compliance timing is not settled fact today and we do not present it as one. What is operative now is the same thing that was operative before the rule: a member can permission access to their accounts. We work consent-first — access is authorized and logged, the field set is minimized to what the use case needs, consent scope and revocation are recorded, and an NDA is in place where the engagement calls for one. We shape the output toward FDX-aligned fields, since FDX is the CFPB-recognized standards body, so the same integration carries forward if a standardized channel becomes the norm.

Working with us on this

The runnable client for the Members Choice session — login, MFA handling, token refresh, account list and dated transaction pulls — is delivered within one to two weeks. You can take it as source: source-code delivery starts at $300, and you pay after delivery once the integration runs to your satisfaction. Or you can skip hosting it and call our endpoints instead, paying per call with no upfront fee. You bring the app name and what you need from its data; we handle the access, the consent setup and the build. Start the conversation at /contact.html.

Other Texas and credit-union apps in the same data space

Named for ecosystem context, not ranked. Each holds comparable per-member account data a unified integration would normalize the same way:

• RBFCU Mobile — Randolph-Brooks Federal Credit Union; balances, transfers, card controls and check deposit for a large Texas membership.
• TDECU Digital Banking — the largest Houston-area credit union; balances, history, bill pay, budgets and mortgage views.
• USAA — San Antonio-based; deposit, card and loan data for a military membership.
• Alliant Credit Union — nationwide; transaction history and spending breakdowns across connected accounts.
• Security Service Federal Credit Union — one of the largest credit unions in Texas; standard deposit and loan surfaces.
• Texas Bay Credit Union — Houston-area; checking, savings and loan activity behind member login.
• Navy Federal — large national credit union; deposit, card and loan account data.
• PenFed Mobile — national credit union; balances, transfers and loan servicing data.

Screens from the app

How this brief was put together

Checked in May 2026 against the Members Choice mobile and online banking pages, the app's App Store listing, and the CFPB's current rulemaking and FDX recognition material. Sources opened: Members Choice mobile banking, MCCU Houston TX on the App Store, CFPB Section 1033 reconsideration, and CFPB recognition of FDX as a standards body.

Mapping reviewed 2026-05-18 by the OpenBanking Studio integration desk.

Questions integrators ask about MCCU Houston TX

The app lets members connect accounts from other institutions. Does that mean Members Choice exposes an aggregation API we can call?

That feature is inbound: it pulls a member's outside accounts into the Members Choice view using a consumer-permissioned aggregator path. An integration that needs Members Choice data works the member's own authenticated session instead, which is where the checking, savings, card, loan and aggregated balances all resolve.

Members Choice runs checking, business, mortgage, auto and credit-card accounts under one login. Does an integration cover all of them?

Yes. The account-list call returned after authentication enumerates every product tied to the member, including business sub-accounts and the externally aggregated ones. Transaction granularity differs by product, so we type each account in the normalized output rather than flattening a credit card into the same shape as a checking account.

How does the CFPB Section 1033 reconsideration change a Members Choice build right now?

It does not block the work. Members Choice is an NCUA-chartered credit union, so the operative path today is member-permissioned access through a consenting account, which stands on consumer authorization regardless of where the federal rule settles. We design the data model toward FDX-aligned fields so the same integration carries forward if a standardized sharing channel becomes the norm.

If Members Choice changes its digital banking front end, does the integration stop working?

A front-end or release change can move endpoint paths or response shapes. We account for that in maintenance: the auth and account calls are checked on a schedule, and the client code is patched before a break reaches a consumer of the feed.