Integrating Thomasville National Bank under the account holder's authorization

Account-holder data in the app

The TNB Google Play listing and the bank's online & mobile services page describe the surfaces below in the bank's own words. Where granularity is inferred, it is marked.

Three routes that fit TNB

An integration plan that pretends every community bank is the same misses the point. TNB is small and regional. The route we recommend depends on whether a major aggregator already covers it for your specific holder, and on whether you need write surfaces or only read.

Route 1 — Aggregator-routed access

If your end-user can authorize Plaid, MX, Finicity (now part of Mastercard) or Yodlee against their TNB account, the cheapest spine is to consume the normalized balance and transaction stream from there. Reachable: balances, transactions, identity. Effort: short — the integration is your aggregator's; ours is the glue. Durability: dependent on whether the aggregator maintains coverage for TNB and on the broader shift toward bank-charged aggregator access (JPMorgan's announced fees to aggregators is a signal worth tracking). We handle the aggregator onboarding with you, on your account, and ship the client that consumes the feed.

Route 2 — Consumer-credentialed client against tnbank.com

Where aggregator coverage is missing or partial, the working path is a client that signs in as the holder using credentials the holder gives, captures the session, and reads the same pages the holder reads. Reachable: everything the holder sees, including statements and bill-pay history. Effort: a one-to-two-week build per surface set. Durability: tied to the production frontend; we ship a verification pass with the source so a refresh shows up at delivery time rather than on a Friday night. Access is arranged with you during onboarding against a consenting account; we don't bypass authentication and we don't store credentials beyond what the consent agreement specifies.

Route 3 — Native export as the audit trail

TNB's e-statements (and, where the portal supports them, QFX/QBO/CSV transaction downloads — the standard set for white-label community-bank platforms) make a clean append-only record. On their own they are not enough — the cadence is monthly and there is no programmatic trigger — but as the audit trail behind route 1 or route 2 they are the right thing.

In practice: if your holders are already inside a Plaid- or MX-supported view of TNB, route 1 carries the run-rate work and route 3 is the receipt. If they are not, route 2 is the working client and route 3 is what you reconcile against.

A working request, end to end

Illustrative — final field names and the exact handshake are confirmed during the build against the production frontend. The pattern is the one a TNB consumer-credentialed read client actually uses.

import requests
from typing import Iterator

BASE = "https://www.tnbank.com"  # final auth endpoint resolved during the build

def open_session(username: str, password: str, otp_callback) -> requests.Session:
    s = requests.Session()
    s.headers["User-Agent"] = "OpenBankingStudio/1.0 (+integration@example.com)"
    s.post(f"{BASE}/login", data={"u": username, "p": password})
    if needs_otp(s):                      # SMS / TOTP handoff, holder-driven
        s.post(f"{BASE}/otp", data={"code": otp_callback()})
    return s

def list_accounts(s) -> list[dict]:
    r = s.get(f"{BASE}/accounts")
    r.raise_for_status()
    return parse_accounts(r.text)          # -> [{id, type, nickname, balance, available}]

def transactions(s, account_id: str, since: str) -> Iterator[dict]:
    page = 1
    while True:
        r = s.get(f"{BASE}/accounts/{account_id}/transactions",
                  params={"since": since, "page": page})
        rows = parse_transactions(r.text)  # -> [{date, amount, memo, status}]
        if not rows: return
        yield from rows
        page += 1

Two things are quietly load-bearing here. The OTP step is the holder's, not ours — it has to be, because the authorization is the holder's. And the parsers exist as the thing under test: when TNB ships a frontend change, the parser is what moves, not the rest of the client.

What we hand over

• An OpenAPI / Swagger spec covering the surfaces above — balances, transactions (with cursor/since paging), statement listing, alert subscriptions, transfer initiation, bill-pay list and post.
• An auth-flow report — the cookie and token chain captured during the build, the OTP handoff, the session lifetime we observed, and the keep-alive shape.
• Runnable source in Python or Node.js implementing the handshake, retry with backoff, and pagination — the file you saw above is one piece of that.
• A test suite (pytest or jest) that exercises the client against the consenting sandbox account, including the unhappy paths — expired session, OTP required, ledger empty for a date range.
• Interface documentation — field semantics for TNB specifically: what "pending" means in the ledger you'll see, how memo is populated, what a returned transfer looks like.
• Data-retention and consent-record guidance — what to log, what to drop on a per-request basis, the consent-record format your auditor will want.

Authorization basis & supervision

TNB is a national-charter bank — primary supervision sits with the OCC, deposits are FDIC-insured under certificate 34068, and consumer-finance conduct falls under the CFPB. The dependable basis for any integration we deliver against TNB is the account holder's own consent: the holder authorizes, the holder can revoke, and the engagement records that consent in writing with scope and expiry.

The forward-looking piece is the CFPB's Personal Financial Data Rights rule under section 1033, finalized as 12 CFR Part 1033. Treat it as unsettled rather than governing: the Eastern District of Kentucky enjoined the CFPB from enforcing the rule, and in August 2025 the Bureau issued an Advance Notice of Proposed Rulemaking reopening it. The comment window closed in October 2025; no replacement rule has issued. For a TNB integration today, the right anchor is the holder's authorization. If the rule lands in a different shape and TNB becomes obligated to expose a standardized data interface, an integration built on the holder's consent reads that as a cheaper version of the same connection — not a redesign.

Engineering notes for a TNB build

Two notes that show up in the actual work, written so you know what we're accounting for rather than what you have to clear.

Frontend refresh, not a one-time event. TNB ran a New Online Banking rollout described on its own site. We pin the build to the current production frontend, ship a verification pass alongside the source, and run that pass on demand. When the bank refreshes markup or shifts the auth flow, the pass tells you in one run; the fix is scoped to whichever parser moved, not a rebuild.

Read and write are different blast radii. Mobile deposit, transfers, and bill-pay share an app shell but ride different backends and different authorization scopes. We scope the integration per surface, keep the tokens for the read client and the payment client separate, and gate writes behind an explicit second consent so a balance fetch can't quietly post a payment. Where you only need read, we ship only read.

Alerts as a webhook, not a poll. TNB issues account alerts as push and email. If you want them mirrored into a downstream system, we wire the mirror off the alerts subscription rather than polling the dashboard — fewer requests, cleaner signal, and the consent stays narrow.

Price and timing

A balances-and-transactions read client for TNB usually scopes to one to two weeks of work. That is the source-code engagement: we hand over the OpenAPI spec, the runnable client, the tests, the auth-flow report, and the interface notes; you pay from $300 on delivery, once you've signed off on what's in your hands. If you prefer not to host anything, the other model is a hosted endpoint you call against your authorized holders' accounts — no upfront fee, you pay per call. Either way the app name plus what you want from it is enough to start; the rest of the engagement runs from there. Send us the brief and we'll come back with the route, the scope, and a date.

What the holder sees in the app

Listed surfaces are easier to plan against when you can see them. Tap any thumbnail to enlarge.

Sources checked

This brief was put together from the bank's own holder-facing pages, the FDIC registry, and CFPB rule-status records — checked in May 2026. Specific items below.

• Thomasville National Bank — Mobile Banking page (bank's description of app surfaces)
• FDIC BankFind — TNB certificate 34068 (charter type, regulator, deposit insurance)
• Thomasville Bancshares 2024 results release (asset size context)
• CFPB — Personal Financial Data Rights Reconsideration (current rule status)

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

Other community banks of this shape

If you are mapping TNB as one of several US community-bank connections rather than the only one, these are real apps in the same shape — small or regional banks whose holders see the same set of balance, transaction, statement, transfer, and bill-pay surfaces, with the same authorization basis under the holder's consent.

• Ameris Bank Mobile — regional bank with a Southeast footprint; the same balance, transaction, and bill-pay surfaces, larger asset base.
• Synovus Mobile Banking — Georgia-headquartered regional with a richer treasury/business set on top of the consumer view.
• South State Bank Mobile — Southeast regional; standard read surfaces plus mobile deposit, similar holder-authorization model.
• Cadence Bank Mobile — regional with a wide branch footprint across the South; the same data shape with a different vendor stack.
• Renasant Mobile Banking — Mississippi-headquartered regional; statements, transfers, bill-pay through a holder login.
• United Community Mobile — multi-state Southeast regional with a deeper digital toolkit but the same holder-data surface area.
• Pinnacle Bank Mobile — Tennessee-based; community-bank-shaped data with the same read/write split a TNB integration faces.
• First Federal Bank Mobile — North Florida overlap with TNB; familiar surface set for an integration that already targets community-bank stacks.

Questions integrators raise before starting