Estacado FCU, taken apart for member-authorized integration

The Android package id com.bankjoyapp.estacado tells you most of what you need before opening the app: this is a Bankjoy white-label, not a CU-built app, sitting on Jack Henry's Symitar core through the jXchange service layer (Bankjoy's own press release on joining the Jack Henry vendor program names that integration explicitly). Estacado Federal Credit Union itself is a small Lea County, New Mexico institution — chartered in 1953, NCUA charter 8299, roughly $103M in assets across about 8,200 members per the agency's call-report records, branches stretched from Hobbs through Tatum and Eunice in NM and west into Seminole and Denver City in Texas. The app is the digital face of that — live balances, real-time transfers between member accounts, Payveris bill pay, remote check deposit, e-statements. Substantively short. That is what makes the integration shape clean.

For an integrator's purposes, the takeaway is that none of this needs new vendor relationships. A member who is willing to authorize the access supplies all the consent surface that's needed, the app's own session model carries every record they can see in-app, and the build is small enough — call it a 1–2 week cycle — that the value question is whether sync of these surfaces into your accounting, treasury, or member-onboarding system is worth the floor price. We tend to think it is for anyone who has more than a handful of Estacado members feeding records to them by spreadsheet today.

What's actually inside the app, surface by surface

The table below maps how the app describes each surface to where it originates and what an integrator typically does with it.

Three routes to the same records

For a credit union of this profile, three routes apply. They are not equivalent.

Member-consented protocol integration against the Bankjoy session

This is the route we'd take. The member authorizes us (or a hosted endpoint they enable) to log into the app with their credentials over a documented, logged session, and the integration extracts records exactly as the member sees them. Coverage is the full set in the table above. Effort is modest because Bankjoy's session shape is consistent across its credit-union deployments — we've already mapped the auth and the listing endpoints on sister credit unions and the work amortizes. Durability is good as long as we account for the front-end change cadence (see engineering notes below).

Regulated open-banking consent

In a country with an in-force open-banking instrument this would be the spine. In the US it is not, yet — see the §1033 note below. We mention the route only so the reader knows it's been considered; it does not change what we'd actually do for Estacado FCU today.

Native export

The app produces e-statements as periodic PDFs, and members can save those off. Useful as a fallback for an audit-style snapshot, but it is monthly cadence and PDF-formatted — not a substitute for the live transaction stream most integrators actually want.

The recommendation, plainly: route one, with PDF e-statements parsed in the same pipeline so the integrator gets a single normalized timeline instead of two parallel formats.

What ships at the end of a build

An Estacado FCU engagement closes with a concrete delivery set:

• Runnable source for the read endpoints (Python or Node.js, integrator's choice) — login + session refresh, account listing, transaction window, e-statement fetch and PDF row parsing, Payveris bill-pay fetch, RDC history fetch.
• An OpenAPI document describing the normalized surface — one schema for accounts, transactions, transfers, bill-pay events, and statement rows, so downstream code doesn't branch on origin.
• A short auth-flow report: the Bankjoy session model as it behaves for this credit union, the MFA path the app uses, the token-rotation cadence and the failure modes we hit and handled.
• Pytest / Jest tests against recorded responses so a future BankJoy or Payveris UI change shows up as a red light, not a silent data gap.
• Interface documentation and a data-retention / consent-record note covering what is logged, where, and for how long.

In code, the shape of the extract

Illustrative only — exact endpoint paths and token field names are confirmed against the live session during the build, not asserted here:

# Estacado FCU (Bankjoy white-label) — read flow sketch
# Auth chain: member credentials -> session token -> periodic refresh.

from openbanking_studio.bankjoy import Session

sess = Session.login(
    institution="estacado-fcu",
    username=MEMBER_USERNAME,
    password=MEMBER_PASSWORD,
    mfa_callback=prompt_otp,      # SMS / app MFA as the member sees it
    consent_record_id=CONSENT_ID, # stored with timestamp + scope
)

accounts = sess.get("/v1/accounts")
for acct in accounts:
    txns = sess.paginate(
        "/v1/accounts/{id}/transactions".format(id=acct["id"]),
        since="2026-01-01",
    )
    # transactions normalized to: {date, amount, description, type, balance_after}
    write_to_warehouse(acct, txns)

# Bill-pay surface is a separate authenticated call (Payveris-side):
billpay = sess.get("/v1/billpay/history", since="2026-01-01")

# E-statements: list, fetch PDF, parse rows into the same shape as txns.
for stmt in sess.get("/v1/estatements"):
    pdf = sess.download(stmt["url"])
    rows = parse_statement_pdf(pdf)  # confirmed during the build
    merge_into_warehouse(stmt, rows)

The normalized record an integrator actually consumes looks like this — also illustrative, finalized in the OpenAPI doc that ships:

{
  "account_id": "ESTACADO-S01",
  "type": "share_savings",
  "balance": { "available": 1842.10, "ledger": 1842.10, "currency": "USD" },
  "as_of": "2026-05-24T18:02:11Z",
  "transactions": [
    { "ts": "2026-05-23", "amount": -42.18, "kind": "ach_debit",
      "description": "PAYVERIS BILL PAY - CITY OF HOBBS UTIL",
      "source": "payveris", "match_ref": "BP-90021" }
  ]
}

Where the legal basis actually sits for Estacado

The dependable basis today is the member's own authorization to share their Estacado FCU data with a named third party, captured at the start of the engagement and held in a consent record with timestamp, scope and revocation path. The CFPB's §1033 personal financial data rights rule — the closest the US has come to a federal open-banking instrument for member-permissioned access — is currently enjoined under court order and back inside the agency's reconsideration pipeline. It is not in force, and Estacado FCU, a small NCUA-chartered credit union, sits well outside any near-term phasing under any of the framings the agency has aired. The shorter version: consent is the live basis, §1033 is a watch item.

On the agreement side we operate under NDA when the client asks for one, log every session, and minimize the data we pull to what the integrator named in the scope — no scraping the app for surfaces the integrator does not actually need.

Engineering notes we account for on this build

Three points specific to Estacado FCU's stack that we plan around at the start of the engagement, not at the end:

• Bankjoy session token rotation. The session sits over jXchange and rotates tokens fast — fast enough that a naive retry loop will get stuck behind a stale token mid-paginate. We wire the refresh into the client up front so a long transaction backfill does not silently drop pages.
• Payveris is its own auth chain. Bill-pay history is a Payveris-side surface that the Bankjoy app embeds; from the integration's perspective it is a second authenticated endpoint. We treat it as a parallel pull and reconcile against the transaction stream during the build so the integrator gets one timeline.
• E-statements as PDFs, normalized in-pipeline. The monthly statement is a PDF, not a row-oriented feed. We extract the line items into the same normalized schema as the live transaction stream, so a downstream consumer sees one shape and not two parallel formats to reconcile.

None of these are blockers. They are the parts of the build a generic mobile-banking integration template gets wrong on the first run, so the brief lists them where a reader can see them.

Sources behind this brief

What was checked, in May 2026: the app's Play Store listing for current feature wording and the explicit Bankjoy package id; the credit union's own history page for charter date and footprint; Bankjoy's vendor-program announcement for the Symitar/jXchange relationship; and the CFPB's reconsideration page for the current status of the §1033 rule.

• Estacado FCU on Google Play (com.bankjoyapp.estacado)
• Estacado FCU — about the credit union
• Bankjoy joins the Jack Henry vendor integration program (Symitar / jXchange)
• CFPB — Personal Financial Data Rights reconsideration

OpenBanking Studio · mapping notes, May 2026.

Sister apps in roughly the same shape

Other small or mid-sized US credit unions on the Bankjoy stack — useful context if the integration is meant to grow beyond Estacado, because the auth and account-listing shape carries across these.

• Emporia State Federal Credit Union — Kansas-based credit union; launched its current Bankjoy-powered app in early 2024, similar live-balance / transfer / RDC mix.
• One Detroit Credit Union — Detroit CDFI credit union; one of the early reference Bankjoy customers and a useful comparison for member-permissioned mobile flows.
• Magnolia FCU — Mississippi credit union running Bankjoy for online and mobile banking; same core surface set.
• SafeAmerica Credit Union — California credit union; another Bankjoy white-label with comparable integration shape.
• Cooperative Teachers Credit Union — Texas teachers' CU; small-CU mobile banking on Bankjoy.
• Mobility Credit Union — Irving, Texas; Bankjoy-powered member banking app.
• Las Colinas Federal Credit Union — Irving, Texas; another Bankjoy customer in the same Dallas-area cluster.
• Fort Financial Credit Union — Fort Wayne, Indiana; small-CU app on the same stack.
• Missouri Central Credit Union — Missouri community CU; Bankjoy mobile and online.
• InvesTex Credit Union — Houston-area CU; Bankjoy-powered digital banking.

Names are plain text on purpose — same-stack sister apps share most of an integration, but each one has its own consent text and field-of-membership rules to handle when the engagement extends.

Screens you can actually see in the store listing

The interface evidence below is the Play Store screenshot set — clickable to enlarge. Useful when the integrator wants to point at exactly which screen a record comes from.

Questions integrators ask about this app

Is this app actually a Bankjoy white-label, and does that change how we integrate?

Yes — the Android package id com.bankjoyapp.estacado gives that away, and Bankjoy's own press confirms it sits on Jack Henry's Symitar core via the jXchange service layer. It changes the build shape: the session model, token rotation, and account-listing endpoints look like other Bankjoy-powered credit unions we've worked through, so the parser scaffolding is largely portable. The Payveris-side bill-pay surface is the part that is genuinely separate.

How is bill-pay history surfaced inside this app versus core transactions?

Core transactions and balances come from the Symitar core through the Bankjoy session. Bill-pay records originate on the Payveris side and surface in the app as their own screen with a slightly different shape — payee, scheduled date, status, sometimes a confirmation number. We treat that as a second consented endpoint and reconcile the two streams during the build so the integrator gets one timeline rather than two.

What's the current legal basis for pulling a member's Estacado FCU data?

The member's own consent to access and share their data with a named third party, captured at the start of the engagement and logged. The CFPB's §1033 personal financial data rights rule is presently enjoined and back under agency reconsideration, so it is not the live basis for this work; a small NCUA-chartered credit union of Estacado's size sits well outside any near-term phasing in any case. Consent stays the dependable basis regardless of where §1033 lands.

Can the same client be reused if we onboard a sister credit union later?

Largely, yes — most other Bankjoy white-labels (Emporia State FCU, Magnolia FCU, One Detroit Credit Union, Mobility CU, Las Colinas FCU and similar) share the same auth and account-listing shape, so the per-credit-union work is mostly branding, the field-of-membership consent text, and any institution-specific add-ons. Payveris vs. another bill-pay vendor is the variable that actually changes the second endpoint.

How to start a build for Estacado FCU

Source-code delivery starts at $300 for a tight scope on a single member-consented surface set — runnable code, the OpenAPI document, the tests, paid after you accept what we shipped, on a 1–2 week cycle. The other option is to skip the floor entirely and call our hosted endpoint per-request, paying only for calls, with nothing upfront. Send the brief and the surfaces you actually want pulled to /contact.html and we will come back with the cycle and the price for what you described.