Integrating Payne County Bank's mobile app

Per its Play Store listing, PCB Mobile ships under the package name com.apiture.xpressmobile.pcbpok.sub, and that string tells an integrator most of what shapes the job. The app is a white-label build of Apiture's Xpress mobile banking platform, branded for The Payne County Bank, an employee-owned community bank in Perkins, Oklahoma that has run since 1898 (per the bank's published history). So the data you would want from it does not sit in a one-off backend. It sits behind Apiture's session and resource model, which is a recognizable shape to work against and the same platform that powers a few hundred other US banks and credit unions.

That matters because the route in, the auth flow, and the way transactions are filtered are all consequences of the platform, not guesses. Below is what the app holds, how we would reach it, and what we hand back.

What the app keeps behind the login

Every domain below is something the app's own description names. The value for an integrator is in the second and third columns: where it originates and how fine-grained it is.

Routes we'd use to reach it

Two or three routes genuinely apply here, and they reach different parts of the app.

Consumer-permissioned aggregator

If PCB is covered by Plaid, MX, Finicity or Akoya, a consumer-consented connection reads balances and transactions cleanly, with little for you to maintain. It is the lightest path. It also stops at reads: an aggregator will not run a transfer, queue a bill payment, or report deposit status. Coverage of a single community bank varies by network, so part of the work is confirming PCB is actually reachable on the one you prefer.

Authorized integration of the Apiture session

Under the accountholder's authorization, we map the app's own client-to-server traffic, the token exchange and refresh, and the JSON resource calls that back each screen. This reaches everything the app shows, including the state-changing surfaces: transfers, the bill-pay queue, payee edits, deposit submission and status. Effort is moderate; durability tracks Apiture's front-end versions, which we account for in maintenance.

Native statement export

Where online banking offers OFX, QFX or CSV export, we wire a scheduled retrieval and a parser. It is cheap and read-only, at statement grain rather than live.

Which one to build depends on whether you need to write. An aggregator gives a tidy, consented read if a balance-and-transaction feed is all you are after. For the parts of this app that change state, the Apiture-session route is the one that actually reaches them, and it is the build we steer most clients toward here. Statement export stays handy as a low-cost reconciliation copy alongside either.

How a session and a statement pull line up

The auth is the interesting part. The snippet is illustrative; exact field names and paths are confirmed against captured traffic during the build.

POST /oauth2/token            # credential exchange, not the biometric step
  grant_type=password
  username, password
-> { access_token, refresh_token, expires_in }

GET /accounts                  # list, with current balances
  Authorization: Bearer <access_token>

GET /accounts/{id}/transactions
  ?from=2026-01-01&to=2026-06-11
  &minAmount=&maxAmount=&checkNumber=    # mirrors the in-app search
-> 200: [ { postedDate, amount, type, checkNo, description, runningBalance } ]
-> 401: token expired  -> replay refresh_token, retry once
-> 429: throttled      -> back off, respect Retry-After

# transfers / bill pay use the same bearer session, POST-side,
# scoped per account because limits differ by product type

The transaction call is the one worth getting right. PCB's in-app search filters by date, amount and check number, so the client passes those through as query parameters rather than pulling everything and filtering locally.

What lands in your repository

Each deliverable maps to a real surface above, not a generic template.

• An OpenAPI (Swagger) specification covering accounts, the filtered transaction search, transfers, bill pay and payees, and deposit status.
• A protocol and auth-flow report: the token exchange and refresh on this Apiture build, and how the biometric sign-on relates to the credential the server actually checks.
• Runnable client source for the key endpoints in Python and Node.js, with the retry and refresh logic shown above.
• Automated tests, including contract tests pinned to recorded response shapes so a platform change is caught early.
• Interface documentation an in-house engineer can keep working from.
• Compliance and data-retention guidance, plus the consent-record format we use.

Build notes specific to an Apiture white-label

These are the things we plan around so they do not surprise anyone later.

Platform releases move the screens. Because this is an Apiture Xpress build, the screens and the resource calls behind them shift when Apiture ships a platform update; the company rolled out a new AI-driven interface across its base in late 2025. We pin the client to observed response shapes and run a re-validation check when the app version changes, so a central refresh does not quietly break the transaction parser.

Biometrics sit above the real auth. Fingerprint and face sign-on are a device-local convenience over a stored credential, not the authentication the backend evaluates. We build the session around the actual credential-plus-token exchange and design the refresh around the token lifetime, so a scheduled sync does not drop part-way.

Limits and search differ by product. Balances and history read the same across consumer and business accounts, but transfer and bill-pay limits do not. We scope those write calls per account type, and we map how the search parameterizes date, amount and check-number ranges so all three filters are honored server-side. Access is arranged with you during onboarding; the build runs against a consenting accountholder's login or a sponsor test environment, whichever the engagement uses.

Consent and the US data-rights picture

PCB is a state-chartered, FDIC-insured Oklahoma bank, so the dependable basis for reaching its data is the accountholder's own authorization: recorded, scoped to what the integration needs, and revocable. That is what we build against. The CFPB's Personal Financial Data Rights rule (Section 1033) might someday push banks toward a standardized consumer-data feed, but it is not in force today; enforcement is enjoined and the rule is back under reconsideration. It is a thing to watch, not the thing we depend on. We pull only the fields the job calls for, keep consent and access logs, and work under NDA where you want one.

Keeping it current

Apiture pushes platform updates centrally, so a change to the PCB build usually mirrors a wider release rather than a one-off tweak by the bank. That is a help: we watch the app version and the response shapes, and re-run the contract tests on a schedule, so drift shows up as a failing test rather than a silent gap in your data.

Screens from the listing

Store screenshots, for reference. Tap to enlarge.

Apps in the same corner of the market

Same category, useful context if you are mapping more than one institution into a single integration. Each holds the kind of account data this app does.

• RCB Bank — an Oklahoma community bank app with balances, bill pay, transfers and check deposit.
• BancFirst — Oklahoma's largest state-chartered bank; balances, transfers, bill pay and mobile deposit.
• BOK Financial (Bank of Oklahoma) — a larger Oklahoma-headquartered bank holding consumer and business account data.
• Surety Bank — a community bank running on the same Apiture platform.
• First Reliance Bank — another Apiture-powered community bank with comparable account surfaces.
• Savings Bank of Mendocino County — an Apiture client with consumer and small-business banking data.
• Listerhill Credit Union — a credit union on Apiture, holding member account and transaction records.
• Alabama Credit Union — member balances, transfers and payments on the same platform family.

Questions integrators ask about this one

How far back does PCB Mobile's transaction history go, and can you filter it the way the app does?

The app lets you search recent transactions by date, amount or check number, and the export we build honors those same filters against the Apiture backend. How deep the history runs is set by the bank's retention on the core, not the app; we confirm the available window during the build and page through it rather than assuming a fixed range.

Do you reach the data through an aggregator like Plaid, or directly?

Either, depending on what you need. If Payne County Bank is covered by Plaid, MX or a similar network, a consumer-permissioned aggregator gives a clean read of balances and transactions with little to maintain. For transfers, bill pay, payee edits and deposit status, we integrate the Apiture session directly under the accountholder's authorization, because aggregators do not move money or expose those write surfaces.

Does CFPB Section 1033 require Payne County Bank to share this data with us?

Not as a present obligation. That rule is not in force; enforcement is currently enjoined and the CFPB has the rule back under reconsideration, so it does not compel a bank this size to hand over a standardized feed today. What we actually build on is the accountholder's own documented, revocable authorization, which does not depend on where Section 1033 ends up.

The app signs in with fingerprint or face, so can a server-side integration even hold a session?

Yes. The biometric sign-on is a device-local convenience over a stored credential; it is not the authentication the server sees. Underneath, the app exchanges a credential for a token and refreshes it, and that token flow is what a server-side client replays under the accountholder's authorization. We map the token lifetime and refresh so the session stays valid across a scheduled run.

What we checked

This brief was put together in June 2026 from the app's own Play Store description and the following primary sources, each opened directly: the bank's FDIC BankFind record for charter, location and roughly $154M in assets; Apiture's digital banking platform page for the white-label and core-integration details the package name points to; and, for the US data-rights position, the CFPB's Section 1033 reconsideration notice alongside a legal summary of the enforcement injunction. Reviewed by the OpenBanking Studio integration desk, June 2026.

A working PCB Mobile client — the typed endpoints, the auth report, the OpenAPI spec, tests and docs — usually takes one to two weeks once the route is settled. You can take it as source code for a flat fee from $300, paid only after it is delivered and you have confirmed it runs; or skip the codebase and call our hosted endpoints instead, paying per call with nothing up front. Tell us the app and what you need out of its data, and we will scope it with you.