Reaching VeraBank account and treasury data from one authenticated app

One Q2 digital-banking back end answers both the retail VeraBank app and a business client's treasury console. That is the integration story here. The same login that shows a customer a checking balance and a deposited check image also originates, reviews and approves ACH and wire batches and runs Positive Pay for a commercial account — VeraBank moved consumer and commercial banking onto a single Q2 platform and was named Q2's 2024 Bank of the Year for the rollout, per Q2's customer announcement. For an integrator that means the reachable surface is wider than a plain personal-banking app, and it has to be split by role on the way out.

Bottom line: the consumer ledger is the easy part, and a consent-based aggregation feed covers it durably. The value that is specific to VeraBank sits in the surfaces aggregation rails do not carry — e-statement and check-image binaries, and the commercial treasury operations. Reaching those means replaying the app's own authenticated session, which is the route we would build the spine on and layer consented aggregation alongside for the always-on balance and transaction sync.

Account data the VeraBank app actually carries

Every row below maps to a surface the app exposes once a customer is signed in, named the way VeraBank and the Q2 platform present it.

Authorized routes to VeraBank account data

Three routes genuinely apply to this app. Each is described by what it reaches, how durable it is, and what we set up to run it — access and authorization are arranged with you during onboarding, against a consenting VeraBank login.

1 — User-consented aggregation

The dominant US path for bank balances and transactions: consent-based connectivity, the same class of rails the established US aggregators use to read bank accounts with the customer's authorization. Reaches accounts, balances and transaction history cleanly and stays durable across app releases because it tracks the data layer, not the screen. It does not carry e-statement PDFs, check images, or the treasury console.

2 — Authorized interface integration of the app session

Under the customer's authorization we analyse and replay the VeraBank app's own authenticated Q2 session — device-bound login, MFA, token refresh — and reach everything the app shows: statement and item-image binaries, send-money status, and the commercial treasury surface that route 1 cannot see. Highest coverage; the maintenance cost is tracking Q2's release cadence, which we account for (see the engineering notes).

3 — Native online-banking export

VeraBank online banking and the app expose downloadable e-statements and transaction export in standard ledger formats. A reasonable fallback for periodic, non-real-time needs — a monthly accounting close, an archive job — with no live session to maintain.

For VeraBank specifically we would build route 2 as the backbone, because the statement images and treasury operations are the surfaces clients actually ask for and only the session route carries them, then run route 1 in parallel so the everyday balance and transaction sync stays durable without re-touching the session. Route 3 is kept as the low-maintenance archival path.

A statement-and-transaction call against the Q2 session

Illustrative shape of the session route. Field names are confirmed during the build against a consenting login; this is not transcribed from a published specification.

# Illustrative only — names verified during the build.
POST /q2/auth/session                 # device-bound login
  body: { user, secret, device_id }
  -> 200 { session_token, mfa_required: true }

POST /q2/auth/mfa
  body: { session_token, otp }
  -> 200 { access_token, expires_in: 1200 }     # ~20 min TTL

GET  /q2/accounts
  Authorization: Bearer <access_token>
  X-Device-Id: <device_id>
  -> 200 [ { account_id, nickname, type: "DDA"|"SAV"|"LOAN",
             available_balance, current_balance, currency: "USD" } ]

GET  /q2/accounts/{account_id}/transactions?from=2026-01-01&to=2026-03-31
  -> 200 { items: [ { posted_at, description, amount,
                      running_balance, category, check_image_url? } ],
           next_cursor }

# Treasury role — a separate entitlement on the same session
GET  /q2/treasury/ach/batches?status=pending_approval
  -> 200 [ { batch_id, sec_code, total_amount, effective_date,
             approvals_required, approvals_have } ]

# Error handling the client must implement
401 -> token expired; re-auth via /q2/auth/session
429 -> exponential backoff, honor Retry-After
409 -> treasury approval state moved; re-fetch the batch before retry
      

What lands in your repository

Deliverables are tied to VeraBank's real surfaces, not a generic kit:

• An OpenAPI/Swagger specification covering the accounts, transactions, statement-image and treasury-batch operations as modelled above.
• A protocol and auth-flow report: the Q2 device-bound login, MFA step, bearer-token TTL and refresh, and how the consumer and treasury entitlements separate on one session.
• Runnable source for the key endpoints in Python and Node.js — balance and transaction pull, paged history with cursor, the tokenized statement/check-image fetch, and the treasury batch read/approve calls.
• Automated tests against a consenting account, including the 401 re-auth, 429 backoff and 409 treasury-state paths.
• Interface documentation, plus data-retention and consent-logging guidance scoped to a US bank's records.

Engineering realities of a dual retail-and-treasury app

Two things about this app drive the build, and we handle both as part of the work:

• One session, two entitlement worlds. A VeraBank login can carry personal accounts and a treasury role that originates ACH and wire batches and administers other users. We map that entitlement tree explicitly so a consumer-scoped pull never reaches the origination surface, and a treasury-automation build never reads a personal ledger it was not authorized for — the split is designed in, not assumed.
• Q2 ships on its own cadence. The platform updates independently of the bank. We pin the integration to the session and transaction layer rather than the front end, and keep a maintenance check that re-runs the capture whenever a new build lands, so a cosmetic release does not quietly break the feed.
• The app both holds and aggregates data. It shows VeraBank records and aggregated non-VeraBank balances side by side. We scope extraction to the VeraBank-held data and treat aggregated external balances as display-only, so the integration does not over-reach into other institutions' records without their own consent.

Consent and the US data-rights picture for a Texas national bank

For a national bank like VeraBank, N.A., reaching account data is a consent question rather than a regulatory entitlement. The federal personal-financial-data-rights rule that would have set a uniform US data-access mandate is currently paused pending reconsideration, so we do not build VeraBank access around it; the route runs on the customer's own authorization under the bank's online-banking agreement and US financial-privacy law (GLBA). Consent is explicit and scoped to the data domains the project needs, with revocation honored on the customer's side. We keep consent records and access logs, minimize what is pulled to the agreed domains, and work under an NDA where the engagement calls for one. That is how the studio operates as a matter of course.

Where teams put VeraBank data

• Accounting close. Nightly posted-transaction and running-balance pull per DDA into a ledger, with cleared checks matched by their item-image link.
• Treasury automation. Surface pending ACH and wire batches with approval counts into an ERP cash console, and push approve or reject back through the same entitlement.
• Portfolio monitoring. Periodic FICO score and balance-trend feed for a lending or credit-monitoring product.
• Compliance archive. Scheduled e-statement PDF and deposit-image capture into a retention store with audit logging.

Screens we mapped

Public store screenshots used while modelling the app's surfaces. Select to enlarge.

Other Texas and regional bank apps in the same integration class

The same data shape — authenticated consumer and business accounts behind a mobile app — recurs across these institutions, which is why a unified integration layer is worth building once and reused. Ecosystem context, not a ranking.

• Southside Bank — Tyler, Texas; consumer and business accounts, mobile deposit and Zelle, on a Q2-family stack, the same kind of session and ledger surface.
• Texas Bank and Trust — East and North Texas community bank; bill pay, transfers and card controls behind an authenticated app.
• Prosperity Bank — large Texas bank with consumer and commercial accounts, statements and transfers in one app.
• Austin Bank — East Texas community bank holding the same balance, transaction and statement records per customer.
• Frost Bank — Texas bank with deep consumer and treasury offerings and a comparable authenticated data surface.
• First Financial Bank — Texas regional bank; accounts, transactions and document images behind login.
• Independent Financial — Texas-based bank with consumer and commercial banking and treasury services in one app.
• Broadway Bank — San Antonio bank holding personal and business account data, statements and transfers per customer.

Questions integrators ask about VeraBank

Can you reach the VeraBank treasury surface — ACH and wire batches, Positive Pay — or only the consumer accounts?

The treasury console rides the same Q2 session as the retail accounts. We map the commercial entitlement separately from the consumer one, so an integration scoped to cash-position reporting does not touch ACH or wire origination, and a treasury-automation build does not pull a personal checking ledger it was not authorized for.

The VeraBank app aggregates non-VeraBank accounts too — does that mean you can pull my external balances?

The app shows aggregated external balances for display, but those originate at other institutions. By default we extract the VeraBank-held records and treat aggregated third-party balances as display-only, unless access to a given external account is separately consented at its own source.

VeraBank runs on the Q2 platform — will an app release break the integration?

Q2 ships on its own release cadence. We pin the integration to the session and transaction layer rather than to the front end, and keep a maintenance check that re-runs the capture against a new build, so a cosmetic update does not silently break the feed.

We need VeraBank e-statement PDFs and check images, not only transaction JSON — is that one delivery?

Yes. The statement and check-image fetch is delivered as its own tokenized-URL handler alongside the JSON transaction feed, since the binaries sit behind short-lived signed links rather than in the ledger response. Both ship together in the same one-to-two-week cycle.

Sources and review

Compiled from public sources on 2026-05-18 by OpenBanking Studio's integration desk: VeraBank's own personal mobile-banking pages and Play/App Store listings for the app's stated feature set; Q2's customer announcement for the digital-banking platform and the dual consumer/commercial rollout; and the CFPB and Federal Register records for the current status of US personal-financial-data-rights rulemaking. Primary references:

• VeraBank — Personal Mobile Banking
• Q2 Holdings — VeraBank digital-banking rollout announcement
• CFPB — Personal Financial Data Rights
• Federal Register — Personal Financial Data Rights Reconsideration

The session, statement-image and treasury endpoints arrive as runnable source you can read before you pay anything — source-code delivery starts at $300, settled after delivery once it works against a consenting VeraBank login. Prefer not to host it? Call our hosted endpoints instead, priced per call with nothing up front. Either model runs a one-to-two-week cycle. Tell us the app and what you need from its data; access and compliance are arranged with you from there — start the conversation here.