Pulling account and transaction data out of the NW Preferred FCU app

NW Preferred Federal Credit Union runs out of Tigard, Oregon, and — per third-party credit-union directories — has served members since 1940, holding roughly $174M for about 8,700 of them. The NW Preferred FCU app (Android package com.nwpreferred.android per its Play Store listing, with an iOS build alongside it) is where those members see the records that matter to an integrator: balances, posted and pending transactions, transfers, bill payments, Zelle activity and mobile check deposits. Small institution, real per-member ledger behind the login. That ledger is the subject here, and the way to reach it under the member's own consent.

The bottom line is short. There is a member portal with a tight, well-defined set of financial surfaces and nothing exotic about them. The work is to observe the app's own authenticated traffic to its digital-banking backend, under a consenting member and your authorization, and rebuild those calls as a clean interface you can run. The platform vendor behind the digital-banking screens is not publicly disclosed and is not asserted here; the build identifies it from the app's own behaviour rather than from a guess.

What the app holds for each member

Every row below is a surface the app actually presents to a logged-in member, named the way members encounter it.

The authorized path in

Three routes genuinely apply to an institution this size. They are not equal.

1 — User-consented interface integration / protocol analysis

A consenting member logs in; we observe the app's authenticated calls to the digital-banking backend, then reconstruct them: the login and token step, the account list, transaction pages, transfer submission, bill-pay status, deposit state. Everything in the table above is reachable this way. Effort is moderate and front-loaded into the capture. Durability is medium — the surface is small, so when it shifts it shifts in a contained way. We arrange the consenting test account or a sponsor sandbox with you during onboarding; that setup is our step, not a hoop for you.

2 — Member-consented credential access for your own population

If you integrate on behalf of your own members who bank here, the same surfaces are reached through their explicit consent, scoped per member. Narrower by design, and the right shape when the consumer of the data is the member themselves.

3 — Native export as a fallback

Online banking and the app expose statements and downloadable history. Batch only, lower fidelity, no pending items — useful as a reconciliation backstop, not as the live feed.

For NW Preferred FCU we would build on route 1 and keep route 3 wired in as a periodic cross-check, because a small credit union's statement export is a cheap, stable way to catch any drift in the live capture. Route 2 only comes forward when your users are the members themselves.

A statement query, sketched

Illustrative shape, not copied traffic — field names and the exact token mechanics are confirmed during the build against a consenting account.

# 1. Authenticate the consenting member, hold the session
POST /auth/login
  { "user": "<member>", "secret": "<passphrase>", "device": "<bound-id>" }
  -> 200 { "access_token": "...", "refresh_token": "...", "expires_in": 900 }

# 2. List the member's shares and loans
GET /accounts            Authorization: Bearer <access_token>
  -> 200 [ { "acct_id": "S0", "type": "share",  "available": 1843.07 },
           { "acct_id": "L4", "type": "loan",   "balance": -9120.55 } ]

# 3. Pull posted + pending lines for one account
GET /accounts/S0/transactions?from=2026-04-01&to=2026-05-17
  -> 200 [ { "posted": "2026-05-14", "amount": -52.10,
             "desc": "BILL PAY / PGE", "status": "posted",
             "running": 1843.07 },
           { "posted": null, "amount": -20.00,
             "desc": "ZELLE SEND", "status": "pending" } ]

# Token nears expiry -> refresh before the next page, do not re-login
POST /auth/refresh   { "refresh_token": "..." }   # see build notes on idle timeout
      

What lands at the end of the build

Concrete artefacts, each tied to a surface above:

• An OpenAPI specification covering login/token, account list, transactions, transfers, bill pay and deposit status as they exist for this app.
• A protocol and auth-flow report: the login step, the bearer/refresh token chain, device binding and session timeout behaviour observed during the capture.
• Runnable source for the key endpoints in Python and Node.js — the same calls the snippet sketches, working against a consenting account.
• Automated tests over the typed records, including the share-vs-loan and bill-pay-vs-transfer distinctions so a misclassification fails the suite.
• Interface documentation a backend engineer can hand to a teammate, plus consent-record and data-retention guidance fit for an NCUA-supervised member relationship.

Where integrators put this

• A small-business accounting tool that reconciles a member's NW Preferred share account against its own ledger nightly, including pending items.
• A lender pulling a consenting applicant's transaction history and balances for affordability assessment, then dropping the connection.
• A treasury dashboard that mirrors bill-pay send/deliver dates so a finance team sees credit-union payments next to everything else.
• A personal-finance app a member uses to fold this account into a single view alongside other institutions.

Member consent and NCUA supervision

NW Preferred is a federally chartered credit union supervised by the NCUA, with member shares insured by the NCUSIF. The gate on member data is the member's own express consent — electronic or written — and the studio works only with that consent plus your written authorization on file. The CFPB personal financial data rights rule (12 CFR Part 1033) sets a data-provider asset threshold near $850M, per the CFPB final rule and the eCFR; directory figures put this credit union close to $174M, well under it, so a mandated portability interface is not the practical lever and we do not lean on one. Access is consent-based, data is minimised to the fields the use case needs, consent and access are logged, and an NDA is in place where you require it.

Things we plan around for this build

• The digital-banking session has an idle timeout; we design the token refresh around it so a long transaction backfill does not drop mid-run and re-trigger a full login.
• Members here often hold a mix of share and loan accounts; we map each account type explicitly so a loan payment is never recorded as an internal transfer.
• The shared-branch and ATM locator is network reference data, not member data — it stays in a separate part of the schema so a consumer can never treat a branch record as an account record.
• When the credit union updates its mobile banking screens, we re-run the capture against a consenting account and diff the field set before any update ships, so a renamed field is caught in a controlled pass.
• Access and onboarding are arranged with you: the build runs against a consenting account or a sponsor sandbox, set up together at the start of the engagement.

Screens from the app

Store screenshots, used here only to show the surfaces described above. Select one to enlarge.

Sources checked for NW Preferred FCU

On 2026-05-17 the credit union's own online-and-mobile banking page was read for the named feature set and the Zelle reference; third-party credit-union directories were used for the charter year, asset and member figures and the field of membership (treated as reported, not certified); the app's Play Store listing for the package identifier; and the CFPB personal financial data rights rule for the data-provider threshold. Primary references:

• NW Preferred FCU — online and mobile banking
• Google Play — NW Preferred FCU listing
• eCFR — 12 CFR Part 1033, Personal Financial Data Rights
• CreditUnionsOnline — NW Preferred FCU profile

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

Other credit-union apps in the same data picture

These hold comparable per-member financial records; an integrator unifying credit-union data tends to meet them together. Listed for context, not ranked.

• OnPoint Community Credit Union — large Oregon credit union; balances, transactions, Zelle and mobile deposit behind member login.
• Rivermark Community Credit Union — Portland-area; its app absorbed the former Advantis members after the 2024 merger, with rewards and card controls layered on the same account data.
• Advantis Credit Union — legacy Portland brand now folded into Rivermark; relevant where historical Advantis member data is in scope.
• Unitus Community Credit Union — Portland-founded; standard share/loan ledger and transfers.
• Alternatives Federal Credit Union — community-development FCU; the same authenticated balance and transaction surfaces.
• Alliant Credit Union — national, digital-first; balance preview and in-app transaction data.
• Eastman Credit Union — well-rated app exposing the usual member account and payment records.
• Delta Community Credit Union — large SEG-based credit union with full mobile account access.
• ESL Federal Credit Union — regional FCU; transfers, bill pay and deposit data behind login.
• Wright-Patt Credit Union — large Ohio credit union with a comparable member-data footprint.

Questions integrators ask about NW Preferred FCU

Does the integration touch NW Preferred's shared-branch network, or only the member's own accounts?

Only the member's own accounts. Consent is per member, so the build reads that member's shares, loans, transaction history and transfer activity. The ATM and shared-branch locator the app surfaces is static network reference data, not member data, and we keep it in a separate part of the schema.

NW Preferred is an NCUA-chartered credit union well under the CFPB data-rights asset threshold. Does that change the route?

It changes the lever, not the outcome. The CFPB personal financial data rights rule sets a data-provider asset threshold around 850 million dollars; directory figures put this credit union near 174 million, well below it, so a mandated portability interface is not the practical path. The integration runs instead on the member's express consent plus your written authorization, which is the route we would take here anyway.

Can you cover Zelle and bill-pay activity, or only internal transfers?

Both, where the consenting member has them. The credit union names Zelle on its own online-banking page, and bill pay and external transfers are in the app's stated feature set, so the capture includes payee lists, send and deliver dates, Zelle counterparties and status alongside internal share-to-share moves. Each flows into its own typed record so a bill payment is never mis-keyed as a transfer.

How do you keep the integration working when NW Preferred updates its mobile banking screens?

We re-run the traffic capture against a consenting account and diff the field set before shipping any update, so a renamed field or a changed login step is caught in a controlled pass rather than in your production sync. Maintenance windows are short because the surface area here is small.

The source for the balance, transaction, transfer, bill-pay and deposit calls comes back as runnable Python or Node alongside a matching OpenAPI file and tests; on the source-delivery model you pay from $300, and only after it is delivered and you have run it and are satisfied. Prefer to host nothing? The same endpoints run as a metered hosted API, billed per call, with nothing paid upfront. Either way the cycle is one to two weeks, and you bring only the app name and what you want from its data — access and the compliance paperwork are arranged with you as part of the work. Start the conversation at our contact page.