Authorized data integration for Peoples State Bank of Velva

Peoples State Bank of Velva runs one mobile front-end — branded PSB Velva, package com.psbvelva.grip per its Play Store listing — across a two-branch footprint in Velva and Minot, North Dakota. The bank itself has been state-chartered and FDIC-insured since the 1930s, with roots back to 1915 per the bank's own about page. For an integrator, that means a single, narrow back-end to map: one mobile session model, one statement format, one set of in-app surfaces that mirror the bank's online-banking platform. Our job is to expose that back-end as a clean, runnable interface for your system, under the account-holder's own authorization. Lead with the data; consent and access are arranged with you during onboarding, not something you have to assemble before we begin.

Authorized routes to PSB Velva data

The integration is not built on a single channel. We pick from the following based on what data you actually need and who is consenting.

1. Authorized interface integration of the mobile backend. Under the account-holder's consent, we map the request signing, token rotation and JSON envelopes used by the PSB Velva app and expose them as your endpoints. Strongest coverage of in-app surfaces (balance, transaction ledger, transfer instructions, mobile deposit, card controls). Highest fidelity for real-time posting. Refresh effort scales with the bank's vendor cycle — we re-verify on schedule.
2. Consumer-permissioned aggregator route. PSB Velva already aggregates external accounts inside the app, so a US data aggregator (Plaid, MX or Finicity in this market) almost certainly already has a connection class for it. For accounts that fit into the standard balance and transaction shape, this is the cheapest and most durable read path. FDX-aligned where the aggregator publishes it that way.
3. Online-banking export of statements. The bank's online banking exposes monthly statements directly. Fallback channel for archival and reconciliation when a richer feed is overkill.
4. Direct cooperation with the platform vendor. The .grip suffix recurs on a small set of unrelated US community-bank apps (com.psbbanks.grip, net.psbnewton.grip among them, per Play Store listings), pointing at a shared white-label vendor. Where the vendor will work with you under an introduced commercial agreement, that becomes the steady-state path. We have surfaced this option for clients before and we can scope it.

For most integrators here, route 1 is what we build first and route 2 sits next to it for the external-account fan-out. Routes 3 and 4 are kept warm rather than primary.

Data domains held by PSB Velva

What lands in a PSB Velva delivery

• Runnable Python and Node.js clients for the balance, ledger, transfer, statement and mRDC surfaces — installable from the repo, with request signing and session refresh baked in.
• A Node.js webhook receiver for posted-transaction and balance-threshold events, idempotency-keyed on the posting reference so a replayed delivery does not double-post.
• A test harness with fixtures captured against the access we set up together — runs in CI, fails loudly if a vendor-side response shape drifts.
• A reconciliation script that walks the statement endpoint and compares against the ledger feed — useful in the first few weeks while you build confidence in the live path.
• Configuration for an SDK target of your choice; Go is the third language we ship without much fuss.
• OpenAPI document covering the endpoints we expose to your stack.
• Auth-flow write-up: the session model used by PSB Velva, token lifetimes, the rotation strategy, and the failure modes we observed during the build.
• Short retention and consent memo describing how the consumer's authorization is captured, logged, and revocable.

Webhook handler — illustrative

The receiver below is the shape we ship for posted-transaction events on PSB Velva. Field names follow what we see during the build and are confirmed against the live response before the repo is handed over.

// node 20 — receives a posted-transaction event from the PSB Velva integration
// signature: HMAC-SHA256 over the raw body with the shared secret you provision.
import express from 'express'
import crypto from 'node:crypto'

const app = express()
app.use(express.raw({ type: 'application/json', limit: '256kb' }))

const SECRET = process.env.PSBV_WEBHOOK_SECRET
const seen = new Map()  // swap for redis in prod

function verify(sig, body) {
  const mac = crypto.createHmac('sha256', SECRET).update(body).digest('hex')
  return crypto.timingSafeEqual(Buffer.from(sig, 'hex'), Buffer.from(mac, 'hex'))
}

app.post('/psbvelva/posted', (req, res) => {
  const sig = req.header('x-psbvelva-signature') || ''
  if (!verify(sig, req.body)) return res.status(401).end()

  const evt = JSON.parse(req.body.toString('utf8'))
  // evt: { event_id, account_id, posting_ref, amount_cents, currency,
  //        direction: 'debit'|'credit', posted_at, description, tags[] }

  if (seen.has(evt.posting_ref)) return res.status(200).end()
  seen.set(evt.posting_ref, Date.now())

  // hand off to your ledger; never block the receiver on downstream work
  queue.publish('psbvelva.posted', evt)
  res.status(202).end()
})

app.listen(8080)

Statement and mRDC surfaces are similar — the deposit endpoint takes a multipart body with the front and back image plus a deposit metadata block, and returns a deposit reference we then poll until cleared.

Engineering notes for this build

A few app-specific things we account for, and what we do about them so they do not surprise you in week three.

• Shared white-label backend. The .grip package suffix recurs across unrelated community-bank apps. We map the platform's common surface once on our side and then layer the PSB Velva tenant overlay (tenant id, branding endpoints, configured products) — so the integration is portable to the next bank on the same platform with mostly configuration work, not a rebuild.
• In-app aggregation already routes through a third-party data aggregator. Rather than re-scrape every external institution PSB Velva can link, we wire to whichever aggregator the consenting customer is already authorising inside the app and inherit that consent record. This keeps the external-account fan-out within the same legal frame as the in-app aggregation feature.
• Mobile remote deposit is binary and order-sensitive. The mRDC path accepts JPEG or PNG image pairs and is fussy about orientation, lighting and the back-of-check endorsement; we run a Mitek-style image preflight inside the client so the user sees a "retake" message instead of a silent reject.
• Session lifetimes are short. Mobile-banking sessions on a platform of this size typically rotate inside fifteen minutes. The SDK refreshes ahead of expiry and treats a re-auth challenge as a structured event your code can subscribe to, rather than a silent disconnect.
• Two-branch operational footprint. Single-tenant, single-region, no clustered identifier collisions across markets — so we do not have to design around multi-jurisdiction routing the way we would for a national issuer. Less code; cleaner test fixtures.

Regulatory posture and consent

The integration runs under the account-holder's own authorization to access their data — captured, logged, and revocable. The legal anchor today is the bank's online-banking agreement and GLBA's safeguards posture; for the aggregator route, the aggregator's consumer-permissioned data-sharing flow is the consent record. FDX is the de facto US standard for the shape of that data and is gradually being adopted across community-bank platforms, per Financial Data Exchange materials.

Section 1033 — the CFPB Personal Financial Data Rights rule — is the forward-looking piece, not the basis the integration relies on today. The rule was finalized in late 2024 and then enjoined; the CFPB issued an Advance Notice of Proposed Rulemaking on reconsideration in August 2025, and a federal court ordered the Bureau to stop enforcing the rule while reconsideration runs, per the CFPB's own rules-under-development page. We treat 1033 as where the obligations may eventually sit, not as today's law. For a state-chartered community bank of this size the agency's original phased schedule put the compliance obligation well into the future even when the rule was in force; nothing we ship presumes the original deadlines hold. Privacy posture (data minimisation, retention windows, deletion on revocation) is shaped to what the customer consents to, with NDA cover where the engagement calls for it.

Engagement and pricing

A typical PSB Velva delivery is one repository — the Python and Node.js clients, the webhook receiver, the test harness and the reconciliation script — plus the OpenAPI document and the auth-flow write-up alongside it. Source-code delivery starts at $300 and is settled after delivery, once the build runs end-to-end against the access we set up with you. The alternative is the hosted route: you call our endpoints, we operate them, and you pay per call with no upfront commitment. Cycle is 1–2 weeks from kick-off. You tell us the app name and what you want out of the data — access, sponsor introductions and any compliance paperwork are part of the engagement, handled with you. Start at /contact.html.

Review and sources

This page was checked against the bank's own materials, the Play Store listing, the ICBA community-bank directory, the FDIC institution record, and the CFPB's reconsideration page. Citations link out below to the primary records.

• Peoples State Bank of Velva — official site
• PSB Velva on Google Play
• ICBA community-bank directory entry
• CFPB — Personal Financial Data Rights Reconsideration
• Financial Data Exchange (FDX)

OpenFinance Lab — engineering notes, June 2026.

Questions from integrators

Does the integration push transactions in real time or do we have to poll?

Both paths work. Where the bank's online-banking session can be held open against a consenting account, we expose a webhook that fires on a posted-transaction event. Where it cannot, we configure a cursor-based poll on a 30 to 60 second cadence and replay any gap from the statement endpoint. The choice depends on the access we arrange together. Tell us how often you actually need the data and we will design accordingly — /contact.html.

Which language clients ship with the build?

Python and Node.js by default; Go on request. The repo includes the request signer, the session-refresh loop, and a replay-safe webhook receiver. The same surface is also reachable through our hosted endpoints if you would rather skip the local install.

Can the integration cover the external accounts aggregated inside PSB Velva, or only the bank's own ledger?

PSB Velva's in-app aggregation feature points at an upstream data aggregator. For external-account data we wire that same aggregator (Plaid, MX or Finicity in this market) under the consumer's consent, rather than re-implementing each linked institution. The bank's own checking, savings, statements, card controls and deposit images come from the PSB Velva backend directly.

Adjacent community-bank and credit-union apps in the same data shape

These apps occupy the same integration neighbourhood — small-to-mid US community institutions or North Dakota credit unions. Each holds the same broad data shape behind a customer login and slots into the same integration design with tenant configuration rather than a new build.

• Dakota Community Bank & Trust mobile — North Dakota community bank with the same balance, ledger, transfer and mobile deposit feature set.
• Dakota Plains Credit Union — ND credit union app covering balances, transactions, transfers and bill pay.
• Capital Credit Union ND — Bismarck-based credit union with real-time balances, mobile deposit, card controls and P2P pay.
• North Star Community Credit Union — ND credit union with the same online-banking-backed mobile surface and bill pay.
• Aspire Credit Union (Minot, ND) — Minot-based credit union with online and mobile banking, loans and checking.
• First Community Credit Union ND — multi-branch ND credit union with mobile deposit and standard digital banking.
• Citizens Community Credit Union (CCCU) — ND credit union with a mobile app of the same shape.
• Bremer Bank Mobile — larger Upper Midwest community bank, useful as a comparator on the higher-asset tier.
• Bell Bank Mobile — Fargo-headquartered community bank, similar mobile-banking surface.
• First International Bank & Trust — ND-headquartered community bank with a comparable digital-banking front-end.

Interface evidence

Screens captured from the Play Store listing — login, dashboard, account detail, mobile deposit, and the aggregation view. Useful when scoping which surfaces matter for your build.