What it takes to read a First Guaranty Bank account programmatically

Behind a single MyFGB login sits the full picture of a First Guaranty Bank customer: what is in each account today, what has cleared, what is still pending, where money moved, and the messages the bank sent back. First Guaranty Bank has operated out of Hammond, Louisiana since 1934 and is FDIC-insured under certificate 14028, per the FDIC BankFind record. The app exists to put that account state in one customer's hand. Our job is to make the same account state available to a system that customer authorizes — cleanly, on a schedule, in a shape you can build on.

The honest summary up front: every screen the account holder sees in MyFGB is reachable by software acting with that account holder's permission, and that is the route we would run here. The federal data-rights rule that would standardize this is unsettled right now, which changes the transport we prefer over time but not whether the work can be done today.

Account data inside the MyFGB app

These are the surfaces the app itself exposes, named the way it presents them. Granularity is what a session can actually pull, not a wish list.

Getting to that data: the routes that apply here

Consumer-permissioned protocol integration

The account holder authorizes access; we drive the same session the app drives. This reaches everything in the table above because it is the app's own data path. Effort is moderate — the work is in the authentication handshake and pagination, not the payloads. Durability is tied to the app's front end, so we maintain it. Access is arranged with you and a consenting account during onboarding; we capture and document the flow as part of the build.

Standardized transport over FDX

The CFPB has recognized the Financial Data Exchange as a standard-setting body for permissioned financial data. If First Guaranty Bank's digital-banking provider exposes an FDX-conformant endpoint, the same consumer permission carries a cleaner, more durable transport. We design the schema so this swap does not ripple into your code.

Native statement export

Where the portal offers statement or activity download, that file is a coarse, durable backfill. It will not give you pending entries or intraday balances, but it cross-checks the live pull and seeds history. Low effort, used as a complement rather than the spine.

What we would actually run for First Guaranty Bank is the consumer-permissioned session as the working spine, with the FDX transport adopted the moment it is available and native export kept as a reconciliation source. That ordering is driven by what the MyFGB app exposes today versus what is standardizing around it.

A worked example: balances plus pending and posted activity

Field and path names below are illustrative and are confirmed against the live app during the build; the structure — sign-in, one-time-code step, account list, then per-account activity split by status — reflects how this class of app behaves.

# 1. Authenticate. The MyFGB sign-in returns a session plus an OTP challenge.
POST https://digital.<fgb-host>/auth/login
   { "username": "...", "password": "..." }
-> 200 { "session": "tok_…", "challenge": "otp_required", "deviceKnown": false }

POST https://digital.<fgb-host>/auth/otp
   { "session": "tok_…", "code": "######", "rememberDevice": true }
-> 200 { "session": "tok_…", "expiresIn": 900 }

# 2. List accounts the consenting customer holds.
GET /accounts            Authorization: Bearer tok_…
-> [ { "id": "ac_01", "type": "CHECKING", "available": 4182.55, "current": 4205.10 } ]

# 3. Pending and posted are separate reads — keep them separate.
GET /accounts/ac_01/transactions?status=pending&cursor=
-> { "items":[ {"authId":"a91","desc":"...","amount":-58.20,"status":"PENDING"} ],
     "nextCursor": null }

GET /accounts/ac_01/transactions?status=posted&cursor=
-> { "items":[ {"txnId":"p552","postedAt":"2026-05-15","amount":-58.20,
                "runningBalance":4205.10,"status":"POSTED"} ],
     "nextCursor": "c_eyJ…" }

# Error handling that matters in practice:
#   401  -> session aged out; re-run OTP only if device no longer trusted
#   409  -> step-up re-challenge; pause, do not hammer
#   429  -> back off; poll cadence is matched to the account's MFA tolerance

The composite of authId while pending and txnId once posted is what lets a settled entry replace its pending twin instead of double-counting. That single decision drives most of the reconciliation logic.

What lands in your repo

Concrete artifacts, each tied to a surface above:

• An OpenAPI specification covering the sign-in and OTP exchange, account list, and the pending and posted transaction reads as they behave for an FGB account.
• A protocol and auth-flow report: the token lifecycle, device-recognition step, session expiry, and the step-up conditions seen on this app.
• Runnable source — a MyFGB session client plus the balance, transfer, bill-pay and transaction endpoints — in Python or Node.js, whichever you build on.
• Automated tests, including a fixture set captured from the live app so a changed field fails a test rather than corrupting your data.
• A normalized schema that carries the pending-to-posted status lifecycle, with interface documentation written for an engineer who has never seen the app.
• Data-retention and consent-record guidance scoped to how the account holder authorized the access.

Permission and the US data-rights picture for an FGB account

The legal spine here is simple: a First Guaranty Bank customer has the right to authorize a third party to reach their own deposit data, and our access stands on that authorization, recorded and scoped. First Guaranty Bank is a CFPB-covered insured depository, so the federal frame is Section 1033 of Dodd-Frank, administered by the Consumer Financial Protection Bureau. That rule is in active reconsideration — the CFPB opened an advance notice of proposed rulemaking on 22 August 2025 and the compliance dates were stayed by the Eastern District of Kentucky on 29 October 2025 — so we do not state its forward obligations as settled, and we do not need them: the consumer-permissioned route does not depend on the rule's final form. We run authorized access only, minimize the fields pulled to what the use case needs, keep consent and access logs, and work under an NDA where the engagement calls for one. If the rule lands and FGB's provider exposes an FDX endpoint, that becomes the cleaner path and the consent model barely changes.

Engineering realities we plan around

Specific to this app, written as things we handle:

• Device recognition on sign-in. The MyFGB login pairs a one-time code with device trust. We model that challenge in the session client and register the automation as a recognized device with the account holder, so a scheduled pull does not re-trigger step-up every run.
• Pending-to-posted drift. An authorization can change amount or disappear between the pending list and the posted ledger. We key records by a stable composite and carry a status lifecycle, so a pending entry that settles updates in place.
• One data model, four states. Branch, ATM and ITM content is segmented across LA, KY, TX and WV; the account data is not. We do not shard the integration by state, which keeps the schema flat and the sync simple.
• Front-end change. When the app's session surface shifts, the captured fixture set re-runs and the change shows up as a failing test before it reaches your database, not as silent corruption.

Where this goes in practice

• A business that banks at FGB pulls balances plus posted and pending activity across its accounts nightly into an internal treasury dashboard.
• A bookkeeping product syncs posted transactions into accounting software with stable IDs and a pending-to-posted reconciliation step.
• A lender has a consenting applicant authorize a bounded transaction pull for cash-flow underwriting.
• A personal-finance app adds First Guaranty Bank as a supported institution through the consumer-permissioned client.

Keeping the feed honest

Data is exactly as fresh as the app's own session: balances and pending entries are near real time, posted activity follows the bank's posting cycle. We poll on a cadence matched to the account's tolerance for re-authentication, cache between pulls, and back off on a step-up rather than forcing it. A monitored canary account flags front-end drift before it reaches your data.

Screens from the listing

Store screenshots, for interface reference. Select to enlarge.

How this brief was put together

Compiled on 17 May 2026 from the app's own store listings and description, the bank's public digital-services material, the FDIC institution record, and the CFPB's current Section 1033 status. Primary sources opened:

• FDIC BankFind — First Guaranty Bank (cert. 14028)
• First Guaranty Bank Mobile on the App Store
• CFPB — Personal Financial Data Rights (Section 1033)
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 2025)

Compiled by the OpenBanking Studio integration desk · 2026-05-17.

Other apps in the same integration class

Regional and community bank apps across the Gulf South sit in the same class — authenticated deposit data behind a one-customer login, reachable on the same consumer-permissioned pattern. Named neutrally for ecosystem context, not ranked:

• Hancock Whitney — checking, savings, card and loan data with Zelle and bill pay behind login.
• Regions Bank — retail deposit, card and payment data across a multi-state footprint.
• Origin Bank — Louisiana-rooted retail and business deposit accounts and transfers.
• b1BANK — Business First Bancshares' retail and commercial banking data.
• Home Bank — Lafayette-based deposit, bill pay and mobile-deposit data.
• Investar Bank — Baton Rouge community-bank deposit and transaction data.
• Gulf Coast Bank & Trust — New Orleans deposit accounts, transfers and payments.
• Fidelity Bank (NOLA) — Louisiana retail banking with online bill pay.

The same client shape covers all of them, which is why a single normalized schema usually serves a portfolio rather than one bank.

Questions integrators ask about the FGB app

FGB runs branches in four states — is the account data different state to state?

No. Branch, ATM and ITM content is segmented by Louisiana, Kentucky, Texas and West Virginia, but the account data model the app reads is the same regardless of where the account was opened. We do not shard the integration by state; coverage is locator metadata, not a data partition.

How does an automated pull get past the one-time-code step on the FGB login?

The MyFGB sign-in uses a one-time code and device recognition, which is typical for this class of app. We model that challenge in the session client and register the automation as a known device together with the account holder during onboarding, so a routine pull does not trigger step-up on every run. The exact challenge sequence is captured in the auth-flow report.

Can pending entries and posted entries be told apart in the output?

Yes. The app shows pending transactions separately from posted history, and the normalized schema keeps a status field plus a stable composite key so a pending authorization that later settles updates in place instead of being counted twice.

The CFPB Section 1033 rule is in reconsideration — does that stop this integration?

No. The route rests on the account holder's own authorization to reach their own First Guaranty Bank data, not on the federal rule's final shape. If FGB's digital-banking provider later exposes an FDX-conformant endpoint, we move the transport across without changing the schema you build against.

Timeline on a build like this is one to two weeks. Take it as runnable source — the MyFGB session client, the balance and transaction endpoints, the tests and the auth-flow report — from $300, invoiced only after delivery once it runs against a consenting account to your satisfaction; or skip hosting anything and call our endpoints instead, paying per call with nothing upfront. Tell us the app and what you need from its data at /contact.html and we will scope it back to you.