Member-authorized integration for Sovita Credit Union Mobile

The data, and the cadence question

Sovita Credit Union runs roughly $515 million in assets out of Flint, Michigan, per the 2024 announcement of its core move to Member Driven Technologies. The mobile app is where a member sees every balance, posted transaction, statement and scheduled transfer. For a third party that wants that data on a schedule, the real question is not whether the data exists — it is cadence. How often do you poll the member's session, how do you remember what you already pulled, and how do you stop a pending charge from being counted twice once it settles. That last one trips up most naive pulls.

The route we would actually run is a member-authorized poll of the app's own traffic, mapped by protocol analysis, with a stored cursor per account and posted-versus-pending handling built in. Access to a consenting member account is arranged with you during onboarding; the build then runs against that live session. Everything below is scoped to Sovita's real surfaces, not a generic banking template.

What the app holds, account by account

The feature set comes from Sovita's own store listing and digital-banking guide. Each row is a surface an integrator can reach once a member consents.

Authorized ways in

Member-authorized protocol analysis (recommended)

With a consenting member, we observe and map the app's own request and response traffic, then rebuild it as a clean client. This reaches everything the member sees: balances, the full transaction stream including the member-added tags and notes, transfers, bill pay, statements and deposit status. Effort is moderate; the token and cookie chain takes the most care. Durability is good as long as we re-pin on the upcoming Banno migration — which we plan for rather than react to.

User-consented credential access

Where a workflow prefers an aggregation-style consent handshake, we wire the member-permissioned flow and normalize what comes back to the same shape as the protocol route. This trades some breadth for a cleaner consent record. We set up the consent capture and revocation handling as part of the engagement.

Native export as a fallback

Statements and transaction exports the member can pull themselves cover historical backfill when a live feed is not yet needed. Useful for a one-time load; thin for anything ongoing. We treat it as the seed for the delta poll, not the destination.

A delta poll against the transaction feed

Illustrative shape of the poll worker, confirmed against a consenting member session during the build. Field names settle once we map the live traffic; the cursor and posted-versus-pending logic are the parts that matter.

# Delta poll. Auth: bearer token from the app's login/refresh exchange
# (the full cookie + token chain is mapped per build).

GET /members/{member_id}/accounts/{account_id}/transactions?since=CURSOR&limit=100
Authorization: Bearer SESSION_TOKEN
Accept: application/json

200 OK
{
  "account_id": "sav-0921",
  "next_cursor": "tx_2026-06-14T19:02:11Z_88421",
  "transactions": [
    {
      "id": "88421",
      "posted_at": "2026-06-14T18:55:02Z",
      "status": "posted",            # posted | pending
      "amount": -42.17,
      "running_balance": 1380.55,
      "description": "BILL PAY - DTE ENERGY",
      "tags": ["utilities"],         # member-added enrichment, not core ledger
      "note": "june bill",
      "receipt_image": null
    }
  ]
}

# 401 -> run the token refresh, replay the same `since` cursor.
# Pending rows are held in a side table and matched on settle by id,
# so a charge that later posts is not read as two transactions.
      

The shape we normalize to

Whatever the live app returns, you receive one stable schema across every member and account, so your code does not care which Sovita surface a field came from.

{
  "account":     { "id": "sav-0921", "type": "savings", "currency": "USD", "balance": 1380.55 },
  "transaction": {
    "id": "88421",
    "account_id": "sav-0921",
    "posted_at": "2026-06-14T18:55:02Z",
    "amount": { "value": -42.17, "currency": "USD" },
    "direction": "debit",
    "channel": "bill_pay",
    "enrichment": { "tags": ["utilities"], "note": "june bill", "receipt": null }
  }
}
      

What you get

The headline deliverable is code that runs, not paperwork. For Sovita that means:

• Runnable source in Python or Node.js: the auth and token-refresh client, the delta-poll worker, and helpers for the deposit-status, statement and bill-pay surfaces.
• A poll-and-reconcile worker that carries the per-account cursor and the pending-to-posted match, ready to drop into your scheduler.
• An automated test suite covering the auth refresh, an empty-delta poll, a paged poll and a pending-then-posted transition, with fixtures you can run against a sandbox session.
• An OpenAPI / Swagger description of the mapped surfaces, kept as a secondary artifact for your own docs.
• A protocol and auth-flow write-up: the cookie and token chain, refresh timing, and where the enrichment fields attach.
• Interface documentation plus short data-retention and consent-logging guidance scoped to a US credit union member's data.

Member consent and where US data rights stand

For a Sovita member's data, the basis we rely on is the member's own authorization. A US member can consent to share their financial data; that consent — scoped to the accounts and fields you actually need, logged, and revocable — is what the integration runs on, and it is the part we keep airtight. Receipt and check images stay minimized to what the member authorizes.

The federal open-banking rule under Section 1033 is not a foundation you can build on today. A court has enjoined the CFPB from enforcing it, and the Bureau has reopened it for reconsideration. We treat it as the direction US data sharing may move, not as current law, and we do not design the Sovita integration as if those obligations were in force. Where work touches member records we operate under NDA, with data minimization and an access log as standard.

What we account for on a Banno-backed credit union

Two things about Sovita specifically shape the build, and we handle both rather than hand them to you.

The core-and-digital migration. Sovita announced a move to Member Driven Technologies hosting Jack Henry's Symitar core and the Banno digital platform. That means the endpoint surface a member's session hits is changing as the rollout proceeds. We map whatever the live session actually reaches and pin the integration there, then re-map the affected calls when a member is moved over — so a platform change is a small maintenance task, not a rebuild.

Member enrichment versus the core ledger. The app lets members attach tags, notes and photos of receipts and checks to transactions. Those are member-generated, not core ledger fields, so they can lag or be absent. We treat enrichment as its own surface and reconcile each item back to its transaction by id, which keeps your ledger clean while still surfacing the extra context where it exists. Bill pay also splits between company payees and person-to-person recipients, which carry different identifiers downstream; we model the two distinctly rather than flattening them.

Screens we worked from

Store screenshots used while mapping the surfaces above. Tap to enlarge.

Other Michigan member apps in the same integration picture

A single integration usually has to cover more than one credit union. These are real same-category Michigan apps an aggregator commonly maps alongside Sovita; names are listed for context, not ranked.

• Lake Trust Credit Union — statewide credit union whose app holds balances, transfers and transaction alerts for member accounts.
• Lake Michigan Credit Union — one of the state's largest, with mobile deposit, transfers and statement access per member.
• Dort Financial Credit Union — Flint-based like Sovita, holding member accounts, loans and bill-pay records.
• ELGA Credit Union — Genesee County member app covering balances, transfers and deposit capture.
• Genisys Credit Union — well-rated mobile banking with rewards-checking, transfers and account activity.
• Frankenmuth Credit Union — mobile deposit, online banking and account access for its members.
• University of Michigan Credit Union — member accounts, transfers and statements for the Ann Arbor community.
• Financial Plus Credit Union — another rebranded mid-Michigan credit union holding comparable member account data.

What integrators ask us about Sovita

Sovita is moving its core to Jack Henry Banno through MDT. Does that change what you can integrate?

It changes the endpoints, not the approach. We map whatever surface a consenting member's session actually reaches — the current org.sovitacu.grip build today, the Banno layer as it rolls in — and pin the integration to the live session. When Sovita moves a member over, we re-map the affected calls rather than rebuild from scratch.

How fresh is the data, and is it polled or pushed?

We run it as a delta poll: the worker asks for everything after a stored cursor, on a cadence we tune to how often the member's accounts actually change. Pending and posted transactions are tracked separately so a charge that later posts is not counted twice. If you need tighter freshness, we shorten the poll window; there is no fixed minimum we impose.

Can you capture the member-added tags, notes and receipt photos, or only the core ledger?

Both, kept separate. Tags, notes and receipt images are member-generated enrichment, not core ledger fields, so we treat them as their own surface and reconcile each one back to its transaction by id. Receipt-image pulls stay limited to what the member authorizes and nothing beyond it.

What is the legal basis for reaching a Sovita member's data today?

The member's own authorization. A US member can consent to share their financial data, and that consent — logged, scoped, revocable — is what the integration runs on. The federal open-banking rule under Section 1033 is currently enjoined and back under CFPB reconsideration, so we do not build as if it were in force; we treat it as where the rules may head, not today's basis.

Getting a Sovita build moving

A first working pull against a consenting Sovita member account is a one-to-two-week build. Take it as source you own outright — from $300, invoiced only after it is delivered and you have checked it — or skip the code and call our hosted endpoints, paying per call with nothing upfront. Either way you start the same: tell us it is Sovita Credit Union Mobile and what you need from its data on our contact page.

Start a Sovita integration

How this was put together

Checked in June 2026 against Sovita's own member-facing material and the public record. The app's feature list — balances, transactions, mobile check deposit, scheduled transfers, bill pay, statements, secure messaging — comes from its store listing. The core-and-digital direction, a 2024 move to Member Driven Technologies hosting Jack Henry's Symitar core and Banno digital platform, comes from the partnership announcement. The US data-rights status comes from the CFPB and trade-press coverage of the Section 1033 injunction.

• CUInsight — Sovita Credit Union partners with MDT
• ABA Banking Journal — court halts Section 1033 enforcement
• CFPB — Personal Financial Data Rights reconsideration
• Google Play — Sovita Credit Union Mobile listing

Written up by an OpenFinance Lab integration engineer; protocol-analysis notes dated 15 June 2026.