Integrating the myOFM account feed inside TBT Mobile

Behind a TBTmyWay login, this app gathers balances and transaction history from accounts the customer holds elsewhere, not only the ones at Texas Bank and Trust. The bank brands that aggregation feature myOFM, and its own digital-banking page describes it as a way to track every financial account in one place even when the accounts are not with the bank. So the data surface is wider than a single institution's ledger. That is the thing worth integrating.

For most teams the useful read is the merged transaction stream: per-account balances, posted transactions with merchant and category, and the user's own enrichment on top. We reach it the way the app does — through the authenticated session, with the account holder's consent — and hand back code that pulls it on a schedule. The lead question is freshness, not access, because half the feed is second-hand from other banks.

What sits behind a TBTmyWay login

These are the surfaces the app actually exposes, drawn from its store listing and the bank's feature pages. Each maps to something an integrator can model.

Authorized ways into the account data

Three routes genuinely apply here. Which one leads depends on whether you want a single customer's TBT accounts or the whole aggregated picture myOFM already maintains.

Consent-based interface integration

We work the authenticated session a TBTmyWay customer uses, under that customer's authorization, and read the same balance and transaction surfaces the app renders. Reachable: everything the user can see in-app. Effort is moderate; durability is good as long as the auth flow is tracked. We set up a consenting test account with you at onboarding and build against that.

Integration at the myOFM aggregation layer

Because myOFM already stitches together outside institutions, integrating where that data lands lets you inherit those connections rather than re-linking every bank yourself. Reachable: the consolidated cross-institution feed. Effort is lower per added institution; durability follows the aggregator's connection health, which we monitor.

Native export as a fallback

Where a customer needs documents rather than a live feed, the eStatements archive and in-app transaction views give a file-based path. It is the least real-time option and we treat it as a backfill source, not the spine of a sync.

For a community-bank PFM app whose value is the merged view, we would lead with the consent-based session for a customer's own accounts and add the aggregation-layer read when outside institutions matter. The native export fills history gaps.

What you get back at hand-off

The deliverable is working code first, with the written artifacts around it.

• Runnable client source in Python and Node.js — token exchange against the consenting session, the account list (TBT plus aggregated externals), and the transaction-delta pull with a cursor.
• An event handler for the alert stream — a worked receiver for low-funds and bill-due events, wired to whatever you do downstream.
• An automated test suite — recorded fixtures for the auth flow and a transaction page, so a change in the upstream behaviour shows up as a failing assertion rather than a quiet gap.
• Sync design — a bulk backfill for history plus an incremental delta over posted_at, against a normalized schema that keeps TBT and aggregated accounts distinguishable.
• An OpenAPI description and an auth-flow report — the token and session chain as it actually behaves here, written up once the build confirms it.
• Interface documentation plus data-retention and consent guidance — what is stored, for how long, and on what authorization.

How a sync call looks

Illustrative only; field names are confirmed against the live session during the build. It shows the two reads most teams want — the account list with a freshness stamp, and an incremental transaction pull that carries the user enrichment.

# Generated client we hand over: TBT Mobile account feed
from tbt_feed import Session

s = Session.from_consent(consent_token)   # a consenting TBTmyWay account
s.refresh_if_stale()                      # renew the token before it lapses

# Every account the app shows: TBT-held plus myOFM-aggregated externals
for acct in s.accounts():
    print(acct.id, acct.institution, acct.balance, acct.as_of)

# Pull only what posted since our last cursor for one account
page = s.transactions(account_id=acct.id, since_cursor=cursor)
for txn in page.items:
    upsert({                              # keyed on txn.id
        "id": txn.id,
        "posted_at": txn.posted_at,
        "merchant": txn.merchant,
        "amount": txn.amount,
        "category": txn.category,
        # in-app enrichment, present only when the user added it
        "tags": txn.tags or [],
        "note": txn.note,
        "receipt_image_id": txn.receipt_image_id,
    })
cursor = page.next_cursor

# Alerts the app raises arrive as events
@app.post("/hooks/tbt-alert")
def on_alert(evt):
    if evt.type == "low_funds":
        notify(evt.account_id, evt.threshold)
    elif evt.type == "bill_due":
        queue_review(evt.account_id, evt.due_date)
    return {"ok": True}

Where teams plug this in

• A bookkeeping tool that ingests a client's full cash position across TBT and outside accounts ahead of the monthly close.
• A lender pulling categorized transaction history for a cash-flow read, with the as_of stamp telling it which balances are live.
• An expense product that consumes the receipt photos and tags users already attach in the app.
• A treasury dashboard that reacts to low-funds alerts to trigger a sweep.

Consent and the US data-rights picture

The data holder is Texas Bank and Trust Company; the person who can authorize access is the enrolled TBTmyWay customer. That authorization is the dependable basis for everything we build — consent on record, scoped to the accounts and fields you need, revocable, and logged. We keep the read data-minimized and sign an NDA where the work touches anything sensitive.

On the federal rule: the CFPB's Section 1033 Personal Financial Data Rights rule was finalized but is currently enjoined and back in reconsideration at the agency, so it is not the framework an integration rides today. We treat it as where consumer-data access in the US may go, not as present law. The design we deliver rests on the account holder's own consent, which means it does not depend on how 1033 is resettled and extends cleanly if a stable version arrives.

Build details we plan around

Two things about this app shape the engineering, and we handle both on our side.

Mixed freshness across the feed. TBT's own accounts update close to live, but the accounts myOFM aggregates from other institutions settle on the upstream provider's polling cadence and can lag or temporarily drop a link. We carry a per-account as_of through the schema and treat aggregated-account connection health as a monitored state, so a downstream consumer never mistakes a stale external balance for a live one.

Optional, user-generated enrichment. Tags, notes, receipt and check images, and geo-information exist only when the customer added them. We model these as nullable side fields keyed to the transaction, so a bare transaction and a richly annotated one both validate against the same schema. Access to a consenting account or a sandbox is arranged with you during onboarding; we build the token and passcode-gated auth flow against that rather than around scraped credentials.

Cost and the build cycle

A first working pull of the transaction feed usually lands inside one to two weeks. You can take the result as source code — runnable API source plus documentation, from $300, billed only after delivery once you have checked it does what you need. Or run it as a hosted API you call and pay for per request, with nothing upfront. Tell us the app and what you want out of its data, and access and compliance get arranged with you as part of the work. Start a TBT Mobile integration

Screens we worked from

What we read, and when

Checked on 8 June 2026 against the app's public store listing and Texas Bank and Trust's own digital-banking pages, plus current US regulatory status for consumer data access. Primary sources:

• Texas Bank and Trust Mobile on Google Play — feature list and data the app aggregates.
• TBT digital-banking features — myOFM aggregation, eStatements window, card controls and alerts.
• CFPB — Personal Financial Data Rights Reconsideration — current status of the §1033 rule.
• Section 1033 enjoined and under reconsideration — the injunction and reconsideration timeline.

OpenFinance Lab · interface assessment, June 2026.

Comparable money apps

The same multi-account, aggregation-first pattern shows up across these consumer finance apps. They share the integration problem TBT Mobile poses — many institutions behind one view — which is why naming them helps map the space.

• Monarch Money — net-worth and budgeting dashboard that syncs thousands of institutions through Plaid, Finicity and MX.
• YNAB (You Need A Budget) — zero-based budgeting that imports transactions from connected bank and card accounts.
• Rocket Money — cash-flow tracking and bill management over synced external accounts.
• Credit Karma — net-worth and account tracking that took on Mint's aggregation features.
• Quicken Simplifi — budgeting and real-time net worth across connected accounts.
• PocketGuard — spending-left view that aggregates bank, card and investment balances.
• Copilot Money — account, brokerage and crypto aggregation in a single dashboard.

Questions integrators ask

Some accounts in the app come from other banks. How current is that data?

Accounts held at Texas Bank and Trust refresh close to real time, the way they do inside TBTmyWay. The accounts pulled in through myOFM aggregation settle on the upstream provider's polling schedule, so they can lag or drop a connection. We expose a per-account as_of timestamp in the sync so your side always knows which balances are live and which are a recent snapshot.

Do you build against myOFM's aggregation layer or the account data directly?

Either, depending on what you need. For a customer's own Texas Bank and Trust accounts we work the authenticated session the app already uses. For the wider picture that myOFM assembles across outside institutions, we integrate at the aggregation layer so you inherit those connections instead of rebuilding them. We pick the route per project after looking at which accounts actually matter to you.

Does the CFPB open-banking rule give a right to this data today?

Not as settled law right now. The CFPB's Section 1033 Personal Financial Data Rights rule was finalized but is currently enjoined and back in reconsideration at the agency, so it is not in force. The basis we rely on is the account holder's own authorization to access their data, which is what every integration we deliver is built on. If 1033 lands in a stable form, the same consent-based design extends to it.

Can you capture the tags, notes and receipt images people attach to transactions?

Yes. That enrichment is user-generated and optional per transaction, so we model it as separate nullable fields keyed to the transaction id. A purchase with a photographed receipt, a note and a geo-tag comes through with those attachments populated; a plain transaction comes through clean without breaking the schema.