Reaching account data inside the Tennessee Military FCU mobile app

Tennessee Military FCU — the same institution as East Tennessee Military Association FCU, reachable through two member sites — keeps the full retail-banking record set behind a single member-authenticated session. The Play listing identifies the Android build as net.etmafcu.etmafcu; an iOS build is listed on the App Store. The credit union states its savings are federally insured by the NCUA to at least $250,000. None of that data is browsable without a member login, which sets the route: the dependable way in is the member authorizing access to their own session, and we build the integration around that session rather than around any open feed.

What member data the app actually holds

The mobile app and the credit union's digital-tools page describe a conventional but complete retail dataset. Mapped to what an integrator would actually consume:

The useful subtlety here is that the account summary mixes record types. Certificates carry maturity dates; loans carry due dates and payment amounts; cards carry limits. A naive scrape flattens all of it into one "balance" number. The value of a proper integration is keeping those types distinct.

Getting to that data: the authorized routes

Three routes apply to this credit union. We would recommend the first as the backbone and treat the others as fallback or fast-path.

1 — Member-consented session access

The member authorizes access to their own banking session, the same way they would when linking the account to a budgeting or accounting tool. This is the route with the firmest legal footing in the US today, it reaches every screen the member sees, and it survives because it rides the member relationship rather than a vendor arrangement. Onboarding — the consenting account, the credential method, the scope — is set up with you during the engagement.

2 — Authorized interface integration and protocol analysis

We capture and document the traffic between the app and its banking backend under the customer's authorization, then rebuild the request/response and auth chain as clean, callable code. This is how the summary, transaction, and card-control surfaces become an API rather than a screen. Effort is moderate; durability depends on the platform front end, which we address in the engineering notes below.

3 — Native export as a fallback

Credit-union digital banking of this kind commonly offers statement and transaction download (PDF statements, and OFX/QFX or CSV transaction files). Where that exists for this member portal it is a low-effort fallback for history backfill, though it does not cover live balances, card controls, or transfers. We confirm the exact export formats during the build rather than assume them.

Recommendation in plain terms: build on the member-consented session, normalize it through the protocol work so the output is a stable API, and keep export wired only as a backfill path. That combination is what holds up when the front end shifts.

What you get from us

Everything below is scoped to this app's real surfaces, not a generic checklist:

• An OpenAPI/Swagger specification covering account summary, transaction history, loan/card snapshot, transfers, bill pay, and card controls as discrete typed endpoints.
• A protocol and auth-flow report documenting the login, token/cookie chain, and session refresh as the app actually performs it, including the biometric and PIN sign-in paths.
• Runnable source for the key endpoints in Python and Node.js — authentication, balance and transaction pulls, and the certificate/loan record types kept separate.
• Automated tests against the documented surfaces, including session-expiry and re-auth handling.
• Interface documentation a developer can hand to a new engineer and have them productive without re-deriving the flow.
• Compliance and data-retention guidance: what is logged, what consent record is kept, and how data is minimized to the integration's purpose.

A look at the session and statement flow

Illustrative pseudo-code for the backbone — the shape, field names, and host pattern reflect what surfaces during the build for a portal of this kind; exact values are confirmed against the consenting account, not asserted here.

# 1. Establish the member-consented session
POST  {digital_banking_host}/auth/login
  body: { username, secret, device_id }
  note: app also offers PIN / fingerprint / Face ID /
        voice as the member's chosen method — handled
        as a step-up, not a static password assumption
-> 200 { session_token, refresh_token, mfa_state }

# 2. Pull the typed account summary (do NOT flatten)
GET   {digital_banking_host}/accounts/summary
  auth: Bearer session_token
-> 200 {
     shares:       [ { id, name, available, current } ],
     checking:     [ { id, available, current } ],
     certificates: [ { id, balance, maturity_date, rate } ],
     loans:        [ { id, balance, due_date, payment_amount } ],
     cards:        [ { id, last4, status, limit } ]
   }

# 3. Transaction history per account
GET   {digital_banking_host}/accounts/{id}/transactions?from&to
  auth: Bearer session_token
-> 200 { items: [ { date, description, amount, status, type } ],
         paging: { next_cursor } }

# Error handling that matters here:
#  401 -> refresh_token flow, then one retry
#  401 again or mfa_state=required -> surface re-consent,
#       never silently loop a stale session

Who regulates this and what consent we rely on

Tennessee Military FCU is a federally chartered credit union; the NCUA charters and insures it, and the credit union states share insurance to at least $250,000. Its specific NCUA charter number is not publicly disclosed and is not asserted here. The integration's legal basis is not a regulator-mandated feed — it is the member's own authorization to access and share their own financial data, recorded and revocable.

The CFPB's Personal Financial Data Rights rule under Section 1033 is the forward-looking piece, not current law. It was issued, then enjoined by the U.S. District Court for the Eastern District of Kentucky, and the CFPB has reopened it for reconsideration (advance notice docket CFPB-2025-0037, August 2025). We treat §1033 as where US data-sharing may eventually go, not as something this integration rides today; for a credit union of this size, any phased obligations — if a rule resumes at all — would not be early-wave. What the feed depends on now is consent scope, an expiry the member controls, prompt revocation handling, and data minimized to the integration's purpose.

Engineering details we account for

Specific to this app, these are the things we design around rather than discover late:

• Third-party banking host. The member-facing front end is served from an external digital-banking host (a financial-net.com endpoint surfaced during the build); the platform brand is not publicly disclosed and is not asserted here. We pin the session and token chain to that host and keep a lightweight monitor that flags captured-flow drift the moment the platform's front end shifts, so a break is caught in maintenance and not by the member.
• Mixed record types in one summary. Share/savings, checking, certificates, loans, and cards arrive together. We model them as distinct types up front so a certificate maturity date or a loan payment amount never collapses into a generic balance.
• Member-chosen authentication. Sign-in offers PIN, voice recognition, fingerprint, and facial recognition. We build the integration around the member-consented session and the credential method actually in use, and put step-up/biometric re-auth into the token-refresh design rather than assuming a fixed password session.
• One institution, two front doors. tmfcu.net and etmafcu.net are the same credit union; we treat it as a single integration target so the work is not duplicated across the two member sites.

How teams put this feed to use

• A PFM or budgeting product that lets a member link their Tennessee Military FCU accounts and see balances and categorized transactions alongside other institutions.
• An accounting or bookkeeping tool pulling transaction history for members who run a small business through the credit union, with the certificate/loan records kept separate for accurate liability reporting.
• A debt-tracking or financial-wellness app reading the loan and card snapshot — balance, due date, payment amount — to drive reminders and payoff projections.
• An internal treasury or reconciliation job that, under member consent, captures transfers and bill-pay events as ledger entries instead of manual re-keying.

App screens we mapped

Public store screenshots used while mapping the surfaces above. Select to enlarge.

Other military and credit-union banking apps in scope

Same category, named for context — ecosystem framing, not a ranking. Each holds a comparable per-member dataset that a unified integration would normalize the same way:

• Navy Federal Credit Union — large military credit union; balances, transactions, transfers, cards behind a member login.
• PenFed Credit Union — Pentagon Federal; checking, savings, loans and card data per member account.
• USAA Mobile — banking, lending and card records for military families behind authenticated access.
• Security Service Federal Credit Union — retail accounts, transfers and card controls in a member app.
• Andrews Federal Credit Union — military and government members in the US and overseas; standard retail dataset.
• Service Credit Union — military-affiliated; accounts, loans and payment data per member.
• Tennessee Valley Federal Credit Union — regional Tennessee credit union with the same balance/transaction surfaces.
• Tinker Federal Credit Union — large federal credit union; account, loan and card records behind member auth.

Questions integrators ask about this one

The app shows certificate maturity dates and loan snapshots, not just a checking balance — do those come through?

Yes. We model share/savings, checking, certificate and loan/card records as separate types from the start, so a certificate maturity date or a loan due date does not collapse into a generic balance field on the way out.

Tennessee Military FCU and ETMA Federal Credit Union look like the same place — does that split the work?

It is one institution behind two member sites (tmfcu.net and etmafcu.net), and the Android package is net.etmafcu.etmafcu per the Play listing. Same member session, same digital-banking host, so it is a single integration, not two.

The federal open-banking rule is not enforceable right now — what is the integration actually built on?

The member's own authorization to access and share their data. CFPB Section 1033 is the forward-looking piece, currently enjoined and back in agency reconsideration; it is not what the feed depends on today, and a credit union this size would not be in any first wave even if a rule resumes.

Does the build run against a live member account or a test one?

Access is arranged with you during onboarding. The build runs against a consenting member account or a sponsor test account, with calls logged and data minimized to what the integration needs.

How this mapping was done

Checked in May 2026 against the app's public store listings, the credit union's own digital-tools description, and the current US data-rights status. Primary sources opened:

• TN Military FCU on the Apple App Store
• ETMA Federal Credit Union (net.etmafcu.etmafcu) on Google Play
• Tennessee Military FCU — digital tools and mobile features
• CFPB — Personal Financial Data Rights reconsideration

OpenBanking Studio integration desk · mapping reviewed May 2026.

A finished Tennessee Military FCU integration is a typed account-summary and transaction API with runnable Python and Node.js source, delivered in one to two weeks. You can take it as source-code delivery from $300, paid only after delivery once you have it working and are satisfied; or use it as a hosted, pay-per-call API with no upfront fee and billing only for the calls you make. You give us the app name and what you need from its data — access, the consenting account, and any compliance paperwork are arranged with you as part of the engagement. Start the conversation at /contact.html.