Reaching account data behind Texas Bank and Trust Mobile

myOFM, the aggregation layer inside this East Texas community-bank app, already pulls in accounts the bank itself does not own — which is the interesting part of the integration. A buyer who treats TBT as just another small-bank wrapper misses that the app is also a partial PFM. Two data surfaces, one member session.

The app in one panel

The recommendation, in one line, is to build against the member session: the bank's primary screens and myOFM share an authenticated context, and an extractor that already understands both is shorter than two extractors stitched together.

What sits behind a member session

These are the domains the app actually surfaces. The granularity column is what the wire returns, not what the UI shows — the two are not always the same.

Routes to the data

Three routes apply here. They are not mutually exclusive — the recommended build uses the first and reaches for the third as a cold-start fallback.

1. Member-authorized interface integration

The member grants access to their own account, the studio captures consent and credentials inside the engagement, and the extractor authenticates against tbtmyway.texasbankandtrust.com the same way the mobile and web client do. Reaches every domain in the table above. This is the durable route because it sits on a basis — the member's own right to their account — that does not depend on any regulator finalizing anything.

2. Aggregator-fronted access

A consumer aggregator (Plaid, Finicity, MX) reaches TBT on the user's behalf and exposes a normalized feed downstream. Useful when the buyer already has aggregator plumbing. The trade-off is that aggregator coverage of community banks is uneven and the myOFM-only enrichment fields (tags, notes, geo) do not survive the aggregator's schema.

3. Native export

The TBT portal supports statement download and account export from the member view. Useful as a backfill while the live integration spins up, or as a recovery path during an outage. Not viable as the primary feed — file cadence does not match what a live system needs.

For a buyer who wants TBT and its myOFM enrichment in one place with predictable freshness, route 1 is what we build and routes 2 and 3 live in the codebase as fallbacks.

What a call into myOFM looks like

Illustrative — the exact path names and field shapes are confirmed during the build against the live portal and pinned into the contract tests.

# illustrative; confirmed against the live portal during the build
import requests

s = requests.Session()

# Step 1 — authenticate as the consenting member.
# Credentials are captured inside the engagement under the consent record;
# the build never asks the buyer's end users for them outside that flow.
s.post(
    "https://tbtmyway.texasbankandtrust.com/auth/session",
    json={"username": creds.username, "password": creds.password},
    headers={"X-Client": "obs-tbt-build/1.x"},
).raise_for_status()

# Step 2 — bank-owned accounts.
own = s.get("https://tbtmyway.texasbankandtrust.com/api/accounts").json()

# Step 3 — myOFM aggregated view: TBT accounts + outside-FI accounts the
# member has linked. Same session, separate surface.
agg = s.get("https://tbtmyway.texasbankandtrust.com/api/myofm/accounts").json()

# Step 4 — per-account transactions with the user-enrichment fields
# (tags, notes, geo, receipt blob refs) preserved.
for acct in agg["accounts"]:
    txns = s.get(
        f"https://tbtmyway.texasbankandtrust.com/api/myofm/accounts/{acct['id']}/transactions",
        params={"from": "2026-01-01", "to": "2026-05-29"},
    ).json()
    yield normalize(acct, txns["items"])  # one shape downstream

Error handling on this path is mostly about session lifetime: TBT's portal expires the session aggressively after idle, and the myOFM surface returns a soft 401 that the bank-owned surface does not. The build refreshes the session, replays the in-flight page, and only escalates after the second retry — that single decision avoids most of the noise we have seen on community-bank front ends.

What lands in your repo

Concrete artefacts, sized to TBT specifically rather than to a generic finance app:

• An OpenAPI 3.1 specification for the normalized output — accounts, transactions, balances, the myOFM enrichment block — written so a downstream consumer can compile a client without seeing the TBT-specific wire shapes.
• A protocol and auth-flow report describing how the portal session is established, how myOFM hangs off it, and how the soft-401 path differs from the hard one.
• Runnable extractor source in Python or Node.js, whichever your stack prefers, with one module per data domain in the table above.
• A contract-test pass that records a known good response and runs it nightly so a TBT front-end change goes red in your CI before it surprises an end user.
• Interface documentation for your team — the data dictionary, the consent shape, the failure modes, and the runbook for when the portal updates.
• Compliance notes covering data minimization, retention windows, and the consent record format we use, written for a US community-bank context.

Member consent and the rule picture

TBT is a state-chartered community bank — supervised by the Texas Department of Banking with FDIC insurance. The institution-level rules that bear on this build are operational ones (BSA/AML logging, GLBA privacy, the usual Reg E and Reg DD picture for consumer accounts). The forward-looking question — whether TBT must hand a consumer's data to a third party at the consumer's request — sits with the CFPB's Personal Financial Data Rights rule, which was finalized in 2024 and has since been enjoined while the Bureau reconsiders it. We do not treat that rule as the basis for this build; the basis is the member's own consent to reach their own account.

The practical compliance posture: the consent record names the member, the accounts in scope, the data domains, the retention window, and the revocation route. The build logs every fetch under that consent record. If the member revokes, the next run halts and the artefacts move into the retention disposal queue.

Notes we keep on a build like this

Three things that come up specifically with TBT and that the engagement handles, rather than presenting as your homework:

• Two auth chains, one session. The bank's primary screens and the myOFM aggregator surface share a member session but have separate token refresh paths. The build keeps the chains separate inside the extractor, so a refresh on the aggregator side cannot quietly invalidate the bank session and silently truncate the day's pull.
• Pinned to the current front-end revision. Community-bank portals update on uneven cadences. We pin the build to the version we tested against and the nightly contract-test pass tells us when TBT ships a change. Patches go out within the same release window so the consumer never sees a stale field.
• Scoped to what the member can actually see. If a member has toggled an outside-FI account hidden in myOFM, the extractor honours that — the consent record covers what the member sees, and the build does not reach past it. A "pull everything" extractor would be cheaper to write and harder to justify under a consent audit.

Texas community-bank apps with overlapping data

Buyers asking us about TBT typically also have one or more of these in scope. The data overlap is real, but each app has its own auth shape and its own aggregator quirks.

• Texas Regional Bank Mobile — a Rio Grande Valley and Hill Country community-bank app with the same statement-and-bill-pay core, no equivalent myOFM-style aggregator on top.
• Texas Bank Mobile (TXBank) — Central Texas community bank, balances and transactions plus bill pay, narrower data set than TBT.
• Community National Bank and Trust MyBankTX — Hill Country independent bank with mobile deposit and bill pay; transaction enrichment is thinner than TBT's myOFM.
• TrustTexas Bank Mobile — South Texas community bank, similar mobile-deposit and transfer surfaces, no in-app aggregator of outside accounts.
• Texas Trust Credit Union Mobile — a credit union rather than a bank, comparable transaction history and card controls, NCUA-supervised rather than FDIC.
• Prosperity Bank Mobile — larger Texas community bank, similar core data, broader treasury surface that a business integrator may also care about.
• Southside Bank Mobile — East Texas regional bank with adjacent geography and a similar feature set.
• Independent Financial Mobile — Texas regional bank, statement and bill-pay surfaces, no in-app PFM aggregator equivalent to myOFM.

Common questions on the TBT build

Can the build reach my Texas Bank and Trust accounts plus the ones I have linked through myOFM into one feed?

Yes. Both surfaces sit behind the same member session — the bank's own accounts and the outside-FI accounts the member has linked into myOFM. Our extractor walks both and emits a single normalized account-id / transaction stream so downstream code does not need to know which side each row came from.

How does the build keep working when TBT updates the mobile app or the portal?

We ship a contract-test pass that runs nightly against a recorded transaction shape. When TBT renames a field or moves a step in the login flow, the pass goes red, we ship a patch under the included maintenance window, and downstream consumers see no break.

Texas Bank and Trust is a community bank — does any US rule actually require them to share this data with us today?

Not today. The CFPB Personal Financial Data Rights rule that would have moved the industry in that direction is currently enjoined while the Bureau reconsiders it, and TBT has no live obligation to a third party under it. The build runs on the member's own authorization to access their account — that is the basis we rely on.

What happens to the tags, notes and receipt images a customer has added inside myOFM?

They come along. myOFM stores those as per-transaction enrichment fields on the same record the extractor reads, so we pass them through into the normalized output and they stay queryable downstream.

So: the build lands in 1–2 weeks. Source-code delivery starts at $300 and is paid after delivery once you are satisfied; the other path is the hosted endpoints we run, where you call them and pay per call with no upfront fee. Send the app name and what you need from its data through contact — access, consent capture and compliance are arranged with you inside the engagement.

What this draws on

This brief was put together against the live TBT property and the relevant US rule sources, on 2026-05-29. Citations:

• Texas Bank and Trust — Mobile Banking page — confirms the mobile app's scope and the aggregator framing.
• Texas Bank and Trust — Digital Banking Features — confirms account aggregation, alerts and tagging features.
• Texas Bank and Trust — myOFM Terms and Conditions (PDF) — names the in-app aggregator and the scope of its data handling.
• CFPB — Personal Financial Data Rights Reconsideration — primary source on the §1033 reconsideration status.