What an authorised integration against Geaux JEFF actually reaches

Jefferson Parish Employees Federal Credit Union (JPEFCU), a Kenner-based credit union with around 14,000 members across five branches per its public profile, ships Geaux JEFF as the member front end for share, share-draft and loan accounts. The Android package id is org.jpefcu.grip (per its Play Store listing) and the iOS build is App Store ID 1643768811 (per the App Store listing). It is one of the more feature-dense small-CU apps in Louisiana — receipt-photo attachments on transactions, member-side aggregation of outside accounts, debit-card on/off — and that density is what an integrator notices first, because most of it is reachable under a single authenticated member session.

Member-side surfaces inside Geaux JEFF

Each of these reflects a screen or action a JPEFCU member actually sees in the app today. The rightmost column is what a downstream integrator typically does once the data lands.

Two authorised routes, plus a fallback

1. Consumer-permissioned session (the workhorse)

The member logs in once during onboarding, authorises a long-lived session under NDA, and our session manager runs against the same authenticated portal Geaux JEFF itself uses. Every domain in the table above is reachable. Effort is moderate; durability is good because the credit-union portal does not churn often; the consent record names the member, the account ids and the domains.

2. Aggregator handoff (Plaid, MX, Akoya, Finicity)

JPEFCU members already aggregate outside accounts inside the app, which means the wider US aggregator ecosystem already knows how to read a JPEFCU member's balances and transactions. Pick whichever aggregator your downstream is already wired to and accept a normalised feed. Shallower than route 1 — no receipt attachments, no card controls, no statement PDFs — but a sensible choice when the rest of your stack is aggregator-shaped.

3. Native export, as a backfill

Monthly statements come down as PDFs from the app itself; CSV transaction exports are available from the desktop home-banking version of the same portal. Useful when an accountant wants a one-shot historical pull and nothing more.

For most live integrations we'd run route 1, because the per-transaction richness — receipt photos, member memos, the aggregated-account merge — is the thing route 2 cannot give you. Where the downstream is already an aggregator-shaped pipeline, route 2 is the lower-friction pick and worth saying so in the scoping call.

An endpoint sketch against the transactions surface

Auth chain is established once per member during onboarding; the session cookie and CSRF pair carry every subsequent call. Path names below are illustrative — exact routes are confirmed during the build against a consenting member account.

# Geaux JEFF — pulling a member-authorised transaction window
# The session below mirrors the authenticated state Geaux JEFF itself
# holds after the member completes the in-app login + biometric step-up.

import httpx

class GeauxJeffSession:
    BASE = "https://m.jpefcu.org/portal"  # confirmed-during-build

    def __init__(self, session_cookie: str, csrf: str):
        self.client = httpx.Client(
            cookies={"PORTAL_SESS": session_cookie},
            headers={"X-CSRF-Token": csrf, "Accept": "application/json"},
            timeout=15.0,
        )

    def list_accounts(self):
        r = self.client.get(f"{self.BASE}/accounts")
        r.raise_for_status()
        return [
            {
                "account_id":         a["id"],
                "nickname":           a.get("nickname"),
                "balance_available":  a["available"],
                "balance_ledger":     a["ledger"],
                "kind":               a["type"],  # share / share_draft / loan
            }
            for a in r.json()["accounts"]
        ]

    def transactions(self, account_id: str, since: str):
        # Receipt-attachment ids come back only when the member
        # has attached a photo of the receipt or check in-app.
        r = self.client.get(
            f"{self.BASE}/accounts/{account_id}/txns",
            params={"from": since},
        )
        if r.status_code == 401:
            # Biometric step-up was required by a sensitive surface;
            # caller should retry after the member re-authorises.
            raise StepUpRequired(account_id)
        r.raise_for_status()
        return r.json()["transactions"]

    def fetch_attachment(self, attachment_id: str) -> bytes:
        # Second-pass fetch — attachments live on a short-lived signed URL.
        sig = self.client.get(f"{self.BASE}/attach/{attachment_id}/url").json()
        return httpx.get(sig["url"], timeout=20.0).content

What lands in your repo at handoff

• OpenAPI spec covering the accounts list, transactions feed (with attachment refs), statements endpoint, transfers, bill pay, card controls and the aggregated-account view — each marked with which member-account types enable it.
• Auth-flow report: the cookie/CSRF chain, the biometric step-up trigger list, token lifetime, what counts as a logout from the JPEFCU side, and the retry semantics our session manager applies.
• Runnable source in Python (with a Node.js mirror if you ask for one) — the session manager, the account/transaction/statement clients, the attachment two-pass fetcher, and the contract-test suite.
• Automated tests against a consenting member account: golden-path balance pull, transaction-window pull with and without attachments, statement download, card-lock round-trip with audit log.
• Operational notes: consent-renewal cadence, the small set of endpoints that require a fresh biometric step-up, a data-retention guidance memo, and a runbook for portal-change re-validation.

Authorisation basis and where §1033 sits today

Every build runs on the member's own consent. JPEFCU holds share, share-draft, loan and aggregated-account data on the member's behalf, and a member has long been able to authorise a third party — an accountant, a PFM, an aggregator working for the member — to receive that data. Our consent record names the member, the specific account ids, the data domains and the expiry; revocation handles the rest. The credit union itself is named as the data source in the consent text so there is no ambiguity about who is being read.

For a credit union of JPEFCU's size, §1033 — the CFPB's Personal Financial Data Rights rule — is forward-looking rather than present-tense. The CFPB has withdrawn enforcement and is reconsidering the rule under an Advance Notice of Proposed Rulemaking dated 22 August 2025, so the as-finalised asset-size tiers and compliance dates are not law a JPEFCU integration plans against today. JPEFCU sits well below the asset bands the as-finalised text would have phased in first in any case. If a reconsidered rule emerges with obligations a CU this size has to meet, we re-validate the build against it; the live integration runs on the member's consent in the meantime.

Where the build touches data covered by NCUA member-privacy rules or state-level data-protection statutes, the consent text and retention memo reflect that scope — we don't price compliance review separately, it is part of how the build is delivered.

What we account for during the build

These are the things this specific app makes you think about. None of them is a blocker — they are the engineering judgments that turn a working prototype into something a small credit-union's portal won't break in production.

• Biometric step-up on sensitive surfaces. Geaux JEFF triggers a step-up when a member opens "monthly statements" or "deposit a check". That reads as a 401 to a naive client. Our session manager catches the step-up code, surfaces a typed exception to the caller, and resumes after the member re-authorises, so the downstream pipeline sees one logical request rather than a flap.
• Receipt and check photos as a second-pass fetch. The attachment id is in the transaction row but the binary sits behind a short-lived signed URL on a separate path. Treating attachments as a second pass means a slow image backend never stalls the transaction stream — and the integrator can opt out of attachments entirely on bulk loads.
• Aggregated outside accounts can drift without JPEFCU touching the portal. The aggregation surface is fed by whichever aggregator JPEFCU is configured against, not by JPEFCU itself, so the shape can shift when the aggregator updates. We pin the schema we hand off, validate against drift on each pull, and flag for a re-test pass when an aggregator-side change is detected.
• Per-account-type feature flags. A share-only member sees no loan endpoints; an active loan member adds payment-due and payoff surfaces; a member with no debit card sees no card-control surface. We mark these as feature flags in the OpenAPI rather than returning 404 to the caller, so the downstream's behaviour is determined by capability, not by guessing.
• One credit-union ops calendar. JPEFCU is a small institution; portal updates are infrequent but not zero, and have historically landed on weekends. The contract-test suite in the handoff package is what catches a Monday-morning shape change before it pages anyone.

Price, cycle, and how we work

The first runnable build for Geaux JEFF — accounts, transactions with attachments, statements, with the auth chain wired in and the contract-test suite green — typically lands in 9 to 11 working days, which puts the full cycle inside the 1–2 week window. Source code, the OpenAPI spec, the auth-flow report and the integration tests sit in your repo at handoff; nothing important lives only on our side. Source-code delivery starts at $300 and settles after delivery, once you have run the build against your own consenting member. Or call our hosted endpoint and pay only for the calls you actually make, with no upfront fee. Pick the model that matches whether the integration is going to live in your stack or call ours. Send us the requirement and we will come back with a scoped 1–2 week plan and a named engineer.

Other Louisiana CU apps and aggregator-connected portals

These come up in the same conversations Geaux JEFF does — Louisiana members holding more than one credit-union account, accountants serving multiple Louisiana CUs, or a PFM that wants to cover the state. Names are factual, not ranked.

• Jefferson Financial Federal Credit Union app — a larger Louisiana CU now under merger with Keesler Federal; its member portal exposes the same general balance/transaction/statement triad a JPEFCU integration covers.
• Campus Federal Mobile — branches in Baton Rouge, New Orleans and Shreveport; similar share/share-draft/loan model with mobile deposit and card controls.
• Pelican State Credit Union mobile — statewide footprint focused on financial-wellness products; the data surface and consent flow are very close in shape to JPEFCU's.
• Access of Louisiana FCU Mobile — a regional CU portal with the standard balance/transaction/transfer set.
• OnPath (Louisiana FCU) Mobile — New Orleans-anchored CU with a comparable digital-banking stack.
• GP Louisiana FCU Mobile — a smaller institution; same authenticated-portal pattern, narrower surface area.
• University of Louisiana FCU Mobile — campus-affiliated CU; useful as a comparator because the member-account type mix differs.
• Keesler Federal Credit Union mobile — the Mississippi-anchored CU absorbing Jefferson Financial; relevant if a future integration needs to follow that merger across the state line.

Common integrator questions about Geaux JEFF

Are monthly statements available as parsed line items or only as the PDF Geaux JEFF lets a member save?

The in-app statement is a PDF and that is what comes back from the statement surface. Line-item data lives in the transactions stream, not in the statement, so an integration that wants parsed line items reconstructs them by pulling the transaction window for the statement period. We wire that helper into the build.

Can we sync the outside accounts a member has aggregated inside Geaux JEFF, not just the JPEFCU-native accounts?

Yes. The aggregated-account surface is exposed under the same member session. The data is whatever the aggregator JPEFCU uses returns, which is shallower than the JPEFCU-native transaction feed: institution name, account type, balance, sometimes recent transactions. We surface both feeds and label which is which.

When a card on/off control fires through an integration, does the member still get the JPEFCU push notification?

The card-lock action runs on the JPEFCU side regardless of which client triggered it, so the member sees the same push and the same in-app status. We log every card-state change through our session with the consent record and the originating caller, since that is the surface most likely to draw an "I didn't do that" question later.

What stops an integration from breaking when JPEFCU updates the portal?

A contract-test suite ships with the build and re-runs against a known-shape response set. The maintenance retainer covers a re-validation pass when the portal changes. JPEFCU is a small credit union and updates are infrequent but not zero — historically credit-union portal updates have landed on a Saturday with no notice.

Sources checked and how we verified

The app's own surface area was read against the JPEFCU online-banking page, the Geaux JEFF Play Store listing and the App Store listing; the regulatory status of CFPB Part 1033 was checked against the CFPB's Personal Financial Data Rights reconsideration record published August 2025. Member and branch counts are taken from the credit union's public profile and may be a few months stale; they are stated as approximations on this page for that reason. Mapping reviewed May 2026 by the OpenBanking Studio integration desk.

• JPEFCU — GeauxJEFF Online & Mobile Banking
• Geaux JEFF on Google Play (org.jpefcu.grip)
• Geaux JEFF on the App Store (id 1643768811)
• CFPB — Personal Financial Data Rights Reconsideration (Aug 2025)

Interface evidence

Geaux JEFF screenshots as published by JPEFCU — useful for sense-checking what a member actually sees and which surfaces we are mapping against.