Integrating a Minnesota community bank built on Banno Grip and NetTeller

The package id com.lowrystatebank.grip is the integration tell here. The .grip suffix and the bank's own description — "aggregate all of your financial accounts, including accounts from other banks and credit unions, into a single view" — both point to Banno's Grip white-label, a native aggregation app that Jack Henry's Banno team has shipped for small US community banks for years. Grip runs over NetTeller, the Jack Henry online-banking core that Banno's own platform docs name as one of its most integral underlying services.

That recognition is the whole reason this brief is concrete. We are not auditing whether Lowry State Bank has a website with a login form — we know what the host calls, the enrollment dance and the data shapes look like in this family of apps, because they are the Banno conventions. The bank itself is small (one branch, on Highway 28 between Glenwood and Starbuck, in west-central Minnesota), but it sits on a stack that 300-plus other community institutions also sit on, per Jack Henry's own platform announcements. The integration we deliver is shaped by the stack, not by the size of the bank.

What the app actually holds

Two layers of state. The inner layer is Lowry State Bank's own NetTeller-hosted account data for an enrolled customer. The outer layer is the consumer-added "aggregation" view — external linked accounts that Banno pulls in on the user's behalf and surfaces inside the same app. They are not the same surface and they integrate differently; we treat them separately.

The bank's own description is short. The integration value sits in the inner layer: per-user, authenticated, transactional, durable, and shaped to a documented vendor stack.

Three authorized paths to the data

1. Consumer-permissioned aggregator (Plaid, MX, Finicity)

Plaid, MX and Finicity all index small community banks through their routing numbers and Jack Henry's tokenized data channels. Jack Henry has stated publicly that it has "completely replaced screen-scraping with direct API connection" for sharing data from user accounts to third-party fintechs, with tokenization standing in for credentials. For most third-party use cases — pulling balances, transactions, an income view, an account-verification pull — this is the path. Effort is low. Durability is good in normal conditions and patchy when an aggregator drops a small institution; the build accounts for that with a fallback path. We arrange the aggregator account, the test sandbox and the institution selection with the client during onboarding.

2. Authorized interface integration of the Banno Grip app

For use cases that an aggregator cannot serve — e.g. tooling that needs the bill-pay status flow, statement PDFs, card-control state, or first-line behavior the aggregator flattens — we work the Banno Grip surface directly. Because Banno is a known platform and NetTeller is a known core, the protocol shape is familiar: an enrollment / login sequence that the Banno docs call the "Business Service Layer (BSL) Service" and jXchange calls during enrollment, a session-token chain, and host calls for the account, transaction and statement domains. The work runs under a consenting account belonging to the client (or a sponsor of the client), and the deliverable is documented source and tests for the endpoints in scope. Effort is medium. Durability holds across normal app updates; a UI rewrite is a re-validation event, which the maintenance contract covers explicitly so it does not catch the client by surprise.

3. Native in-app export, where it covers the case

The Lowry State Bank app supports viewing and saving monthly statements, and customers can export the underlying transactions through NetTeller online banking on the desktop (CSV / OFX / QFX are the usual NetTeller export formats). For low-frequency, batch-oriented use cases — once-a-month accounting ingest, year-end downloads — this is enough on its own and we package it as a scheduled export agent rather than an interface-integration build.

For most clients we lean on the consumer-permissioned aggregator first, with the Banno-surface path designed in as the fallback the same client code can switch to when an aggregator drops the institution or the use case outgrows the aggregator's shape. The native export route stands on its own only for the simplest, batch-style cases.

What the wire looks like

The snippet below is the read-side spine of route 1 (consumer-permissioned aggregator). The Plaid endpoints, parameters and product names are taken from current Plaid documentation; the institution-id constant ins_lowry_state_bank is illustrative and is resolved at runtime by an institutions lookup keyed on routing 091208332 — the actual id is confirmed during the build, not asserted here as fact.

# Route 1 — Plaid Link & transactions/get, illustrative
import os, plaid
from plaid.api import plaid_api
from plaid.model.transactions_get_request import TransactionsGetRequest
from plaid.model.link_token_create_request import LinkTokenCreateRequest
from plaid.model.products import Products

cli = plaid_api.PlaidApi(plaid.ApiClient(plaid.Configuration(
    host=plaid.Environment.Production,
    api_key={"clientId": os.environ["PLAID_CLIENT_ID"],
             "secret":   os.environ["PLAID_SECRET"]})))

# 1. Issue a Link token scoped to read access for this consumer.
link = cli.link_token_create(LinkTokenCreateRequest(
    user={"client_user_id": consumer_id},
    client_name="Lowry State Bank — read-only sync",
    products=[Products("transactions")],
    country_codes=["US"], language="en"))
# Consumer completes Link in our app; we receive a public_token,
# exchange it for an access_token, store it consent-scoped per user.

# 2. Pull the rolling transaction window.
resp = cli.transactions_get(TransactionsGetRequest(
    access_token=access_token,
    start_date=date.today() - timedelta(days=90),
    end_date=date.today(),
    options={"count": 500, "offset": 0}))
# resp.accounts -> balances, types, masks
# resp.transactions -> amount, date, name, merchant_name, category,
#                      pending, account_id

# 3. Re-pull on the consent expiry cadence; revoke on user request.

The route-2 snippet (authorized Banno surface) is heavier — session establishment, the NetTeller BSL handshake, encrypted body fields per Banno's conventions — and is fully written and tested as part of the engagement rather than shown in summary on a public page.

Inside the package we hand over

• OpenAPI (Swagger) specification for the endpoints in scope on whichever route we recommend — accounts, transactions, statements, transfers, card-control — with request/response examples drawn from real test pulls.
• Protocol & auth-flow report: OAuth (route 1), or the token / session-cookie / BSL handshake of the Banno surface (route 2), with refresh and revocation behaviour written down explicitly.
• Runnable source in Python (FastAPI / httpx) and Node.js (Express / undici) for the documented endpoints, plus a small CLI for ad-hoc pulls during reconciliation.
• Automated tests: pytest / vitest suites with recorded fixtures, plus a small live-smoke that proves the route still works at deploy time and tells us when the upstream changed.
• Compliance & retention guidance tied to this institution: consent record format, data-minimization policy, retention windows that match the use case, and where the consent-revocation hook lives in our code.
• Operating notes — the small things you only learn by doing one: how the aggregator behaves on duplicate accounts, what an expired-consent error actually looks like in the wild, what to do when the customer changes their NetTeller password mid-session.

US data-rights status, plainly

For a small Minnesota community bank like Lowry State Bank, the dependable basis for an integration today is the customer's own authorization — given through a Plaid / MX / Finicity Link flow off the routing-091208332 institution record, through a credentialed consent flow run inside the engagement, or through a written authorization to extract their own statements. That is what works in present tense for this institution, and it is what we ship against.

Lowry State Bank itself is well under the asset thresholds the CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) had contemplated for first-wave data-provider obligations, so even on the rule's original terms this bank was in the long tail. That is moot today in any case: as finalized, §1033 has since been enjoined and reopened for reconsideration, with the CFPB's Advance Notice of Proposed Rulemaking and the court-ordered stay of compliance dates moving the question back into rulemaking. We do not present §1033 as the framework "governing" the build here — the consumer-authorization basis above is what governs — and we follow the reconsideration so the integration is ready to translate to whatever lands.

State and federal privacy obligations still apply on top: Gramm-Leach-Bliley for the financial side, plus the bank's own posted privacy notice; on our side, we work under NDA, log access, and minimize what we keep.

Things this build has to account for

• Aggregator coverage of small Banno-stack banks is uneven. Plaid, MX and Finicity all can reach a routing-091208332 institution via the Jack Henry tokenized channel, but coverage of any specific small bank can be on or off at any given moment. We design route 1 with route 2 wired in as the fallback path the same client code can switch to, so a coverage drop is a degradation rather than an outage.
• Banno UI rewrites are a re-validation event, not a redesign of the integration. The Banno team is openly modernizing the white-label apps on both iOS and Android. The host calls behind them — NetTeller BSL, jXchange — change much more slowly than the front end. We pin the build to the host-call layer and rerun the protocol-validation suite each major Banno app cycle.
• The aggregated outer layer is not a feed we own. The "external accounts" the customer adds inside Lowry State Bank's app are populated by Banno's aggregator on Banno's terms; we do not redistribute that view. Where a client needs the same picture, we build it with the consumer's consent on our side, mirroring the mechanism rather than the data.
• Joint accounts and Glenwood-side reads. Because Lowry State Bank shares ownership with Glenwood State Bank but keeps its own customer files and its own NetTeller instance, an integration that needs both has to be scoped per-bank, not per-group. We handle the institution-id and routing-number split during onboarding so the client does not have to.
• Statement PDFs need OCR for downstream use. NetTeller statements are real PDFs, not structured documents. If the use case is lender doc-collection or income verification, the deliverable includes the extraction step, not just the file pull.

Sources we opened

Researched 19–20 May 2026. We pulled the FDIC institution record, the bank's own technology and online-banking pages, Banno's NetTeller-overview document, Jack Henry's data-aggregator material, the CFPB's §1033 page and its reconsideration ANPR on the Federal Register, and the Wise routing-number listing. No vendor relationship or affiliation is implied.

• FDIC BankFind — Lowry State Bank (cert 10202)
• Banno Digital Platform & NetTeller Online Banking overview (PDF)
• CFPB — Required Rulemaking on Personal Financial Data Rights
• Federal Register — Personal Financial Data Rights Reconsideration (22 Aug 2025)

Mapping reviewed by the OpenBanking Studio integration desk, May 2026.

Other community-bank apps in the same orbit

• Glenwood State Bank — Lowry's sister bank, also in west-central Minnesota; its own mobile app and online banking sit on the same Jack Henry / NetTeller-family stack, so integrations against the two share most of the protocol work.
• First State Bank Minnesota (FSB Minnesota Mobile) — a separate Minnesota community bank with a small native mobile app on Google Play and the App Store, covering balances, transfers and mobile deposit.
• Pioneer Bank — Mankato / St James / Mapleton, MN; community-bank online and mobile banking with the usual transaction and bill-pay surfaces.
• First State Bank and Trust — community bank operating in Minnesota and Wisconsin, with a consumer mobile app on the same kind of community-bank digital stack.
• The First State Bank of Fountain — small southeastern-Minnesota community bank with online banking and a mobile presence; useful as a sanity-check counterpart for any cross-institution build.
• Frandsen Bank & Trust — Frandsen Mobile Banking on iOS and Android, serving MN, WI and ND; larger footprint but the same community-banking integration patterns apply.

Each name above is the kind of institution a unified integration would want to fan out across once the Lowry build is in place; the actual cross-linking on this site is left to the build's own related-pages step.

Questions integrators of Lowry State Bank tend to ask

Working with us on this

Most community-bank app builds of this shape land in one to two weeks of work end-to-end. The source-code-delivery model is priced from $300, paid only after the runnable Python / Node source, the OpenAPI specification, the protocol report and the test suite are in your hands and you are happy with them; the pay-per-call hosted model lets you skip the build entirely and pay only for the API calls you make against our endpoint, with no upfront fee. Send the app name and what you need from its data to /contact.html and we will scope it from there.