What sits behind the Vermillion State Bank app, and how to talk to it

FDIC certificate 10214 per the FDIC BankFind record, a branch network around the southeast Twin Cities listed across public branch directories, and a mobile app that does something most community banks of this size don't — it ingests balances from other institutions too. That last detail is the reason this page is longer than it looks like it should be: the Vermillion State Bank app is not only a window on Vermillion's own core, it's also a thin PFM hub that mirrors the customer's external accounts. For an integrator, that means two data planes living behind one login.

The bottom line up front: we recommend a customer-consented interface integration that reads the native Vermillion ledger directly, treats the aggregated external accounts as a clearly labelled second source, and ships as runnable source with an OpenAPI spec the customer's team can host. Where a downstream system would prefer not to hold credentials, the same integration runs as our pay-per-call endpoint.

What the app actually stores

Reading the in-app feature copy on Vermillion's own site against the screens the Play Store listing shows, the surfaces an integrator cares about look like this:

Most pieces are exactly what a retail banking integration expects. The PFM mirror is the wrinkle worth labelling early — its refresh cadence and trust level are not the same as the native ledger, and downstream code that treats them as one will eventually get a balance wrong.

Three ways into it

1. Authorized customer-session integration

The dependable route here. We act under the consenting customer's standing online-banking authorization and read what the customer's own app reads. Effort sits in the auth-flow capture, the per-session token handling, and the parser that maps the portal's response shapes onto a clean schema. Access onboarding — the consent form, the test login, the device-pairing piece — runs as part of the build with the customer; the engineer never works from a fake account.

2. PFM-aggregator passthrough

Because the in-app aggregation is the customer's data too, a downstream system can read it through the same session that route 1 uses. We mark every aggregated line with the source institution and the refresh timestamp the aggregator hands the app, so the downstream system can apply its own staleness rules. This is the route we use when the customer's real goal is a full picture rather than only their Vermillion accounts.

3. Native export bridge

The Vermillion online portal lets a customer download account statements; the app surfaces the same statement history. For low-frequency use — quarterly accounting, year-end ingestion — we can build a thin export-handler that polls for new statement files and parses them on receipt. Cheaper to maintain, but no good for anything that needs to see today's posted transactions.

In practice route 1 carries most of the build, with route 2 layered onto the same authorized session; route 3 sits as a fallback or as the read path for an accountant who only needs end-of-quarter.

A working request, sketched

Illustrative — exact paths, header names and response shapes are confirmed during the build against the consenting customer's session, never guessed.

POST /grip/session/login              # establish the customer-session token
Headers: User-Agent, X-Device-Id (paired during onboarding)
Body:    { "username": "...", "password": "...", "passcode": "..." }
Returns: { "session": "...", "expires_in": 1500, "accounts": [...] }

GET /grip/accounts/{accountId}/transactions?from=2026-04-01&to=2026-04-30
Headers: Authorization: Bearer <session>
Returns:
{
  "account_id": "...",
  "source": "native" | "aggregated",
  "as_of": "2026-04-30T22:41:12-05:00",
  "transactions": [
    { "id": "...", "posted_at": "2026-04-29",
      "amount": -42.18, "merchant": "...", "memo": "...",
      "tags": ["fuel"], "note": "...", "image_ref": null,
      "geo": { "lat": ..., "lng": ... } }
  ]
}

# Refresh on 401: re-issue session and replay; do not retry blindly.
# Aggregator-sourced lines carry a separate as_of; respect it for staleness.

What we hand over at the end

• An OpenAPI 3.1 spec covering session, accounts, transactions, statements, alerts and the PFM-mirror endpoints, with the native/aggregated distinction modelled at the schema level.
• A protocol and auth-flow report documenting the session and device-pairing chain captured during the build, with replay traces redacted of customer data.
• Runnable source — Python by default, Node.js on request — for the read endpoints listed above, including session refresh, error classification and a parser that fails loudly when the portal changes shape.
• An automated test pack: contract tests against recorded responses, plus an end-to-end smoke test the customer can re-run after each portal change.
• Interface documentation written for the engineer who will inherit it, not for marketing — including the known fragile points and where to look first when something breaks.
• A short compliance pack: the consent template, retention defaults, log schema and data-minimization notes calibrated to GLBA and Regulation P expectations.

Things the build has to account for

• Two data planes, one login. Native Vermillion ledger lines and aggregated external-bank lines live in the same response surface but are not interchangeable. We separate them at parse time and tag every persisted record with its source, so a downstream reconciliation cannot silently compare a native balance to an aggregator-cached one.
• 4-digit passcode and device pairing. The app's described 4-digit passcode and device-bound session shorten the useful lifetime of any captured auth chain. We design the integration around a documented re-pairing path with the customer — the build does not depend on a single device staying enrolled forever.
• Aggregator refresh cadence. The PFM-mirror balances do not refresh on the same clock as the native ledger; they refresh whenever the aggregator's job last ran. We surface that timestamp in the schema rather than masking it.
• Portal front-end drift. Community-bank online-banking platforms refactor on a vendor schedule rather than the bank's. The build ships with a scheduled re-validation of the captured request and response shapes, so a layout change surfaces in the next scheduled run rather than in a customer ticket.
• Statement formats. The downloadable statements that route 3 leans on come in a fixed set of formats per account type; we parse them all, but we pin the parser version so a silent format tweak doesn't degrade history.

How a typical month runs

• A regional CPA pulls each small-business client's posted Vermillion transactions overnight and pushes them into the firm's AP/AR system, tagged by client.
• A wealth manager mirrors a client's full position — Vermillion accounts plus the external accounts the client has linked through the app's PFM tile — into a single portfolio view, with the aggregator source clearly labelled on each external line.
• An internal-audit tool re-fetches the previous business day's transactions every morning, diffs them against the firm's own books, and routes mismatches into a review queue before the close.

Consent and the §1033 question

For a US community bank of Vermillion's size, the dependable basis for data access today is the customer's own authorization, not a federal data-portability mandate. The integration we deliver runs against that authorization: a written, dated consent record naming the data domains in scope and the retention window, kept alongside the source and re-confirmed on credential change. GLBA and Regulation P shape how we handle, log and minimize the data once it's pulled; NDAs cover the engagement where the customer requests one.

The CFPB's Personal Financial Data Rights rule — 12 CFR Part 1033 — is where this picture may eventually move, but it isn't there yet. The Bureau finalized the rule and a court then enjoined its enforcement; in 2025 the CFPB issued an Advance Notice of Proposed Rulemaking reopening four areas of the rule (who counts as a "representative," fee assessment, data-security cost-benefit, and privacy threat picture). We track the reconsideration and design the integration so a future §1033-style endpoint at this institution, if and when one applies, becomes a swap-in for the route 1 spine rather than a rewrite.

How this brief was put together

The institutional facts come from the FDIC BankFind record for Vermillion State Bank (FDIC cert 10214) and the bank's own mobile-app page. The Play Store listing for com.vermillionbank.grip and the App Store entry for the iOS build provided the feature copy and screen flows referenced above. The regulatory posture is anchored to the CFPB's own Personal Financial Data Rights reconsideration page. Reviewed 2026-05-24 by the OpenBanking Studio integration desk.

Other Minnesota and small-bank apps in the same orbit

An integrator scoping a Vermillion build often ends up scoping one of these in the same quarter; the data shapes rhyme, the auth chains do not.

• Bell Bank — a Twin Cities and Upper Midwest community bank whose mobile app exposes a similar deposit/loan ledger plus a separate small-business portal.
• Highland Bank — Minnesota community bank with a Twin Cities footprint, focused on business banking with a more traditional balances-and-transactions app surface.
• Frandsen Bank & Trust — multi-state community bank across Minnesota and Wisconsin; its app holds the same balances/transactions/statement set without the embedded PFM mirror.
• Community Resource Bank — a Northfield-area community bank close geographically to Vermillion, with a typical retail banking app.
• North American Banking Company — Twin Cities business bank with a heavy treasury-management slant in its digital surface.
• Minnwest Bank — agricultural and small-business community bank across greater Minnesota, with a comparable mobile data surface.
• BankWest — small-state community bank app comparable in surface area to Vermillion's native side.
• Bank of Brookhaven — community-bank mobile app at a similar size, useful as a peer when normalising cross-bank schemas.

Questions integrators actually ask about this one

Does the data we pull include the external accounts that customers have linked into the Vermillion app?

Yes, that is the more interesting half of the picture. The app's marketing leads on multi-account aggregation, so a customer's profile inside the Vermillion mobile portal typically holds both the bank's own deposit and loan accounts and a mirror of accounts at other institutions added through the PFM tile. An integration scoped through that consenting customer reaches both layers; we model them as separate sources so downstream code can tell a native Vermillion balance from an aggregated mirror balance refreshed via a third party.

How is consent recorded when the integration runs against a real customer login rather than a sandbox?

We capture written, dated consent from the customer naming the data domains in scope and the retention window, store it alongside the build, and re-confirm it whenever the customer's password or device pairing changes. Internet Banking credentials never sit in plain text inside the source we deliver — they pass through a token vault and the deliverable is wired to fail closed if the consent record is missing or expired.

Will the integration keep working if Vermillion changes its mobile platform or its PFM partner?

It will need maintenance — that is honest. We design the request and response handlers around stable identifiers (account number, posted date, amount, merchant string) and we re-run the protocol capture as part of every quarterly check. When the portal front end shifts, the parser is the small piece that has to move; the schema and downstream code do not.

What about CFPB Section 1033 — does our integration become unnecessary once the rule is in force?

Section 1033, the Personal Financial Data Rights rule the CFPB finalized and then had enjoined, is currently under reconsideration with the agency soliciting comment on representative status, fees, security and privacy. Even if a future version of the rule mandates a standardized feed at a community bank of this size, the integration we deliver today still has value — it runs now against the customer's own authorization, and we can re-platform onto a future §1033 endpoint when one actually exists and applies.

What the app looks like

Screens referenced while drafting the data-domain table above. Click to enlarge.

Bringing this in is straightforward to scope: send us the app name and what you need from its data, and we'll come back with a route, a price and a calendar. Source-code delivery starts at $300, paid after delivery once you're satisfied with what arrived — that buys you the runnable Python (or Node) source for the routes above, the OpenAPI spec, the test pack and the documentation. The alternative is a pay-per-call hosted API: we run the integration, you hit our endpoints, and the bill is just the calls — no upfront fee. Either path runs on a 1–2 week cycle at this scope. Start the conversation at /contact.html.