Integrating Service CU Mobile Banking account data

Service Credit Union runs out of Portsmouth, New Hampshire, and its mobile app is the member's window onto share accounts, loans, card controls and bill pay. The interesting part for an integrator is cadence: balances move, checks clear, cards get toggled on and off, and a downstream system usually wants to hear about that as it happens, not on a nightly dump. This brief covers what the app holds, how we'd reach it under member authorization, and what we hand back.

The bottom line: this is a clean per-member read with a card-management surface bolted alongside the core ledger. We would build it as a push-first feed off a consenting member session or an aggregator channel, normalize the records, and ship source you can run. No part of the work depends on a settled federal rule, because the member's authorization carries it today.

What member data the app surfaces

The app description and Service CU's own digital-banking pages name these surfaces directly. Each row below is something a member sees in the app and something an integrator would want as a typed record.

Routes into the data, and the one we'd pick

Three routes genuinely apply to a US credit-union app like this. We size each one against what it reaches and how long it stays standing.

Consenting-member interface integration

We work against a member account that has authorized the project, map the app-to-server traffic for the surfaces above, and implement typed reads. This reaches everything the member can see — including the My Cards events that a pure balance-and-transaction feed misses. Effort is moderate; durability depends on the platform, which is why we re-validate (see the build notes). Access is arranged with you during onboarding against a consenting account.

FDX-aligned aggregator channel

Many US credit unions expose member data to third parties through an FDX-aligned channel fronted by an aggregator such as Plaid or MX. Where Service CU's data is reachable that way, this is the most durable read for balances and transactions, because it rides a published standard rather than app internals. It is narrower than the direct interface — card-control state and some bill-pay detail may not be in scope — so we often pair it with route one.

Member-driven export

Statement and transaction export from the member portal is the fallback when a structured feed is not warranted. It is durable and low-effort but coarse: periodic, document-shaped, no event timing. Useful for backfill, weak for the real-time cadence this app's card and deposit events invite.

For most teams we'd run the consenting-member interface as the spine and graft the FDX channel underneath for the balance-and-transaction core, so the everyday feed sits on a standard while the richer card and deposit surfaces still come through. Export is reserved for first-load history.

What lands in your repo

The deliverable is code that runs against this app's surfaces, with the spec and the paperwork following it.

• Runnable client source in Python and Node.js for each surface in the table — balances, transactions, transfers, bill pay, remote-deposit status, and the My Cards reads.
• Webhook handlers that take a posting or card-state event, verify it, normalize it, and write to your store, with a reconcile job that re-reads the full transaction set on a schedule so a missed push self-corrects.
• An automated test harness covering the auth lifecycle, each read, and the event-replay path, so a platform change shows up as a failing assertion.
• Batch-vs-realtime sync design — which surfaces push, which poll on a cursor, and how first-load backfill hands off to the live feed.
• An OpenAPI description of the normalized endpoints we expose to your side.
• A protocol and auth-flow report — the token and session chain as it actually behaves on this app, plus error and retry handling.
• Interface documentation and data-retention guidance tied to the member-consent model.

A transactions pull and a push registration, sketched

Illustrative, and confirmed against the live build before hand-off — field names are normalized to our schema, not copied from the app. The shape is push-first with a cursor read behind it.

# Register a push channel for one consenting member, then page history.
POST /scu/v1/member/{member_ref}/events:subscribe
Authorization: Bearer <member-consent-token>
{
  "surfaces": ["transactions", "remote_deposit", "card_control"],
  "callback": "https://your-app.example/hooks/scu",
  "secret_ref": "whsec_..."          # HMAC secret for signature checks
}
--> 201 { "subscription_id": "sub_8841", "expires_at": "2026-09-01T00:00:00Z" }

# Inbound push when a transaction posts (verify the signature first):
{
  "event": "transaction.posted",
  "member_ref": "m_2f9c",
  "account_ref": "share_01",
  "txn": { "id": "t_55012", "posted_at": "2026-06-01T14:22:05Z",
           "amount": -42.10, "currency": "USD",
           "description": "REMOTE DEPOSIT HOLD RELEASE",
           "source": "remote_deposit" }
}

# Reconcile read — cursor paged, idempotent on txn.id:
GET /scu/v1/member/m_2f9c/transactions?account=share_01&cursor=c_0&limit=200
--> 200 { "items": [ ... ], "next_cursor": "c_200" }

# Token nears expiry -> we re-auth on the consent grant before the feed lapses.

Member consent and the US data-rights picture

Every read here is scoped to a single member who has authorized it. That consent is the dependable basis, and it is what our token lifecycle, logging and revocation handling are built around — a member who withdraws consent drops out of the feed cleanly. We minimize to the surfaces you actually use, keep consent and access records, and work under NDA where the engagement calls for it.

On the federal side: the CFPB's Personal Financial Data Rights rule, Section 1033, is where US member-permissioned data sharing may eventually land. As of mid-2026 it is not the operative framework — a federal court enjoined enforcement in late October 2025 and the bureau has reopened it for reconsideration (per the Federal Register and the CFPB's own reconsideration notice). We design to the member-consent basis that holds today and keep the build adaptable to where 1033 settles, rather than asserting obligations that are currently stayed.

Things we plan around on this build

Two specifics on Service CU shape how we scope the work, and both sit on our side of the line.

• The platform just changed. Service CU retired its older Money Management feature and moved members onto a new digital experience that folds in account aggregation, expense tracking, trends and savings goals (per its upgrade page). We pin the integration to the current build and keep a re-validation test in the harness, so a future platform move surfaces in CI instead of quietly draining the feed.
• My Cards is a separate surface. Debit and credit controls — on/off state, travel notifications, spending history, lost/stolen reporting — live in a card-management service distinct from the core ledger. We model card events and transaction postings as two reconciling streams so a card toggle and the spend it gates line up, rather than flattening them into one feed where the timing drifts.
• Member scope, end to end. Because access is member-only, we design the consent and token lifecycle around a single grant and refresh ahead of expiry, and access itself is arranged with you during onboarding against a consenting account — not something you have to hand us up front.

Cost and how we run it

A first source drop for the balance, transaction and card surfaces typically runs one to two weeks. Source-code delivery starts at $300: you get the runnable client, the webhook and reconcile handlers, the tests and the docs, and you pay after delivery once it works for you. Or use the pay-per-call hosted API, where we run the endpoints and you are billed only for the calls you make, with nothing upfront. Tell us the app and what you need from its data, and we handle the access and compliance pieces with you — start a conversation here.

Where teams plug this in

• A personal-finance app that wants a member's Service CU balances and transactions alongside their other institutions, refreshed as postings land.
• An accounting or bookkeeping tool pulling categorized transaction history and remote-deposit clearing events for a small-business member.
• A fraud or card-controls dashboard mirroring My Cards state so a frozen card and its declined spend show up together.
• A lending or underwriting flow that reads share and loan balances under a one-time member consent.

Screens from the app

Store screenshots, for surface reference. Select one to enlarge.

Other credit-union apps in the same integration bucket

Teams that need Service CU usually need its peers too; a unified member-data layer treats them the same way. These are real, comparable US credit-union apps.

• Eastman Credit Union — retail credit-union app with balances, transfers, deposit and card features; the same per-member read pattern.
• Delta Community Credit Union — large Atlanta-based CU with a full mobile banking surface and card controls.
• Wright-Patt Credit Union — Ohio CU app with deposit, bill pay and transaction history.
• Alliant Credit Union — digital-first CU with ATM locator, transaction history, deposit and bill pay.
• Bethpage Federal Credit Union — New York CU with a comparable balance-and-payments feed.
• New Hampshire Federal Credit Union — a regional NH peer of Service CU with the same member-only model.
• Pacific Service Credit Union — California CU on a cloud-native digital banking platform.
• Alternatives Federal Credit Union — community CU with balances, transfers and deposit in its app.

How this brief was put together

Checked in late May and early June 2026 against the app's store listings, Service CU's own digital-banking and upgrade pages, the US FDX standard, and the current Section 1033 status. Sources opened:

• Service CU Mobile Banking on Google Play
• Service Credit Union — Our New Digital Experience
• Federal Register — Personal Financial Data Rights Reconsideration
• Financial Data Exchange (FDX)

Notes by an OpenFinance Lab integration engineer; assessment dated 2026-06-01.

Questions integrators ask us

Can new transactions push to us in real time, or is it poll-only?

Both shapes are on the table. The cleanest design registers a webhook so a posted transaction, a remote check deposit clearing, or a card-control change pushes to your endpoint, with a periodic reconcile against the full transaction read so nothing is missed if a push is dropped. Where a push channel is not available for a given surface we fall back to a cursor-based poll on the consent token.

Which Service CU surfaces can you actually read?

The member-facing ones the app exposes: share and loan balances, transaction history, transfers between accounts, bill-pay payees and payments, remote deposit status, and the My Cards surface (debit and credit spending history, card on/off state, travel notifications). Each becomes a normalized read in the source we hand over.

What is the dependable legal basis for the read on a US credit union app?

The member's own authorization. We build against a consenting member account or an FDX-aligned data channel exposed through the credit union's aggregator. The CFPB Personal Financial Data Rights rule (Section 1033) is where US data-sharing may settle, but it is currently enjoined and back in reconsideration, so we do not treat it as the present-day basis.

The app just moved to a new digital platform — does that break the work?

It is the first thing we account for. Service CU retired its older Money Management feature and moved members onto a new digital experience with account aggregation and spending trends. We pin the integration to the current build and re-validate against it, so a platform refresh surfaces in a test rather than going unnoticed.