Pulling member data out of TCFCU Mobile Banking

Tulare County Federal Credit Union sits at the small end of the US credit-union sector — around 10,200 members and roughly $95 million in assets per its NCUA-reported figures, four branches in the Central Valley, chartered in 1939 per the credit union's own About page. The interesting thing for an integrator is not that scale. It is that the mobile app folds the credit union's own Symitar-core ledger together with whatever other banks and credit unions a member has linked through the in-app aggregation feature. One consented session, two data graphs.

The bottom line for a buyer: this is a small community credit union, not a money-centre bank, but the data graph the mobile session sees is unusually wide because the member is the one stitching it together. Our build treats the TCFCU-side ledger as the durable spine and the cross-institution view as a member-owned overlay scoped per consent. Both are reachable.

What sits behind the login

The mobile session, once authenticated, lets the member do most of what a small-credit-union member needs done — and each of those surfaces is something an integrator can map. The credit union's own product page lists the same set of capabilities described on the store listing, which is a useful sanity check that we have not over-read the marketing copy. The table below is read off the live app and the credit union's published digital-banking page.

What governs the access

This is a US federally chartered credit union, so the framework is the federal one. The dependable basis is the member's own consent — recorded, scoped to specific data domains, time-limited and revocable. On top of that, NCUA Regulation P (Privacy of Consumer Financial Information) governs how the credit union itself discloses member data; we operate within those rules, with logging and NDA cover where the buyer asks for them.

The CFPB's Personal Financial Data Rights rule under Section 1033 of the Dodd-Frank Act is where this area may go, not where it currently is. The rule was finalized in October 2024, was challenged in court, and on October 29, 2025 the Eastern District of Kentucky enjoined the CFPB from enforcing it while the agency reconsiders — the CFPB itself published an advance notice of proposed rulemaking in August 2025 reopening core questions including representative scope and fees. For an institution at TCFCU's size, the rule as finalized would not have phased obligations down this far in any case (as finalized, since stayed); we treat §1033 as the forward-looking piece to track, not the current legal basis for our build. The basis today is the member.

How we reach it

Three routes apply for this app, and they are not interchangeable.

Member-consented interface integration of the mobile session

This is the spine. With the member's written authorization, we reproduce the mobile session against the credit union's TLS-pinned backend: log in with the member's digital-banking credentials (the same ones used in the app, per the credit union's onboarding instructions), refresh the session token the way the mobile app does, then call the same surfaces the app calls. Reachable: everything in the data-domains table above. Effort: a one-to-two-week build for the core. Durability: good — the Symitar-family backend changes slowly, and the Jack Henry stack has been explicitly moving away from screen scraping toward stable session-bound calls, which works in our favour.

Aggregator passthrough for the cross-institution view

The credit union's "see all your accounts in one place" feature is a member-side aggregator integration. When the integration's job is to read the cross-institution view rather than only the TCFCU-side balances, we route through the aggregator the credit union already uses, on the member's consent token, rather than re-scraping each external bank. Reachable: every external account the member has linked. Effort: small once the spine route is up. Durability: tied to the aggregator's refresh schedule and its own coverage.

Native export

Monthly statements as PDFs, plus the transaction download from the web portal. Useful as a fallback when a buyer only needs end-of-month snapshots and does not want a live integration. Effort: trivial. Durability: high — file formats here are stable.

What we recommend, almost always for this app: the member-consented session route for the live data, with the aggregator passthrough enabled only if the buyer's product actually needs the cross-institution view. Native export becomes the maintenance backstop.

The package we hand over

For TCFCU Mobile Banking specifically, the delivery looks like this:

• OpenAPI specification covering accounts, transactions (with the member-metadata fields preserved), statements, transfers, P2P, RDC and card controls — written against the surfaces the mobile session actually returns, not a generic credit-union template.
• Protocol and auth-flow report: a written walkthrough of the device-bound session login, token refresh, the CSRF / replay-protection headers, and the multipart RDC submission flow. This is the document a future maintainer reads first.
• Runnable source in Python and Node.js for the core endpoints. Login, account list, transactions paged by date, e-statement download, internal transfer, and the RDC three-step submission. The Python flavour is what most buyers run; the Node.js mirror exists for product teams that want it.
• Automated tests against a member-consented test account, covering session expiry and refresh, paging, and the RDC accept / hold / manual-review states.
• Interface documentation for the buyer's own engineers: how to provision a session, how the cross-institution view differs from the TCFCU-side ledger, where the per-member consent boundary sits.
• Compliance and data-retention guidance tied to NCUA Regulation P and the credit union's own privacy notice, with a recommended retention window and a redaction list for receipt photos.

Auth-and-fetch sketch

Illustrative only — field names are anonymized and the exact paths are confirmed against the live session during the build.

# Member-consented session against TCFCU's mobile backend.
# Device-bound token over the credit union's TLS-pinned channel.

import httpx

session = login(
    username=member_user,
    password=member_pass,
    device_fingerprint=our_device_id,   # bound during onboarding to mimic the app
)

# Symitar-backed shares and loans, surfaced through the mobile session.
accounts = session.get("/api/v3/members/me/accounts").json()
for a in accounts:
    print(a["share_id"], a["display_name"], a["available_balance"])

# Posted transactions, paged by date. The member-added metadata
# (tags, notes, receipt-photo URLs) comes through on each row.
txns = session.get(
    "/api/v3/members/me/accounts/{share_id}/transactions",
    params={"from": "2026-04-01", "to": "2026-04-30"},
).json()

# Cross-institution view — separate endpoint, backed by the
# aggregator the credit union uses for the "all your accounts" feature.
# Only the member's linked external accounts come through, and
# only inside the consent window.
external = session.get("/api/v3/members/me/external-accounts").json()

# Mobile check deposit: front, back, then the intent call.
front  = session.post("/api/v3/rdc/images", files={"image": open(front_jpg, "rb")}).json()
back   = session.post("/api/v3/rdc/images", files={"image": open(back_jpg,  "rb")}).json()
intent = session.post("/api/v3/rdc/deposits", json={
    "amount_cents": 12500,
    "into_share_id": target_share,
    "front_id": front["id"],
    "back_id":  back["id"],
}).json()
# intent["state"] in {"accepted", "hold", "manual_review"}

What the build handles

A few specifics that we account for on this app, not buyer prerequisites — these are the things we work out during the engagement.

Sub-$100M institution, soft rate limits. A credit union this size does not run unlimited backend capacity; the Jack Henry stack imposes session-scoped soft rate limits during normal mobile use. We design the sync cadence around those limits rather than fighting them, and we batch the statement-PDF pulls overnight against a consenting member account during the build phase.

The cross-institution view is the member's data, not the credit union's. When the buyer wants the "all accounts" surface, we scope the consent token carefully so non-TCFCU balances are only pulled where the member's authorization actually covers them; the build documents this boundary explicitly so a future product change does not silently widen it.

RDC is image-and-state, not just an amount. The mobile-check-deposit flow returns provisional, hold, and manual-review states; we map all three and surface them in the API so a downstream caller can show the right thing to the end user. We also handle the OCR-feedback step, where the server returns a parsed MICR readout that may disagree with what the user typed.

Login uses the member's digital-banking credentials. Per the credit union's own onboarding text, the mobile app reuses the internet-banking login. We carry the same posture: one credential, one consent, one session — and we plan password-rotation handling into the build rather than letting the integration silently break the next time a member changes their password.

Keeping it from drifting

Two specific freshness risks on this app. The first is that the Jack Henry stack rolls forward — Banno's move off screen scraping in 2023 is the kind of change that shifts endpoints under your feet — so the maintenance window includes a contract test against the live mobile session whenever the app version bumps, with a diff report against the prior baseline. The second is the aggregator side: the cross-institution view depends on a third party whose coverage and refresh schedule can change. We log both surfaces with their version stamps so a regression points at the right cause.

Screens from the app

The screenshots below are from the Play Store listing; they are useful for orienting an engineer to what the live session exposes. Click to enlarge.

Adjacent member-banking apps

For buyers building cross-credit-union products, the apps below sit in the same shape — community or mid-sized US credit unions, member-only mobile portals, similar data domains. Names listed for orientation only.

• Tucoemas Federal Credit Union Mobile — the other Tulare-County credit union, smaller, similar member-services posture.
• Alliant Credit Union Mobile — much larger nationwide credit union; same shape of balances, transfers, statements behind the login.
• Golden 1 Credit Union — California's largest credit union, member portal with a comparable digital-banking set.
• Kinecta Federal Credit Union Mobile — Southern California credit union; mobile session exposes similar surfaces.
• Patelco Credit Union — Bay Area credit union; aggregation features and bill pay are the overlap.
• SchoolsFirst FCU — large California credit union for the education sector; statements and transfers are the integration overlap.
• Logix Federal Credit Union — Southern California; mobile banking with comparable RDC and card-control flows.
• Self-Help Federal Credit Union — community-development credit union; useful comparison for member-data minimization patterns.
• America First Credit Union — Utah-based; another Symitar-family core, with broadly the same integration surface.

Behind this write-up

What we checked: the Play Store and App Store listings for TCFCU Mobile Banking, the credit union's own digital-banking page, a 2025 industry interview describing the move to Jack Henry Symitar, the NCUA call-report context for an institution this size, and the current public record on the CFPB Section 1033 stay — the EDKY injunction of October 29, 2025 and the CFPB's August 2025 advance notice of proposed rulemaking. Citations:

• Google Play listing for TCFCU Mobile Banking (org.tularefcu.grip)
• Tulare County FCU — Digital Banking
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 2025)
• Jack Henry's phase-out of screen scraping on the Banno digital-banking platform

Reviewed 2026-05-24 by the OpenBanking Studio integration desk.

Questions we hear before signing

Can the aggregated external-account view be pulled, or only the TCFCU-side balances?

Both, in principle, but they are different data graphs. The TCFCU side is the credit union's own Symitar ledger — shares, loans, transactions, statements — and is the durable part of the build. The cross-institution view is a member-curated graph the credit union sources from a third-party aggregator; we treat those rows as the member's own data and scope them to whatever the consent actually covers. If a member has linked three outside banks, those three come through; if they later unlink one, it drops.

Does the current stay on the CFPB Section 1033 rule change how this integration works today?

Not really. For an institution this size — Tulare County FCU is roughly a $95M-asset credit union per its publicly reported figures — the §1033 rule as finalized in October 2024 did not phase obligations down to this size band, and the rule has since been stayed and reopened for reconsideration after the Eastern District of Kentucky injunction in October 2025. The dependable basis for the build today is the member's own consent under federal Regulation P and the credit union's own privacy notice. §1033 is the forward-looking piece we follow, not a current obligation we ride.

What does the mobile check-deposit flow actually look like once it is mapped?

It is a three-step multipart submission: front-image upload, back-image upload, then a deposit-intent call that carries the dollar amount, the destination share, and a client-side hash of both images. The server replies with a provisional deposit ID, an OCR readout of the MICR line, and either an accept, a hold, or a manual-review state. We map all three states in the build so a downstream caller knows whether the funds are pending review or already provisional.

Pricing here is straightforward: source-code delivery starts at $300 and is paid after delivery, once the build does what you wanted — or you skip the delivery model entirely and use the hosted endpoint on a pay-per-call basis, with no upfront fee. The cycle for either model is one to two weeks. Tell us the app name and what you want out of its data; access, consenting test accounts and the compliance paperwork are worked out with you as part of the engagement. Start a conversation about a TCFCU Mobile Banking build.