Pulling balances, transactions and check images out of HPCU Mobile Banking

Houston Police Credit Union runs HPCU Mobile Banking for its Houston, Texas membership. Behind a member login the app carries the records most integrations are after: current and available balances, posted and pending transactions with descriptions, scanned check images, mobile check-deposit status, and a bill-pay and transfer history (per the app's Google Play listing and hpcu.coop). None of that is broadcast anywhere. It lives inside one member's authenticated session. The job here is turning that session into a steady, consented feed your own stack can subscribe to.

The short version: a single signed-in member is the unit of access, and almost everything visible in the app is reachable once that member consents. We build on a session-level integration, keep a native export path for first-load backfill, and shape the output toward the data model the US market is settling on. The rest of this page is the detail behind that.

What the app holds, and what you would do with it

Each row below is a surface the app actually exposes to a logged-in member, named the way the app names it where possible.

Routes into the data

Member-consented session integration

This is the route we recommend for HPCU. With the member's consent we map the authenticated calls the app makes and read what the member sees — balances, the transaction list, check images, deposit status, bill pay, transfers. Effort is moderate, because we identify the live endpoints by observing the consented session rather than guessing a backend. Durability is tied to the app's own auth and layout, so we re-validate when the app changes. Access is arranged with you and the member during onboarding.

FDX-style normalized consent

The Financial Data Exchange model — OAuth/OIDC consent and standardized account, balance and transaction objects — is the shape US data sharing is converging on (FDX published API v6.4 in spring 2025, per FDX materials). Where an FDX or aggregator consent surface is reachable for this credit union, the same normalized client points at it with little rework. We design toward that target so today's build does not become tomorrow's rewrite.

Native export, for backfill

Members can pull statements and transaction history from online banking. We script that export and parse it as a backstop for the initial load and for periods before a live feed existed. Lower freshness, but useful history with no extra access. In practice we run the session route for ongoing data and use export only to seed the first sync.

The build you get

The headline deliverable is code that runs, not a binder.

• A runnable client in Python and Node.js that signs in with the consented member session and reads the member's accounts and transactions.
• A webhook service that emits posted-transaction, cleared-deposit and settled-payment events to your endpoint, each signed, with replay for missed deliveries.
• An automated test harness with recorded fixtures that exercises every endpoint, so a behavior change in the app is visible before it reaches your users.
• A normalized schema for accounts, transactions and check-image references, shaped to FDX conventions so it lines up with other feeds you ingest.
• An OpenAPI description plus a protocol and auth-flow report documenting the token and session chain we observed during the build.
• A short data-retention and consent-handling note covering what is stored, for how long, and how revocation propagates.

What an event looks like

Two sketches from a real build. The first is the loop that reads a consented account; the second is the webhook our service posts to you when something new appears. Field names are illustrative and were confirmed during the build, not taken from any HPCU-published schema.

# Read a consented member account, normalize to an FDX-style record.
session = hpcu.authorize(member_consent)          # OAuth/OIDC or observed session
for acct in session.accounts():
    bal = acct.balances()                         # current + available
    txns = acct.transactions(since=cursor)        # posted + pending, descriptions
    emit(normalize(acct, bal, txns))              # -> your ingestion endpoint
cursor = txns.next_cursor                         # delta from here next run

POST https://your-stack.example/hooks/hpcu
X-OFL-Signature: sha256=...
{
  "event": "transaction.posted",
  "account_ref": "acct_8f2c...",        # opaque ref, mapped to the member's share/checking
  "posted_at": "2026-06-15T14:02:11Z",
  "amount": -42.18,
  "currency": "USD",
  "description": "BILL PAY - CenterPoint Energy",
  "status": "posted",                   # posted | pending
  "source": "billpay",                  # billpay | mobile_deposit | transfer | card
  "check_image": null                   # populated with a fetch URL for deposited items
}

Where teams plug this in

• A budgeting or PFM app folding a member's HPCU checking into one dashboard alongside their other accounts.
• An accounting tool reconciling a small business's HPCU transactions against invoices each morning.
• A lender confirming balances and recent transaction history, with member consent, during an application.
• A treasury workflow watching for large posted deposits to fire a sweep the moment funds clear.

Authorization and oversight

The dependable basis for this work is the member's own authorization. They consent, we read only what they approve, and access stays logged and revocable. Houston Police Credit Union sits under NCUA supervision, and member data handling falls under GLBA. The piece still in motion is the CFPB's Personal Financial Data Rights rule (Section 1033): its compliance dates were stayed in late 2025 in Forcht Bank v. CFPB while the Bureau reconsiders the rule, so we treat it as where US data rights may head rather than as today's binding framework. We normalize toward the FDX data model because that is what the market is aligning on, and we keep consent records and audit logs so an integration can show exactly what it read and when.

What we account for in an HPCU build

A few specifics shape the work here, all handled on our side:

• Deposits are not single events. A mobile-deposited check is submitted in the app, then accepted, then cleared or returned. We model that lifecycle and emit a webhook on each state change, so your system tracks funds availability instead of assuming a deposit is final the moment it is photographed (per the app's deposit flow and HPCU's mobile-deposit disclosure).
• Sessions expire. We schedule re-authorization within the member's consent window so the feed keeps running without nagging them at random; if consent is revoked, the feed stops cleanly and the event log records it.
• Check images are heavy. Rather than inline image bytes in every transaction, we reference them by fetch URL and pull them on demand, which keeps the main feed small and fast.
• The backend vendor is not asserted. Which digital-banking platform powers the app is not publicly disclosed and is not assumed here; we map the actual endpoints from the consented session, so the client does not depend on a guessed backend.

Working with us on this

Most HPCU builds land in one to two weeks. Source-code delivery starts at $300: you receive the runnable Python and Node.js client, the webhook service, the test harness and the interface docs, and you pay only after delivery, once it works against your account. If you would rather not host anything, use our pay-per-call endpoints instead — you call them, you pay for what you call, nothing upfront. Tell us the app and what you need from its data, and we take it from there. Start a project on the contact page.

Screens we worked from

App screenshots from the store listing. Tap to enlarge.

How this was put together

Checked on 2026-06-15 against the app's own listing and the credit union's site for the feature set, plus the FDX and CFPB sources for the data-model and regulatory picture. Primary references:

• HPCU Mobile Banking on Google Play
• Houston Police Credit Union service guide
• Financial Data Exchange (FDX)
• CFPB — Personal Financial Data Rights reconsideration

Compiled by OpenFinance Lab — interface engineering · 2026-06-15.

Peer apps in the same integration bucket

Other US credit-union apps that hold comparable member data, useful context if you are building one feed across several institutions. Ecosystem only, no ranking.

• Navy Federal Credit Union — large-scale checking, savings and loan data behind a member login.
• PenFed Mobile — accounts, cards and transfers for a nationwide membership.
• Alliant Credit Union — digital-first checking, deposits and budgeting tools.
• Golden 1 Mobile — California member accounts, payments and deposit capture.
• SECU Mobile Access — State Employees' Credit Union balances, transactions and bill pay.
• Star One Mobile Banking — Silicon Valley credit-union accounts and transfers.
• RBFCU Mobile — Texas-based Randolph-Brooks accounts, deposits and payments.
• BECU Mobile — Pacific Northwest member accounts, transactions and transfers.

Questions integrators ask

Can HPCU transactions arrive as a push feed instead of being polled?

The app does not broadcast events to outside systems, so we build a small service that watches the consented member session and re-emits each posted transaction, cleared mobile deposit and settled bill payment as a signed webhook to your endpoint, with replay for anything you missed while your receiver was down.

How do you reach scanned check images and mobile-deposit status?

Viewing check images and depositing checks are first-class features in the app, so the same authenticated calls that render an image or a deposit's status are the ones we map. Images come back as larger binary payloads, so we fetch them on demand and reference them by URL inside the transaction event rather than inlining them.

Which US rules govern pulling a member's HPCU data?

The dependable basis is the member's own authorization: they consent, we read only what they approve, and access is logged and revocable. The credit union sits under NCUA supervision and member data falls under GLBA. The CFPB's Personal Financial Data Rights rule (Section 1033) is the forward-looking piece, with its compliance dates stayed in late 2025 while the Bureau reconsiders it, so we treat it as where US open banking may head, not as today's binding framework.

Do you build against a live HPCU login or a separate test account?

Access is arranged with you during onboarding. The build runs against a consenting member account, or a sponsor sandbox if one is provided; credentials stay with the member, every session is logged, and we keep only the fields your use case needs.