Reaching YOURFNB balances, statements, and the outside accounts it aggregates

The single most useful thing in YOURFNB, from an integration standpoint, is the aggregated view. First National Bank of Williamson members link accounts held at other banks and credit unions and read them next to their FNB balances in one list. That one feature decides the shape of any integration. You are not pulling a single institution’s ledger — you are pulling a member-curated set of accounts, each with its own source and its own refresh latency, already consolidated inside the app the member uses.

For a consumer of this data, the natural first step is a bulk backfill: read the full account set and as much transaction history as the member can see, normalize it once, then keep it current with smaller incremental reads. The app names its own surfaces plainly — transactions you can tag and attach receipt photos to, monthly statements, internal transfers, payments to a company or a person, mobile check deposit, and debit-card controls. Each of those is a place data originates. Below is what is actually reachable, the authorized route we would take, and what we hand over.

Bottom line: one consented session against the live app captures the whole consolidated picture in a single place, which is cleaner than chasing each linked institution separately. We would build the protocol path against that session, with native statement export as a backfill for older documents.

What sits behind a YOURFNB login

These are the surfaces the app exposes to an authenticated member, mapped to where each one originates and what an integrator would do with it. The set follows the feature list in the app’s own store description.

Authorized ways in

Three routes fit this app. All of them run on the member’s own access; nothing here describes getting around a login.

Interface integration and protocol analysis of the app

We observe and re-implement the traffic the YOURFNB client makes after the member signs in with a passcode or biometric. This reaches everything the member sees in one place — native balances and the aggregated external accounts together. It is the most complete route and the most durable while the app shell stays stable. Access is arranged with you during onboarding against a consenting member account, so the build runs end to end before delivery.

Aggregation-style consented read for the external slice

The outside accounts in YOURFNB are themselves pulled with read-only consent, the pattern US aggregators such as MX, Finicity and Plaid run on. Where you only need the linked-institution slice, a parallel consented read can complement the app path and give that data its own refresh cadence.

Native export as backfill

Statements are downloadable inside the app, so the document archive can be ingested directly as a one-time historical load. This route is narrow but reliable for older records that predate your incremental sync.

What we would actually recommend: make the app path the spine, because a single consented session already holds the consolidated view, and use statement export to backfill history. The aggregation-style read is worth adding only if you want the external accounts on a separate clock from the FNB-native data.

Session and transaction pull, as observed

A sketch of the flow we implement. Field names and paths here are illustrative and get confirmed against the live client during the build; the structure is what a consumer of this app deals with.

# YOURFNB  (Android package com.yourfnbonline.grip)
# 1) Device-bound session from the member's passcode/biometric sign-in
POST https://go.yourfnbonline.com/grip/auth/session
  { "device_id": "<enrolled-device>", "factor": "biometric|passcode" }
  -> { "access_token": "...", "expires_in": 900, "member_ref": "..." }

# 2) Unified account list: FNB-native + aggregated external, tagged by source
GET /grip/accounts?include=linked
  Authorization: Bearer <access_token>
  -> [ { "account_ref":"a_01", "type":"checking", "source":"fnb",
         "balance":{ "available":"...", "current":"..." } },
       { "account_ref":"a_77", "type":"savings",  "source":"aggregated",
         "institution":"...", "as_of":"...", "balance":{ "current":"..." } } ]

# 3) Transactions, cursor-driven: empty cursor = bulk backfill, then top-up
GET /grip/accounts/{account_ref}/transactions?cursor=<last>&limit=200
  -> { "items":[ { "id":"...", "posted":"...", "amount":"...",
                   "tags":[...], "has_receipt":true } ],
       "next_cursor":"..." }   # null when caught up

# Retry note: a re-run with the same cursor returns the same page,
# so backfill is safe to resume after an interruption.

The cursor is the whole game for a banking feed. An empty cursor walks history for the backfill; the saved cursor then fetches only what posted since. The source field is what keeps native and external balances distinguishable downstream.

One schema across native and linked accounts

Because the app mixes FNB-held and externally linked accounts, the deliverable normalizes both into one shape, carrying the source and a freshness stamp so a stale linked-bank read is never mistaken for a live balance.

{
  "account_ref": "a_77",
  "owner": "member",
  "source": "aggregated",          // "fnb" | "aggregated"
  "institution": "Other Bank, N.A.",
  "type": "savings",
  "balance": { "current": "1240.55", "currency": "USD" },
  "as_of": "2026-06-15T09:02:00Z",  // per-account freshness
  "tx_cursor": "..."
}

What lands in your repo

Delivery is code first. The headline artifact is source you can run, scoped to the surfaces above.

• Runnable clients in Python and Node.js for the session handshake, the unified account list, and the transaction backfill plus incremental sync.
• Batch backfill and incremental sync design with cursor checkpointing, so a resumed run continues from the last saved page instead of starting over.
• An automated test suite that exercises the flow against a consenting member account and asserts on the account-source flag and balance freshness.
• The normalized schema above, plus mapping notes from the raw app fields to it.
• An OpenAPI description of the surfaces we re-implement, and a protocol and auth-flow report covering the device-bound token chain.
• Interface documentation and data-retention guidance for handling member financial data.

Consent and the US data-rights picture

The dependable basis for this work is the member’s own authorization — the same read-only consent YOURFNB already uses when it aggregates a member’s outside accounts. We operate that way throughout: access granted by the account holder, every consented session logged, consent records kept, data minimized to what the integration needs, and an NDA in place where the engagement calls for one.

The CFPB’s Section 1033 Personal Financial Data Rights rule is not something this integration rides on today. A federal court in Kentucky enjoined its enforcement in late 2025, and the Bureau reopened it through an advance notice of proposed rulemaking, so its specifics are unsettled. We treat it as a direction the rules may take, not current law, and we do not build obligations on numbers that are back in reconsideration.

Build details we account for

Two things about YOURFNB specifically shape how we write the integration.

The aggregated accounts are read-only mirrors with their own latency. An external balance the app shows might have been refreshed minutes or hours ago by whatever aggregator feeds it. We carry a per-account as_of stamp through to the normalized records and surface FNB-native balances and linked-bank balances on separate freshness clocks, so a consumer never treats a cached mirror as a live figure.

The .grip client is a multi-tenant shell. The same app binary signature appears across more than one First National Bank listing on Google Play, with the institution differing by tenant and host. We pin the build to the Williamson tenant and keep the host parameterized, which means the protocol work is reusable if you later need a sibling institution on the same platform rather than a rewrite.

Session tokens are short-lived and tied to an enrolled device, so the build keeps re-authentication on its own timer, sequenced with the consent the member granted. Access, the consenting test account, and any sandbox are arranged with you as part of onboarding.

Inside the app

Store screenshots of YOURFNB, useful for orienting against the surfaces above. Select to enlarge.

Apps that aggregate the same way

YOURFNB’s consolidated view puts it in the same data category as the consumer aggregation apps below. Each holds a comparable cross-institution picture, which matters because a unified integration usually has to speak to several of these at once. Named for context, not ranked.

• Monarch Money — links bank, card and investment accounts into budgets and net worth; the closest full replacement many former Mint users picked.
• Rocket Money — aggregates accounts with a focus on recurring charges and subscription tracking.
• YNAB (You Need A Budget) — pulls linked accounts into a zero-based budgeting model.
• Simplifi by Quicken — aggregates balances and transactions around spending plans and projected cash flow.
• Copilot — an iOS-first aggregator with strong transaction categorization and net-worth tracking.
• Credit Karma — now links accounts for a net-worth view; where Intuit pointed many former Mint users.
• PocketGuard — links accounts to show spendable balance after bills and goals.
• Tiller — feeds aggregated bank and card data into spreadsheets.

Questions integrators ask about YOURFNB

Does YOURFNB data come back as a one-time snapshot, or can the integration keep it current?

Both are part of the build. We backfill historical transactions and statements in bulk, then run an incremental pull keyed on the last cursor so new activity and balance changes are picked up on a schedule you set. Aggregated external accounts refresh on their own latency, so we track their freshness separately from First National Bank of Williamson's native balances.

Can the build tell First National Bank of Williamson's own accounts apart from the linked outside ones?

Yes. The unified view tags each account by source, so the integration carries a native-versus-aggregated flag through to the normalized schema. You can route FNB-held balances and externally linked balances to different consumers, or reconcile them together.

Which US data-rights rules govern pulling data out of YOURFNB?

The basis we rely on is the member's own authorization, the same read-only consent the app already uses to aggregate outside accounts. The CFPB Section 1033 Personal Financial Data Rights rule is not something this work depends on: its enforcement was enjoined by a federal court in late 2025 and the Bureau reopened it for reconsideration, so we treat it as a possible future direction rather than current law.

The same .grip app shell powers several First National Bank apps. Does that change anything?

It helps. The client behind com.yourfnbonline.grip is a multi-tenant shell, so the protocol work transfers across tenants. We pin the build to the Williamson tenant and parameterize the host, which keeps the source reusable if you later need a sibling institution on the same platform.

Sources and authorship

Checked on 15 June 2026 against the app’s own store listings and the bank’s public pages, plus the current CFPB rulemaking record for the data-rights status. Version 3.35.0 is the build named on the App Store at the time of writing. Primary references:

• YOURFNB on the Apple App Store
• YOURFNB on Google Play (com.yourfnbonline.grip)
• The First National Bank of Williamson — about
• CFPB — Personal Financial Data Rights reconsideration

Compiled from the YOURFNB build by OpenFinance Lab — engineering notes, 15 June 2026.

Getting started

A first YOURFNB drop — session handling, the unified account list with the source flag, and a cursor-driven transaction backfill — runs about one to two weeks. Take it as runnable source from $300, billed only after delivery once it works against your consenting account; or skip running it yourself and call our hosted endpoints on a pay-per-call basis with nothing upfront. Send the app name and what you need from its data through our contact page, and we arrange access and the consenting test account with you from there.

Start a YOURFNB integration