How a third party reaches the same account portal BotV Mobile uses

BotV Mobile already pulls external bank and credit union accounts into one view — the integration target sits on the same member portal behind that view. Bank of the Valley is a seven-branch community bank out of Bellwood, Nebraska. Reaching its mobile data is a small-bank problem with a particular shape: the access basis is the member's own authorization, the data surface is whatever the Internet Banking back end serves to the mobile client, and the build has to weather mobile-app refreshes without much notice from the bank's side.

Bottom line: this is not a regulated open-banking play. For a US community bank of this size, the working basis is the customer's own right to read and delegate access to their own accounts — what matters is the member portal that the BotV Mobile client speaks to, and a clean way to read it on the member's behalf. The route we'd build is consented protocol implementation against the same back end the app uses, with PDF statement export as a narrow fallback for bookkeeping cases.

What's behind the login

Each row maps to a real surface visible inside BotV Mobile per the bank's own feature page and the app's Play Store description.

Three ways in

1. Consented protocol implementation against the BotV mobile client's back end

The member authorizes us (in writing, with revocation rights) to read their own accounts. We implement the same auth, session and read calls the BotV Mobile app uses, and run them on the member's behalf. This route covers essentially everything visible in the app — balances, postings, statements, transfer initiation, the works. Effort: a couple of weeks for a clean first build; durability is good as long as the bank's back end is more stable than the app shell, which it usually is at this size. Access onboarding is handled with the client, not asked of them up front.

2. PDF statement export

Monthly statements available inside the app are usable as a narrow ingest channel — fine for accounting feeds, useless for real-time cashflow. We treat this as a complement, not a primary route. Effort: low. Durability: high, because statement PDFs change shape rarely.

3. Direct work with Bank of the Valley under a written partnership

Possible. For a seven-branch bank this is slow, sponsor-dependent, and not the default path most projects need. We mention it because it occasionally fits — for instance when the integrating party is a Nebraska business with a deep account relationship and wants formal letterhead. We arrange the introduction and paperwork as part of the engagement when it is the right call.

What we'd usually run for a project landing on BotV Mobile is route one with route two as a complement for archival ingest. Route three sits in reserve for the cases where the customer wants it.

Session sketch

An outline of a member-consented session against the Bank of the Valley Internet Banking back end. Host, header and field names below are illustrative — exact values are confirmed during the build for each app release.

def open_session(username, password, device_id):
    r = client.post(
        f"{BOTV_HOST}/auth/v1/session",
        json={
            "username": username,
            "password": password,
            "device_id": device_id,
            "channel": "mobile",
        },
        headers={"User-Agent": MOBILE_UA},
    )
    if r.status_code == 401:
        raise AuthFailed(r.json().get("error"))
    if r.status_code == 403:
        # MFA gate — SMS code, security questions, or device registration
        return mfa_challenge(r.json())
    body = r.json()
    return Session(
        token=body["token"],
        refresh=body["refresh_token"],
        expires_in=body["expires_in"],
    )

def list_accounts(session):
    r = client.get(
        f"{BOTV_HOST}/banking/v1/accounts",
        headers={"Authorization": f"Bearer {session.token}"},
    )
    r.raise_for_status()
    return [normalise(a) for a in r.json()["accounts"]]

def transactions(session, account_id, since):
    r = client.get(
        f"{BOTV_HOST}/banking/v1/accounts/{account_id}/transactions",
        headers={"Authorization": f"Bearer {session.token}"},
        params={"since": since.isoformat(), "limit": 200},
    )
    r.raise_for_status()
    return [
        # member-added tags, notes and check photos surface here as optional fields
        normalise_posting(p) for p in r.json()["postings"]
    ]

What ends up in your repo

For BotV Mobile the practical deliverables are:

• Runnable source for the auth, account-list, transaction, statement and transfer endpoints (Python by default; Node.js if your stack prefers it).
• An OpenAPI 3.1 description of the surfaces above, normalised to ISO 4217 currency codes and ISO 8601 timestamps.
• A protocol and auth-flow report covering device registration, token rotation, MFA branches, and how the member-consent record is stored and revoked.
• Automated tests against a recorded session of a consenting member account, plus a smoke test that runs against the live back end so contract drift gets caught on each app release.
• Interface documentation written for the engineer who will operate the integration — not a slide deck.
• A short data-retention and minimization note specific to a US deposit-account integrator: which fields to keep, which to drop, how long to keep the consent record, who can revoke and how.

Build scenarios

Three shapes this work typically takes.

• Bookkeeping for a Bellwood-area small business. Pull postings nightly into the accounting tool of choice; carry member-added tags through; archive monthly statements as PDFs. Route one for live data, route two for the audit trail.
• Personal financial dashboard. Read balances, postings and the external-account aggregation view so the member sees BotV alongside other holdings in one app. Route one only; the aggregated outside accounts are treated as a snapshot, not authoritative.
• Treasury automation for a multi-entity client. Initiate internal transfers on a schedule, watch balance alerts, push mobile-deposit submissions through programmatically. Route one with extra care around business-account permissions and ACH surfaces.

Engineering judgments specific to this build

The shape of the work here turns on a few things we account for up front.

• Same back end, two front ends. Internet Banking on the web and BotV Mobile both speak to one set of services. We version the integration against the mobile build so a web-only redesign — the more common refresh — does not move the contract under us. The web client serves as a useful cross-check during the build, not as the primary target.
• MFA on first device, then device-token reuse. The app challenges with SMS, security questions or device registration on first login. We capture the device-token issuance once during onboarding and rehydrate it so the integration does not produce a fresh challenge on every sync; we also wire the path back through the challenge cleanly when the token is revoked.
• The aggregation surface is downstream, not authoritative. External accounts inside BotV are themselves fed by a third-party aggregator. When the project goal is the member's BotV view, we read that surface as is. When the goal is fresh data from the other banks, we wire those integrations directly rather than chaining through the BotV portal.
• Personal vs business surfaces. Business accounts at the bank expose multi-user permissions, ACH origination and positive-pay flags that personal accounts do not. We scope the integration per account type so the right surfaces show up — and so a permission belonging to one user doesn't leak through the integration to another.

The legal anchor we actually use

For a US deposit account at a state-chartered Nebraska community bank, the dependable basis is the customer's own right to access and delegate access to their own accounts. We document that consent — purpose, scope, fields, retention, revocation path — and store it alongside the integration. The CFPB's Personal Financial Data Rights rule under §1033 is the open question for this segment: it was enjoined from enforcement and is back in agency reconsideration, and it is not what we anchor any current build on. If and when reconsideration lands somewhere stable, we adjust. NDAs and per-engagement data-handling addenda are arranged with the client during onboarding — they are part of how we work, not a hoop we ask the client to clear before we start.

Price and turnaround

$300 buys runnable source for the BotV Mobile flows you actually need — paid after we hand the code over and you've satisfied yourself it works against a consenting account. The hosted alternative is a pay-per-call endpoint we run: no upfront fee, you pay per request. One to two weeks is the usual cycle for the core surfaces above; business-side ACH or positive-pay work adds to that. Send the app name and what you want to read out of it via the contact page and the brief comes back the same week.

Interface evidence

The screens used while writing this brief. Click to enlarge.

Peer community-bank apps in the same shape

Other US community and regional banks whose mobile apps share the data shape covered above. Listed for ecosystem context, not ranked.

• Platte Valley Bank Mobile — Nebraska and Wyoming regional bank, similar deposit-account and mobile-deposit surfaces.
• First Nebraska Bank Mobile — small Nebraska community bank with a comparable Internet Banking back end.
• Pinnacle Bank Mobile — multi-state community bank (NE/KS/MO) with a deeper feature set on the same backbone.
• NebraskaLand National Bank Mobile — small-business and personal accounts behind one mobile client, similar to BotV.
• American National Bank — Omaha-headquartered community bank, similar member portal pattern.
• Cornhusker Bank Mobile — Lincoln-based, classic community-bank mobile feature set.
• First National Bank of Omaha — larger regional, useful as a reference shape with richer business surfaces.
• Nodaway Valley Bank Mobile — neighbouring-state community bank, similar Internet-Banking-fed app.

Source notes

What was checked while writing this: the Bank of the Valley Internet Banking page for the published feature list; the BotV Mobile Play Store listing for the package name and stated capabilities; the FDIC BankFind record for charter status; and the CFPB's published reconsideration record for the federal data-rights rule.

• bankofthevalley.com — Mobile Banking
• Play Store — BotV Mobile (com.bankofthevalley.grip)
• FDIC BankFind — Bank of the Valley record
• CFPB — Personal Financial Data Rights Reconsideration

Reviewed 2026-05-21 by the OpenBanking Studio integration desk.

Questions that come up

BotV Mobile already aggregates external bank and credit union accounts — can a third party tap that same aggregated view?

Yes, but treat it as a downstream view, not a primary source. The aggregation surface inside BotV Mobile is fed by a third-party aggregator pulling other institutions into the bank's own portal. If the goal is a snapshot of what the member already sees inside BotV, reading that surface is fine. If you need fresh, authoritative data from those external banks, wire those integrations separately rather than chaining through the BotV view.

Does the integration cover both personal and business accounts at Bank of the Valley?

It can. Both account types live behind the same Internet Banking credentials and the same mobile client, but the data surfaces differ — business accounts expose multi-user permissions, ACH origination, and positive-pay flags that personal accounts do not. We map the relevant surfaces during the build per the project's actual account mix.

What happens to the build when Bank of the Valley pushes a new app version?

Most field-level renames and endpoint moves are absorbed quickly because the underlying Internet Banking back end changes less often than the app shell. We run a smoke-test pass on each fresh build and patch contract drift as part of maintenance. A full server-side rewrite is rare for a bank this size, but if one ships we re-baseline the integration.

If a member adds a tag, note, or check photo to a transaction in BotV Mobile, can the integration read those back?

Yes, and that metadata is genuinely useful. Tags, notes, and receipt photos written through the app are stored alongside the posting on the bank's side and surface through the same account endpoints. We map them as optional fields on the transaction record so bookkeeping and tax workflows can ingest them without losing what the member already categorised.