Washington State Mobile, broken down for integration work

Behind the Washington State Mobile login sits a multi-bank PFM aggregation view: balances, transactions, and merchant-spend summaries from this Iowa community bank plus any external accounts the customer has linked in, per the app's own Play Store description. That makes it a slightly unusual integration target. For an end consumer it is a community-bank app; for an integrator the payload looks closer to a small PFM aggregator, with two provenance tiers travelling together. Most of the build work hinges on that split — the native-bank tier is straightforward, while the externally-aggregated tier travels with the user's consent and has to be treated as third-party feed data, not first-party Washington State Bank records.

What the app actually holds

The table below lists what is reachable behind the login, where each surface originates inside the app, and what an integrator usually does with it. Field names follow the app's own language where the Play Store listing or the bank's mobile-banking page makes them explicit; where they are inferred from screens, the type is given rather than the exact label.

Routes we'd actually take

Three routes are realistic. Each names what is reachable, the effort it carries, how durable it tends to be, and what we set up to run it.

1. Consumer-permissioned access via the customer's own Internet Banking session

This is the dependable route. The customer authorizes the studio (or the integrator) to read their own account through their existing credentials and the 4-digit passcode the app enforces, exactly as they would on the device. We capture the auth handshake, the session refresh, and the structured calls the app uses to populate balances, transactions and the PFM-aggregated view. The build runs against a real consenting account; access setup, the consent record, and an NDA where the integrator needs one are arranged with you during onboarding.

2. FDX-aligned aggregator handoff, where the bank shows up

FDX-aligned coverage of US banks now spans the major share of consumer accounts, per the Financial Data Exchange's own public reporting. Coverage of an institution this size is uneven, and we check it per build rather than assuming it. Where a direct FDX-style connector to Washington State Bank exists in a network the integrator already uses, we wire the feed into the same normalized schema as route 1 so downstream code does not branch on which underlying transport delivered the data.

3. Native export, as a fallback

The app and the web Internet Banking present statements and transaction history that the user can export themselves — CSV, OFX or PDF depending on the screen. For a small or one-off integration this is sometimes enough. We script the export, parse the file formats, and hand back a short ETL the integrator can run on a schedule. It does not carry the merchant-spend summaries or the PFM-aggregated external feed; if those matter, route 1 is the answer.

For most builds the consumer-permissioned route is what we'd anchor on — it works at this bank's scale regardless of aggregator coverage. The FDX-aligned route substitutes in cleanly when Washington State Bank lights up in a network the integrator already pays for. Native export covers a reconciliation-only need without standing up the rest.

What you actually get from us

The standard hand-over for a Washington State Mobile build is:

• An OpenAPI / Swagger spec for the calls we use against the app and the Internet Banking back end, with request and response examples that reflect this app's real payload shapes.
• A protocol and auth-flow report covering how the login, token issuance, refresh and passcode lockout behave in practice, and where they diverge from a generic OAuth flow.
• Runnable source for the key endpoints in Python and Node.js, with the session model and retry behaviour already wired up.
• An automated test suite that exercises the auth flow, the account-list call, transaction pagination, and the PFM external-account tier, against a sandbox account or the consenting account agreed during onboarding.
• Interface documentation aimed at the engineer who has to maintain it next quarter, not just the one who consumes it now.
• A short compliance and retention note — what the integration logs, how long it holds raw transaction data, and how a consent revocation propagates through the pipeline.

What the wire actually looks like

Illustrative shape only. Exact field names and paths are confirmed during the build against the live app, and are not asserted here from documentation that may have moved. The point is to show the surfaces and the auth model we'd be coding against, not to publish a contract.

POST /api/v1/auth/login
{
  "device_id": "<install-bound uuid>",
  "username":  "<internet-banking user>",
  "password":  "<internet-banking password>"
}
→ 200 {
  "session_token":  "...",
  "refresh_token":  "...",
  "user":           { "id": "...", "passcode_required": true }
}

# After the 4-digit passcode prompt:
POST /api/v1/auth/passcode { "passcode": "<4-digit>" }
→ 200 { "session_token": "...", "scope": ["accounts","tx","pfm.external"] }

GET /api/v1/aggregation/accounts
Authorization: Bearer <session_token>
→ 200 {
  "accounts": [
    { "id":"acc_wsb_chk_1", "tier":"native",        "institution":"Washington State Bank",
      "type":"checking", "balance":1834.22, "currency":"USD" },
    { "id":"acc_ext_42",    "tier":"pfm-external",  "institution":"<linked bank>",
      "type":"savings",  "balance":12044.10, "currency":"USD", "source":"aggregator" }
  ]
}

GET /api/v1/aggregation/transactions?account_id=acc_wsb_chk_1&since=2026-04-01
→ 200 {
  "transactions": [
    { "id":"tx_91", "posted":"2026-04-03", "amount":-47.18,
      "merchant":"<local merchant>", "category":"Groceries",
      "tags":["weekly"], "geo":{"lat":41.41,"lon":-92.91},
      "note":"family run", "receipt_image_id":"img_5510" }
  ],
  "next_cursor": "..."
}

Where this sits in US data-sharing rules

Washington State Bank is a state-chartered Iowa community institution, per the FDIC's BankFind record. Even in §1033 as it was finalized in October 2024, an institution this small would have been on the longest implementation tail before any obligation kicked in. The rule has since been enjoined and reopened for reconsideration in mid-2025, so that tail is itself unsettled. §1033 is described here as where the US framework may go, not as what governs this integration today.

The dependable basis for reading a Washington State Mobile account is the consumer's own authorization to access their own data — backed by the bank's own Internet Banking terms and standard US financial-privacy practice. In practice that means we run integrations on consent records the customer signs and can revoke, log every call against those records, minimize what we retain, and operate under NDA where the integrator needs one. If §1033 lands later in a recognizable shape, swapping in an FDX-style endpoint where the bank exposes one is a small surface change rather than a redesign.

Things we account for that a quick read of the app would miss

• Two provenance tiers in one payload. The account list contains both first-party balances at Washington State Bank and accounts the PFM layer has aggregated from other institutions. We tag the two tiers explicitly in the extract so downstream code never treats an aggregated third-party feed as if it were a Washington State Bank record. That distinction matters for compliance — the two tiers have different consent scopes — and it matters for engineering, because the external tier's freshness model is the aggregator's, not the bank's.
• Credential session plus a 4-digit passcode lockout. Customers sign in with their full Internet Banking credentials, and the app then layers a 4-digit passcode for fast unlock per its Play Store description. We design the session model around credential rotation, the passcode prompt, and the lockout that fires after repeated failures, so a stalled sync never locks the customer out of their own banking. The token-refresh path is part of what we hand over.
• Merchant-spend summaries are derived, not stored. The rolling averages by merchant that the app surfaces are computed inside the app from the underlying transaction set. We re-derive them from the raw transactions on our side, so the consumer sees consistent numbers regardless of which device or session generated them, and so the integration does not silently drift the day the bank changes its rounding rule.
• Front-end churn on a shared mobile shell. The "GRIP"-style mobile shell appears on several Iowa community-bank apps (CSB Iowa, Our Community Bank, The Community Bank Digital and others share the same package suffix). Changes the vendor rolls out land on Washington State Mobile without local notice. We schedule a quarterly re-check inside the maintenance plan, so a vendor-side change is caught and patched before the integrator first sees it as a 500.

What the app surfaces look like

Screens published by Washington State Bank on Google Play, included here as visual reference for the surfaces named above.

Other apps in the same shape

Several small US banks ship a similar PFM-aggregation app, and a cluster of Iowa community banks in particular run on the same shared mobile shell. Useful to know which neighbours look the same when you are planning a multi-institution integration. Listed for category context, not endorsement.

• CSB Iowa (Community Savings Bank) — same multi-account aggregation pattern; same tags, notes and geo enrichments per its Play Store description.
• Farmers Bank Spencer, IA — community-bank mobile with PFM aggregation across other institutions.
• Community Bank of Oelwein (Iowa) — adds aggregated external accounts inside a community-bank shell.
• CBIOWA (Community Bank Iowa) — Iowa community-bank mobile app with similar feature surface.
• MainstreetCBF Mobile — community-bank mobile banking with external-account linking.
• CNB Mobile — community-bank mobile app in the same US footprint pattern.
• Our Community Bank — another deployment of the same "GRIP"-style aggregating shell.
• The Community Bank Digital — also a "GRIP"-style multi-account aggregation app.
• Key Community Bank Mobile — community-bank mobile from a larger US institution, useful as a coverage comparator.
• Mascoma Bank — community-bank mobile in the US Northeast with overlapping surfaces.

Questions integrators actually ask about this one

Does the cross-institution view inside Washington State Mobile come out with the rest of the data, or do we have to re-aggregate other banks separately?

Both routes are possible and they answer different questions. The app's own PFM layer already aggregates accounts the customer linked at other institutions, so with the customer's session you can read that consolidated view as a normalized snapshot. If you want a more durable feed you also pull each external institution directly through an aggregator or FDX-aligned connection, and treat what comes out of Washington State Mobile as the canonical view of the Washington State Bank tier. We will recommend the split that fits what you are building.

Is Washington State Bank large enough to show up in FDX-aligned aggregator coverage?

It is a small Iowa community bank, so FDX-grade direct coverage is uneven for an institution of this size. In practice the dependable route is consumer-permissioned access via the customer's own login, which works regardless of whether a given aggregator has wired a direct connector to this specific bank. We pick the source per institution rather than assuming one network covers them all.

What happens to a Washington State Mobile integration if the CFPB rewrites Section 1033?

The rule was finalized in October 2024 and is currently enjoined and back in agency reconsideration, so its final shape is unsettled. We build the extractor on the consumer's own authorization to read their own account, which does not depend on §1033's final wording. If and when the rule lands, swapping in an FDX-style endpoint where one becomes available is a small change rather than a redesign.

What was checked, and where it came from

The data surfaces and feature behaviour described above were cross-read against the app's published Play Store listing, the bank's own mobile-banking page, and the current regulatory record for US consumer-permissioned data sharing. Sources opened during this mapping:

• Washington State Mobile on Google Play — feature list, screens, package ID.
• Washington State Bank — Mobile Banking — the bank's own description of the app and its enrolment path.
• CFPB — Personal Financial Data Rights (§1033) — current status of the rule and reconsideration process.
• Financial Data Exchange (FDX) — the recognized standards body for US consumer-permissioned data sharing.

Mapped by the OpenBanking Studio integration desk · 24 May 2026

Pricing is plain. Source-code delivery starts at $300 and is paid only after we hand over the runnable extractor, the OpenAPI doc and the tests, and you have verified the build against a real Washington State Bank account. The hosted track lets you skip the build entirely and pay per call against our endpoint instead, with no upfront fee. Send the app name and the surfaces you need via the contact form; access setup, NDA and the consent record are arranged with you during onboarding, typically inside a 1–2 week build cycle.