Integrating CSB Lankin, a Banno-powered community bank in North Dakota

The package id com.citizensstatebank.grip gives the architecture away: this mobile app is a Jack Henry / Banno deployment, specifically the Banno "Grip" platform that JHA acquired in 2014 and has since folded into its open-banking digital stack. The bank behind it is Citizens State Bank of Lankin — a state-chartered community bank in Lankin, North Dakota, in continuous operation since 1905 according to the bank's own history and the FDIC's BankFind entry under certificate 9422. Four branches, all in the Walsh and Pembina county corner of the state. The customer-facing app is what you see; the integration surface is what Banno exposes once a CSB Lankin internet-banking user is signed in.

The aggregation pitch on the listing — "accounts from other banks and credit unions, into a single view" — is the tell. That is not a feature the Lankin bank built; it is Banno's data-aggregator integration, which Jack Henry has been wiring to Akoya, Finicity (Mastercard), Plaid, MX, Intuit, Stripe, Visa Open Banking Solutions and Envestnet | Yodlee in place of screen scraping. So an integration here has two surfaces in play: the Banno-side authenticated session for the CSB Lankin holder, and, under that user's consent, the external accounts they have linked through Banno's aggregator chain.

What you can reach from a CSB Lankin session

The Play Store listing and the bank's own mobile-banking page describe the surfaces below. Each row is something a CSB Lankin user already sees in the app, so a consent-backed integration tracks the same scope they could read themselves.

Three routes into a Banno Grip stack

Three routes apply to this app. They differ in effort, durability, and how much of the Banno-side cooperation the engagement assumes.

Route A — Authorized session integration against the Banno mobile API

The Grip Android app talks to a Banno-hosted backend over OAuth-bearer JSON. Under the account holder's written authorization, we map that auth chain (device registration, MFA, token refresh) and the JSON shapes for the surfaces above, then deliver client code that drives the same endpoints the app itself uses. Effort: moderate; durability: tied to Banno release cadence; we re-validate as a maintenance step. This is the route we lead with for a single-bank scope.

Route B — Aggregator-side, consumer-permissioned data sharing

Banno already integrates with Akoya, Finicity, Plaid, MX, Intuit, Stripe, Visa Open Banking Solutions and Envestnet | Yodlee, and Jack Henry has been retiring screen scraping in favor of these direct API links. If the customer just needs balances and transactions on Citizens State Bank of Lankin accounts (and on whatever the user has aggregated in), a consent-based connection through one of these aggregators is the cleanest standing route — FDX-aligned, revocable by the user from inside the bank app, and unaffected by future Banno UI changes. Slightly narrower domain reach than Route A, much higher durability.

Route C — User-driven export and document capture

The app already lets a CSB Lankin user save monthly statements as PDFs and view tagged transactions with attached receipt images. For audit-grade workflows where the customer wants exactly what the user themselves can see, a thin wrapper over consented downloads is a low-risk fallback. We use it as a backstop or for compliance-sensitive scopes, not as the primary spine.

Our default on a CSB Lankin engagement is Route B for the standing balance / transaction feed and Route A on top of it for the surfaces the aggregator does not reach (mobile-deposit history, card controls, internal-transfer initiation, alerts configuration). Route C lives behind both as the auditable fallback.

A token refresh and a statement pull, sketched

Illustrative only — exact field names and headers are confirmed during the build against a consenting CSB Lankin login. The shapes below mirror the patterns observed on Banno-fronted mobile clients.

# csb_lankin_client.py — illustrative
import time, requests

BANNO_HOST = "https://banno.csb100.bank"  # Banno-hosted tenant for Citizens State Bank of Lankin

def refresh(session):
    r = session.post(
        f"{BANNO_HOST}/a/consumer/api/v0/auth/refresh",
        json={"refresh_token": session.refresh_token,
              "device_id": session.device_id},
        headers={"X-CSRF-Token": session.csrf, "User-Agent": session.ua},
        timeout=20,
    )
    r.raise_for_status()
    body = r.json()
    session.access_token = body["access_token"]
    session.expires_at   = time.time() + body["expires_in"] - 30
    return session

def list_accounts(session):
    refresh_if_needed(session)
    r = session.get(
        f"{BANNO_HOST}/a/consumer/api/v0/users/me/accounts",
        headers={"Authorization": f"Bearer {session.access_token}"},
        timeout=20,
    )
    r.raise_for_status()
    # Includes CSB-owned and aggregator-linked accounts when the user has linked any
    return r.json()["accounts"]

def fetch_statement(session, account_id, period):
    r = session.get(
        f"{BANNO_HOST}/a/consumer/api/v0/accounts/{account_id}/statements/{period}",
        headers={"Authorization": f"Bearer {session.access_token}",
                 "Accept": "application/pdf"},
        timeout=30,
    )
    r.raise_for_status()
    return r.content  # PDF bytes — same artifact the user sees in the app

What lands at the end of the build

• An OpenAPI 3 spec for the CSB Lankin surfaces in scope — auth chain, accounts, transactions, statements, mobile-deposit history, transfers, alerts.
• A protocol & auth-flow report covering Banno's device registration, MFA handling, token refresh, and the JSON envelopes we relied on, with version pins.
• Runnable source in Python and Node.js for every endpoint in the spec, with retry / backoff / idempotency where transfers are in scope.
• An automated test pack with fixtures captured from a consenting account, so a Banno release that shifts a field flags before silent drift.
• Where the aggregator route (B) is in scope, a parallel client against the Akoya / Finicity / Plaid / MX path with FDX-aligned field mapping.
• Interface documentation and a short data-retention & consent-handling note written for this US community-bank deployment.

US data rights here in 2026: consent first, §1033 still pending

For a four-branch state-chartered bank like Citizens State Bank of Lankin, the dependable basis right now is the account holder's own written authorization. The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is under reconsideration: the Bureau published an ANPR on 22 August 2025, a federal court has enjoined enforcement, and the April 2026 compliance dates have been stayed. So §1033 is the forward-looking question for the bank's regulator, not the rule we ride today. The CFPB has also recognized FDX as the open-banking standard-setting body, which is the standard our aggregator-route client (Route B) follows whether or not the rule is reactivated in its original form.

Practically: the engagement runs on the customer's signed authorization, NDA where the scope calls for it, scoped logging of what was read, data minimization in storage, and a short consent record we keep alongside the build. If the customer wants Citizens State Bank of Lankin in the loop for a sandbox account or for documented Banno-side cooperation, we approach the bank with you during onboarding — that conversation is part of the project.

Things we handle on a Banno community-bank build

• Banno release cadence. Banno ships changes to its consumer mobile platform on its own schedule and has been actively retiring screen-scraping for inbound aggregator traffic. We pin the auth chain and JSON parsers to versioned fixtures so when a release shifts a field, the test pack tells us before the customer notices.
• Aggregator routing inside the session. The "other bank" accounts in a CSB Lankin view come through one of Banno's aggregator partners. We confirm which partner is wired for this tenant at the start so we know whether to drive Route B through Akoya, Finicity, Plaid, MX, Intuit or Yodlee — each has its own consent UI and refresh semantics, and we set the client to whichever one Banno hands the session to.
• Bank size and access posture. A four-branch community bank is not a money-center; we approach Citizens State Bank of Lankin during onboarding the way we would any small servicer — quietly, with the customer's authorization in hand, and through the right channel rather than through a developer portal. That outreach is our step, arranged with you.
• MFA on a low-volume tenant. CSB Lankin users see a 4-digit passcode plus device biometrics. We design the auth chain so device registration is a one-time setup against a consenting login and so the integration does not spam the user's second factor on every refresh.
• Aggregation versus servicing. Reading aggregated balances and reading CSB-owned balances are different scopes; the consent the user already granted inside the app covers what they can see, and our build scopes the integration to a subset of that. We map this with the customer up front so the integration's read surface is auditable.

How the engagement actually runs

On a CSB Lankin build the cycle is one to two weeks for the first account: a Banno-flavored auth chain mapped, balances and statements normalized, mobile-deposit and transfer plumbing where the scope wants it, plus a test pack against a consenting login (or a Banno tenant sandbox we wire up with you). Source-code delivery starts at $300, billed only after you have reviewed what arrives — you see the OpenAPI, the runnable Python and Node clients, the test fixtures, and the protocol report before any invoice. If you would rather not host the code, call our endpoints and pay per call — no upfront fee, billed on usage. To start a scope conversation, write to us via /contact.html with the app name and what you want from the data; access, sandbox arrangement, and compliance paperwork are handled with you from there.

When the UI or aggregator shifts

Banno is a moving platform; a community-bank tenant inherits whatever JHA ships next. We treat reliability as a maintenance commitment rather than a one-shot delivery: the test pack runs on a schedule against the same consenting account, a field drift on the Banno side or an aggregator-side change becomes a flagged regression instead of a silent gap, and small re-validation work falls inside the maintenance window the engagement defines. For pay-per-call hosted customers this is invisible — the endpoints stay current and you only see calls succeed.

App evidence — what a CSB Lankin user actually sees

The screens below are the public Play Store screenshots, included so the data domains above can be checked against the surfaces the app shows. Click any tile to enlarge.

Other small US community-bank apps that look like this one

Apps in the same shape — small US community banks with a Banno or Banno-like mobile front end, aggregation built on top of the same handful of US data aggregators, and a similar set of consumer features. Names are listed for ecosystem context, not as a ranking.

• Dakota Mobile (Dakota Community Bank & Trust) — a North Dakota neighbor of CSB Lankin with balances, transfers, bill pay, mobile deposit, and alerts; an integration looks structurally similar.
• Bank of North Dakota mobile — the state-owned bank's consumer app for checking and savings holders; a quieter feature set, the same authenticated-portal pattern.
• Community State Bank mobile — another community-state-bank app (Wisconsin) on a Banno-style stack; same balances, transfers and mobile-deposit surfaces.
• Cumberland Security Bank mobile (CSBweb) — Kentucky community bank, comparable feature surface; aggregation reach again depends on which US data aggregator the digital vendor routes through.
• BankCSB Mobile — a small US community bank app with bill pay, mobile deposit and statement view; same domains, same consent shape.
• CSBI Mobile Banking — another small-bank consumer app in the same category bracket; useful as a comparable for scope and timeline.
• First Community Bank app — one of the community banks publicly named as moving onto Jack Henry's digital platform; an integration would look very close to this one.
• Sunrise Banks mobile — community bank app on the same JHA / Banno orbit; aggregation through the same partner list.

Questions we get on this kind of build

Will the build still work after Banno's next platform release?

Banno ships front-end and aggregator changes on its own cadence, which is one reason we keep the auth chain and the parsing pinned to versioned fixtures. When a release shifts a token shape or a response field, the test pack flags it before the integration silently degrades. We re-validate as part of maintenance instead of leaving it to a customer to notice.

Can we pull the aggregated "other bank" accounts too, or only Citizens State Bank balances?

The external accounts a CSB Lankin user has linked appear in their session because Banno is fronting one of the aggregator partners. Reaching those balances follows the same consent the user already granted inside the app; we scope what is in-bounds during onboarding so the integration only surfaces what the customer actually owns the right to read.

Does the current §1033 enforcement stay change anything for this build?

For a four-branch state-chartered bank that already runs on Banno, very little changes day-to-day. Enforcement is paused while the CFPB reconsiders the rule, so the dependable basis is the account holder's consent — exactly what an authorized integration here rides on regardless of where the rule lands.

Do you need the bank's blessing, or just the account holder's authorization?

The account holder's written authorization is what we operate under, plus NDA where the scope warrants it. If the engagement wants the bank's cooperation — for a sandbox account or for a documented Banno-side route — we approach Citizens State Bank of Lankin during onboarding together with you. That conversation is part of the project, not a barrier in front of it.

What is the realistic timeline to a working pull for one CSB Lankin account?

One to two weeks for a single account, end to end: auth chain mapped, balances and statements normalized, transfers stubbed if the scope wants them, tests against a consenting login. You see the source and the report before any invoice — source-code delivery is paid after you sign off.

What was checked, and where

This brief was put together from the Play Store and App Store listings for CSB Lankin, the bank's own site at csb100.bank (including its "Our Story" page on the 1905 charter), the FDIC BankFind entry for institution number 9422, Banno's published integrations and data-aggregator partner list, and the current CFPB Personal Financial Data Rights reconsideration docket. Specific references kept open during the write-up:

• FDIC BankFind — Citizens State Bank of Lankin (cert 9422)
• Banno knowledge base — Data Aggregators (Akoya, Finicity, Plaid, MX, Intuit, Yodlee, Visa OBS, Stripe)
• CFPB — Personal Financial Data Rights Reconsideration
• Federal Register — §1033 Reconsideration ANPR (22 Aug 2025)

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