FNB Iron Mountain's app carries two ledgers — reading both for one integration

FNB Iron Mountain's mobile app does something unusual for a community-bank build of its size: alongside the bank's own deposit and loan ledger it carries a second body of data — the user's outside accounts, aggregated in from other financial institutions and re-displayed on the same screens. From an integration standpoint that is two data sets in one app, not one, and an integrator who wants the full picture needs a plan for both surfaces rather than just the bank's own.

The bottom line for an integrator: the bank's own data is the predictable part, reachable cleanly under member consent. The aggregation layer is the more interesting part, because it exposes a heterogeneous feed of other-institution accounts already normalised inside the app — data the integrator would otherwise stitch together themselves. We map both, in one session, so they round-trip into one schema with the source institution preserved per record.

Data inside the app

Walking through what the app actually exposes to a signed-in member, surface by surface:

How we'd reach it

1. Aggregator-network integration under member consent

FNB Iron Mountain sits inside the US consumer-bank aggregation ecosystem. Any PFM tool that already connects to this bank does so through one of the four major aggregators — Plaid, MX, Finicity, or Yodlee — under the member's credential or token consent. For pure first-party bank data (balances and transactions on the bank's own ledger), this is the highest-durability route: the aggregators maintain the connection through bank front-end changes, and the consent record is held in the aggregator's audit log. The trade is on coverage — some of the app's richer surfaces (the aggregation tab itself, merchant rollups computed in the app, the user's annotations) live above the aggregator's view.

2. Authorized session integration against the app's own surface

With the member's authorization, we map the same authenticated calls the FNB app itself makes — login at bank.fnbimk.com, the device-passcode layer, token refresh, account list, transactions, alerts, the aggregation tab — and ship that as runnable source. This is the route that reaches everything, including the second surface (the user's outside accounts as the app already presents them) and the enrichments. It is also where careful re-validation matters most, which we account for in scope.

3. Native download

The bank's Internet Banking surface offers CSV / OFX download per account. That is useful for one-shot pulls or as a fallback for a manual back-fill; it is not a sync.

For most integrations a hybrid wins: route 1 for the bank-ledger spine because it is the most durable, route 2 layered on for the aggregation tab and annotations because nothing else reaches them, and route 3 kept as a manual fallback. We’ll write the choice into the spec, not just the code.

What lands on your servers

Concretely, the handover for this app:

• An OpenAPI document covering the calls we map — account list, transactions per account, alert state, the aggregation tab, transaction annotations — with the field shapes as we observed them.
• A short protocol & auth-flow report: how the app authenticates against the bank's online-banking core, where the session token lives, what re-issues it, and what the aggregation layer does behind the scenes.
• Runnable source in Python or Node, organised per endpoint. Credentials are injected at the boundary, so the same code runs against a sponsor sandbox or a consenting member account without conditional branches in the business logic.
• Test fixtures replaying the recorded responses, plus a small live-test suite gated behind an env switch.
• An interface document for handoff: which fields are stable, which are vendor-renamed every few releases, what to log for the consent record, what to check first when the bank's front end is refreshed.
• A short compliance & retention note — what to keep, for how long, and under whose authority — written for this engagement, not as a generic template.

A working example

Illustrative shape of the bank-side session; exact wire format is confirmed during the build against a live consenting account.

# Sketch of an FNB Iron Mountain mobile session
# Real header values, paths and response shapes are validated
# against a consenting account during delivery.
import requests

class FNBIronMountainClient:
    BASE = "https://bank.fnbimk.com"

    def __init__(self, username, password, device_pin):
        self.s = requests.Session()
        self.s.headers["User-Agent"] = "FNBIMK-GRIP/Android"
        self._login(username, password, device_pin)

    def _login(self, u, p, pin):
        r = self.s.post(f"{self.BASE}/auth/login",
                        json={"u": u, "p": p, "device_pin": pin})
        r.raise_for_status()
        self.token = r.json()["session_token"]
        self.s.headers["Authorization"] = f"Bearer {self.token}"

    def bank_accounts(self):
        # deposit + loan accounts on FNB Iron Mountain's own ledger
        return self.s.get(f"{self.BASE}/api/accounts").json()

    def transactions(self, account_id, since=None):
        params = {"since": since} if since else {}
        return self.s.get(
            f"{self.BASE}/api/accounts/{account_id}/transactions",
            params=params).json()

    def linked_external_accounts(self):
        # second surface: outside accounts the member added
        # through the aggregation tab in-app
        return self.s.get(f"{self.BASE}/api/aggregation/linked").json()

    def annotations(self, transaction_id):
        # user-added tags, notes, attached image and geo
        return self.s.get(
            f"{self.BASE}/api/transactions/{transaction_id}/annotations"
        ).json()

US consent & the §1033 question

The dependable basis for an FNB Iron Mountain integration is the member's own authorization to access their account data. That is true today and stays true regardless of where federal rulemaking lands. The bank itself is supervised at the federal level (FDIC certificate 5062, per the FDIC institution directory), so its handling of member data is already bound by GLBA's safeguards rule; those obligations flow through the contract chain into anything we build on top.

CFPB Section 1033 — the Personal Financial Data Rights rule — is the forward-looking piece. As of writing it is enjoined and back in agency reconsideration after the August 2025 advance notice of proposed rulemaking, so it is not the current legal basis for anyone's data access. What the rewrite looks like, which size of institution gets which deadline once it lands again, and how the “representative” question gets settled — that is what stakeholders are still arguing about. FNB Iron Mountain sits at roughly $400M in assets, which under the originally finalized phase-in would have placed it in the latest tier; those obligations were stayed, so we do not plan the integration around them. We plan it around member consent and revisit the picture if §1033 returns in a form that materially changes it.

Things we plan around

• The two-surface schema. The bank's own ledger and the aggregation tab carry different data shapes. We design the normalised schema so the source institution is preserved per record, because collapsing them silently loses provenance and breaks downstream reconciliation.
• The device-passcode layer. The app layers a 4-digit device passcode over the same Internet Banking credentials. We capture that layer in the auth flow and document refresh behaviour so the runtime client does not quietly drop out of session on the next launch.
• Front-end drift. The bank's web and mobile surfaces evolve together. We re-check the recorded calls before sign-off and on a maintenance cadence agreed during the engagement, so a UI refresh on the bank's side does not silently break the integration.
• Annotation round-trip. Tags, notes, image attachments and geo metadata sit alongside the canonical transaction. We map them as a distinct join so they ride the same sync without polluting the core transaction shape.
• Access & compliance, handled with you. A sponsor sandbox or a consenting test account is arranged during onboarding, NDAs where the engagement needs one, and the consent record is logged from the first run. None of that is a hurdle for you to clear before we begin.

Where these notes came from

The brief leans on the app's Google Play listing, the bank's own Digital Banking page, the CFPB's Personal Financial Data Rights Reconsideration page and the Federal Register notice of the August 2025 ANPR, with background on the litigation summarised by Cozen O'Connor. Where a specific number is given (asset size, certificate, package id) it is attributed inline; everything else is what an integrator sees when working with this app.

Interface evidence

The screenshots distributed on the Play listing. Tap to enlarge.

Adjacent apps

Other apps in the same US personal-finance and community-banking neighbourhood — an integrator working with FNB Iron Mountain's data often ends up touching one of these as well:

• Banno — Jack Henry's white-label digital-banking stack; the same PFM-aggregation pattern dressed in a different community bank's branding.
• Empower Personal Dashboard — holds linked-account positions across banks, brokers and cards under member consent.
• Quicken Simplifi — subscription PFM that sits on top of the major US aggregators to reach the same kind of bank-account feed.
• Monarch Money — household-finance aggregator with the same per-user permissioned data surface.
• Rocket Money — subscription / bill-tracking aggregator pulling transaction streams from connected accounts.
• Copilot Money — US-focused PFM with a comparable transaction-and-balance feed.
• YNAB — budgeting app that pulls transaction data from US connected accounts.
• NerdWallet — free budgeting and account-overview app that taps into the same aggregator backbone.

Questions integrators usually ask

How does FNB Iron Mountain's app pull in accounts from outside the bank?

The app's aggregation layer brings in linked external accounts under the user's own credential consent. From an integration angle that's a separate surface from the bank's own ledger, and we treat it as a second feed in the schema so the source institution is preserved per record.

Which US data-rights framework does this engagement actually sit under?

Day to day, the member's own authorization and the bank's GLBA obligations. CFPB Section 1033 — the Personal Financial Data Rights rule — is currently enjoined and back in agency reconsideration after an August 2025 ANPR, so we do not plan the build around it; we will adjust the consent path if and when it returns in a binding form.

Does FNB Iron Mountain's roughly $400M asset size change the integration plan?

It changes the regulatory tail more than the build itself. As originally finalized, Section 1033 would have placed institutions of this size in the latest phase, but those obligations were stayed; we treat member-consent access as the constant and Section 1033 as a watch-item rather than a planning input.

Can the same approach reach the user-added tags, notes and receipt images?

Yes. Those enrichments live alongside the canonical transaction record inside the authenticated session and come through as a distinct join. We model them as their own table so they do not get dropped when normalising the transaction stream.

Working with us

Source-code delivery for an FNB Iron Mountain integration starts at $300, paid after delivery once the runnable code is in your hands and you have signed off. If you would rather skip the upfront step entirely, the same surface is available as hosted endpoints on a pay-per-call basis — you pay for the calls you make, no upfront fee. Either way the cycle runs one-to-two weeks from kickoff to a working hand-off. Drop us a line at /contact.html with the app name and what you want from its data; access, the sponsor account or sandbox, NDAs and the consent record are arranged with you from there.

Mapping reviewed 2026-05-19 · notes by the OpenBanking Studio integration desk.