Connecting third-party software to INOVA Federal Mobile member accounts

Behind a one-time-code login, INOVA Federal Mobile carries the working banking record for a roughly $663 million credit union out of Elkhart, Indiana — about 47,509 members, per the financial report at creditunionsonline.com dated September 30, 2025. The app itself states what it exposes once a member is in: balances, fund transfers, bill pay, mobile check deposit, and card controls. That is the surface an integrator actually wants, and it lives behind a member session. The work here is reaching that session under the account owner's authorization and turning what the app reads into something a program can consume.

The honest bottom line: this is a single-institution mobile banking app whose value is the per-member ledger. We treat it as a protocol-analysis job. One consenting member account is enough to map the session bootstrap, the account list, and the statement read, and from there the integration is deterministic. Where a downstream system only needs balances and transactions, a consumer-permissioned aggregation path can stand in front of that same data; we say below where each route earns its place.

What sits behind the INOVA member login

Each row below is a surface the app itself presents to a signed-in member. The granularity column is what a single authenticated read returns in practice; the integrator-use column is what teams typically build on it.

Zelle send/receive records ride alongside the transfer module and reconcile the same way as A2A movement. The deposit-account and savings-rate products the credit union markets publicly are not member-specific and are out of scope for an integration; the value here is strictly the authenticated ledger.

Authorized paths into the member data

Three routes genuinely apply. We recommend the first as the spine for anything that needs the full surface, and treat the others as the right tool for narrower jobs.

Protocol analysis of the member app, under the owner's authorization

We observe and document the traffic the app exchanges after a member signs in — the enrollment and one-time-code step, the session token it carries, the account-list call, the activity and statement reads. This reaches every surface in the table, including card controls and bill pay, because it follows exactly what the app does. Effort is moderate and front-loaded into the first mapping. Durability is good with a maintenance pass watching the member portal's release cadence. Access is arranged with you during onboarding: the build runs against a sponsoring member account or owner-authorized credentials, and that arrangement is part of the engagement, not something you hand over before we start.

Consumer-permissioned aggregation

Where a product only needs balances and transactions, the member can authorize a US data-aggregation path (the Financial Data Exchange model that aggregators such as MX and Finicity operate, with known mid-sized credit-union coverage). This is lighter to stand up and durable, but it is narrower — card controls, deposit events and bill-pay detail are typically out of its reach. We wire it where the product surface is genuinely balance-and-transaction only.

Native e-statement export

The app's e-statements give a clean, member-authorized backfill for history that predates a live connection. It is a supplement, not a primary feed: monthly cadence, document-shaped, useful for audit and lending pulls. We use it to seed history so a new integration is not blank on day one.

A look at the session and statement calls

The shape below is illustrative and reflects the member flow the app describes; exact field names and the token mechanism are confirmed during the build against a consenting account, not assumed here.

# 1. Enrollment / step-up: member completes a one-time code (SMS | voice | email)
POST /auth/otp/verify
  { "username": "<member>", "otp": "<6-digit>", "channel": "sms" }
  -> 200 { "session": "<opaque-token>", "expires_in": 900,
           "refresh": "<refresh-token>" }
  -> 401 { "error": "otp_expired" }       # re-issue code, do not retry blind

# 2. Account list for the signed-in member
GET /accounts            Authorization: Bearer <session>
  -> 200 { "accounts": [
       { "id": "S0", "type": "share",  "name": "Regular Savings",
         "available": 1840.55, "current": 1840.55 },
       { "id": "C1", "type": "checking", "available": 612.08 } ] }

# 3. Posted + pending activity, paged
GET /accounts/C1/activity?from=2026-04-01&to=2026-05-18&cursor=
  -> 200 { "txns": [
       { "posted": "2026-05-15", "amount": -42.10,
         "status": "posted",  "desc": "ACH DEBIT ..." },
       { "posted": null, "amount": -18.00,
         "status": "pending", "desc": "CARD AUTH ..." } ],
     "next_cursor": "<opaque>" }

# Session refresh; on hard expiry the member re-runs the one-time code
POST /auth/session/refresh   { "refresh": "<refresh-token>" }

The handling that matters in real use is around the one-time code and pending-to-posted drift, not the happy path. Both are addressed in the engineering notes.

What lands in your repository

Concrete artifacts, tied to the surfaces above:

• An OpenAPI specification covering the session bootstrap, account list, activity, e-statement and (where in scope) transfer and bill-pay calls as they behave for an INOVA member.
• A protocol and auth-flow report: the one-time-code enrollment, the session/refresh token chain, expiry behavior, and the re-auth trigger conditions.
• Runnable source for the key reads — Python or Node.js — that signs in a consenting member, pages activity, and emits a normalized account-and-transaction schema.
• Automated tests against recorded fixtures, including the OTP-expired and pending-to-posted cases.
• Interface documentation plus data-retention and consent-logging guidance scoped to a federal-credit-union member relationship.

Member consent and the data-rights picture for a federal credit union

INOVA is an NCUA-chartered federal credit union, so the operative consent is the member's own authorization to access their account, governed by the credit union's online-banking terms and the financial-privacy expectations that already apply to it. No active US rule currently requires a credit union of INOVA's size to provide this access on a regulated basis: the federal personal-financial-data-rights rule under Dodd-Frank section 1033 that would reach an institution of its size is, as of this writing, enjoined and back in CFPB rulemaking (the Bureau's Personal Financial Data Rights Reconsideration). We do not assert its phased timetable as settled, precisely because it is not. What that means in practice is unchanged: the route is access the account owner consents to. Consent is explicit and scoped to named surfaces, revocable by the member, and time-bound; access is logged with a consent record, data is minimized to what the product needs, and an NDA covers the engagement where you require one. That posture is how the studio operates, not a gate the reader has to clear first.

Engineering realities we plan around for this build

Three things specific to this app shape the work, and we handle each on our side.

• One-time-code step-up. Enrollment and risk-triggered step-up send a code over SMS, voice, or email. We design the session bootstrap so the consenting member supplies that code once, hold a refreshable session, and build an explicit re-authentication path for when the credit union's risk engine forces a new code mid-stream — so the feed does not silently stall.
• Read surfaces vs. money movement. Transfers, bill pay, and Zelle are write-capable sub-rails behind the same login as the read-only ledger. We scope the integration to the surfaces you ask for and leave the payment-initiation paths untouched unless moving money is explicitly part of the engagement.
• Member-portal release cadence. The signed-in front end changes on the digital-banking vendor's schedule. We add a monitored re-validation step to maintenance so the parser is corrected before a layout or field change drifts the feed, rather than after a customer notices.

Keeping the feed accurate after launch

Balances and activity move intraday; a transaction can appear pending and re-settle as posted with a changed amount or date. The delivered code reconciles pending against posted on the natural key rather than appending duplicates, and the polling cadence is set to the member's tolerance against the institution's observed rate behavior — frequent enough to be current, restrained enough not to trip step-up. e-Statements update monthly and are treated as the source of truth for closed periods.

Screens we mapped

Store screenshots used while mapping the member flow. Select to enlarge.

Other credit-union and banking apps in the same conversation

Teams asking for an INOVA connection usually run the same product against several institutions. These are real same-category apps; named here only to show how a unified feed spans them, with no ranking implied.

• Alliant Credit Union — large digital-first credit union whose app holds member balances, transactions, and a balance-preview surface that maps to the same normalized schema.
• Navy Federal Credit Union — the largest US credit union; member accounts, transfers and card data behind a comparable authenticated app session.
• PenFed (Pentagon Federal Credit Union) — national membership with checking, savings and loan ledgers reachable on the same consent model.
• Delta Community Credit Union — Georgia's largest credit union; balances and posted/pending activity that reconcile like INOVA's.
• ESL Federal Credit Union — Rochester, New York institution with member statements and transfer records in the same shape.
• Bethpage Federal Credit Union — sizeable Northeast credit union; account and bill-pay data behind a member login.
• Alternatives Federal Credit Union — community credit union whose mobile app exposes the same balance and transaction surface.
• Ally Bank — branchless bank with deposit and transaction data commonly aggregated alongside credit-union accounts in one feed.

Questions integrators ask about INOVA Federal Mobile

Does INOVA's one-time-code login block an automated integration?

No. Enrollment and step-up at INOVA send a one-time code over SMS, voice call, or email. The consenting member completes that code once during onboarding; the integration then holds a refreshable session and follows a defined re-authentication path when the credit union's risk engine forces a fresh code.

Can you separate read-only statement data from money-movement endpoints like Zelle and transfers?

Yes. We scope the build to the surfaces you ask for. A reporting or bookkeeping use case stays on the balance, transaction, and e-statement reads and never touches the transfer, bill-pay, or Zelle write paths unless initiating payments is explicitly part of the engagement.

Is there a US open-banking rule that already forces INOVA to expose this data?

Not in a way you can rely on today. The federal personal-financial-data-rights rule under Dodd-Frank section 1033 that would reach an institution of INOVA's size is currently enjoined and back in CFPB rulemaking, so the dependable route is access the member consents to, not a mandated credit-union API.

We run payroll and a PFM feature for INOVA members and want a unified feed. Where would you start?

Balances and posted transactions first, since those carry the most product value and the lowest risk surface, then e-statements for backfill. Send the member-facing flow you are building to /contact.html and we will map the rest around it.

Sources and review for this INOVA mapping

This brief was put together in May 2026 from the credit union's own digital-banking and mobile-banking material, its public financial profile, and the current federal data-rights record. Primary sources opened: INOVA digital-banking overview, INOVA mobile-banking FAQ (PDF), INOVA financial performance report, and the CFPB Personal Financial Data Rights Reconsideration.

Mapping by the OpenBanking Studio integration desk · May 2026.

Source for the INOVA session bootstrap, the account-list and activity reads, and a normalized account-and-transaction schema arrives in your repository inside one to two weeks; you pay from $300 on delivery, and only once it runs against a consenting member account to your satisfaction. If you would rather not host it, the same calls are available as a metered hosted API billed per call with nothing upfront. Tell us the surfaces you need and the product you are building at openbankingstudio.com/contact, and we handle access, authorization and compliance with you as part of the work — you bring the app name and the requirement.