Reaching account data inside Turbotville National Bank’s mobile app

Founded in 1910, TNB runs the kind of mobile app a small north-central Pennsylvania community bank tends to run: white-label, hosted on a shared platform, narrowly scoped to balances, transfers, bill pay, deposits and wallet provisioning. Per the FDIC BankFind record (certificate 7789) it is a single-location OCC-chartered national bank, which matters less for the marketing and more for what an integrator has to plan around — the institution is well below any covered-data-provider asset threshold that the original CFPB §1033 rule contemplated, so for the moment everything practical hangs off the member’s own authorization rather than an in-force data-rights regime.

The Android package name com.mfoundry.mb.android.mb_031313753 (per its Play Store listing) is the give-away on the back end. The mb_ prefix and the trailing nine-digit number are the standard mFoundry per-tenant slug, and the digits match TNB’s ABA routing number 031313753 exactly. mFoundry, the white-label mobile banking platform that powers the app, was bought by FIS in 2013 for about $120 million according to contemporaneous press coverage, and the surviving stack now sits inside the FIS Digital One / Digital One Flex product lineage. That platform context drives how the data is reached.

What the app actually holds

The published feature set is short. The integrator’s map of it is what matters — here is what is reachable per member session and what a downstream system usually does with each piece.

Three ways into a TNB account, ranked by what works

Three routes genuinely apply here. The recommendation is at the end of this section.

Route 1 — aggregator on-net

If TNB is reachable through the aggregator the customer already uses (Plaid, Finicity, MX, Yodlee), the integration is a thin layer over that connection. For a single-branch community bank, aggregator coverage is uneven: the major players keep direct connections to the top several hundred US institutions and reach the long tail of 11,000+ banks via resold or scraped backends, so the practical question on day one of the build is which aggregator currently serves TNB cleanly and at what data fidelity. The studio runs that coverage check live before recommending this as the primary path. Effort: low if on-net. Durability: high — the aggregator absorbs upstream movement. Cost: per-call aggregator pricing on top of integration cost.

Route 2 — consented interface integration against the mFoundry tenant

With the customer’s authorization and a member-consented test account, the mobile and online-banking endpoints under the mb_031313753 tenant are mapped: login + challenge, account list, transactions windowed by date, transfer initiation, bill-pay history. The endpoint shape, MFA factors and version pin are confirmed during the build under session capture; nothing is assumed from another mFoundry tenant. Effort: moderate — one to two weeks. Durability: medium — tied to TNB’s app version, so a scheduled smoke check is bundled into the handover. Cost: lowest ongoing if the customer hosts the integration themselves.

Route 3 — member-supplied export

Online Banking at onlinebanking.ttnb.com typically supports downloads in QFX / OFX / CSV. For one-off migrations or low-frequency snapshots, a consented credential or a member-supplied export file is sufficient and avoids any live session at all. Effort: minimal. Durability: low — format breaks are unannounced and the export window is whatever the member can pull.

For TNB the route worth building first is route 1 if the customer already runs an aggregator and the live coverage check comes back clean; if not, route 2 against the mFoundry tenant is the next step, with route 3 reserved for the one-shot cases where a continuous feed isn’t justified. The data model the studio delivers is identical across all three so the source can swap later without callers noticing.

US data-access rules around TNB in May 2026

TNB is a small OCC-chartered national bank with assets well below the original CFPB §1033 covered-data-provider thresholds, so even when the Personal Financial Data Rights rule (12 CFR Part 1033) was finalized in October 2024 it would have placed TNB in one of the last cohorts in scope, if at all. The rule was promptly enjoined by the Eastern District of Kentucky and the CFPB issued an Advance Notice of Proposed Rulemaking on reconsideration in August 2025, with comments closing 21 October 2025; treating §1033 as in-force today is a misread of where the rule actually sits. The dependable basis for any pull from a TNB account in May 2026 is the customer’s own documented authorization under GLBA / Reg P, layered with the bank’s own member terms.

That has practical consequences. Consent scope is explicit (which accounts, which surfaces, for how long), the audit trail is kept on the integration side, the data set is minimized at the pull, and access tokens are revocable on the member’s side. If §1033 eventually settles into a form covering small community banks, the same data model maps onto a data-rights-API call without a rewrite — the integration is built so the wire source can change but the published shape does not.

What the request flow looks like

An illustrative sketch of the consented session against the mFoundry tenant. Endpoint paths, exact field names and the User-Agent version pin are confirmed during the build under session capture; this is shape, not a hand-off.

# Illustrative — confirmed at build time against the live mFoundry tenant.
import httpx
from datetime import date, timedelta

class TnbSession:
    # mFoundry tenant slug includes the routing number, per the Android package id.
    BASE = "https://mobile.olbanking.com/.../mb_031313753"

    def __init__(self, username, password):
        self.cli = httpx.Client(http2=True, headers={
            "User-Agent":         "TNB-Android/<ver pinned at build>",
            "x-mfoundry-tenant":  "mb_031313753",
        })
        self.session = None
        self.u, self.p = username, password

    def login(self, answer_challenge):
        r = self.cli.post(f"{self.BASE}/auth/start",
                          json={"u": self.u, "p": self.p}).json()
        if r.get("step") == "challenge":          # OOB/OTP or KBA factor
            r = self.cli.post(f"{self.BASE}/auth/answer",
                              json={"sid": r["sid"],
                                    "answer": answer_challenge(r["challenge"])}).json()
        self.session = r["session"]

    def accounts(self):
        r = self.cli.get(f"{self.BASE}/accounts",
                         headers={"Authorization": f"Bearer {self.session}"}).json()
        return [{
            "id":         a["acctRef"],
            "kind":       a["acctType"],          # CHK | SAV | LOAN
            "available":  a["avlBal"],
            "current":    a["curBal"],
            "mask":       a["nbrLast4"],
        } for a in r["accounts"]]

    def transactions(self, acct_ref, since=None):
        since = since or (date.today() - timedelta(days=90))
        r = self.cli.get(f"{self.BASE}/accounts/{acct_ref}/txns",
                         params={"from": since.isoformat(), "limit": 200},
                         headers={"Authorization": f"Bearer {self.session}"}).json()
        # Pending mobile-deposit items carry a hold-window flag the mapper exposes.
        return r["txns"]

What lands in your repo

For a TNB build, the drop is small and concrete:

• An OpenAPI 3.1 specification describing the published shape — /accounts, /accounts/{id}/transactions, /transfers, /billpay, /deposits — with examples drawn from a redacted live session.
• Runnable source in Python and Node.js for the login + challenge dance, the account list, the windowed transaction pull, transfer initiation, and bill-pay history; the same module is parameterized by mFoundry tenant slug so a sister bank on the same stack drops in by configuration.
• An auth-flow and protocol report covering the OOB/OTP challenge factor, session lifetime, the User-Agent pin, and where the mFoundry tenant URL is anchored.
• A normalized JSON schema for account, transaction, transfer and bill-payment records that aligns with the OFX/QFX field set used by QuickBooks-class tools and is straightforward to render as an FDX-style payload upstream.
• A test suite that exercises the live endpoints against a consented test account, plus replay fixtures for offline CI.
• Compliance notes: consent record format, retention guidance, the GLBA / Reg P framing, and an explicit position on §1033 so the data-rights story is documented rather than assumed.
• An interface-documentation README for the operations team that will run the integration once the studio hands it over.

Things the build accounts for at TNB specifically

Five points the studio plans around when scoping a TNB integration:

• Single-branch institution, shared platform. TNB’s back end is a tenant on the FIS-owned mFoundry / Digital One lineage. Endpoint patterns rhyme across hundreds of community banks on the same stack, but per-tenant items — field names, MFA factor, version pin, session lifetime — are confirmed for TNB specifically rather than copied from another tenant.
• Aggregator coverage is verified live, not assumed. For a long-tail bank like TNB, aggregator coverage shifts and is sometimes resold. The build runs the live coverage check inside the customer’s own aggregator account first so the route recommendation is not a guess.
• Pending mobile-deposit hold window. Remote-deposit items sit in a hold state for a window after capture and can flip status; the mapper exposes that as an explicit field so downstream accounting doesn’t double-count a deposit between pending and posted.
• Bill Pay enrollment gate. The Bill Pay surface only returns data for members enrolled in TNB’s Bill Pay product. The integration distinguishes “no bill-pay records” from “not enrolled” rather than collapsing both to an empty list, because the downstream meaning is different.
• Re-validation cycle baked in. Because route 2 is anchored to the live mobile front end, a small smoke test runs login + account list + a transaction window on a schedule against a consented test account and pages the studio when a response shape moves — that is part of how the work is maintained, not something the customer has to set up themselves. Access, consent paperwork and a test account are arranged with the customer during onboarding.

Keeping a TNB integration alive after handover

Two failure modes dominate. Auth tightening — the mFoundry stack tends to roll new challenge factors quietly — is caught by the smoke loop on the challenge endpoint and is usually a one-line factor handler change. Field renames in account or transaction payloads are absorbed by the mapper layer; callers continue to see the published model. Both paths are documented in the handover README so the customer’s own engineers can keep the integration in step without re-engaging the studio for every cycle. For customers on the hosted API model, the studio carries that maintenance directly.

App surfaces (Play Store screenshots)

How this brief was put together

Built from a read of the FDIC’s public record on TNB, the bank’s own product pages, the routing-number registry, the Play Store listing for the app, and primary reporting on the mFoundry / FIS lineage that powers the back end. The CFPB §1033 status is taken from the Bureau’s own reconsideration page and the Federal Register notice. Specific sources opened:

• FDIC BankFind — The Turbotville National Bank, certificate 7789
• TNB — Mobile Wallet & Mobile Banking product page
• Routing-number record for ABA 031313753 (Turbotville Natl Bank)
• CFPB — Personal Financial Data Rights Reconsideration (§1033)
• American Banker — FIS acquires mFoundry (2013)

Mapping notes by OpenBanking Studio’s integration desk, reviewed 2026-05-30.

Other community-bank apps in the same shape

Same-category US community-bank mobile apps that an integrator usually thinks about alongside TNB — small balance-sheets, white-label back ends, similar surfaces. The data model the studio delivers normalizes across all of them so a single client app can read several banks through one schema.

• Penn Community Bank — Bucks County (PA) community bank with retail and small-business mobile features; the surfaces map directly onto the TNB data model.
• Mid Penn Bank — multi-branch PA community bank, comparable mobile feature set with broader treasury surfaces for business members.
• Community Bank N.A. (cb.bank, PA/WV) — community-bank mobile app with check deposit and account transfers in the same shape as TNB.
• Clarion County Community Bank — small PA community bank with retail and a separate business app; relevant for cross-bank consolidation flows.
• Community State Bank of Orbisonia — small PA community bank, balances and transactions only; useful as a low-surface comparator.
• First Commonwealth Bank — larger PA/OH bank, similar retail mobile surfaces and scheduled-transfer flow.
• First Community Bank — another community bank on the mFoundry tenant lineage, package id com.mfoundry.mb.android.mb_082908573 per its Play Store listing — the same template, different tenant slug.
• Conestoga Bank — documented as an mFoundry mobile-banking customer in primary reporting; same back-end shape as TNB.

Questions an integrator usually has about TNB

Is TNB already covered by Plaid or Finicity, and does that change the build?

For a single-branch institution like TNB, aggregator coverage is uneven and often resold from a long-tail backend rather than a direct connection. The build starts by checking live coverage in the aggregator the customer already uses; if TNB is reachable there, the integration becomes a thin normalization layer over the aggregator response. If it isn’t, the same data model is fed by a consented session against the mobile or online-banking front end, with the public API surface of the page kept stable so the upstream source can swap later without callers noticing.

The TNB app runs on the mFoundry platform — can the same integration be reused for other small banks on that stack?

Largely yes for the shape of it. Endpoint patterns, the tenant slug carrying the routing number, and the auth challenge flow follow the mFoundry template across hundreds of community banks and credit unions on the FIS Digital One / mFoundry lineage. Field names, MFA factors, session lifetimes and the version-pin in the User-Agent are per-tenant and confirmed at build time, so the runnable source is parameterized by tenant rather than hard-coded — adding a second bank on the same stack is usually a configuration job, not a rewrite.

What happens when TNB pushes a new app version and the shape of the responses moves?

Two things. A small monitoring loop runs the smoke endpoints (login, account list, one transaction window) on a schedule against a consented test account and surfaces a diff when fields move or auth tightens. The integration code is structured so the wire format and the published response model are separated by a thin mapper, so most upstream movement is a mapper change rather than a caller-visible break. The studio carries that monitoring loop as part of ongoing maintenance if the customer wants it.

Can transactions pulled from TNB feed straight into QuickBooks, a budgeting tool, or a member-onboarding flow?

Yes — the delivered model normalizes the TNB account, transaction, transfer and bill-payment records into a small JSON schema that is compatible with the OFX/QFX field set used by QuickBooks and most personal-finance tools, and is straightforward to map onto an FDX-style payload for internal pipelines. The same payload feeds know-your-customer onboarding and income-verification flows; the only TNB-specific quirk is the way pending check deposits are flagged during the mobile-deposit hold window, which the mapper exposes as an explicit status.

For TNB specifically, the build is small enough that the runnable Python/Node source, OpenAPI spec, tests and handover notes typically land within 1–2 weeks of kickoff. Source-code delivery is priced from $300 and paid only after the working code is in your hands; if you would rather not host anything, the same integration runs as a pay-per-call hosted API with no upfront fee. Tell us the app and what you need from its data — access arrangements, a consented test account, and the compliance paperwork are handled with you during onboarding.