Reaching the accounts behind Embarrass Vermillion FCU's app

Behind the EVFCU login sits a FLEX core — the credit-union processing system CMC has run since 1978 and which, per FLEX's own company pages, now serves well over 250 credit unions across the US. The phone app, published under the package com.cmcflex.ftmobile.evf on its Play Store listing, is a thin client on CMC's shared FT Mobile platform. That single fact shapes everything downstream: the balances, the posted history, the check images you see in the app are read out of FLEX, and an integration that speaks to that core travels well beyond this one credit union.

What sits behind the member login

The app's store description is plain about its surfaces, and each maps to a record that originates in FLEX rather than on the device. The table below is the working map we'd start from.

Authorized ways into the data

Three routes genuinely apply here. They differ in reach and in how durable they are when the front end changes.

Member-consented client integration

A member authorizes access to their own account; we drive the same authenticated flow the FT Mobile app uses, with the session lifecycle documented. This reaches everything the member can see in the app — balances, history, images, transfer status. It is the richest path and, because FLEX is a stable shared core, durable across minor app releases. Access is arranged with you and the member during onboarding, against a consenting test account.

Protocol analysis of the app traffic

We observe and document the FT Mobile request and response shapes — auth handshake, account list, history paging, image fetch — and turn them into a clean spec plus runnable client code. This is what makes the first route reproducible and testable rather than a one-off. Effort here is front-loaded; maintenance is light because the core schema rarely moves.

Credentialed read-only aggregation

Where a member only needs balance and history sync into another tool, a read-only aggregation path (the model used by Plaid, MX and Finicity, and the kind of access NCUA guidance to credit unions addresses) is a lighter fallback. It is narrower than the client integration but quick to stand up.

For EVFCU we'd build the member-consented client flow first and document it as the contract, because it carries the check-image and transfer surfaces the aggregation path tends to drop; the read-only sync is worth keeping only when a project genuinely needs nothing past balances and history. Which one we lead with is a per-project call, not a fixed rule.

What you get

Deliverables are tied to the surfaces above, not a generic checklist:

• An OpenAPI / Swagger spec covering the auth handshake, account list, history paging, image fetch and transfer endpoints as observed.
• A protocol and auth-flow report: the FT Mobile session token chain, refresh behaviour, and how device identity factors in.
• Runnable source for the key endpoints in Python and Node.js — login, list suffixes, page history, resolve check images.
• A normalised account schema that keeps share suffixes, loan suffixes and available-versus-current balances distinct.
• Automated tests against a consenting account, including token-expiry and paging edge cases.
• Interface documentation plus data-retention and consent-logging guidance written for a US credit-union context.

A statement pull, sketched

Illustrative shapes only — exact field names are confirmed during the build, not taken from any published spec. The point is the flow: short-lived session token, suffix list, dated history with image references.

# Illustrative — field names verified during the build.
POST /ftmobile/auth/login          # FT Mobile session on the FLEX core
  { "member": "...", "pin": "...", "device_id": "..." }
  -> { "session_token": "...", "expires_in": 900 }

GET  /ftmobile/accounts             # share + loan suffixes together
  Authorization: Bearer <session_token>
  -> [ { "suffix": "S0001", "type": "share",
         "current": 1240.55, "available": 1180.55 },
       { "suffix": "L0007", "type": "loan",
         "current": -8420.00, "available": 0.00 } ]

GET  /ftmobile/accounts/S0001/history?from=2026-01-01
  -> [ { "posted": "2026-01-04", "amount": -52.10,
         "desc": "ACH WITHDRAWAL", "check_img": null },
       { "posted": "2026-01-06", "amount": -118.00,
         "desc": "DRAFT 8842", "check_img": "img/8842" } ]

# 401 on an expired token -> re-run login, retry once.
# History is paged; we follow the cursor, not a fixed page count.

Consent and the US data-rights picture

This is a US credit union, so the framing is American and it is unsettled. The dependable legal basis is the member's own authorization to reach their own account — consent we capture, scope and log, with the member able to revoke it. The CFPB's Section 1033 Personal Financial Data Rights rule is where US open banking may eventually go, but it is not current law: a federal court enjoined enforcement in late October 2025 and the CFPB has reopened the rule for reconsideration, so we do not build on it as a present-tense obligation. We design the consent model to stand on its own today and to absorb a revived 1033 later without a rewrite. Funds at the credit union are NCUA-insured per NCUA's standard $250,000 coverage; the integration touches data, not the insurance posture. Operationally: authorized access only, consent records retained, data minimised to what the project needs, and an NDA where the work touches anything sensitive.

Things the FLEX build has to get right

Two specifics carry most of the engineering judgment on this one.

First, the suffix model. FLEX hangs share and loan accounts off a single base member number, and the app lists them in one stack. We map each suffix with its type and its own available-versus-current balance, because code that treats the list as flat will happily net a loan balance against a savings share. That mapping is something we own in the schema, not a quirk we hand back to you.

Second, the shared-core upside and its catch. Because EVFCU runs the same FT Mobile platform as a row of other credit unions, one well-documented integration is most of the work for the next — we build it so the credit-union-specific bits (institution id, branding, suffix conventions) are configuration, not hard-coded. The catch is that a platform-wide FT Mobile release can shift response shapes for everyone at once, so we fold a re-validation step into maintenance that re-checks the captured contract after app updates. Access for all of this is arranged with you and a consenting member during onboarding, against a test account — it is a step we run, not a hurdle you clear first.

Screens from the app

Store screenshots, useful for orienting the interface map. Tap to enlarge.

Other credit-union apps in the same orbit

Names for context and keyword reach, not ranking. The first group shares EVFCU's FT Mobile / FLEX lineage, so an integration approach carries across them; the rest are how people aggregate credit-union data more broadly.

• Campco FCU — Wyoming credit-union app on the same CMC FT Mobile platform; balances, history, transfers, bill pay and loan payments.
• CFDCU Mobile — balances, transfers and branch/ATM lookup on the same shared core.
• Golden Valley Federal CU — anytime account access built on the FT Mobile framework.
• EP FCU — another FLEX-based credit-union client with the same member-account surfaces.
• Community Connect FCU — FT Mobile app holding per-member balances and posted history.
• Virginia Coop CU — FLEX-platform mobile banking with the same suffix-based account model.
• Alliant Credit Union — a large credit union whose app is commonly linked through aggregators like Plaid for read-only sync.
• Quicken Simplifi — a money-management app that pulls credit-union balances and transactions in via aggregation rather than holding them itself.

Sources and review

Checked on 6 June 2026 against the app's own listings and primary regulatory sources: the EVFCU Google Play listing for surfaces and package id, Embarrass Vermillion FCU's online-services page, the FLEX core-driven mobile app overview for the platform lineage, and the CFPB's own Personal Financial Data Rights reconsideration page for the 1033 status. Reviewed by the OpenBanking Studio integration desk, June 2026.

Questions integrators ask about EVFCU

Where does EVFCU keep the data, and what does that mean for an integration?

The app is a front end to CMC's FLEX core, the credit-union processing system behind the FT Mobile platform. So the balances, share and loan suffixes, posted history and check images all originate in FLEX, not in the phone. We model the integration against that core flow, which also means the same approach generalises to the other FLEX-based credit-union apps.

What is the legal basis for reaching a member's account at a US credit union?

The dependable basis is the member's own authorization to access their own data. The CFPB's Section 1033 Personal Financial Data Rights rule is where US open banking may eventually land, but it is not in force: a federal court enjoined enforcement in October 2025 and the rule is back in agency reconsideration. We build on member consent today and keep the design ready to track 1033 if it returns.

Can you separate share accounts from loan suffixes the way the app shows them?

Yes. FLEX organises a membership as a base member number with share and loan suffixes, and the app lists them together. Our normalised schema keeps the suffix, the account type and the available-versus-current balance distinct, so downstream code is not guessing which line is a savings share and which is an auto loan.

Do you handle the check-image surface, or just balances and history?

Both. Check images and mobile-deposit records are part of what the app exposes per its store description, so we map the image references alongside the transaction rows and document how they are fetched and how long they stay retrievable, rather than treating images as out of band.

Working with us

Tell us this is EVFCU, on the CMC FT Mobile platform, and what you want out of its data — we handle the route, the access arrangements with a consenting member, and the build. Source-code delivery starts at $300: the runnable client, the OpenAPI spec, the tests and the docs land in your repo, and you pay once it's delivered and you're satisfied. If you'd rather run nothing yourself, use our hosted endpoints on a pay-per-call basis with no upfront fee. Either path runs on a one-to-two-week cycle. Send what you need from EVFCU's accounts to /contact.html and we'll come back with a concrete scope.