Pulling account, transaction, and aggregated-feed data from CSB Lankin

Two halves matter for anyone integrating CSB Lankin: the data the bank holds on its own core, and the aggregated view of outside checking, credit, and brokerage accounts the app pulls in around it. The Play Store listing leads with that — the app is described as a way to fold accounts from other banks and credit unions into a single screen on top of the member''s own balances at Citizens State Bank of Lankin (Lankin, North Dakota; per the bank''s public social presence the institution dates back roughly a century, and we treat that as background colour rather than a fact this brief leans on). For an integrator the practical consequence is that the page is really two ingestion problems wearing one app.

Our approach reflects that. The dependable basis for getting at the data is the member''s own authorization to mirror what they see in-app; everything else hangs off that grant. We work member-by-member, with credentials and consent records arranged with the client during onboarding, and ship the integration as runnable source plus a thin freshness layer that keeps the two halves from drifting apart.

What sits behind the login

Working from the published feature list and the app''s in-session screens, the data domains a CSB Lankin member can see — and an integration would mirror under their consent — break down as follows.

Routes we''d actually take

Three routes fit this app, with one clear lead.

Member-authorized interface integration of the mobile app

The strongest single source. The member signs in once during onboarding, the studio maps the authenticated traffic between the app and the core, and the build re-creates the same calls against the same surfaces under the same session. Reach is wide — both halves of the screen, including the aggregated feed once it has been linked. Durability is medium; protocol drift on the bank''s core or on the aggregation partner''s side is the maintenance load, and we wire a freshness check into the delivered code so a silent break shows up as a failing reconciliation, not a quiet hole in the data.

Consenting-account credential sync

A narrower variant where the integration only ever talks under the member''s own credentials, with no replay outside the scope of a live consent. Useful when the consuming product has its own consent UX and wants to keep the bank-shaped piece small. Effort: low to medium. Durability: rises with how stable the member''s authentication flow is on the bank side.

Native export, where the member uses it

The statement archive supports member-driven retrieval; some downstream PFM tools accept aggregated exports as a fallback. This is the right route only for sporadic, document-shaped use, not the live aggregation work the app is built around. We name it for completeness and rarely lead with it.

For most asks against CSB Lankin the member-authorized interface route is the one we lead on, with the consenting-credential variant kept available as a posture choice when the consuming product wants tighter scoping. Native export is a backstop, not a design.

What ships at handoff

The deliverables are weighted toward code that runs on day one, with the paper artifacts in support of it.

• Runnable client source in Python and Node.js for the two halves of the feed — bank-owned data and aggregated outside accounts — packaged as a small SDK with consent-state in one place.
• A webhook handler skeleton that takes the core''s push events and fans them into the integrating product''s queue, with idempotency keyed on the bank''s own event identifier so a re-delivery never doubles a posting.
• A reconciliation worker that walks the aggregated cache, ages rows by their per-FI as-of stamp, and re-fetches outside accounts whose freshness has slipped past the configured window.
• An automated test suite with recorded session fixtures for both halves, so a future drift in the bank''s response shape surfaces as a failing test on the next CI run.
• An OpenAPI description of the endpoints the integration exposes downstream, an auth-flow report covering the member''s login, the consent grant, and the aggregated-feed onboarding, and a short retention and data-minimization note for the legal review of whichever product is ingesting this.

One endpoint, sketched

Illustrative — the wire shape is confirmed against the live session during the build, not from documentation we don''t have.

GET /v1/csb-lankin/member/{member_id}/accounts?include=aggregated&since={cursor}
Authorization: Bearer <member-scoped token>
X-Freshness-Window: 6h

# response, sketched
{
  "self_accounts": [
    { "id": "csb-1041", "type": "checking",
      "available": "...", "ledger": "...",
      "as_of": "2026-05-31T11:04:00Z" }
  ],
  "aggregated": [
    { "fi": "outside-fi-A", "kind": "credit_card",
      "balance": "...",
      "as_of": "2026-05-31T07:00:00Z",
      "freshness": "fresh" },
    { "fi": "outside-fi-B", "kind": "brokerage",
      "balance": "...",
      "as_of": "2026-05-30T22:11:00Z",
      "freshness": "stale", "reason": "outside-FI MFA required" }
  ],
  "next_cursor": "...",
  "consent_expires_at": "2026-08-29T00:00:00Z"
}

# reconciliation worker, pseudo
for row in aggregated:
    if row.as_of < now - freshness_window(row.fi):
        enqueue_refetch(row.fi, member_id, consent_id)
        mark(row, "refetching")

Freshness, refresh, and the consent clock

Because two clocks run inside one screen, the build holds three windows side by side: the core''s own update cadence (effectively event-driven on a member action), the partner aggregation provider''s refresh cycle for each outside FI (which varies per FI and per the provider''s back-off state), and the consent window itself (re-prompted ahead of expiry rather than after, so a member never finds a quiet hole the morning after their grant lapsed). The reconciliation worker is the place this all meets. It does not invent freshness — it surfaces the gap so the integrating product can decide whether to show stale data, ask the member to re-authenticate the outside account, or hold back.

Where the rule sits today

The dependable basis for a US member''s data here is their own authorization — recorded against a consent ID we hand to the client, scoped to the surfaces the build actually mirrors, and revocable in both directions (the aggregated half and the bank-owned half can be retired independently or together). The CFPB''s §1033 work — Personal Financial Data Rights — is the part still moving: the U.S. District Court for the Eastern District of Kentucky has stayed the compliance deadline, and the Bureau opened an Advance Notice of Proposed Rulemaking in August 2025 to revisit core questions like who counts as a "representative" making a request and how covered persons may recover their response costs. Whether a Lankin-sized bank is in scope at all is the part community-bank advocacy through ICBA has been pushing on, asking that institutions at or below $10 billion be exempted from whatever lands next. None of that is in force, so this brief does not present any specific asset threshold, deadline, or scope obligation as a present-tense duty on Citizens State Bank of Lankin. The integration rides member consent now; the §1033 outcome is future work the build will absorb when the rewrite arrives.

Engineering calls the build resolves

Two app-specific calls that we make up front so the client does not have to chase them later.

• The two-halves split is a first-class shape in the schema. Bank-owned rows and aggregated rows look similar enough that integrators routinely flatten them and then quietly overwrite a real balance with a stale mirror. The studio writes the two-halves split into the delivered model — separate tables, separate freshness, separate revocation paths — and exposes it the same way through the SDK so consumers can''t accidentally merge them.
• Aggregation-partner back-off is owned by the worker, not the caller. Outside-FI throttling and MFA-required states reach us through the aggregation provider''s feed (the bank''s public reference to Geezeo gives us a starting hypothesis about the provider for the planning conversation, which we confirm during the build, not at the page). When that happens, the reconciliation worker re-queues with the provider''s recommended back-off, marks the row, and never busy-loops the partner; the caller sees a stable "stale, reason X" rather than a 4xx storm. This single decision is the difference between an integration that lasts and one that gets rate-limited out of existence within a week.

Questions integrators ask us about this app

How does the aggregated half behave when an outside institution throttles the partner provider?

The aggregated feed and the core-bank feed are two clocks. Outside-FI rate limits, MFA prompts, and partner-provider backoffs touch only the aggregated half — the bank''s own balances and statements keep ticking on their normal cadence. The handoff we ship makes that split explicit so a stale outside account never silently overwrites a fresh core balance.

What''s the reconciliation pattern between the bank''s own ledger and the aggregated outside accounts?

Treat the core ledger as the source of truth for any Citizens State Bank of Lankin account; the aggregated rows are read-only mirrors with their own as-of timestamps. Reconciliation runs on the core push, then walks the aggregated cache by FI to flag rows older than the freshness window.

Does the mobile-deposit flow expose check images, or only status?

From a member''s session we observe deposit status transitions and the photographed front/back image references the app stores against a deposit record. Image retrieval is gated on the member''s session scope, and we mirror that limit in the delivered code rather than caching images outside it.

What does consent revocation look like for the aggregated half versus the bank''s own data?

Two revocation paths exist. A member can pull credentials off an aggregated outside account inside the app, which leaves bank-owned data intact; or they can de-authorize our integration end-to-end, which retires both halves. The build records each revocation against the original consent ID so a later request never replays an old grant.

Sources checked for this page

Material consulted while putting this together, May 2026: the CSB Lankin Google Play listing and the App Store listing; the bank''s own mobile banking page for the published feature set; the CFPB''s Personal Financial Data Rights reconsideration page and the ICBA note on the court-stayed compliance deadline for the §1033 status. Reviewed by OpenFinance Lab on 31 May 2026.

Adjacent apps in the same aggregation space

For an integrator scoping a unified product, these are the apps in the same shape — a member''s own bank account stitched together with an aggregated view of outside FIs. Listed as ecosystem context, with no ranking implied.

• CSBI Mobile Banking — Citizens State Bank of Indiana''s mobile app, built on the same vendor pattern as CSB Lankin (the package suffix is the giveaway); the same two-halves shape applies.
• Quicken Simplifi — a consumer-side aggregator that ingests bank, credit, and investment accounts into a single budgeting view; structurally the same problem viewed from the consumer''s end.
• Monarch Money — household-scope aggregation across institutions with shared visibility; treats outside-FI freshness as a first-class concept.
• Rocket Money — aggregation paired with subscription and bill management; the outside-account half closely matches the aggregated feed CSB Lankin exposes.
• Tiller Money — spreadsheet-backed aggregation of bank, credit, and investment accounts; relevant if the integrating product wants tabular pull-throughs rather than dashboards.
• YNAB — budget-first ingestion of aggregated accounts; instructive for the reconciliation pattern the brief above uses.
• Copilot Money — design-led aggregation app; relevant for the categorization-and-tagging surface the CSB Lankin transactions table already supports.
• PocketGuard — spending-guardrail aggregator; same outside-FI problem at a smaller surface area.

Source-code delivery on a CSB Lankin-shaped integration starts at $300, paid only after we hand over a build that behaves the way you scoped it — typically 1–2 weeks from kickoff to a usable drop. If you would rather not own the code at all, calling our hosted endpoints and paying per call is the other shape we offer, with no upfront fee. The simplest next step is to tell us the app and the data you need; access, sponsor sandboxes, and the consent paperwork are arranged with you as part of the engagement, not as a wall in front of it.