Reading Fortis Bank account data from a third-party stack

The Play Store identifier com.fortispb.grip resolves to Fortis Bank — a small commercial bank chartered in Colorado, with a loan-production office in Cottonwood Heights, Utah and FDIC certificate 34401 per the FDIC BankFind record. The institution rebranded twice in the last decade: per its own bank-locator filings it was Front Range Bank from 1997, became Fortis Private Bank in 2016, and adopted the present Fortis Bank name in 2023. The mobile front-end is published on Google Play with that package id (and on the App Store as bundle 1080201122 per its listing), and reads from the same Internet Banking back-end the bank's web customers use at myaccounts.fortisbankus.com. That is the surface this page is concerned with.

Bottom line: a small US community bank whose mobile app is a thin client over a standard Internet Banking stack. The interesting per-user data — balances, postings, the bank's merchant categories, customer-added tags and notes — sits behind a normal account login. There is no useful headline number to chase. The work is wiring a clean consumer-authorized read against an institution of this size and rebrand history.

What is actually reachable inside the GRIP-build app

The capabilities the Play Store listing names are the surfaces an integrator works against. The four rows below come directly from how the app describes itself; granularity is what we have seen on platforms of this class and is confirmed during the build, not promised up front.

The authorized routes that hold up

Three routes are workable for an institution of this size. We pick one as the spine and keep the others as failovers.

1. Consumer-authorized aggregator read (the spine)

Plaid, Finicity (Mastercard) and MX all carry US bank coverage at the community-bank tier. The consumer authorizes the aggregator as their representative; the aggregator returns balances, transactions and identity to your backend through a tokenized OAuth-style connection rather than holding the consumer's password. Per Plaid's public posture on its migration off screen scraping, around 80% of its traffic now runs on, or is committed to, API rather than credential connections — that share is uneven institution by institution, and is verified for Fortis Bank specifically during the build rather than assumed.

Effort: low to medium. Most of the work is the consent UX, the cursor and pagination semantics, and the token-refresh choreography. Durability: high — the route survives an issuer-side platform change because the aggregator absorbs it. For Fortis Bank engagements this is the recommended spine in almost every case.

2. Authorized interface integration against the GRIP-build app

Where aggregator coverage is incomplete or the refresh cadence is unacceptable, we run a documented protocol analysis of the GRIP-build app's traffic to the Internet Banking back-end. The work runs under written customer consent and against a consenting account the customer controls. The output is the request and response shape of the endpoints the app actually calls — login, account list, postings, the enrichment-write path for tags and notes — plus a runnable client. Effort: medium; the surface is small. Durability: tied to the bank's Internet Banking stack — historically stable for this institution, but every rebrand is a re-validation moment, which is why the build notes below pin the connection to the FDIC certificate.

3. Native export as a backstop

As a backstop for the first 24 months of history before the live read takes over, the Internet Banking web's per-statement export (OFX, QFX, CSV where offered) is the cheapest source. We use it as a one-off backfill, never as a sync mechanism.

The artifact bundle for a Fortis Bank build

Concrete artifacts sized for an institution this small. The order below is the order we hand them over.

1. A runnable Python and Node.js client against the spine route: connection resume from a stored consent token, paged transaction pull with cursor, balance refresh, write-back for user tags and notes where the route supports it, retry-on-429, and reconnection-on-revoked-consent. This is the most useful artifact first.
2. Webhook-or-poll handler scaffolding on the integrator side: a cursor table, an idempotency check against a posting-side stable key (booking-date plus amount-cents plus description hash, with the aggregator's posting id where present), and a back-off schedule tuned to the partner's published refresh policy.
3. An automated test harness — fixtures captured against a consenting test account, plus a small contract test that fails fast when the upstream payload shape drifts. This is what catches a quiet back-end change before it pollutes downstream books.
4. A batch-vs-realtime sync design — a one-page diagram and a written rationale for why this specific feed is polled at the chosen cadence, and where a realtime path would attach in the design.
5. An OpenAPI specification for the integrator-facing endpoints we build, plus a protocol and auth-flow report for the GRIP-build surface when route 2 is used.
6. A data-retention and consent-records memo sized to a US community-bank engagement: what is logged, where consent records sit, and how a revocation propagates through the cache.

Reconciliation sketch

Illustrative — field names and the cursor scheme are confirmed during the build, not promised here. The shape below is the reconciliation pattern we use for an institution of Fortis Bank's size, where the practical question is whether the next poll caught every posting that landed since the last successful cursor.

# Consumer-authorized read against a Fortis Bank connection,
# via an aggregator acting as the consumer's representative.

from fortis_bank_client import FortisConnection, PostingsCursor

conn = FortisConnection.resume(
    consent_token=os.environ["CONSENT_TOKEN"],     # tokenized, never the user's password
    consumer_id="user_8421",
)

# Snapshot balances on every poll.
for acct in conn.accounts():
    write_balance(
        account_id=acct.id,
        available_cents=acct.available_cents,
        ledger_cents=acct.ledger_cents,
        as_of=acct.fetched_at,
    )

# Walk new postings forward with a cursor stored on our side.
cursor = PostingsCursor.load(conn.id) or PostingsCursor.beginning()

page = conn.postings(after=cursor, limit=250)
while page:
    for p in page.items:
        # Stable key for idempotent upsert across re-polls and
        # eventual aggregator-side re-posting of the same row.
        key = stable_posting_key(
            connection_id=conn.id,
            booking_date=p.booking_date,
            amount_cents=p.amount_cents,
            description=p.description_raw,
            external_id=p.aggregator_posting_id,   # may be absent on backfilled rows
        )
        upsert_posting(
            key=key,
            merchant_category=p.merchant_category, # bank-enriched
            user_tags=p.user_tags,                 # GRIP-build tags
            user_note=p.user_note,
            user_geo=p.user_geo,
        )
    cursor = page.next_cursor
    page = conn.postings(after=cursor, limit=250)

PostingsCursor.save(conn.id, cursor)

# Consent-window arithmetic: ask for renewal ahead of expiry,
# rather than discovering the connection is read-locked at the next poll.
if conn.consent.expires_in_days() < 7:
    request_consent_renewal(conn.consumer_id, conn.id)

Consent, US data-rights status, and what actually governs this read

The dependable basis for this work is the consumer's own authorization. The aggregator — or the studio under a documented engagement — acts as the consumer's representative against Fortis Bank's Internet Banking system, with consent records, a logged token chain, and a revocation path that propagates back through every cache on our side.

The forward-looking piece is CFPB Section 1033 — the Personal Financial Data Rights rule the CFPB finalized in late 2024. As of this writing the rule is not in force: a court enjoined enforcement and the CFPB itself reopened the rule for reconsideration in 2025 via an Advance Notice of Proposed Rulemaking, with the litigation stayed pending the new rulemaking. For a Fed-nonmember state-chartered community bank of Fortis Bank's scale, what the eventual rule will require and on what schedule is therefore not settled. We treat §1033 as where US data-portability rules may go, not as what governs this read today. What governs today is the consumer's authorization.

Operationally that translates into: an NDA with the integrator where the work touches non-public details; written authorization from the consenting consumer; minimum-necessary data scoping per account; and a destruction-on-revocation path that is tested before launch, not promised on a slide.

Build notes for this institution specifically

• Rebrand history is a real risk surface. Front Range Bank, then Fortis Private Bank in 2016, then Fortis Bank in 2023 — per the institution's own filings. Each rebrand has historically touched at least the customer-facing domain names. We pin the connection to the FDIC certificate (34401) on our side, so that an aggregator-published institution rename does not orphan the consented connection, and we re-validate the GRIP-build surface against the new branding as part of acceptance.
• The merchant-category and user-enrichment columns matter on import. The Play Store listing explicitly calls out customer-added tags, notes, images and geo-marks on postings. If the import discards those, the integrator has lost a real piece of the customer's existing organization of their finances. We map them through into the upserted row as first-class fields, and treat their absence on a particular posting as a meaningful signal that the customer has not enriched that row yet, rather than as a default.
• Refresh cadence is designed around the consent window, not against it. Aggregator consent windows at US community-bank tier typically run 24 to 90 days between renewals, depending on partner and consumer behaviour. We schedule the renewal prompt at least a week ahead of expiry so the connection never goes read-locked mid-billing-run, and the poll cadence is set against the bank's actual posting rhythm rather than a generic hourly tick.
• Aggregator coverage is verified, not assumed. Coverage of a community bank of Fortis Bank's size by any single aggregator is uneven and changes over time. We confirm Plaid, Finicity and MX coverage of FDIC cert 34401 specifically before committing the spine, and we design the failover path before delivery rather than after a production incident.

Comparable apps in the same integration shape

Other US community, regional and private bank apps whose integration story sits in roughly the same place — small-to-mid commercial bank mobile front-end, consumer-authorized aggregation as the practical read path. Listing them widens what an integrator can plan against; no comparison is implied beyond that.

• Community Banks of Colorado — NBH Bank's Colorado community-bank app, with mobile deposit, balances and transactions on the same surface profile.
• Vectra Bank Colorado — Denver-area commercial bank under the Zions Bancorporation family, with a similar Internet Banking + mobile pairing.
• ANB Bank — Colorado community bank app spanning personal and small-business accounts.
• Alpine Bank — Colorado community bank with mobile and business banking apps on a comparable digital-banking stack.
• FirstBank Colorado — large Colorado community-bank app, same headline data domains.
• Bank of Colorado — community bank app with the standard aggregation-plus-transactions surface.
• Zions Bank — Utah-headquartered regional bank, a frequent cross-state institution for a Fortis customer.
• Mountain America Credit Union — large Utah credit union; consumer-authorized read patterns translate directly.
• First Community Bank Utah — Utah community bank app with the same digital-banking-stack profile.

Questions we actually get on Fortis Bank work

How fresh can a Fortis Bank feed reconcile after a mid-day deposit?

Realistically the limit is the aggregator's own refresh cadence and the bank's posting schedule. We poll on a cursor — typically every 30 to 60 minutes during business hours — and reconcile against the posted ledger, not the available balance. A deposit shows up when the bank posts it, not when the customer taps deposit; the consumer-authorized read inherits whatever posting latency Fortis Bank's own Internet Banking shows.

Do the tags, notes and geo-marks the GRIP app lets users add survive the read?

Where the back-end stores them as fields on the posting (which is the design the app's Play Store listing implies), yes — they come through as user_tags, user_note and user_geo on the client side and we upsert them onto the destination row. Where the back-end keeps them as a separate enrichment layer, we mirror that as a second join on our side rather than collapse them into the posting. Either shape is confirmed during the build.

What happens to a Fortis Bank connection if the institution rebrands or migrates platforms again?

Pin to the FDIC certificate on the integrator side. The institution has already rebranded twice in the last decade (Front Range Bank, then Fortis Private Bank, then Fortis Bank per its own bank-locator filings); aggregators eventually catch up but display names and routing labels are unreliable across a transition. The certificate is the stable handle, and the GRIP-build surface gets re-validated as part of the rebrand response.

Does CFPB Section 1033 apply to a community bank this size?

It is unsettled. The rule was finalized in late 2024, enjoined by an Eastern District of Kentucky court, and reopened by the CFPB itself for reconsideration in 2025 with the litigation stayed pending the new rulemaking. Whatever the eventual rule looks like, what it requires of an institution Fortis Bank's size and on what schedule is not yet fixed. The present read does not depend on §1033 — it rides the consumer's own authorization, which is the dependable basis here regardless of how §1033 lands.

What was checked, and where

OpenFinance Lab · engineering notes, May 2026. Sources opened for this page:

• Fortis Bank on Google Play — confirms the package id, store name, and the app's own description of its surfaces.
• FDIC BankFind detail for Fortis Bank (certificate 34401) — charter type, supervisory regime, headquarters, history.
• CFPB · Required Rulemaking on Personal Financial Data Rights and Federal Register · Personal Financial Data Rights Reconsideration (August 2025) — current §1033 posture.
• Fortis Bank — About — confirms the Front Range Bank → Fortis Private Bank → Fortis Bank rebrand history.

Engagement

A Fortis Bank build typically lands in 1–2 weeks, with the runnable client, the test harness and the docs arriving together. The source-code delivery is from $300 and is paid after delivery, once the runnable client is on your machine and the docs are what was promised. The pay-per-call hosted endpoint has no upfront fee — you call it for a Fortis Bank connection and pay only for what you call. Either way, the next step is to tell us which Fortis Bank surfaces you need and what you intend to do with them; access, sandbox and compliance paperwork are arranged with you from there.