Connecting to YOURFNB, the First National Bank of Williamson's mobile app

The First National Bank of Williamson is a national-charter community bank headquartered in Williamson, West Virginia, with roughly $112 million in assets per the FDIC's BankFind entry (cert. 6805, RSSD 917630). Its retail mobile app ships as YOURFNB on Android (package com.yourfnbonline.grip per its Play Store listing) and iOS (App Store id 1575743186 per its App Store listing). The interesting part for an integrator is what the customer-facing app actually exposes once a user is signed in — a transaction ledger you can tag and annotate, RDC, account-to-account transfers, person-to-person payments, card controls, statement PDFs and balance alerts — all behind the same authenticated session.

The honest read is that this is a small charter with rich authenticated-portal data and no public catalogue to point at. That is fine — it is how most of US community banking looks at the data-rights level, and the route we would take here is the one we routinely deliver for charters of this size. The recommendation up front: drive the build off the consenting customer's own YOURFNB session, ship a normalized OpenAPI on top of it, and keep an aggregator path open as a fallback for customers who already have a Plaid or MX link in place.

Data that actually lives in the YOURFNB account

Mapped from the Play and App Store descriptions and what the app screens visibly surface:

Authorized routes for getting at it

Three routes apply in this case. They are not equal, and the page is honest about which we would push toward.

1. User-consented protocol analysis of the YOURFNB session

The customer signs in to YOURFNB inside a controlled environment, gives written, scoped consent to act on their behalf, and we map the request/response shape the app uses against the bank's host (go.yourfnbonline.com per the bank's own browser landing page). The deliverable is an OpenAPI plus runnable client code. Durability is reasonable but not infinite — the app is a white-label build shared across small FNB charters, so a vendor update can change endpoint shapes. We handle that as part of the engagement, not as a customer headache. Effort: medium. Best fit when the customer is a single business or family-of-accounts integrator who wants their data, not the whole bank's book.

2. Aggregator fallback (Plaid, MX, Finicity, Yodlee)

If the customer already has a Plaid Link or MX connection to FNB Williamson, the cheaper option is to wire onto that. Aggregators cover balances and transactions well for small US charters and are appropriate for read-only flows. The trade is depth — RDC images, tag/receipt metadata, alert config and the card-control write surface generally do not come through aggregators. We use this route when the customer is fine with the limits, and we ship a thin adapter so the calling code does not care which source backs it.

3. Native export

The app exposes monthly statement PDFs and the transaction list is exportable from the web sibling. For a one-shot reconciliation job this can be enough, and we will say so honestly when it is — there is no need to commission a custom integration if the customer only needs last quarter's CSVs.

We would lead with route 1 here. Aggregator coverage of a small WV charter can be patchy, and the parts customers most want — the tagged transactions and the RDC images — only really live in the YOURFNB session itself.

What you get back at handoff

For a YOURFNB engagement, the package is concrete:

• An OpenAPI 3.1 specification covering the surfaces above, with separate read endpoints for balances, transactions, statements and RDC, and clearly-marked write endpoints for transfers, P2P, and the debit-card lock/reorder pair.
• A protocol and auth-flow report — the login chain, session/token handling, step-up auth on write operations, refresh behaviour, idle timeout — written so a new engineer on your team can read it and ship.
• Runnable client source in Python and Node.js for the key endpoints. Not a stub. The Python client is what gets used by most customers, the Node version is there for browser-adjacent stacks.
• A pytest suite that exercises the happy path and the realistic failure modes (login challenge, expired session, RDC pending vs cleared, transfer rejected for insufficient funds).
• Interface documentation and a short operational runbook — what to watch for, what to alert on, how to revalidate after a vendor build update.
• Consent and data-retention guidance written for a US bank's compliance posture: scoped authorization, revocation, logging, data-minimization.

A look at the request shape

The block below is illustrative — final field names and exact endpoints are confirmed during the build against a consenting account — but the auth pattern and the transaction-list contract are the kind of thing the OpenAPI will pin down precisely.

# Illustrative; finalized during the build against a consenting YOURFNB session.

POST /session/login
Content-Type: application/json
{
  "username": "<user>",
  "passcode": "<4-digit-passcode>",
  "device": { "fingerprint": "<dvc>", "biometric": false }
}
→ 200 { "session_token": "...", "expires_in": 900, "step_up_required": false }

GET /accounts/{account_id}/transactions?since=2026-04-01&limit=200
Authorization: Bearer <session_token>
→ 200 {
  "account_id": "...",
  "transactions": [
    {
      "id": "txn_01J...",
      "posted_at": "2026-05-28T14:02:11Z",
      "amount": -42.17,
      "currency": "USD",
      "merchant": "PIGGLY WIGGLY #114",
      "status": "posted",
      "user_tag": "groceries",
      "user_note": "weekly run",
      "receipt_image_url": "https://.../rcpt/...jpg"
    },
    { "id": "txn_01J...", "status": "pending", "amount": -18.40, "merchant": "SHELL OIL" }
  ],
  "next_cursor": null
}

# RDC has its own shape — the image lives on the deposit, not the posted txn
GET /rdc/deposits/{deposit_id}
→ 200 {
  "deposit_id": "...", "declared_amount": 250.00,
  "front_image_url": "...", "back_image_url": "...",
  "clearing_status": "pending", "hold_until": "2026-06-02"
}

Where the build gets tricky, and how we handle it

The honest engineering notes for this specific app:

• Shared white-label build. The .grip package suffix is shared across at least the Williamson app, the FNB Jeanerette app (com.yourfnb.grip) and another small FNB build (com.fnb_bank.grip), so the YOURFNB client is a vendor-supplied skin that does get updated. We pin contract tests against the version we built on and re-run them before each scheduled sync after a known update, so a parser regression does not surface as silent missing data downstream.
• RDC is not just a transaction. A deposit emits an image pair, a declared amount, a clearing status and a hold date, and only later does a matching credit appear in the posted ledger. The integration treats RDC as its own resource and reconciles to the posted credit when it lands, rather than pretending the deposit and the credit are the same record.
• Card controls are write operations and they touch fraud paths. Lock/reorder are wired into the OpenAPI as explicit write endpoints with step-up auth, an idempotency key on lock, and an audit log on every call. We design them assuming the bank's fraud team can see every action and we want it that way.
• Small-charter operational reality. Williamson is a three-branch institution with a small ops staff. We handle bank-side coordination (sponsor introductions, sandbox or controlled-account access, written authorization paperwork) during onboarding so the customer's main task is to tell us which accounts they want covered and what they want to do with the data.

Consent and the §1033 backdrop

Concretely for FNB Williamson: there is no in-force US data-rights rule the build can sit on today. The CFPB's Personal Financial Data Rights rule under 12 CFR Part 1033 was finalized in October 2024, then enjoined and stayed by the court in Forcht Bank v. CFPB in late 2025, with the Bureau publishing an advance notice of reconsideration in August 2025. It is where the regime may end up; it is not where the regime is. The basis we actually use is the customer's own authorization — written, scoped to specific data domains (balances, transactions, RDC, statements, card state), time-bounded, and revocable. Every authorized call is logged with a consent reference. If §1033 lands in a form a small national bank like Williamson has to comply with, the consent and audit layer we ship is the layer that points at it.

Likely integration scenarios

• Bookkeeping ingest for a Mingo-County small business. Posted transactions plus statement PDFs flow into the customer's accounting tool nightly. RDC images attach to the same records. Cheapest viable build.
• Family-office cash visibility. Balances across a household's YOURFNB accounts, plus a few external aggregator-sourced accounts, normalized into a single read endpoint behind one auth.
• Lost-card automation. A consumer-facing helper app that detects a likely lost-card pattern and calls the YOURFNB card-lock write endpoint with step-up auth, then files a reorder.
• Mortgage underwriting evidence. A read-only consent for the last 12 statement PDFs and 24 months of posted transactions, pulled once, signed and archived.

Freshness and reliability

YOURFNB is a session-based app with relatively short token lifetimes — minutes, not hours — so a long-running sync is really a loop of consented re-auths. We design around that rather than against it: scheduled syncs run at the cadence the customer actually needs (most pick hourly for balances, daily for transactions), and any write call goes through a fresh interactive session. The aggregator fallback, where used, runs against its own SLA and is monitored separately so the customer sees one combined health signal.

Other community bank apps in the same lane

An aggregator covering YOURFNB sensibly also covers other small US community-bank apps. These are the names we hear next to it most often:

• Your FNB Jeanerette — the First National Bank of Jeanerette, Louisiana, on what appears to be the same vendor shell as YOURFNB.
• FNBOnline — another small First National Bank build on the same package family.
• FNB Community Bank — Midwest City, Choctaw and Moore, Oklahoma; a similarly-sized community charter with a comparable feature set.
• The FNB Community Bank — separate community bank brand, similar product surface for an integrator.
• FNB Bank — Western Kentucky community bank with mobile balances, transfers and RDC.
• Our Community Mobile Banking — small-credit-union mobile app family with mobile check deposit and card management.
• CommunityAmerica Credit Union — larger Kansas-City credit union with a similar member-facing data set.
• United Community Bank — southeast US community bank with debit-card controls and statement download.
• Community Bank, N.A. (CBNA) — upstate New York community bank app.
• Community First Credit Union — CU mobile platform with the same RDC and transaction surface.

None of these are competitors to YOURFNB in the consumer sense; they are simply the next-door integrations a customer who has consented to a YOURFNB build often asks for in the same engagement.

Where the facts came from

This page draws on the bank's own digital presence (the YOURFNB Play Store and App Store listings, and the bank's go.yourfnbonline.com sign-in surface), the FDIC's BankFind entry for cert. 6805, and the public CFPB / Federal Register record of the §1033 reconsideration. Sources checked:

• YOURFNB on Google Play
• YOURFNB on the App Store
• FDIC BankFind — The First National Bank of Williamson
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 22, 2025)

Mapped May 2026 by the OpenBanking Studio integration desk.

Questions integrators ask first

Can the build cover mobile check deposit, not just the visible account history?

Yes. RDC has its own surface inside YOURFNB — front/back capture, a clearing status, and a hold window — so we treat it as its own endpoint and store the image alongside the posted transaction once it matches. The sync is timed against the bank's settlement window so the integration doesn't claim 'cleared' before posted truth.

How is the debit-card lock and reorder action wired into the API?

Those are write actions, not reads, so they get a separate route in the OpenAPI we deliver, with explicit consent scopes and an audit log on every call. The reorder flow needs an address payload; the lock toggle is idempotent. Both are gated by step-up auth in the YOURFNB session and we mirror that in the spec.

Where does US §1033 fit for a small national bank like FNB Williamson?

§1033 is where the US data-rights regime may end up; today it is enjoined and back at the CFPB for reconsideration, so it is not the basis the build leans on. The dependable basis right now is the customer's own authorization, captured on the record, scoped per data domain, and revocable. If and when §1033 settles, the consent layer we ship is straightforward to repoint.

What about the photos and tags users attach to transactions inside YOURFNB?

Those are stored against the transaction record — receipt or check image plus a free-text tag/note — and the app surfaces them in the transaction detail view. We pull them through the same authorized session as the posted transaction, normalize the image references, and expose them as optional fields on the transaction object so downstream code can ignore them if it doesn't need them.

Send the requirement — which YOURFNB data, which write surfaces, which scenarios — and we will scope it: source-code delivery from $300, paid after delivery once you have run it against a consenting account and are satisfied, or a pay-per-call hosted API with no upfront fee. Cycle 1–2 weeks. Start a conversation at /contact.html.