Working with Interfaith FCU Mobile data through member-consented eBranch access

Interfaith FCU Mobile is the member app for a federally chartered credit union of about $127M in assets and roughly 7,648 members (per its CreditUnionsOnline.com profile), headquartered in Montclair, California. The app's data does not live in the app — it lives behind go.umfcu.org, the credit union's eBranch home-banking portal, which the mobile app is essentially a wrapper for. Any integration with "Interfaith FCU Mobile" is really an integration with eBranch, reached on behalf of a consenting member.

Bottom line: this is a small-CU build. The straightforward route is to act as the member, reach eBranch under their signed authorization, and normalise the few surfaces an integrator actually wants — balances, the transaction ledger, monthly statements, and the transfer/Bill Pay write paths if they need them. That's the engagement we'd run; everything below is the detail of how.

Where the member data actually sits

The mobile app shows what a member sees in eBranch: a list of share accounts (savings, checking, loans, certificates), recent activity per account, monthly statements, and the transfer and Bill Pay tools. None of this is generated locally on the phone. Each tap calls into go.umfcu.org, which sits on top of the credit union's core; the app is the rendering layer, not the source of truth. That matters for integration because it means there is one authoritative surface to map (eBranch), not two divergent ones.

The app description adds one wrinkle worth calling out: members can pull in accounts from other banks and credit unions into a single view. Those external accounts are not Interfaith FCU's data — they come from a third-party account-aggregation feed embedded in eBranch. Reaching them is a different integration problem from reaching the member's own UMFCU accounts, and we treat it as one when scoping.

Data surfaces, mapped to what an integrator actually wants from them

How the build runs against eBranch end-to-end

Illustrative shape, not a published spec — the exact paths, parameter names, and CSRF mechanics are confirmed during the build against a consenting member account. The pattern, however, is straightforward and very common for small-CU portals:

# Member-consented session against eBranch (go.umfcu.org).
# Endpoint shapes confirmed during the build, not from a public doc.
import requests

s = requests.Session()
s.headers.update({"User-Agent": "OpenBankingStudio/1.0 (consented build)"})

# 1. Hit the login page to pick up CSRF / session cookies.
r = s.get("https://go.umfcu.org/login")
csrf = extract_csrf(r.text)

# 2. Submit credentials supplied under the member's signed consent.
r = s.post(
    "https://go.umfcu.org/login",
    data={"username": MEMBER_USER, "password": MEMBER_PASS, "csrf": csrf},
    allow_redirects=False,
)
if r.status_code not in (302, 303):
    raise AuthError("eBranch refused the credential pair")

# 3. Pull the account summary (share list + balances).
accounts = s.get("https://go.umfcu.org/api/accounts").json()

# 4. Transactions: page back day-by-day; eBranch caps the window per request.
def fetch_tx(account_id, days=90):
    return s.get(
        f"https://go.umfcu.org/api/accounts/{account_id}/transactions",
        params={"days": days},
    ).json()

# 5. eStatements: list cycles, then fetch the PDF for the ones we need.
cycles = s.get("https://go.umfcu.org/api/estatements").json()
pdf = s.get(cycles[0]["pdf_url"]).content
        

If the portal serves a 2FA challenge — likely on a fresh device fingerprint — we capture the challenge step under the same consent and use the device-bound token in subsequent runs, instead of re-prompting on every poll. That's the difference between a build that wakes a member at 3am for a code and a build that quietly runs.

The routes that actually fit a credit union this size

Member-authorized eBranch session (recommended)

The member signs an authorization, we operate eBranch on their behalf, and the integration normalises the read surfaces above into a clean JSON feed. Effort: a week or two to map and harden. Durability: high until UMFCU changes its digital banking front end, at which point we re-map. Compliance posture: clean — every call is something the member could have done themselves.

Captured-traffic protocol analysis

Where the mobile app itself talks to a different backend path than the browser eBranch does, we capture the app's own traffic under the member's authorization and document those endpoints directly. Worth doing when the app exposes something the browser portal hides (camera-based remote deposit calls, for example), and skipping when the browser surface already covers the same domain.

Third-party aggregator passthrough

For the outside accounts that members link inside eBranch, the right route is a parallel consent against the aggregator the credit union uses — not pretending the eBranch session also reaches them. Useful if the integrator wants the unified view the member already sees inside the app.

Native eStatement export

A fallback for archive-only use cases: members can already download their own eStatement PDFs from eBranch (the site keeps roughly a year of cycles), and an integrator who only needs document retention can pair that with a member-supplied dump. We rarely recommend it on its own because it gives the integrator no live balances or transactions.

What we'd recommend on a typical UMFCU build: route 1 as the spine, route 3 only if the integrator genuinely needs the aggregated external feed, route 2 only where it adds something route 1 cannot give.

What lands at the end of the engagement

• An OpenAPI 3.1 specification covering the eBranch surfaces in scope — accounts, transactions, eStatements, transfers, Bill Pay, card controls — keyed to a single normalised member feed.
• A protocol & auth-flow report describing the eBranch login chain (cookies, CSRF token, any 2FA step) and how the integration handles each one without re-prompting the member.
• Runnable Python source for the read endpoints (account list, transactions, eStatements) and the write endpoints in scope (internal transfer, EFT, Bill Pay). Node.js port on request.
• Automated tests against either a captured session or a consenting test member, including the "front-end changed" failure mode so a future regression shows up as a red build, not a silent miss.
• Interface documentation for an integrator who'd never seen UMFCU before — what each surface contains, what it doesn't, and what to do when eBranch returns the maintenance page.
• Compliance & data-retention notes covering NCUA's relevant guidance for member-authorized access and the consent log shape we'd recommend.

Engineering notes from past credit-union builds

A few things specific to a build like this that we account for up front, so they don't surprise anyone mid-engagement:

• Field-of-membership matters to scope. UMFCU's field of membership traces back to the United Methodist conference. That doesn't restrict the integration technically, but it does mean the consenting members in scope are a defined population and the engagement docs name that population explicitly — useful when the legal review comes round.
• Session shape changes when the portal changes. Small-CU portals get re-skinned on the vendor's schedule, not the credit union's. We map the surfaces semantically (account summary, ledger query, statement list) rather than to brittle CSS or DOM positions, and we wire the test suite to fail loudly when the underlying response shape drifts.
• 2FA is a project, not a footnote. If eBranch challenges new device fingerprints, we plan the consent to include a one-time enrolment step where the member helps us pass that challenge once and we then operate from a device-trusted state. Skipping this is the most common cause of "integration worked in the demo, dies in production".
• External-aggregator data is a separate consent. The accounts that eBranch shows from other institutions sit behind a different vendor relationship; we scope and price that slice independently, with its own consent against that aggregator, rather than implying the UMFCU consent covers it.
• eStatement parsing has to be defensive. The PDFs follow the credit union's statement template, which changes occasionally. We pin a parser against the current layout, snapshot a hash of the template, and the build refuses to silently misread a new layout — it flags the change instead.

Freshness and what "live" actually means here

eBranch is the credit union's online face onto its core; it is not the core itself. Posted balances refresh roughly in line with the credit union's posting cycle, with same-day posted activity available during the business day and prior-day batch postings settled overnight. The integration inherits that cadence. We don't promise sub-second freshness on a small-CU portal — we promise honest cadence: when something is end-of-day, the feed marks it end-of-day, and the integrator's downstream logic isn't fooled.

Member authorization, federal supervision, and where §1033 actually sits

Interfaith FCU is a federally chartered credit union under NCUA supervision. Its NCUA charter (per the federal regulator's directory) is #05816, and its asset size (about $127M, per CreditUnionsOnline.com) sits well below the $850 million asset threshold the CFPB used when finalising its draft Section 1033 Personal Financial Data Rights framework. §1033 itself is currently enjoined and is back at the Bureau for reconsideration (per the Federal Register's August 2025 reconsideration notice), so it is not, today, an in-force basis for accessing UMFCU member data — and even were it in force, the threshold would exempt this credit union.

What the integration actually rides on is the member's own written authorization to access their eBranch account on their behalf — scope limited to the data domains we touch, retention window stated, revocation route documented, every request logged. That's the dependable basis today. If §1033 lands later in a form that pulls credit unions of UMFCU's size in, the consent log already produced maps cleanly to what the rule would require; nothing about the integration changes underneath. We don't describe defeating any authentication step — the work is reverse engineering of the eBranch interface for interoperability under the member's authorization, the same posture NCUA's own member-permissioned guidance contemplates.

Pricing and turnaround for a UMFCU-sized build

Source-code delivery for a build like this starts at $300 and is paid only after we hand over a runnable integration that you've tested against your own member account. We turn one of these around in one to two weeks. The alternative is the hosted route: we operate the endpoints, you call them, you pay per call, and there is no upfront fee. Same source, same deliverables, different operational shape. Send the scope to /contact.html and we'll come back with which of the two fits your case and a fixed quote.

Other credit-union mobile apps in the same band

For integrators who already work across the credit-union sector, the same eBranch pattern (member-authorized read of a portal-backed mobile app, normalised into a single feed) is the routine shape. A few peer apps that come up alongside UMFCU on aggregator-style projects:

• Eastman Credit Union Mobile — large Tennessee-based CU app, same surface shape but at much larger asset size.
• ESL Federal Credit Union Mobile — Rochester, NY; balances, statements, transfers, with similar member-authorized integration posture.
• Wright-Patt Credit Union Mobile — large Ohio CU; mature mobile flows including remote deposit.
• Redstone Federal Credit Union Mobile — Alabama-based CU app with the same core integration domains.
• Delta Community Credit Union Mobile Banking — Atlanta-based CU; broad transaction history and external-account aggregation similar to UMFCU's.
• America First Mobile — Utah-based federally chartered CU; the same eBranch-style portal pattern at far larger scale.
• Alliant Credit Union Mobile — Illinois-chartered CU with a fully online member base; statements and transfers are the lead integration domains.
• BECU Mobile — Washington-state CU; member-permissioned access into balances, transactions, and statements is the typical scope.

These are listed only to widen the integration landscape — UMFCU is not a competitor to any of them, and integrating one app does not produce code that works against another without re-mapping. Names belong to their respective credit unions.

Questions we hear on a build like this

Do you need a live eBranch login before the build can start?

Not on day one. We start from the app name and what you want from its data; access — a consenting member account, a sponsor sandbox arranged with Interfaith FCU, or a captured session under signed authorization — is worked out during onboarding, not as a gate to begin.

Are the outside accounts that the app aggregates in scope, or only Interfaith FCU's own ledger?

Those are two different feeds. Interfaith FCU's own checking, savings and loan ledgers come straight out of eBranch. The accounts the app pulls in from other banks and credit unions sit behind a third-party aggregator embedded in eBranch — reaching those cleanly needs a parallel consent against that aggregator, which we scope as a separate slice of the build.

How is monthly statement data handled compared to live balances?

Statements come out of the eStatements area as per-cycle PDFs; balances and posted transactions come from the eBranch JSON endpoints. The deliverable normalises both into one member feed and keeps the source PDF alongside the parsed line items, so an auditor can trace any figure back to the original document.

What happens if Interfaith FCU swaps the digital banking platform behind go.umfcu.org?

Re-validation is part of how we operate the integration. When the front end at go.umfcu.org changes shape, we re-map the surfaces against the new platform and ship a patch — same source-code tree or same hosted endpoints, not a fresh project.

Sources and review

What was checked for this brief: the app's Play Store listing for the package ID, app description, and feature set; the credit union's own mobile-banking and online-services pages for what eBranch actually offers a member; the CreditUnionsOnline.com profile for charter, asset size and member count; and the Federal Register's August 2025 reconsideration notice for the current §1033 posture. Specifically:

• Interfaith FCU Mobile — Google Play Store listing
• Interfaith Federal Credit Union — Mobile Banking page
• Interfaith Federal Credit Union — CreditUnionsOnline.com profile
• Personal Financial Data Rights Reconsideration — Federal Register, 22 Aug 2025

Mapped by the OpenBanking Studio integration desk · 2026-05-21.

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