Pulling Sovita Credit Union member data, with consent

Flint Teachers Credit Union opened in 1934. The same charter rebranded to Sovita Credit Union in 2020 (per CUToday's reporting on the name change), and the Sovita Credit Union Mobile app is the daily surface members touch — balances, transfers, mobile remote deposit, CheckFree-fronted bill pay, statements and secure messages, as the in-app description and the credit union's e-services pages describe them. The institution carries a Michigan state credit union charter; NCUA insures the shares. The package ID is org.sovitacu.grip per the Play Store listing.

An integrator's question is narrower than "does Sovita have a public feed." The question is: which member-facing surfaces does someone with a consenting member's authorization actually need to read or write, and how does the build stay alive across the next core or front-end refresh. The rest of this page is that scope, for one consuming team at a time.

One reading. Niche-FoM credit union, rich authenticated portal, a small enough institution that vendor stacks rotate. Our recommended route is authorized interface integration on the member's side, with the build modularized so CheckFree bill pay and RDC ship as independent surfaces. Two pages down is the table; everything in this brief points back to it.

Where the data sits

Each row is something a member sees in the app today, named the way the app and the credit union's e-services pages name it. None of this is hypothetical.

How we'd reach it

The routes that actually fit Sovita are three. Each is run with the member's written authorization in hand; access and any sponsor sandbox are arranged with you during onboarding, not left as homework.

Authorized interface integration (recommended)

We treat the mobile and web client as the documented surface and reverse-engineer the request shape, auth ceremony and token lifecycle a consenting member's session uses, then implement that as a stable client library on your side. Reachable: every surface in the table above. Effort: moderate, concentrated in the auth flow and the bill-pay handoff. Durability: medium — credit unions of this size periodically refresh the digital-banking vendor, so the maintenance plan keeps a check live that fires the first time a host, header set or schema drifts. This is what we'd pick for Sovita.

Member-consented credential access

Lighter scope. A consenting member supplies credentials (or signs into a session our flow brokers); we mirror statements, transactions and bill-pay history into your system on a schedule. Reachable: read-only surfaces, plus statement downloads. Effort: low. Durability: low to medium — multi-factor prompts and risk-engine challenges are the failure mode, and we account for them rather than design around them.

Native export

For teams that only need statements and a periodic transaction file, the in-app statement download is enough. We package it as a watcher and a normalizer so a human is not in the loop. Reachable: PDF statements; transaction CSV where the portal exposes one. Effort: minimal. Durability: high while the export endpoints stay put.

For anything used more than monthly, route 1 is the build we propose; native export stays in the box as a backstop when a credential session fails to renew.

What ships at handover

• An OpenAPI 3.1 specification covering the Sovita surfaces in scope, written to the shape the member-side client actually exchanges — not a guess.
• A protocol & auth-flow report: how sign-in, MFA, session refresh, and the CheckFree-fronted bill-pay handoff are observed during the build, with the exact ceremonies traced.
• Runnable source for the agreed endpoints in Python (FastAPI + httpx) or Node.js (TypeScript + undici), one transport per surface, with retry, backoff and rate-limit awareness.
• An automated test suite — happy path, MFA challenge, expired token, RDC image-pair rejection, bill-pay payee-not-found — runnable against a sandbox account or, with consent, a live member account.
• Interface documentation aimed at the engineer who will own the integration after us, including the maintenance-trigger list (front-end version string, auth host change, schema drift).
• A short compliance and data-retention note specific to a Michigan credit-union member set, covering NDA terms, consent-record storage, and the data-minimization defaults the source ships with.

Talking to the endpoints

Illustrative shape, not the production trace. The actual host, header set and challenge ceremony are confirmed during the build against a consenting Sovita member session and recorded in the protocol report.

POST /digital-banking/v1/sessions
Host: sovita-mobile.<digital-banking-host>
Content-Type: application/json
X-Device-Fingerprint: <rolling>

{
  "member_number": "<consenting member>",
  "credential":    "<held in vault, never in source>",
  "client":        "obs-sovita-integration/0.1"
}

-- 200 OK
{
  "access_token": "<jwt-like>",
  "expires_in": 900,
  "mfa": { "required": true, "channels": ["sms","email","biometric"] }
}

GET /digital-banking/v1/accounts
Authorization: Bearer <access_token>

-- 200 OK
{
  "accounts": [
    { "id":"S0001", "type":"share",   "nickname":"Savings",  "balance":  421.18, "available":  421.18 },
    { "id":"C0001", "type":"draft",   "nickname":"Checking", "balance": 1872.04, "available": 1844.04 },
    { "id":"L0007", "type":"loan",    "nickname":"Auto",     "balance":-9341.62, "next_due":"2026-06-05" }
  ]
}

GET /digital-banking/v1/accounts/C0001/transactions?since=2026-04-01
-- returns posted + pending, with member tags, notes, receipt-photo refs

POST /digital-banking/v1/rdc/deposits
-- multipart: front.jpg, back.jpg, account_id, amount

POST /digital-banking/v1/billpay/payments
-- payee_id, amount, send_on, memo (CheckFree-fronted handoff)

Errors that matter: 409 mfa_pending on session creation, 422 image_pair_unreadable on RDC, 402 daily_limit on bill pay. The client we ship handles each as a typed exception with a human-readable hint, not a stack trace.

Member consent and the rules around it

Sovita carries a Michigan state credit union charter and federal NCUA share insurance, so the immediate rules of the road for this build are Gramm-Leach-Bliley's data-handling expectations, NCUA's part 748 security program lineage as it touches member records, and Michigan Department of Insurance and Financial Services supervision — not a sector-wide data-rights mandate. The CFPB's Personal Financial Data Rights work under 12 CFR Part 1033, were it to land in current form, would point Sovita toward a more standardized data-portability lane; as of this review the rule is not in force and we treat it as where the regime may go, not what we build against today. The dependable basis for the integration is the member's own written authorization to access their data, captured before any traffic is recorded.

Practical implications: the consent record is stored alongside the integration, scoped per-member and per-surface, with revocation honored by the next sync cycle. Logs are kept; raw credentials are not. Data minimization is the default — if your widget needs only available balance, the source we ship pulls only available balance.

What the build accounts for

Things we plan in from the start because we have seen them bite small-to-mid credit-union integrations.

• Field-of-membership shape. Sovita's eligibility runs through Michigan educators, healthcare workers and library staff in named counties (per the membership-eligibility page). The data attached to a given member can include employer-named direct-deposit lines and payroll-cadence statements that read very differently from a mass-market consumer bank. We size the test corpus to that population rather than assume a generic consumer-bank shape.
• CheckFree handoff is its own object graph. Bill pay is fronted by CheckFree (per the Sovita e-services page), so the request that looks like "schedule a payment" actually spans two systems with different error semantics. We model payees, scheduled payments and history as a separate module so an integrator can adopt bill pay independently of the rest.
• RDC is image-pair, not just amount. The mobile deposit flow uses front and back photographs of the check; both are validated server-side. We surface image-pair rejections as a typed error and keep the original images, with retention bounded by the consent record.
• Vendor refresh is when, not if. Credit unions of Sovita's size move digital-banking vendors on a multi-year cadence. The maintenance plan ships with a drift sentinel — the first time a host, schema or auth ceremony shifts, the test suite tells us, not your users.

Engagement and price

The build runs end-to-end on the member's side of the wall, so price keys to the shape of the deliverable and not to seats or volume. Source-code delivery starts at $300 — runnable Python or Node alongside the OpenAPI spec, the protocol report and the test suite — and you pay after handover, once you are satisfied. Pay-per-call hosted is the alternative: we run the integration on our infrastructure, you call our endpoints, no upfront fee, billed per call. Either path closes in one to two weeks for the surfaces above; CheckFree and RDC can be added as later modules without re-doing the auth layer. To scope a Sovita-specific build, write to us at /contact.html with the surfaces you need and the consent shape you have in mind.

Sources we opened

Direct citations checked while writing this brief. Each link is the deep page we read, not a homepage.

• Sovita Credit Union — Membership eligibility (field-of-membership boundaries)
• Sovita Credit Union — Online banking e-services page (CheckFree bill pay, mobile deposit, biometric sign-in)
• Google Play listing for Sovita Credit Union Mobile (package id, feature description)
• CUToday — Flint Area School Employees CU name change (rebrand history)

Assessment by the OpenBanking Studio integration desk, 2026-05-21.

Other credit-union apps in the same neighborhood

Same-category Michigan and member-owned credit-union apps an integrator often meets in the same procurement. Names are listed in plain text; the data shape across them is similar enough that a Sovita-style build ports with modest re-mapping.

• Lake Michigan Credit Union — large Michigan credit union with a mature mobile portal; balances, transfers, statements and bill pay follow the same shape.
• MSU Federal Credit Union — university-anchored Michigan credit union (East Lansing); rich member-record surface for staff and student populations.
• Dort Financial Credit Union — Flint-area neighbor; mobile data domains overlap closely with Sovita's.
• ELGA Credit Union — also Flint-area; member-account, RDC and bill-pay surfaces.
• Financial Plus Credit Union — Flint headquartered; comparable digital-banking footprint.
• Genisys Credit Union — Michigan-based, broad statewide footprint; similar mobile feature set.
• Frankenmuth Credit Union — Michigan community CU; same envelope of mobile surfaces.
• Michigan Schools and Government Credit Union (MSGCU) — adjacent educator-family field of membership.
• DFCU Financial — Michigan; member-portal data shape comparable to Sovita's.

Questions integrators ask

Will the integration survive a Sovita digital-banking platform upgrade?

Credit unions of Sovita's size rotate vendors and front-end skins more often than core data shapes. We pin the build to the data contract a member actually sees on screen, and the maintenance plan carries a drift sentinel that fires the first time a field name, endpoint host or auth ceremony moves. Re-validation is part of the engagement, not an extra invoice.

How does Sovita's educator-and-healthcare field of membership change the data scope?

Per the membership-eligibility page, eligibility runs through Michigan educators, healthcare workers, library staff in named counties, and immediate family — so the population is narrow and the data attached to a given member can include payroll-routing patterns, employer-named direct-deposit lines, and statement series that read very differently from a mass-market consumer bank. We scope the test corpus accordingly and avoid treating Sovita as a generic consumer-bank shape.

Can the source code cover CheckFree Bill Pay and mobile remote deposit, or only internal transfers?

Both surfaces are inside the member portal, so both are reachable on the member's side under consent. CheckFree-fronted bill pay is treated as its own object graph — payees, scheduled payments, history — and RDC is mirrored as image-pair submission plus deposit status. We mark them as separate modules in the deliverable so you can adopt them independently.

Is the build keyed to a single consenting member or to many?

Either shape is workable; the engagement decides. A single-member build is faster and cheaper and is common for treasury or bookkeeping use. A many-member build needs a consent ledger and per-member credential vault, which we set up with you during onboarding rather than treating as a gate.

Interface evidence

Screenshots from the Play listing for Sovita Credit Union Mobile, used here only to identify the surfaces named in the table above.