Pulling balance and statement data from My Bank of Clovis

Snapshot

The bottom line is short. Bank of Clovis runs the usual community-bank customer-data set behind a vendor-built front end, the legal floor for forced data sharing has not arrived for charters this size, and the integration that actually ships is the one the account holder authorizes — either through an aggregator that already speaks to the bank's core, or through a mapped session of the portal itself.

Customer-facing data surfaces

Each row is a surface the app or the portal already exposes to the account holder. The integrator's job is to bring it across, normalize it, and keep it in sync.

Authorized paths to that data

1. Consent-based aggregator

Plaid, Finicity, MX and Akoya all carry community-bank coverage of varying depth — some direct into the bank's core, some still on the screen-scrape side. Where the coverage is direct, this route lands the structured domains (balances, transactions, account/routing metadata) with the least re-validation work over time, since the aggregator absorbs auth churn. We confirm Bank of Clovis's coverage tier at scoping, set up the aggregator app credentials, and run the build against a consenting test account.

2. Customer-authorized protocol mapping

The account holder authorizes us to map their own session of the mobile app and the mybank.bankofclovis.com portal — what the regulator and the trade press now call interoperability work, done for data extraction. This is the route that reaches everything the user can see, including the receipt photos and mobile-deposit images that aggregators flatten away. One engineer-week is typical to map the session/MFA/token-refresh chain and stabilize the endpoints we care about.

3. Native export

The monthly PDF statement is the only built-in export the app advertises. It is high-fidelity but coarse and slow. We ship a parser for the bank's statement format so this can sit as a fallback when the other two routes are temporarily unavailable.

For a typical Bank of Clovis brief, route 1 carries the structured domains and route 2 fills in the attachments and the lower-traffic surfaces (alerts, card toggle, P2P). Route 3 is the safety net, not the spine.

A request-flow sketch from a consenting session

Illustrative. The actual field names and paths are confirmed against a consenting account during the build; the shape below is what a typical community-bank portal session of this style produces.

# Auth — MFA on first device-pair, refresh after that

POST /api/auth/login
  body: {"username": "...", "password": "...", "deviceId": "..."}
  -> 200 {"sessionToken": "...", "mfaRequired": true}

POST /api/auth/mfa
  body: {"sessionToken": "...", "otp": "123456"}
  -> 200 {
       "accessToken": "Bearer ...",
       "refreshToken": "...",
       "expiresIn": 1800,
       "accounts": [
         {"id": "ACC-...", "type": "checking", "mask": "1234"},
         {"id": "ACC-...", "type": "savings",  "mask": "9876"}
       ]
     }

# Transactions for one account, with the user's tags / notes / attachments

GET /api/accounts/{id}/transactions?from=2026-01-01&to=2026-05-24
  Authorization: Bearer ...
  -> 200 {
       "transactions": [
         {
           "id": "TXN-...",
           "postedDate": "2026-05-21",
           "amount": -42.18,
           "currency": "USD",
           "description": "POS PURCHASE - ALBERTSONS #...",
           "userTags": ["business"],
           "memo": "client lunch",
           "attachments": [
             {"kind": "receipt", "url": "...", "sha256": "..."}
           ]
         }
       ],
       "nextCursor": null
     }

# Statement download

GET /api/accounts/{id}/statements/2026-04
  Authorization: Bearer ...
  -> 200 application/pdf

Source code and documents you take away

• An OpenAPI 3.x specification for the integrated endpoints — balances, transactions (with attachments), statement download, transfers, alerts config, card status — written against the surfaces this app actually has.
• A protocol & auth-flow report that walks through login, MFA, device pairing, the refresh window, and the failure modes we saw during the build.
• Runnable client source in Python (httpx + pydantic models) and Node.js (undici), with a retry/backoff layer sized to the bank's portal behavior.
• A test suite — recorded fixtures plus a small live-smoke runner that uses a consenting account.
• A PDF-statement parser for the Bank of Clovis statement template, with an attachment-hash log for audit.
• A short consent and data-retention note scoped to the integration you actually want — not a generic privacy template.

Consent and the US data-rights posture

The dependable basis for this integration is the account holder's authorization. The federal rule that would have changed that — the CFPB Personal Financial Data Rights rule under §1033 — was enjoined by the Eastern District of Kentucky in late 2024, sat reopened for reconsideration in 2025, and is, as of this writing, not in force; the agency's August 2025 advance notice took comments through October 2025, and no new rule has issued. For a charter the size of Bank of Clovis, even the original schedule placed the smallest tier years away from any obligation. So the right way to read §1033 today is forward-looking. The integration we build does not lean on it.

What it does lean on: documented authorization at engagement start (scope, expiry, revocation route), the kind of access logging a customer's auditor would expect to see, data minimization to the surfaces the integration actually uses, and NDA where the work touches anything sensitive on either side.

Notes from the engineering side

Three things about this particular app shape the build, and we handle them rather than passing them back to you as homework.

Receipt photos and check images are attachments, not fields. The Bank of Clovis app puts a real value on tags, notes and "photos of receipts and checks" inside the transaction record. Aggregators flatten these to a memo, if they surface them at all. When those images matter for audit, AP automation, or mortgage prep, we scope route 2 for that specific surface, copy the binary into your object storage under your retention policy, and log a hash so the audit trail holds up.

The session is short, the device trust is long. First-pair MFA followed by a refresh-token window that survives across days is the typical shape for this kind of platform. We design the sync around that window so the refresh does not silently expire mid-run, and a refresh failure routes to a human-readable re-pair prompt rather than a quiet stop.

Small UI pushes from the vendor are routine. Bank of Clovis runs on a white-label community-bank platform; field names and HTML attributes drift between releases. The handoff carries a fixture-diff check so that a vendor push which renames a field is caught at the next scheduled sync, not in production. We carry the first re-validation in the post-delivery window so you are not alone with it.

Other community-bank apps in the same shape

An integrator who builds for Bank of Clovis is almost always asked to cover other small US charters next. The data shape is similar across the set; the auth chain and the white-label vendor change. Plain list, no ranking, no link-out — every name below is the publisher's own.

• Citizens Bank of Clovis (CBC Mobile) — the other Clovis-based independent, balances, transfers, bill pay, mobile deposit.
• New Mexico Bank & Trust mobile — multi-branch NM presence with the same transaction-and-statement surface set.
• WaFd Bank mobile — Pacific-Northwest charter with a Clovis branch, similar online-portal data model.
• Wells Fargo Mobile — large-bank baseline most aggregators already cover directly.
• U.S. Bank Mobile — another large-bank reference point with deep aggregator coverage.
• UMB Bank — operates a Clovis branch; mid-size charter, broad mobile feature set.
• Pioneer Bank (New Mexico) — Roswell-based community charter, comparable surfaces.
• First American Bank — NM-wide independent with a similar online-banking platform feel.
• Centinel Bank of Taos — small NM charter, the same community-bank vendor pattern.
• Sunflower Bank — regional charter with NM presence; similar mobile deposit and statement surfaces.

Questions an integrator usually asks first

Is Bank of Clovis already covered by Plaid, Finicity, MX or Akoya, or does that need a separate path?

Aggregator coverage depends on which network has a direct connection into the bank's core and which only screen-scrape the portal. We check Plaid, Finicity, MX and Akoya at scoping. If coverage is direct, route 1 carries the structured domains; if it is screen-scrape only or missing, route 2 (customer-authorized protocol mapping of the actual portal session) is what we build, and the deliverable still lands in the same normalized schema.

Can you reach the receipt photos and mobile-deposit images, or only the line items?

Receipt photos and mobile-deposit images live as attachments off the transaction record, not as inline fields, and aggregators typically only surface the line item. We reach the images through route 2 under the account holder's authorization, copy them into your object storage under your retention policy, and record a hash so the audit trail is verifiable end-to-end.

Does the CFPB Personal Financial Data Rights rule give us a stable legal floor for this integration?

Not today. The rule was enjoined in late 2024 by the Eastern District of Kentucky, sits back in CFPB reconsideration after the August 2025 advance notice, and even as originally written placed the smallest charter tier years out from any compliance obligation. We build on the account holder's own authorization, logged and revocable, and treat §1033 as forward-looking rather than a present-tense floor for a charter this size.

How is the customer's authorization recorded, and what happens when they revoke it?

Consent is captured at engagement start with scope, expiry and revocation path, stored next to the integration logs, and revocation triggers an immediate stop on pulls plus rotation of any cached credentials. If Bank of Clovis later joins an aggregator's verified network, we can migrate the existing consent record onto that path without re-onboarding the customer.

Sources for this brief

For this brief we read the FDIC BankFind record for The Bank of Clovis (certificate 57022), the bank's own mobile-banking and online-banking pages, the Google Play listing for the com.bankofclovis.grip package, and the CFPB's Personal Financial Data Rights reconsideration page alongside the Cozen O'Connor alert that summarizes the late-2024 injunction and the current enforcement posture. The session-flow sketch above is illustrative; it is confirmed against a consenting account during the build.

• FDIC BankFind — The Bank of Clovis (cert 57022)
• The Bank of Clovis — Mobile Banking page
• CFPB — Personal Financial Data Rights Reconsideration
• Cozen O'Connor — §1033 enjoined and under reconsideration

Mapping reviewed May 2026 by the OpenBanking Studio integration desk.

Published screens

Screens as the publisher shows them in the store listing. Click to enlarge.