Pulling balances, payments and statements from Tri City National Bank

Reading a Tri City National Bank account

Tri City National Bank runs deposit and lending accounts for customers across the Milwaukee area, and its app surfaces most of what those accounts hold: current balances, posted transactions, statements, Zelle sends and receives, scheduled Bill Pay, a monthly spending report, debit-card controls, and a free credit-score panel. For an integrator, the useful split is between data that travels well over a consented aggregation connection and data that only lives inside the app session.

The first group — balances, transactions, account and loan records — is the durable part. We backfill it in bulk, normalize it, then keep it fresh with a small incremental job. The second group — the cash-flow tracker, card controls, the bureau-fed credit score — comes off the app's own surfaces and gets folded into the same model. Everything runs on the account holder's authorization.

What the app actually holds

These rows track the surfaces the app presents today, mapped to where each one originates and what a team typically does with it. Field names shown elsewhere on this page are confirmed against a live account during the build.

Authorized ways into the account

Three routes apply here. Each is built on the account holder's permission, and access is arranged with you and the consenting member during onboarding — not something you line up before we begin.

Consent-based aggregation connection

The US has no single bank-run API every institution exposes, so production data still flows through consumer-permissioned aggregation. Where Tri City fronts an FDX-aligned data-access network, the balance, transaction and account records come back in a standards-shaped form over an OAuth-tokenized connection. This is the route we lean on for the durable feed. Effort is moderate; durability is high because it rides a maintained standard rather than a screen layout.

Authorized session integration

The surfaces aggregation never carries — the cash-flow tracker, debit-card controls, the credit-score module, Zelle status detail — come from analyzing the app's own authorized session under the customer's authorization. Effort is higher and we re-validate when the app changes, but it reaches data nothing else exposes.

Member-consented login and native export

For statements and documents, a consented login plus the portal's own download path is often the lowest-effort option. It is a clean fallback for anything available as a file rather than a feed.

For a Tri City build we would put balances and transactions on the consented aggregation connection and use a session-level integration only for the app-specific panels that feed never includes. That keeps the heavy, always-on path on the most stable surface.

A transaction backfill, in code

Here is the shape of the bulk job we stand up first: pull the deepest window the consented connection allows, normalize it, and hand back a cursor so the next run only fetches what posted since. Illustrative; field names are confirmed against a live account during the build.

# OpenFinance Lab — Tri City backfill worker (illustrative)
POST /connectors/tricity/transactions:backfill
{
  "connection_id": "conn_8f3c...",      # consented session, set up at onboarding
  "account_id":    "chk_2210",
  "window":  { "from": "2023-01-01", "to": "2026-06-01" },
  "page_size": 500
}

200 OK
{
  "account_id": "chk_2210",
  "next_cursor": "eyJvZmZzZXQiOjUwMH0",  # resume token for the incremental pull
  "balance": { "available": 1830.55, "ledger": 1902.10,
               "as_of": "2026-06-01T07:00:00Z" },
  "transactions": [
    { "posted_at": "2026-05-29", "amount": -42.17, "currency": "USD",
      "description": "ZELLE TO J DOE", "channel": "zelle",
      "category": "transfer", "status": "posted" },
    { "posted_at": "2026-05-28", "amount": 1500.00, "currency": "USD",
      "description": "PAYROLL ACH", "channel": "ach",
      "category": "income", "status": "posted" }
  ]
}

# steady state: GET .../transactions?cursor=eyJvZmZzZXQiOjUwMH0
# returns only rows posted after the cursor; empty page => nothing new.

Bill Pay and Zelle each carry their own status lifecycle, so the worker emits them as distinct payment objects rather than flattening both into one transaction list. A pending Zelle send and a scheduled bill payment reconcile on different clocks.

What you get back from us

The headline deliverable is code you can run, not a document you have to act on.

• Runnable connector source in Python and Node.js: the bulk backfill worker, the cursor-based delta job, and the parsers for each surface above.
• An automated test suite with recorded response fixtures, so the mapping is verifiable without hitting a live account on every run.
• Scheduled-job scaffolding for the incremental sync, with the idempotency and resume logic wired in.
• A normalized schema mapping Tri City's surfaces (balances, transactions, Zelle, Bill Pay, credit score) onto your own model.
• An OpenAPI description of the endpoints we expose, plus a protocol and auth-flow report covering the OAuth, token and session chain as it applies here.
• Interface documentation and a short data-retention and consent note for your records.

If you would rather not run any of it, the same surfaces are available as a hosted API you call instead.

Where this gets used

• A cash-flow dashboard that backfills two to three years of Tri City transactions, categorizes them, and drives a personal-finance view.
• Payables reconciliation that syncs Bill Pay and Zelle statuses into an accounting ledger as they settle.
• A consent-based affordability check for lending, reading balances and transaction history with the member's permission.
• A net-worth view that combines Tri City accounts with the external accounts the app already aggregates.

Consent and the US data-rights picture

Tri City is a nationally chartered bank supervised by the OCC and FDIC-insured (FDIC certificate 18922, per FDIC BankFind), so member account data sits under GLBA privacy rules and the bank's own terms. The reliable legal basis for any integration is the account holder authorizing access to their own data — that is what we build on, with consent records and access logging kept throughout.

The CFPB's Personal Financial Data Rights rule (Section 1033) would, if it takes effect, move much of this onto standardized bank-run APIs. As of mid-2026 a federal court has enjoined its enforcement and the CFPB has reopened the rule, so it is forward-looking rather than current law and we do not treat it as the governing framework. Where Tri City supports an FDX-aligned data-access connection — FDX being the data-sharing standard the CFPB has recognized as a standard-setting body — we use it, because it gives tokenized, consent-scoped access without depending on a screen layout. We work under NDA where the engagement calls for it, and minimize the data pulled to what your use case needs.

What we account for on a Tri City build

A few specifics about this app shape the work, and we handle each as part of the build:

• The credit-score panel is a third-party bureau feed surfaced inside the app, not core deposit data. We treat it as a separate upstream with its own consent and refresh cadence, mapped apart from the balance feed so a bureau-side change does not break the account sync.
• The app's connect-accounts feature means some balances on screen belong to external linked institutions, not to Tri City. We tag every account by whether it originates at Tri City or is an aggregated external link, because reconciliation downstream has to know which bank actually holds the money.
• History depth is bounded by what the consented connection exposes. We run the bulk backfill to that depth once, then switch to cursor-based delta pulls so the steady-state job stays small and the historical window is captured before it scrolls out of reach.

Screens we mapped against

The app's published screenshots, used to confirm which surfaces exist and how the account, payment and credit views are laid out.

Other Wisconsin banking apps nearby

Same regional, community-banking territory. Teams that integrate one of these usually want the rest behind one normalized model, which is why we list them.

• WaterStone Bank — Southeast Wisconsin bank with Zelle, mobile deposit and bill pay built into its app, holding the same balance and transaction records.
• Nicolet National Bank — Wisconsin bank with mobile and online banking plus a personal-finance budgeting tool over transactions and payments.
• Johnson Financial Group — Racine-based bank and wealth firm whose app covers deposit accounts and payments.
• Associated Bank — large Wisconsin-headquartered bank with deposit, card and payment data behind its mobile app.
• Community First Credit Union — Northeast Wisconsin credit union offering budgeting, card controls and credit-score monitoring.
• Central Wisconsin Credit Union — member-facing app with account access, balances and transfers.
• WESTconsin Credit Union — app with bill pay, mobile deposit, transfers, balances and card controls.
• Royal Credit Union — Wisconsin and Minnesota credit union with mobile check capture and account management.
• City and County Credit Union — biometric login and bill pay over member account data.

How this brief came together

Put together on 2026-06-14 from primary material: Tri City's own digital-banking features pages, its Google Play listing, the CFPB Personal Financial Data Rights page, and the Financial Data Exchange. Where a detail is not public — the exact aggregator Tri City fronts, internal field names, history depth — the page says so rather than guessing.

— OpenFinance Lab · interface review, June 2026.

What integrators ask

How far back can you backfill Tri City transactions, and how does the feed stay current after that?

History depth depends on the consented connection we stand up for the account; in practice we pull the full window the connection exposes in one bulk job, then move to small cursor-based delta pulls keyed off the last posted transaction. Steady state stays cheap because each later run only fetches what changed since the previous cursor.

Can you get the spending-insights and cash-flow tracker, or only balances and transactions?

Balances and posted transactions come off the consented aggregation feed in a normalized shape. The monthly spending report, the cash-flow tracker, debit-card controls and the credit-score panel are app-session surfaces rather than aggregation fields, so we integrate those separately through authorized session analysis against a consenting account and merge them into the same model.

What is the legal basis when Tri City is a US national bank and the CFPB open-banking rule is unsettled?

The dependable basis is the account holder's own authorization to access their data, under Tri City's terms and GLBA privacy rules. The CFPB Section 1033 rule could later push this onto standardized bank-run APIs, but a federal court has enjoined its enforcement and the CFPB has reopened it, so we do not build against it as current law. Where Tri City supports an FDX-aligned data-access connection, we use it.

Is the credit score shown in the app something you can pull?

That panel is a third-party bureau feed surfaced inside the app, not core deposit data. We can integrate it as its own upstream with its own consent and refresh cadence, kept apart from the balance-and-transaction feed so a bureau-side change does not ripple into the account sync.

Getting a Tri City connection built

Send us the app name and what you need out of a Tri City account; arranging access against a consenting member is part of the job, not something we ask you to sort out first. The source-code build is a flat fee from $300 — you pay after we deliver the runnable code plus docs and you have checked it works. Prefer not to run it yourself? Call our hosted endpoints and pay per request, with nothing upfront. Either way, plan on one to two weeks. Tell us what you are building and we will scope it.

Start a Tri City integration