Member-consented access to SHPFCU To Go! accounts

State Highway Patrol Federal Credit Union runs SHPFCU To Go! on the FLEXcutech mobile core, serving roughly 5,973 members from a single Columbus, Ohio branch (per its NCUA call report, charter 13432). For a member, the app is the front door to everything the credit union holds: share and share-draft balances, certificate and loan positions, a running transaction history, internal transfers, bill pay, and check deposits captured from the phone camera. All of that lives server-side behind an authenticated session. The integration question is narrow and answerable: how to read those records, on a member's behalf, in a form another system can consume.

The route we would take here is interface integration over the app's own authenticated traffic, scoped to a consenting member account. The FLEXcutech backend speaks a consistent protocol across the credit unions that license it, which makes the session and request shapes predictable; what stays SHPFCU-specific is the tenant routing and the account-suffix scheme. That combination is what we deliver against.

What a member account actually holds

These are the surfaces named the way SHPFCU and the app present them, with what an integrator would do once the records are normalized.

Routes to the data

Member-consented interface integration

This is the route we would build on. With a member's authorization, we map the authenticated session the app uses against the FLEXcutech backend, then implement the calls that return balances, history and transfer results as clean endpoints. Reachable: the full per-account picture a member sees in the app. Effort: moderate, because the protocol is shared across the cmcflex.ftmobile family and the patterns repeat. Durability: good, with a re-validation pass when the credit union updates the app. We arrange the consenting account and any sandbox access with you during onboarding.

Regulated open-banking consent (forward-looking)

For a US credit union, member-permissioned data sharing is the direction the CFPB's Personal Financial Data Rights rule points toward. We track it, and where a standardized member-consent channel becomes available for an institution this size, we can build to it. Today it is a future option rather than the working path, so we do not design the integration to depend on it.

Native export as a fallback

Where a member can export their own statement or transaction file, that file is a low-effort supplement — useful for backfill or one-time reconciliation, weaker for anything real-time. We treat it as a top-up to the live integration, not a substitute.

Given the data shape and the shared platform, the consented interface route is the one worth building. It returns the same records the member sees, updates in near real time, and reuses protocol knowledge that already covers dozens of sibling credit-union apps — so the recommendation here is to put the live integration first and keep export only for historical fill-in.

Session flow we would implement

Illustrative shape of the authenticated balance read, with field names confirmed during the build rather than assumed up front. Auth on the FLEXcutech core is a member login that yields a session token; account reads carry that token and a member/account selector.

# 1. Establish the member session (token confirmed during the build)
POST /ftmobile/auth/session
  { "institution": "sth", "member": "<member-no>", "secret": "<consented>" }
-> 200 { "sessionToken": "…", "expiresIn": 900, "accounts": ["S0","S70","L01"] }

# 2. Read balances per share-suffix
GET /ftmobile/accounts/balances
  Authorization: Session <sessionToken>
-> 200 { "S0":  {"type":"share",       "available": 1840.22, "current": 1840.22},
         "S70": {"type":"certificate", "available": 5000.00, "current": 5102.41},
         "L01": {"type":"loan",        "balance":  -7421.18, "nextDue":"2026-07-01"} }

# 3. Pull posted history, then reconcile shared-branch entries
GET /ftmobile/accounts/S0/history?since=2026-05-01
-> 200 { "postings": [ {"date":"2026-05-30","amt":-42.10,"desc":"SHARED BRANCH WD","src":"network"}, … ] }

# Error handling: 401 -> silent session expiry, re-auth within the consent window;
# network-sourced postings are de-duplicated against the home ledger before export.
      

What lands at the end

Each deliverable is tied to the surfaces above, not a generic checklist.

• An OpenAPI specification covering the balance, history, transfer and deposit-status endpoints as they apply to SHPFCU's account scheme.
• A protocol and auth-flow report documenting the FLEXcutech session token, its lifetime, the re-auth path on expiry, and how member/account selectors are passed.
• Runnable source for the key reads (Python or Node.js), including the share-suffix mapping and the shared-branch de-duplication step.
• Automated tests against a consenting account or sandbox, covering session expiry and the multi-account balance read.
• Interface documentation plus data-retention and consent-logging guidance written for an NCUA-supervised institution.

Consent and the NCUA frame

The basis we rely on is the member's own authorization over their accounts — the same authority that lets them log into SHPFCU To Go! in the first place. State Highway Patrol FCU is federally chartered and supervised by the National Credit Union Administration, with deposits insured; we run the work to match that posture: access is authorized and logged, data pulled is minimized to what the integration needs, consent records are kept, and an NDA is in place where the engagement calls for one. Consent is treated as time-bound and revocable, and the sync is built to respect that window.

The CFPB's Personal Financial Data Rights rule, Section 1033, is the piece people ask about for US accounts. As of this writing it is not in force — enforcement is enjoined and the rule is back with the agency for reconsideration — so it is where member-permissioned access may go, not the law the build leans on today. We design to member consent now and follow the rule's progress.

Engineering notes specific to this app

Two things shape the SHPFCU build in particular, and we handle both rather than passing them to you.

• Shared white-label core, single-tenant data. SHPFCU To Go! is one instance of the com.cmcflex.ftmobile codebase that many credit unions license, so the request and token shapes are familiar. We pin the build to SHPFCU's tenant routing and to its own share-suffix codes (shares, share drafts, certificates, loans), because an account labeled "S70" here is not the same as on another credit union's instance.
• Shared-branching reconciliation. Some postings arrive through the shared-branch network rather than a home-branch transaction. We reconcile those against the home-account ledger so a single withdrawal made at another credit union's counter is not counted twice when the feed is normalized.
• Remote-deposit lifecycle. Check deposits captured in the app move through submission, acceptance and hold states. We model those states so a downstream system reads accurate funds-availability rather than treating a pending deposit as settled.

Access for any of this — a consenting member account or a sponsor sandbox — is arranged with you as part of onboarding. None of it is something you need to have ready before we begin.

Working with us

The first read against a consenting SHPFCU account usually returns within the first few days of a one-to-two-week build. From there, two ways to pay. You can take source-code delivery from $300 — runnable API source plus the spec, the protocol report, tests and documentation — and you pay after delivery, once you have it in hand and it works. Or you can skip the build entirely and call our hosted endpoints, paying only for the calls you make, with no upfront fee. Either way you hand us the app name and what you need from its data; the access, consent and compliance steps are arranged together with you. To start or to ask a question, get in touch here.

Where this gets used

• A personal-finance app that wants a member's SHPFCU balances and transactions alongside their other institutions, refreshed daily.
• A bookkeeping tool pulling categorized share-draft activity for a member who runs a small operation through the account.
• A lending or underwriting flow reading consented balance and loan-position data directly rather than via screenshots.
• An internal credit-union dashboard that needs the same data the app shows, exposed as a clean API for a partner integration.

Screens we worked from

How this was checked

Drawn from the app's own Play Store listing, the credit union's site, the NCUA call-report record for charter 13432, the FLEXcutech platform page, and the CFPB's open-banking rulemaking page, reviewed June 2026. Mapped by the OpenBanking Studio integration desk.

• SHPFCU To Go! on Google Play
• State Highway Patrol FCU NCUA call report (charter 13432)
• FLEXcutech core and digital banking platform
• CFPB Personal Financial Data Rights (Section 1033)

Other apps on the same playing field

Several credit unions ship on the same FLEXcutech white-label core or sit in the same member-banking category, which is why a unified integration generalizes well across them. Named for context, not ranked.

• ANG Federal Credit Union — member balances and transfers on the same cmcflex.ftmobile core.
• Foothills CU Mobile Banking — share and loan account data with remote deposit.
• Freedom CU (UT) Mobile Banking — deposits, bill pay and transfers for its members.
• Alliance CU Mobile Banking — 24/7 account access on the shared platform.
• Money One FCU Mobile — account and transaction history for its membership.
• MPD Community Credit Union — member account management on the same core.
• Moonlight Federal Credit Union — balances and transfers for a small federal charter.
• Connect CU Mobile — share-account data and mobile deposit.
• Serve Credit Union Mobile — member balances, history and transfers.

Questions an integrator asks first

Which account types does SHPFCU To Go! expose, and do they map cleanly?

The app covers shares, share drafts, certificates and loans under one member number, as its listing describes. Those share-suffix codes are how State Highway Patrol FCU structures accounts internally, so part of the build is mapping each suffix to a stable account identifier and a type label before any feed leaves the system.

How are shared-branching transactions handled in the data feed?

SHPFCU participates in shared branching, so some postings originate at other credit unions' branches and arrive through the network. We reconcile those against the home-account ledger so a single transaction is not represented twice when the feed is normalized.

The app runs on the FLEXcutech white-label core. Does that change the integration?

It helps. SHPFCU To Go! shares the com.cmcflex.ftmobile codebase with many other credit unions, so the request and token shapes are consistent across that family. We still pin the build to SHPFCU's own tenant routing and credentials, because the data and account scheme are specific to this credit union.

What is the legal basis for pulling a member's data here?

The dependable basis is the member's own authorization over their accounts. SHPFCU is federally chartered and NCUA-supervised; data-minimized, logged, consent-bound access is how we run the work. The CFPB Personal Financial Data Rights rule (Section 1033) may formalize this later, but it is not in force today, so the build does not lean on it.