Interfaith FCU Mobile: reconciling core and aggregated balances for a live integration

Interfaith Federal Credit Union runs out of Montclair, California (per public credit-union directory listings), and its mobile app folds two very different data sources into one screen: the credit union's own core ledger, and a set of external bank and credit-union accounts a member chooses to link. That split is the whole story for an integrator. One side is authoritative and changes the instant a transaction posts; the other arrives on an aggregator's schedule and can lag. Any sync worth shipping has to keep those two honest against each other.

The platform underneath is a Lumin Digital build — the org.umfcu.grip package and the verbatim "personal financial advocate / aggregate all of your financial accounts" copy match a cohort of credit-union apps on the same stack. That matters because the same session that reads a native balance also drives the aggregation engine, so one authenticated route reaches both. We would build the read against that session and layer reconciliation on top.

Data inside the app

Each row below is a surface the app actually exposes to a logged-in member, mapped to what an integrator would do with it.

Routes to the data

Three approaches genuinely apply here. They are not equal, and we would not pretend they are.

1. Member-consented interface integration

We analyze the authenticated traffic of the app's own session — the login exchange, the device-bound step-up, and the calls that return balances, transactions and aggregated links — and implement a client against those surfaces. Reachable: everything a member sees in the app. Effort: moderate, concentrated in the auth chain. Durability: good as long as the session model is tracked. Access is arranged with you and a consenting member account during onboarding; the build runs against that account or a sponsor sandbox. This is the route we would lead with, because it reaches the full surface and reconciles the two data origins in one place.

2. FDX-aligned aggregation

The external-account linking inside the app is itself aggregation, and US aggregators (MX is the deep player in the credit-union segment; Finicity and Plaid alongside) converge on FDX data shapes. Where a member's institutions are reachable that way, we normalize to FDX so the output is portable. Reachable: the standardized core domains. Effort: low once consent is in place. Durability: high, standards-backed. This is the better long-run shape for the external side.

3. Native export

Monthly statements and any transaction download the portal offers are a fallback for archival and backfill. Reachable: documents and bulk history, not live state. Effort: low. Durability: high but coarse — good for seeding a store, not for a running sync.

In practice we would build route 1 as the working spine, normalize its output toward the FDX shapes of route 2 so nothing has to be rewritten later, and use route 3 to backfill history on day one.

What we hand over

The deliverable is code that runs, tied to the surfaces above:

• Runnable Python and Node.js clients for the session exchange, balance read, transaction pull (with the tag/note/receipt fields), statement fetch and aggregation-link read.
• A reconciliation harness that diffs the native core against the aggregated external balances and emits a freshness-flagged merged view.
• A poller-to-event bridge that mirrors balance-threshold alerts and deposit-status changes as structured events your stack can subscribe to.
• An automated test suite (pytest plus a Node harness) that runs against a consenting account, so a changed field shows up as a red assertion instead of a quiet drift in a total.
• A normalized schema bridging the app's records to FDX-shaped objects.
• Secondary, alongside the code: an OpenAPI description of the surfaces, an auth-flow report covering the token and step-up chain, interface documentation, and data-retention guidance.

A look at the surface

Illustrative shapes — the exact paths and field names are confirmed during the build against a consenting member session, not asserted here. The point is the reconciliation, not the literal route.

# Auth: internet-banking credentials, then a device-bound passcode/biometric step-up.
POST /grip/auth/session            -> { session_token, device_id, expires_in }
GET  /grip/accounts                -> native core: checking, savings, loan balances
GET  /grip/accounts/{id}/transactions?since=2026-05-01
       -> [{ id, amount, posted_at, tags[], note, receipt_ref }]
GET  /grip/aggregation/links       -> external institutions the member linked
GET  /grip/aggregation/links/{id}/balances
       -> { balance, last_refreshed }      # eventually consistent

# Core is authoritative; aggregated balances past the window are flagged, never overwritten.
def merged_position(core, links, window_min=180):
    rows = list(core)
    for link in links:
        stale = (now() - link["last_refreshed"]) > window_min * 60
        rows.append({ **link, "authoritative": False, "stale": stale })
    return rows
      

Consent & data rights

The basis we build on is the member's own authorization to access their data — explicit, logged, and revocable. For a US credit union, that is the dependable footing today. The CFPB's Personal Financial Data Rights rule under Section 1033 is where open-banking obligations may eventually sit, but it is not in force: a federal court in the Eastern District of Kentucky enjoined enforcement in July 2025, and the Bureau has reopened the rule through an advance notice of proposed rulemaking. We describe §1033 as the forward-looking piece and design toward FDX data shapes so the integration carries over wherever the rulemaking settles, rather than betting on a specific threshold or date. Consent scope is limited to the domains you need, records are kept of what was accessed and when, data is minimized to the fields in use, and we work under NDA where the engagement calls for it.

Where the build gets careful

Two things on this app need real attention, and both are ours to handle, not yours to pre-arrange.

Two data origins, one screen. The native core and the aggregation engine answer on different clocks. We design the sync to treat the core as the source of truth and the aggregated external balances as eventually consistent, carrying each link's last-refresh stamp and flagging anything past the freshness window. A linked institution that goes quiet becomes a marked row, not a silently wrong net-worth figure.

Device-bound step-up. Login pairs internet-banking credentials with a 4-digit passcode and a fingerprint or face check on supported devices, and the device itself is part of the trust model. We map the enrollment and token-refresh chain so the client re-authenticates inside the session lifetime; the enrollment is set up with you and a consenting account during onboarding.

A third, smaller one: receipt and check photos attached to transactions are content, not just metadata. We carry them as referenced blobs so the transaction feed stays lean and the images land in a store you control.

Screens

Public store screenshots, for reference on what the member-facing surfaces look like.

Other apps in this space

A unified integration usually has to reach more than one institution, so the same reconciliation pattern recurs across these neighbours. Named for context, not ranked.

• MyFPCU — Financial Plus Credit Union's app on the same Lumin Digital stack, with the identical aggregation model.
• BHCCU — a credit-union app carrying the same account-aggregation and personal-finance framing.
• Utah First Digital Banking — credit-union mobile banking with linked external accounts and statements.
• Empeople CU — member balances, transfers and aggregated views in one app.
• LAFCU Mobile — Los Angeles-area credit union with core banking plus aggregation.
• Proponent Mobile — credit-union app holding accounts, transfers and card controls.
• Service Credit Union — a larger credit union with a comparable digital-banking surface.
• University Credit Union — member banking with mobile deposit and aggregation features.

How this was checked

Reviewed on 7 June 2026 against the app's public listings and the current US data-rights record. The Play Store and App Store listings supplied the feature surface and the org.umfcu.grip package; the credit union's own mobile-banking page confirmed the member-enrollment model; the CFPB and a law-firm alert established the live §1033 status. Sources opened:

• Interfaith FCU Mobile — Google Play listing
• Interfaith Federal Credit Union — Mobile Banking
• CFPB — Personal Financial Data Rights Reconsideration
• Cozen O'Connor — Section 1033 enjoined and under reconsideration

OpenFinance Lab · integration engineering notes, June 2026.

Questions integrators ask

How do you keep the aggregated external-account balances in step with the credit union's own ledger?

We treat the native core ledger as authoritative and the aggregated external balances as eventually consistent. The sync carries each linked institution's last-refresh timestamp and a freshness window; past that window a linked account is flagged stale rather than folded into a total, so a slow aggregator connection never produces a wrong number.

Which data-rights basis do you rely on for a US credit union like this one?

The member's own authorization is the dependable basis we build on. The CFPB Personal Financial Data Rights rule (Section 1033) is currently enjoined and back in agency reconsideration, so we do not treat it as governing law today; we design toward FDX-aligned data shapes so the work survives wherever that rulemaking lands.

Can the integration capture the tags, notes and receipt photos a member adds to a transaction?

Yes. That metadata lives on the transaction record in the app, not just on the device, so it is reachable on the same authenticated surface as the transaction itself. We map the fields and include them in the normalized schema, with photo attachments handled as referenced blobs rather than inlined.

Does mobile check-deposit status come through the same interface as balances?

Remote deposit items move through their own state machine (submitted, accepted, held, posted), separate from the balance feed. We model deposit status as its own event stream so a held item is visible before it ever changes a balance, and reconcile it against the transaction ledger once it posts.

Source delivery starts at $300 — runnable client code, the reconciliation harness, tests and interface docs, handed over and paid only once you have it in hand and are satisfied. Prefer not to run the build yourself? Call our hosted endpoints instead and pay per call, with nothing upfront. The cycle either way is one to two weeks. Tell us the app and what you need from its data on the contact page and we will scope it back.