Heritage Valley FCU member-portal access, written up for an integrator

Heritage Valley Federal Credit Union has been chartered in York, Pennsylvania since 1935, per its own site, and its NCUA-approved community charter today covers York, Adams, Cumberland and Dauphin counties — per a 2022 expansion the credit union announced through CUInsight. That places its mobile app in a very specific bucket of work for an integrator: a small community-CU front end on Jack Henry's Banno digital-banking platform (per the credit union's joint Swaystack onboarding press release), with one members-only auth path and a member-aggregation feature on top that pulls in accounts from other institutions through a third-party aggregator the platform OEMs in.

If you need this data in your own system — a wealth tool, a treasury console, a member-facing analytics layer, an underwriting feature — the dependable route is a member-consented integration against the same surfaces the official app talks to. That is the work we cost and deliver below. We do not depend on the rule the rest of the US market is waiting on.

What the app exposes to a signed-in member

The Play Store copy and the credit union's own online-banking page line up on the surface area. The list below is what an integrator can reach on behalf of a member who signs in; the wording is kept close to how Heritage Valley itself describes the features.

Reaching that data on the member's behalf

Three routes apply to a credit union of this shape. We would run the first; the others are kept honest as fallbacks for specific surfaces.

1. Member-consented session integration against the Banno-fronted portal

The mobile app signs the member in with their Internet Banking credentials, then receives a session/device-binding token from the platform; subsequent reads are token-bearing JSON calls against the member's accounts. With the member's authorization, we emulate that exchange once, persist the token securely on your side, and run reads at the cadence you need. This is what we ship. Effort is the bulk of week one; the long-run cost is keeping the auth chain current.

2. Native session export of statement history

Heritage Valley's online banking lets a member download statements and transaction history in standard formats; the app surfaces transaction lists live, but historical statement images are typically a different endpoint. Where you need older history than the live list returns, we drive the export flow under the same member session and normalize the file into the same JSON shape as the live surface. Useful as a backfill, not a primary feed.

3. Aggregator-mediated coverage on the member's behalf

A US data aggregator — Plaid, MX, Finicity or Yodlee — can also connect to small CUs through the same member credential, with the member consenting inside the aggregator's flow. If you already pay an aggregator and your coverage of Heritage Valley is solid there, we can stop at a thin adapter against that vendor instead of standing up a direct client. Cheaper to run, but you inherit that vendor's outage and pricing surface; we will say so if that is the right call.

For a buyer pulling member data with the member in the loop, route 1 is what holds up day to day; route 2 fills history; route 3 is a build-or-buy conversation we are happy to have on a call.

What lands in your repo

The deliverable is built around the surfaces above, not a generic library.

• Runnable client in Python and Node.js for the auth bootstrap, account list, balance read, transaction list (with image references), transfer initiation, RDC history and alerts subscription.
• An OpenAPI 3.1 specification of the normalized surface — what we expose to your application, with stable field names that do not change when Banno tweaks a response shape.
• Protocol and auth-flow report: how member sign-in resolves to a session token on this portal, how the device-binding step works on first launch, where TLS pinning is in play and what error envelopes the platform returns.
• Automated tests against a recorded fixture set plus a smoke harness that can be pointed at a consenting member account.
• Interface documentation in Markdown — endpoint by endpoint, with the response samples and the failure modes we observed during the build.
• Compliance notes covering retention, member consent capture, audit log shape and the §1033 forward-looking design points.

A request worth seeing

Pseudocode below sketches what the client looks like once we have mapped sign-in and an account read. Field names are illustrative — the exact wire shape is confirmed during the build against a consenting member account.

# 1. Bootstrap a session from the member's Internet Banking credentials.
session = client.post(
    "/a/auth/session",
    json={
        "username": MEMBER_USER,
        "password": MEMBER_PASS,
        "device": {
            "id": stored_device_id,        # issued on first-launch enrollment
            "attestation": device_attest,  # platform's enrollment receipt
        },
    },
    headers={"X-OpenBanking-Studio-Trace": run_id},
)
session.raise_for_status()
token = session.json()["accessToken"]

# 2. List the member's Heritage Valley-owned accounts.
accts = client.get(
    "/a/accounts",
    headers={"Authorization": f"Bearer {token}"},
).json()

# 3. Pull posted + pending transactions for one share/checking account.
for a in accts["accounts"]:
    if a["institution"] != "heritage-valley-fcu":
        continue  # externally-linked accounts ride a different feed; opt-in only.
    txns = client.get(
        f"/a/accounts/{a['id']}/transactions",
        params={"limit": 250, "since": last_cursor.get(a["id"])},
        headers={"Authorization": f"Bearer {token}"},
    ).json()
    for t in txns["items"]:
        emit_normalized(
            account_id=a["id"],
            posted_at=t["postedAt"],
            amount=t["amount"],
            description=t["description"],
            tags=t.get("memberTags", []),    # member-added in-app
            receipt=t.get("imageRef"),        # RDC or attached receipt photo
        )

# 4. Refresh on the platform's published TTL, retry on 401 with a re-bootstrap.

Where the rules currently sit for this credit union

Heritage Valley is well under any of the largest-institution thresholds the CFPB's §1033 personal-financial-data-rights rule contemplated in its 2024 form. That rule is presently enjoined by a federal court and back through agency reconsideration, with the CFPB's August 2025 Advance Notice signaling a fresh rulemaking. We treat §1033 as a forward-looking standard to design toward — not the legal basis the integration runs on today.

What the integration does run on is the member's own authorization to read their own accounts on their behalf. We log that consent per session, scope it to the surfaces the member approved, hold an NDA where you need one, and minimize what we store on our side to what the contract requires. Member rights under the NCUA framework, and the credit union's own member agreement, are the working contract; the §1033 design points let us re-cut quickly if the rule returns in a form that publishes a small-CU feed.

What we plan for going in

Three things specific to this app are worth calling out — these are how we approach the build, not blockers we hand you.

• Aggregation cascade. Heritage Valley's app shows externally-linked accounts inside the same member session, via an in-app aggregator. We scope the default integration to Heritage Valley-owned accounts so a downstream system does not silently inherit a third aggregator's TOS or refresh cadence. If you want the linked-account read, we add it as an opt-in surface with its own provenance label.
• Device enrollment and biometric unlock. The 4-digit passcode and fingerprint/face unlock are device-side; the wire still uses the Internet Banking credential plus a device-binding token the platform issues on first launch. We complete that enrollment once against a consenting member account, store the issued token in your KMS of choice, and refresh it on the platform's own cadence.
• Platform-front-end churn. Banno releases iterate often. We keep the client thin around auth and listing endpoints and pin a small set of contract tests that flag a shape change before it reaches your production code. If a release moves a field, we ship a point update under the maintenance line rather than reopening the whole client.

How the build runs end to end

1. Kickoff. You hand us the app name, the surfaces you actually need and the member-consent path you have. Access, NDA and any sponsor sandbox or consenting member account are arranged with you in this step.
2. Mapping. We capture the sign-in, device enrollment and listing flows on a consenting member account; we draft the OpenAPI shape for the surfaces in scope.
3. Build. The client and tests are written against the mapped surfaces; the protocol report is filled in as we go.
4. Validation. The smoke harness runs against the same member account; we walk you through the responses and the failure modes we hit.
5. Handover. Source, spec, tests and docs land in your repo or behind our hosted endpoint; you pay after delivery for the source drop, or per call for the hosted option.

What was checked, where

Sources opened for this brief, late May 2026: the app's Google Play listing for feature surface and package id; Heritage Valley's own online and mobile banking page for the member-facing description; the CUInsight Swaystack press release for the Banno platform reference and onboarding context; and the CFPB Personal Financial Data Rights Reconsideration page for the current rule status. Asset and charter facts come from the credit union's own communications and public NCUA-tracker listings; we do not assert internal vendor identifiers we did not see in those sources.

Mapping compiled by the OpenBanking Studio integration desk, 30 May 2026.

Other small-CU apps in the same shape

These are real same-category apps an integrator might also be asked about; data shape and route options carry over with small variation. We do not rank them and we do not pull their data without authorization.

• White Rose Credit Union mobile banking — another York-and-Adams-County CU, comparable member-portal surface set.
• First Capital Federal Credit Union app — the largest York-based CU; similar Banno-class front end.
• Belco Community Credit Union mobile banking — covers Adams, Cumberland, Dauphin and York among other PA counties, member feature set overlaps closely.
• York Educational Federal Credit Union app — serves area school-district employees and families; small-CU portal shape.
• PSECU mobile — a much larger Pennsylvania CU with the same authenticated-portal data domains and a more elaborate session flow.
• American Heritage Credit Union mobile banking — Philadelphia-area CU, name-similar but unrelated to Heritage Valley FCU.
• Members Heritage Credit Union mobile banking — Kentucky-based, comparable single-FI portal scope.
• Eastman Credit Union mobile banking — well-rated US CU app; same surface set with deeper alerting.
• Delta Community Credit Union mobile — Atlanta-area CU, biometric unlock and the same balance/transaction/RDC trio.
• Bethpage Federal Credit Union mobile banking — New York-based CU app, same authorized-route options.

Questions an integrator usually asks first

If a member already aggregates external accounts inside Heritage Valley's app, do you pull those too by default?

No — by default we scope the read to Heritage Valley-owned surfaces, because the externally-linked accounts ride a separate aggregator credential the credit union OEMs in. If a member explicitly authorizes the linked-account read, we can extend coverage, but we surface it as a distinct source in the normalized output so a downstream system never mistakes a member's Chase checking, pulled via the aggregator inside the app, for a Heritage Valley account.

How do you handle the 4-digit passcode and biometric enrollment the app uses on first launch?

The passcode and biometrics are a device-side unlock; on the wire it is the member's Internet Banking credential that bootstraps the session, then a device-binding token the platform issues. We emulate that first-launch enrollment once against a consenting member account, store the issued token securely on your side, and refresh it on the same cadence the official app does.

Does the integration depend on Heritage Valley staying on the Jack Henry Banno platform?

It is tied to whatever digital portal the credit union runs at any given moment — Banno today, per the credit union's own onboarding-partner press materials. If they migrated cores or front ends, surfaces would shift and we would re-cut the affected client modules. We keep the client thin around the auth and listing endpoints for exactly this reason, so the blast radius of a platform change is small.

Can the integration start now, before CFPB §1033 settles?

Yes. The rule is enjoined and back through CFPB reconsideration, so it does not gate the work and is not the basis we ride. The basis is the member's own authorization to read their accounts on their behalf, logged per session. If §1033 returns in a form that publishes a community-CU data feed, we re-cut the client to ride it; until then the consented session is what ships.

If this maps to what you need, the build runs in a one-to-two-week cycle. You can pay after delivery for a runnable source drop with the OpenAPI spec, tests and protocol report, starting at $300 with no upfront commitment, or skip the upfront entirely and call our hosted endpoint per request. Tell us the member-consent scope you have in mind and we will size the build against the surfaces you actually use.