Wiring the Vermillion State Bank account feed into your systems

Balances and transactions from accounts a customer holds elsewhere flow into one view inside this app, alongside their Vermillion State Bank deposit and loan accounts. That blended stream — current balances, posted transactions, merchant spending averages, and the alerts layered on top — is the thing a third-party system would want to pull and keep in sync. The work below treats that feed as an event source you receive, not a screen you scrape.

The app's own description frames it as a free decision-support tool that gathers a person's financial accounts — including accounts at other institutions — into a single up-to-the-minute view. That makes the aggregated transaction list, not any single account, the centre of gravity for an integration. We build the read around that, source-tag every record, and hand back code that runs.

The data this app actually holds

Each row below is a surface the app exposes to the person using it. Where the app names something a particular way — merchant spending averages, the receipt and check images attached to a transaction — the table keeps that name.

Authorized ways in

Three routes apply here, and they stack rather than compete. We arrange the access each one needs with you during onboarding — a consenting account, a sponsor sandbox, whatever the route calls for — so none of this is a hoop you clear before we start.

Consent-based aggregation read

The account holder authorizes access to their own data — the same consent the app leans on when it logs in with Internet Banking credentials. This is the backbone. It reaches the aggregated balances, the transaction stream, and the alert configuration, and it holds up across releases because it follows the consented data path rather than a brittle screen layout.

Authorized protocol analysis of the app session

We map the session and token chain the mobile app uses to talk to its banking backend, then build a typed client against the endpoints it calls. This fills gaps the plain read leaves — enrichment attachments, alert thresholds — and is moderate effort. Durability tracks the app's release cadence; we re-capture the contract when a new version ships.

Native export, for documents

Statements and check images download from online and mobile banking. As a fallback for the document side, export covers what a live read is awkward at. It is low effort and good for backfill.

For most teams the consented read carries the build; protocol analysis covers the enrichment and alert surfaces it cannot, and export handles statements. That ordering is the one we would put in front of you first.

What you get

The headline deliverable is code that runs, not a binder. Concretely, for this app:

• Runnable client source in Python and Node.js for the aggregated-feed pull and the webhook receiver, wired to source-tag every record.
• A webhook handler with signature verification and replay-safe writes, ready to drop behind your edge.
• An automated test suite built on recorded fixtures of the session and the feed.
• A scheduler that runs a one-time backfill and then keeps a delta sync ticking between pushes.
• A normalized transaction schema that folds the outside-institution rows and the bank's own rows into one shape.

Alongside the code: an OpenAPI description of the modeled surface, a short auth-flow and token report covering the login and refresh chain, interface documentation, and data-retention guidance. Those round out the package; the runnable client is what you open first.

The feed handler, in outline

This is the shape of the inbound receiver and the normaliser, mapped to the fields this app actually carries — merchant spend averages, the user-authored tags and notes, the geo and image references on a transaction. Field names settle during the build.

# Inbound: Vermillion State Bank aggregated-feed event (modeled during the build)
# POST /hooks/vsb  - one event per posted or updated transaction or fired alert

import hmac, hashlib, json

SIGNING_KEY = settings.VSB_FEED_KEY   # issued when the consented feed is provisioned

def receive(request):
    raw = request.body
    sig = request.headers.get("X-VSB-Signature", "")
    expected = hmac.new(SIGNING_KEY, raw, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(sig, expected):
        return 401

    evt = json.loads(raw)
    if already_seen(evt["event_id"]):     # a redelivered event is dropped here
        return 200
    if evt["type"] == "transaction.posted":
        store(normalize(evt["transaction"]))
    elif evt["type"] == "alert.triggered":
        fan_out(evt["alert"])             # low-funds / upcoming-bill notice
    return 200

def normalize(t):
    return {
        "id":           t["txn_id"],
        "source":       t["institution"],          # linked outside account or VSB core
        "authoritative": t["institution"] == "vsb_core",
        "posted_at":    t["posted_at"],
        "amount":       t["amount"],
        "balance_after": t.get("running_balance"),
        "merchant":     t.get("merchant_name"),
        "merchant_avg": t.get("merchant_spend_avg"), # the app's spending average
        "tags":         t.get("user_tags", []),      # user-authored, often empty
        "note":         t.get("user_note"),
        "geo":          t.get("geo"),                # attached at capture time
        "image_ref":    t.get("receipt_image"),      # receipt or check photo
    }
      

Where teams put this feed

• A bookkeeping product that ingests a client's full transaction picture in one consented connection, instead of asking them to link six banks by hand.
• A treasury dashboard that watches the alert stream — low funds, an upcoming bill — and acts on it without a person refreshing a screen.
• A lending or underwriting flow that reads a consented transaction history and the merchant rollups to size cash flow.

Consent and the US data-rights picture

What we build on is the account holder's authorization to reach their own data — the same consent the app uses at login. Vermillion State Bank is a state-chartered, FDIC-supervised Minnesota bank, founded in 1918 and carrying FDIC certificate 10214 (per FDIC BankFind and public branch records). The CFPB's Personal Financial Data Rights rule under 12 CFR Part 1033 is where a US consumer-data feed may eventually sit, but it is not in force right now: a federal court enjoined enforcement and the Bureau reopened the rule for fresh rulemaking. We do not present it as settled law, and we do not depend on it. Access is authorized and logged, consent records are kept, data is minimized to what the integration needs, and an NDA covers the work where you want one.

What we account for in the build

Two things about this app shape the engineering, and both are ours to handle.

First, the feed is a blend. Outside-institution rows are read-only and arrive on the aggregator's refresh cycle; the bank's own accounts read close to live. We tag each record by source and reconcile the two, so a six-hour-old external balance is never mistaken for a current core balance.

Second, the enrichments are sparse and human. Tags, notes, receipt and check images, and geo sit on some transactions and not others. We model them as optional, nullable attachments and design the schema so a transaction with none of them still lands cleanly. We also schedule the sync around the account holder's authorization window and arrange re-consent with them before it lapses.

Freshness and sync cadence

The push model carries the common case: an event per posted transaction and per fired alert, verified at the edge and de-duplicated by event id. Between pushes, a scheduled delta sync reconciles, which matters most for the aggregated outside accounts where the upstream refresh is periodic rather than instant. You can dial the delta interval per account class — tighter for the bank's own ledger, looser for slow external links.

Cost and how the work runs

A first drop for this app is the aggregated-feed client and its webhook receiver, in Python and Node.js, delivered inside one to two weeks. You can have the runnable source outright, from $300, paid only after delivery once you have it in hand and you are satisfied. Or call our hosted endpoints instead and pay per call, with nothing upfront. Tell us the app and what you want out of its data, and we set up the access and compliance pieces with you. Start a project or ask a question here.

Screens from the app

Public store screenshots, for reference on what the app surfaces.

What I checked, and where

Reviewed on 2026-06-08 against the app's own store description, the bank's mobile and online banking pages, FDIC registration, and the current status of US consumer-data-rights rulemaking. The primary sources opened for this page:

• Google Play listing for the Vermillion State Bank app
• Vermillion State Bank — Mobile App page
• FDIC BankFind — institution detail (cert 10214)
• Federal Register — Personal Financial Data Rights Reconsideration

Researched and written at OpenFinance Lab — interface assessment, 2026-06-08.

Similar apps in the same orbit

Other apps that pool balances and transactions across institutions, which a unified integration tends to sit next to. Listed for context, not ranked.

• Monarch Money — subscription personal-finance tool that gathers accounts into one view for budgeting and net-worth tracking.
• Rocket Money — aggregation plus subscription tracking and budgeting, with a free tier that links accounts read-only.
• Copilot Money — design-led iOS and macOS app with strong transaction categorisation across linked accounts.
• YNAB (You Need a Budget) — zero-based budgeting that imports linked-account transactions to assign every dollar.
• Quicken Simplifi — a live spending plan driven by aggregated account activity.
• PocketGuard — links checking, savings, cards, loans and investments to show safe-to-spend after bills.
• Mint — the long-running aggregator that shut down in 2024; its users scattered to the apps above.

Questions integrators ask about this feed

How fresh is the aggregated feed, and can it push events instead of being polled?

Two clocks run side by side. The bank's own deposit and loan accounts read close to real time; balances and transactions pulled in from other institutions arrive on the aggregator's refresh cycle, so they can lag by hours. We model the integration as a push: a webhook fires on each posted or updated transaction and on each triggered alert, and a scheduled delta sync fills the space between pushes. You consume events rather than hammering a poll loop.

Does the external-institution data come through at the same fidelity as Vermillion State Bank's own accounts?

No, and the integration says so on every record. Each transaction and balance carries a source field marking it as the bank's own core data or as a read-only pull from a linked outside account. Core records are authoritative; aggregated outside records are refreshed periodically and should not be treated as a live core balance. We reconcile the two so a stale external figure never masquerades as current.

What happens to the tags, notes and receipt photos users add to transactions?

The app lets people attach custom tags, free-text notes, receipt or check images and geo-information to individual transactions. Those are user-authored and sparse, present on some rows and absent on most. We map them as optional, nullable attachments so a plain transaction is never dropped for lacking them, and we carry the image references through when document capture is in the scope you ask for.

Which rules govern access to this account data in the United States?

The dependable basis today is the account holder's own authorization to reach their data, the same consent the app itself relies on at login. Vermillion State Bank is an FDIC-supervised, state-chartered Minnesota bank (FDIC certificate 10214 per FDIC BankFind). The CFPB's Personal Financial Data Rights rule under 12 CFR Part 1033 is where a US data feed may eventually lean, but it is not in force: a federal court enjoined enforcement and the Bureau reopened it for rulemaking. We build on consent now and track where the rule lands.