Mirroring Washington State Mobile's aggregated accounts into your own store

Every login to Washington State Mobile assembles balances, posted transactions, and merchant spending averages from accounts a customer holds across more than one institution. That consolidated personal-finance dataset already sits server-side the moment a Washington State Bank Internet Banking customer enrolls. The app is the window onto it. What an integrator usually wants is a copy of the same dataset, kept current, in a store they control.

The bottom line is simple. The valuable thing here is not one bank's ledger; it is the aggregated picture the app stitches together — Washington State Bank accounts plus whatever external accounts the customer linked, with transactions enriched by tags, notes, and receipt photos. We would build the integration around a consented read of that whole picture, seed it with a one-time backfill, and keep it current with incremental pulls. Everything below is how that gets done and what we hand over.

What the app actually stores

The surfaces below come from the app's own description and the shape of a Geezeo-style PFM backend. Each row is something an integrator can read and put to work; the locator and contact features are listed for completeness but are not sync targets.

Routes in, and the one we'd pick

Three approaches fit this app. They differ in fidelity and in how much they move when the vendor ships an update.

User-consented aggregation read

This is the spine we would build on. The customer already authorizes the app to aggregate external accounts, so we ride the same consent rather than inventing a new one. It returns the full picture — balances, transactions, enrichments, cashflow — and its durability is tied to the consent lifecycle, not to any one screen layout. We set up consent capture and token refresh during onboarding, against a sandbox or a consenting account arranged with the bank.

Authorized interface analysis

Here we map the mobile client's own calls to the partner PFM backend, normalize them, and replay them under the customer's authenticated session. A Geezeo-lineage v1 surface organizes data as users, accounts, transactions, budgets, alerts, and goals, which gives a clean target to model. Effort is a little higher and the binding to a specific API version means we wire version checks into the handover.

Native export as a fallback

Where the PFM layer offers a transaction export, it works for a one-off pull but loses enrichment fidelity and arrives on the user's schedule, not yours. We treat it as a backstop, not the primary feed.

For this app the consented read wins on both counts that matter — it sees everything the customer sees, and it survives interface changes that would break a screen-scrape. We would lead with it and keep the interface analysis ready for any surface the consented read does not expose.

Reading the feed

A Geezeo-lineage v1 backend addresses transactions under a user and account, with a partner-wide token rather than per-user keys. The shapes below are illustrative — exact paths and fields get confirmed during the build — but they reflect the resource layout documented for that API generation.

# Partner-token auth, v1 form:  https://{api_key}@{partner_host}/api/v1/
# Full-history backfill, then incremental by id cursor.

GET /api/v1/users/{user_id}/accounts/{account_id}/transactions.json
    ?since_id={last_seen_id}

200 OK
{
  "transactions": [
    {
      "id": 88421007,
      "posted_at": "2026-06-09",
      "amount": "-42.18",
      "description": "EB GROCERY #214",
      "category": "Groceries",
      "tags": ["reimbursable"],
      "memo": "client lunch",
      "image_url": "…/receipts/88421007.jpg"
    }
  ],
  "paging": { "current": 3, "next_id": 88419550 }
}

# Backfill loop (pseudocode)
for account in list_accounts(user_id):
    cursor = None
    while True:
        batch = get_transactions(user_id, account.id, since_id=cursor)
        upsert(batch.transactions)        # keyed on transaction id
        if not batch.paging.next_id: break
        cursor = batch.paging.next_id

The upsert is keyed on the provider's transaction id, so re-running a backfill rewrites existing rows instead of appending duplicates. Enrichments ride along as their own columns so a core re-pull never strips them.

What lands in your repo

The handover is code first. You get a working integration you can run, read, and own, not a slide deck.

• Runnable clients in Python and Node.js for the accounts, transactions, alerts, and cashflow surfaces.
• A batch backfill job for full per-account history, plus an incremental sync keyed on the transaction id cursor.
• A normalized schema (accounts, transactions, enrichments, alerts) with a migration and an idempotent upsert path.
• An automated test suite built from captured response fixtures, covering the accounts, transactions, and alerts contracts.
• An alerts bridge that turns low-funds and upcoming-bill notifications into events your systems can subscribe to.

Secondary deliverables round it out: an OpenAPI description of the surface we target, a short auth-flow and token report covering the session and partner-token chain, interface documentation, and a data-retention note. They matter, but the runnable code is the headline.

Build notes specific to this one

Two things about this app shape the work, and we account for both rather than handing them to you as homework.

First, aggregation is multi-institution, and each linked external account refreshes on its own provider cadence — a lineage that runs back through CashEdge and Finicity-style connectors. We design the sync to treat per-institution staleness independently, so a slow upstream bank does not stall the whole mirror, and a partial refresh reconciles cleanly instead of overwriting good data with gaps.

Second, the tags, notes, receipt images, and geo a customer adds are user-authored and live only in the PFM layer, not the core ledger. We model them as a separate annotation store keyed to the transaction id, so the enrichment a customer cares about is never collateral damage when core transactions re-sync. Access to a sandbox or a consenting test account is arranged with the bank during onboarding; it is part of how the build runs, not a gate you clear first.

Authorization, and where the US rules sit

The work rests on the customer's own authorization. Enrolling means logging in with Internet Banking credentials and consenting to aggregate external accounts, and that same consent is what a compliant read stands on — captured, logged, and revocable, with the data scope held to what the integration needs.

The US federal picture is unsettled. The CFPB's Section 1033 Personal Financial Data Rights rule was finalized in 2024, but a court has enjoined the Bureau from enforcing it and the rule is back in reconsideration, with an advance rulemaking notice out in 2025; the early-2026 first compliance date came and went without binding anyone. So we do not treat Section 1033 as governing law today. It is where data-access rights may land, and we keep the design ready for it, while the dependable footing remains the consumer's consent. Washington State Bank is a state-chartered, FDIC-supervised institution, which sets the supervisory backdrop. We work under NDA where required and keep consent records and access logs.

Keeping it current

After the first backfill, freshness is a per-account question, not a single clock. We design refresh windows around each institution's update rhythm and the consent's validity, surface the last-good timestamp per account, and renew authorization before the consent window closes. Where the app exposes alerts, those become the cheap trigger to re-check an account out of band rather than waiting for the next scheduled pass.

What we checked

Compiled by OpenFinance Lab's interface-engineering team on 2026-06-15, working from the app's store listing and description, the bank's regulatory record, the documented shape of the PFM API generation the feature set points to, and the current status of US data-access rulemaking. Primary sources:

• Washington State Mobile on Google Play (com.washsb.grip)
• FDIC BankFind — Washington State Bank record
• Geezeo v1 REST API reference (users, accounts, transactions)
• CFPB — Personal Financial Data Rights reconsideration

Similar apps in the same orbit

If you are aggregating one PFM app you usually end up aggregating several. These cover the same consumer category and hold the same kinds of balances and transactions, so a single normalized model tends to absorb them all.

• Monarch Money — multi-provider aggregation of balances, transactions, and investments built for household budgeting.
• Rocket Money — links accounts to track spending, net worth, and recurring subscriptions.
• Copilot Money — pulls bank, card, investment, and crypto accounts with categorized transactions.
• Empower (formerly Personal Capital) — joins banking and investment accounts into a net-worth and portfolio view.
• YNAB — connects accounts to a zero-based budget driven by imported transactions.
• Quicken Simplifi — syncs checking, savings, cards, investments, and loans for cash-flow planning.
• Credit Karma — aggregates accounts and credit data after absorbing Mint's former users.
• Mint — Intuit's aggregation app, retired in 2024; the category reorganized around its successors.

Questions integrators ask about this one

Does the first sync backfill old transactions, or only pick up new ones?

Both. The first run is a full per-account history pull for every linked account, then later runs fetch only what is newer than the last cursor. The upsert is keyed on the provider's transaction id, so re-running a backfill rewrites existing rows instead of appending duplicates.

The app shows accounts from other banks, not just Washington State Bank. Can you mirror those too?

Yes. The dataset the customer already consented to inside the app includes the external accounts they linked, so the consented read returns them alongside the Washington State Bank accounts. We sync each institution on its own refresh cadence rather than assuming one global update.

What happens to my tags, notes, and receipt photos when transactions re-sync?

Those enrichments are authored by the user and live in the personal-finance layer, separate from the core ledger. We store them as an annotation set keyed to the transaction id, so re-pulling core transactions never drops a tag, a note, or an attached receipt image.

Is there a US open-banking rule that decides whether this access is allowed?

Not a settled one right now. The CFPB's Section 1033 Personal Financial Data Rights rule was finalized in 2024 but is currently enjoined and back in agency reconsideration, so it is not in force. The dependable basis for this work is the customer's own authorization, which is the same consent the app already uses to aggregate external accounts.

Screens

The app's published screenshots, for reference on what surfaces are visible to a logged-in user.

A first build of the consented read, the backfill job, and the normalized store typically lands inside one to two weeks. Source-code delivery starts at $300: you receive the runnable clients, the tests, and the interface documentation in your own repository, and you pay after it is delivered and you are satisfied. If hosting nothing yourself is the better fit, the same surfaces are available as a pay-per-call hosted API with no upfront fee — you pay only for the calls you make. Tell us the app name and what you need from its data at Start a request and we will scope it.