W.P.B. Go and the customer-side data behind a small Kentucky bank's mobile app

Five branches, fifty-three staff, just over half a billion dollars in assets — West Point Bank is a small Kentucky community bank chartered in 1914 (per its FDIC call report on Visbanking), and W.P.B. Go is the customer-facing mobile front for those balances and transactions. For an integrator who wants the data behind it — balances, transaction history, custom-tagged spending, the external accounts a customer has linked through the in-app PFM tile — the question is not whether useful records sit on the other side. They do. The question is which authorized path into them clears in this market, at this size of institution, on the timeline you have.

That is the question this brief answers. The short version: the dependable route here is the customer's own consent, executed through an interface integration that the studio writes, documents, and hands back as source. The long version is below.

What W.P.B. Go actually surfaces to its customer

The app describes itself as an aggregator: a single up-to-the-minute view of the customer's bank accounts at West Point Bank and any external accounts they have linked in. That mix matters for an integration, because the two halves do not behave the same way under the hood. Here is the working map.

The integration target is the first five rows. The last row is mentioned for completeness — it is not the reason anyone integrates this app.

Authorized paths to the data

Three routes are realistic here. We rank them by how durably they hold up over a year of operation.

Customer-consented credential access through the existing Internet Banking session

The app's own getting-started text tells the story: a W.P.B. Go user must already be enrolled as a West Point Bank Internet Banking user, and the app logs in with the same credentials. That is the surface to integrate against. With the customer's explicit, logged consent and a scope agreement, we operate on that session — the same one the app uses — and pull balances, transactions, alerts, and PFM-linked records on the customer's behalf. Effort is moderate; durability is good as long as a small quarterly check is part of the engagement, so a portal refresh by the bank's digital vendor does not catch the integration cold. This is the route we recommend in the build.

Interface integration / protocol analysis of the app's traffic

Where a customer wants programmatic parity with what the mobile app shows (and where the web portal does not surface a field — say, the geo points attached to a transaction), we map the mobile client's documented behaviour against a consenting account, identify the endpoints behind each tile, and turn that into a stable spec. Same authorization basis; more engineering surface area. Useful when the brief is mobile-feature parity rather than statement-style export.

Native export, where available

Most small-bank portals can export statements as PDF or transaction lists as CSV/QFX. That export is a fine fallback for one-off backfill work but does not scale to a live sync — there is no real-time event, and the format is what the bank decided to ship. We include native-export handling in the deliverable as a backfill path, not as the spine of the integration.

Most W.P.B. Go briefs end up shaped the same way: consented credential access carries the live read, deeper protocol mapping is layered in only where the web portal omits a field the customer actually needs, and native export covers historical backfill. That mix has held up best for community-bank work of this size.

A working sketch of the auth and read flow

Illustrative — confirmed against the actual portal during the build, since identifier names and the session shape are determined by the bank's digital platform, not by us. The shape below reflects how community-bank consumer portals of this generation typically structure an authenticated session.

# 1. Customer-consented login on the same surface the W.P.B. Go app uses.
POST /ib/login
Content-Type: application/json
{
  "username": "<customer Internet Banking ID>",
  "password": "<password>",
  "client":   "wpb-go-equivalent"
}
=> 200 OK
   Set-Cookie: IBSESSION=...; HttpOnly; Secure
   { "mfa_required": true, "challenge_id": "..." }   # if step-up is in force

# 2. MFA step-up (one-time code by SMS/email or device token).
POST /ib/mfa/verify
{ "challenge_id": "...", "code": "123456" }

# 3. List the accounts visible to the session.
GET /ib/accounts
=> [
     { "id":"acct_1","type":"checking","mask":"...4421",
       "balance":{"available":2410.55,"ledger":2580.00,"as_of":"2026-05-20T13:02Z"} },
     ...
   ]

# 4. Pull a paginated transaction window.
GET /ib/accounts/acct_1/transactions?from=2026-04-01&to=2026-04-30&cursor=...
=> { "items":[
       { "id":"txn_8a3","posted":"2026-04-12","amount":-42.18,
         "description":"...","status":"posted",
         "user_meta":{"tags":["groceries"],"note":"team lunch","geo":[37.84,-85.95]} },
       ... ],
     "next_cursor": "..." }

# 5. Aggregated (external) accounts via the PFM tile.
GET /ib/aggregation/external-accounts
=> [
     { "id":"agg_77","institution":"...","linked_at":"...",
       "balance":{...}, "freshness":"upstream_aggregator", ... }
   ]

The two things that move per build, and that we pin down on the live system rather than guessing, are the exact MFA step-up rules (whether device binding suppresses the challenge on subsequent runs) and the schema split between first-party balance objects and pass-through aggregated ones.

Inside the integration package

What the studio hands back at the end of a W.P.B. Go build:

• An OpenAPI 3.1 specification of the endpoints we actually used, with field-level types annotated by which path returned them (bank-core vs PFM aggregator).
• A short protocol and auth-flow report — login, MFA step-up behaviour observed on the consenting account, session lifetime, cookie/header chain, refresh semantics, and the specific points where the portal can ask for re-authentication.
• Runnable source in Python (with an optional Node.js port) covering login, MFA, account list, transaction pagination, user-meta retrieval, and the PFM-linked accounts read. Includes retries, backoff, and an error taxonomy.
• Automated tests that exercise the happy path against a consenting test account, plus the documented failure paths (bad creds, MFA timeout, session expiry, paginator exhaustion).
• Interface documentation — short, written for the engineer who will pick this up six months later, not auto-generated wall text. Includes a section on what to re-check when the portal front end visibly changes.
• Compliance notes — consent record format, retention policy guidance, and a data-minimization map showing which fields the integration actually stores.

Kentucky charter, US data-rights posture

West Point Bank is FDIC-supervised under a Kentucky state commercial charter. There is no in-force federal open-banking standard in the United States to ride on top of that. The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is the forward-looking piece — it was finalized in late 2024 and, as of mid-2026, is back in agency reconsideration after a 2025 court order out of the Eastern District of Kentucky enjoined the Bureau from enforcing it during that reconsideration (per the CFPB's own rulemaking page and the Federal Register notice). The fact that the injunction came out of the same federal district where West Point Bank sits is a coincidence, but it sharpens the practical point: §1033 is where the rule may go, not the basis we work on today.

The basis we work on today is the consenting customer's authorization, executed under a scoped agreement that names the data domains, the retention horizon, and the deletion trigger. That is what carries the build regardless of how §1033 ultimately lands. Compliance posture across the project is the usual: NDA where the engagement calls for it, consent records kept, access scoped to what the brief asks for, and logged.

Where the build needs care on this specific app

Three things we account for on a W.P.B. Go engagement, written from the build side rather than as a checklist for the customer:

• The PFM tile is not the bank. External accounts shown in the W.P.B. Go view are sourced by the bank's aggregation vendor, not by West Point's own core. Refresh cadence, available history, and field-level completeness all follow whatever the upstream aggregator decided. We split first-party records and aggregated records into distinct objects in the delivered schema and label freshness per object so a downstream system never silently mixes the two.
• MFA step-up is per-session, not per-build. A community-bank Internet Banking session typically tolerates some forms of device binding and reissues a step-up otherwise. We map the actual trigger conditions on the live system and design the customer-facing re-auth prompt around them, rather than assuming a single login per integration lifetime.
• The portal front end changes silently. Small banks ship UI refreshes on their vendor's schedule, and an endpoint name or response shape can shift with one. The maintenance pass we quote with the engagement is sized for that — a quarterly re-validation run, plus an alert path so a break is caught from the integration side before the customer sees it.

Access to a consenting test account, the scope agreement, and any sandbox arrangement are set up with the customer as part of onboarding — that work belongs to the engagement, not to the customer's pre-work.

Sync cadence and what tends to break

Balances and transactions update on the user-facing app within a working day of posting, sometimes faster on push channels. A reasonable integration cadence for downstream consumption is hourly polling on transactions with an on-demand path for balances; the PFM-linked external accounts move on whatever schedule the upstream aggregator runs (typically daily, sometimes longer). The two breakages we see most often on integrations of this shape are MFA-challenge rules changing after a portal refresh, and pagination cursor semantics shifting (offset versus opaque token). Both are caught by the re-validation pass; neither is dramatic if the maintenance window is wired in from day one.

Adjacent small-bank apps in the same lane

A unified integration across community-bank and credit-union mobile apps in Kentucky and the surrounding states tends to draw on the same handful of vendors and the same data shapes. For context — these are not vendors of W.P.B. Go, just neighbours in the integration landscape:

• Field & Main Bank — Kentucky and Southern Indiana community bank with a mobile front backed by Internet Banking credentials; same shape of consent-based integration.
• Community Financial Services Bank (CFSB) — western Kentucky community bank, similar PFM-and-aggregation feature set.
• Park Community Credit Union — Kentucky credit union with a digital banking platform that, like West Point's, holds balances, transactions, and member alerts.
• Commonwealth Credit Union (CCUKY) — central Kentucky credit union; standard NACHA-rail transaction history through the member portal.
• Abound Credit Union — Kentucky-based, with checking/savings and mobile deposit; data character very close to W.P.B. Go.
• Liberty Federal Credit Union — operates across Indiana, Kentucky, and Tennessee; member-side records similar in granularity.
• Heartland Bank — community bank with consumer mobile app backed by Internet Banking credentials.
• Stock Yards Bank & Trust — Louisville-based, broader product set but the consumer-data slice maps cleanly to the W.P.B. Go shape.
• German American Bank — Indiana and Kentucky community bank; same authorized-route logic applies.

The point of listing them is that an integration written for one of these maps with relatively low marginal effort onto the others, once the first build has settled the shape. We say so in the delivery report when it applies.

Questions that come up about this app

How this brief came together

Sources opened for this write-up: the W.P.B. Go App Store listing for the app's stated feature set and platform identifiers; the Visbanking call-report record for West Point Bank's charter, supervision, and balance-sheet scale; the CFPB's own rulemaking page and the Federal Register notice for the current status of the Personal Financial Data Rights rule. References: App Store, Visbanking call report (79042), CFPB §1033 reconsideration page, Federal Register notice.

Reviewed 2026-05-20 by the OpenBanking Studio integration desk — Kentucky community-bank file.

Engagement and contact

A W.P.B. Go build from us costs $300 at the floor, paid only after the source has shipped and the customer has run it. That price covers runnable code for the endpoints above, the OpenAPI spec, the protocol report, the tests, and the interface documentation; it is the source-code-delivery arrangement. The alternative is a hosted endpoint we run ourselves, billed per call with no upfront fee and nothing to install on your side. Cycle is one to two weeks from the point we have the brief and a consenting account to work against. If a W.P.B. Go integration is on your roadmap, the next step is a short note describing what you want to do with the data — send it via /contact.html and we will come back with a scope and a date.