Reaching the data behind HPCU Mobile Banking

Houston Police Credit Union has run a single-bond field of membership since its federal charter, per its own membership pages — sworn HPD officers, department civilian employees, retirees, and immediate family. The HPCU Mobile Banking app sits on top of the same online-banking portal at hpcu.coop and surfaces what those members do day to day: balances, transaction history, internal and external transfers, person-to-person sends, bill pay, remote check deposit, check images, and the CardCommand card-control panel. Every one of those surfaces lives behind a credentialed session against an identifiable member of a small, closed institution. That shapes the entire integration: the route is not a vendor catalog, it is the member's own authorization, captured, logged, and refreshed.

The member's authorization is the basis we work from

The dependable basis for an HPCU integration today is the member's own signed consent to share their account data with a named third party — exactly the way a member would download a statement themselves, only on a schedule and into a system that needs the data structured. Because the field of membership is closed, there is no anonymous population to aggregate against; every integration runs in the name of an identifiable consenting member of HPD, and the consent record is kept alongside the access tokens with a documented revocation path.

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is the piece of U.S. law that may eventually formalize how a credit union must respond to that consent. It is not in force. A federal court has enjoined enforcement and the Bureau has opened a reconsideration docket — the rule is being rewritten, not applied. We treat §1033 as the forward-looking shape the U.S. side may take rather than as current law, and we do not state any threshold or compliance date from the stayed version as settled fact. For a small federally chartered credit union like HPCU the practical position is the same as it was before the rule existed: integration runs on the member's authorization, and the work is professional, NDA-covered, and data-minimized.

Data domains worth pulling, and where each one comes from

Three routes we use in practice

1. Consent-based aggregation via an FDX-aligned aggregator

Where Plaid Core Exchange, MX Data Access, or a similar aggregator already maps HPCU, the cheapest path is to ride that connector under the member's consent. Coverage of small closed-bond credit unions is uneven, so we check it during scoping rather than assuming it. Reachable: balances, transactions, account-holder identity in the FDX schema. Durability: high — the aggregator carries the front-end churn for us. The studio handles aggregator onboarding, sandbox keys, and connector verification.

2. Member-authorized interface integration against the HPCU portal

This is the route that reaches everything a member sees, including CardCommand and mobile deposit. The studio captures the credentialed flow a consenting member performs — login, MFA branch, session cookie, CSRF chain — analyzes the XHR endpoints behind hpcu.coop and the Android binary, and synthesizes a typed client and an OpenAPI surface. Effort: medium. Durability: front-end churn is real and is the reason for the maintenance line.

3. Native member export

eStatements and downloadable activity files for the months a member can already pull from the portal. Useful as backfill and as the always-available floor when a credentialed session is unavailable.

In practice we ship route 2 as the working spine for HPCU because it reaches every surface the member sees, fall back to route 1 wherever an aggregator already covers the credit union, and use route 3 for historical archives. Access, sandbox accounts and member-authorization paperwork are arranged with you during onboarding — not as a precondition you clear before scoping.

The authentication and transaction call, as we wire them

Illustrative pseudo-code for the spine of an HPCU integration. The exact endpoint paths, parameter names, MFA branches, and token shapes are captured against a consenting member's session during the build, not pinned here:

# Illustrative only. Exact endpoint shapes are confirmed during the build
# against the consenting member's portal session, then frozen into the client.
import httpx
from datetime import datetime, timedelta

BASE = "https://hpcu.coop"

async def member_login(member_id: str, password: str, otp_callback) -> httpx.AsyncClient:
    s = httpx.AsyncClient(http2=True, follow_redirects=True, timeout=30)
    pre = await s.get(f"{BASE}/online-banking/login")
    csrf = pre.cookies.get("csrf_token")

    r = await s.post(
        f"{BASE}/online-banking/auth",
        data={"u": member_id, "p": password, "_csrf": csrf},
    )
    body = r.json()
    if body.get("step") == "mfa":
        # HPCU's app branches MFA channel by enrolment; the integration handles
        # both SMS and email branches and refreshes the device-binding token
        # on the same cadence the mobile app does.
        code = await otp_callback(channel=body["channel"])
        r = await s.post(
            f"{BASE}/online-banking/mfa",
            data={"code": code, "device_remember": "1", "_csrf": csrf},
        )
    r.raise_for_status()
    return s

async def list_transactions(s, account_id: str, since: datetime):
    # Endpoint shape is confirmed at build time; the response is then
    # normalized into the FDX-aligned transaction schema below.
    r = await s.get(
        f"{BASE}/api/accounts/{account_id}/transactions",
        params={"from": since.date().isoformat()},
    )
    r.raise_for_status()
    return [normalize(tx) for tx in r.json().get("items", [])]

def normalize(tx: dict) -> dict:
    return {
        "id": tx["id"],
        "posted_at": tx.get("posted") or tx.get("date"),
        "amount_cents": int(round(float(tx["amount"]) * 100)),
        "memo": tx.get("description"),
        "status": "posted" if tx.get("posted") else "pending",
        "check_image_url": tx.get("imageHref"),
    }

What ships at the end

• An OpenAPI 3.1 specification covering exactly the surfaces you asked for — balances, transactions, transfers, RDC status, card controls — written against the FDX transaction schema where it applies.
• An auth-flow report describing the credentialed session: login form fields, both MFA branches, CSRF and cookie chain, token lifetimes — all observed against a consenting member's account during the build.
• Runnable client source in Python and Node.js for the endpoints you actually use; the rest of the surface stays in the spec but is not generated until you need it.
• A pytest suite that hits the live integration against a consenting test account and stops noisily when the portal changes underneath it.
• A single Markdown handover the on-call engineer reads in one sitting — no separate wiki.
• Data-retention and consent-record guidance written for an NCUA-insured U.S. credit union, with the revocation path wired in.

What we account for on a build like this

CardCommand is a vendor-fronted surface, not part of online banking. The card-controls panel HPCU exposes under the CardCommand label is a third-party card-management product white-labelled into the app. We identify the vendor and the tenant subdomain during scoping and point the card-control client at that, rather than assuming it shares hosts with balances and transactions. Card on/off and alert rules cross that boundary; the spec we ship makes that boundary explicit.

MFA channel branching, captured once. HPCU's flow can route the second factor by SMS or by email depending on the member's enrolment. We capture both branches at build time and design the client so a long-running aggregation refreshes the device-binding token on the same cadence the mobile app does — a sync that silently drops out of MFA after weeks is the failure mode we plan against.

Sized for the closed bond. The integration is sized for either a single consenting member workflow (personal financial management) or a payroll-style sweep over an identifiable, finite population (e.g., a benefits platform serving HPD members). We do not size or price as if HPCU is a national consumer rollout, because it is not.

Maintenance against front-end churn. Portal front ends move. The maintenance line we offer alongside the build covers re-validation when the markup changes, with a re-key turnaround measured in hours, not days.

Other Texas credit-union apps to think of alongside

The 6–10 named apps below are the credit-union apps an integrator covering HPCU usually meets in the same conversation. Their underlying data shapes are similar, which is precisely why a single FDX-aligned spec is worth writing once and reusing.

• Houston Federal Credit Union (HFCU) — separate, larger Houston-headquartered credit union with its own mobile app over an Alkami-style portal.
• HEB Federal Credit Union — closed-bond credit union for HEB grocery employees; same data shape, different field of membership.
• Houston Texas Fire Fighters Federal Credit Union — Houston first-responder credit union, the closest peer to HPCU on bond and footprint.
• A+ Federal Credit Union — Texas educator-bond credit union with a broader mobile surface.
• Texas Dow Employees Credit Union (TDECU) — large community credit union along the Gulf Coast.
• Randolph-Brooks Federal Credit Union — large Texas military-bond credit union with extensive aggregator coverage.
• Smart Financial Credit Union — Houston-metro community credit union.
• Members Choice Credit Union — Katy/Houston-area community credit union.

Common questions from teams scoping this

Does HPCU's small, closed-bond size change the integration approach?

It changes sizing and rollout, not feasibility. Field of membership is closed to Houston Police Department officers, civilian staff, retirees and their immediate families per the credit union's listing, so an integration is normally scoped for one consenting member or a payroll-style sweep over a defined population, not a wide consumer rollout.

Would an FDX-aligned aggregator like Plaid or MX already reach HPCU?

Sometimes. Connector coverage for smaller NCUA-chartered credit unions is uneven, so the studio checks whether an aggregator already maps the credit union during scoping. If a connector exists and the data you need is in it, we route through that; if not, the same build uses authorized interface integration against the member portal.

How does the integration reach CardCommand card controls?

CardCommand is a vendor card-management product embedded inside the HPCU mobile app and online banking. The studio identifies the specific vendor tenant during scoping and points the integration at that subdomain, rather than treating the card-control surface as part of the same online-banking host as balances and transactions.

How we checked, and what we read

This brief was built from the credit union's own member-facing pages, the Play Store and App Store listings, the CFPB's reconsideration docket for the Personal Financial Data Rights rule, and the FDX/Plaid documentation that defines the schema we map into. Specifically:

• HPCU Service Guide — confirms the mobile feature set, CardCommand, and the no-fee mobile-deposit posture.
• HPCU Mobile Banking on Google Play — confirms the package id and the publisher.
• CFPB Personal Financial Data Rights Reconsideration — the docket establishing that §1033 is being reconsidered, not enforced.
• Plaid Core Exchange (FDX-aligned) — the aggregator route the studio uses where coverage exists.

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

For a credit union this size the engagement runs short — usually one to two weeks from scoping to a build running end-to-end against a consenting member account, longer only when MFA enrolment needs reshaping on the member's side. Source-code delivery for the HPCU integration starts at $300, paid after delivery once it works against that consenting account; the alternative is the pay-per-call hosted API where the studio runs the integration and your side pays only for the calls it makes, with no upfront fee. Either path starts the same way — tell us what data you need from the app and how often at /contact.html, and we scope from there.