Bird in Hand Mobile: a consent-led integration plan

Bank of Bird-in-Hand chartered in late 2013, the first new US bank in three years, per its Wikipedia entry. It serves Lancaster County's Plain communities and the surrounding rural townships — including from rolling "Gelt Bus" branches that bring tellers to farms. Bird in Hand Mobile is the customer-facing window into all of that. Balances at this bank. Aggregated balances from outside banks and credit unions. Transactions a customer can tag, annotate, or attach a phone photo to. Mobile check deposits. Card on/off. Reaching that data programmatically — for a fintech, an accounting overlay, or a treasury workflow — runs through one anchor: the account holder's own authorization.

Authorized access, while the US rule moves

Bank of Bird-in-Hand is a small FDIC-supervised state-chartered bank. The basis we build on is the customer's own right to authorize a third party to read their own account data. The federal Section 1033 framework is currently enjoined and back in CFPB reconsideration, per the Bureau's reconsideration page; we treat it as a forward-looking variable rather than a present rule the build relies on. Practically, that means consent records, scope minimization, IP allowlisting on our side, and the access posture documented so your examiner can read the trail end to end. If and when a tokenized feed appears for this bank, the same integration moves to that channel without a rewrite.

What the app surfaces to a logged-in customer

Reaching the data in practice

For Bird in Hand Mobile today, the dependable channel is the customer's own consented access to the portal and the app's traffic. We onboard with the client, agree the scope, and arrange access — sponsor sandbox or a consenting live account — as part of the engagement. The forward-looking channel is a §1033-style tokenized feed served on the FDX schema the US industry is converging on; the integration is built so a switch onto that channel is a configuration change rather than a rewrite. The recommended start is the consented route. It works now. It is auditable now. It migrates cleanly when the regulated channel firms up.

A working session sketch

# illustrative — base host and exact field names confirmed during the build
import httpx

class BIHClient:
    def __init__(self, session_cookies, csrf_token, consent_ref):
        self.http = httpx.Client(
            base_url="https://online.bihbank.com",
            cookies=session_cookies,
            headers={
                "X-Csrf-Token": csrf_token,
                "X-Consent-Ref": consent_ref,   # our consent-record id
                "Accept": "application/json",
            },
            timeout=15.0,
        )

    def accounts(self):
        r = self.http.get("/portal/accounts")
        r.raise_for_status()
        return [
            {
                "account_id": a["accountId"],
                "kind": a["accountType"],          # CHK / SAV / LOC
                "owner": "bih" if a.get("owner") == "self"
                         else f"aggregated:{a['source']}",
                "balance_current":   a["currentBalance"],
                "balance_available": a["availableBalance"],
                "as_of": a["asOf"],
            }
            for a in r.json()["accounts"]
        ]

    def transactions(self, account_id, since):
        r = self.http.get(
            f"/portal/accounts/{account_id}/transactions",
            params={"since": since.isoformat()},
        )
        r.raise_for_status()
        return r.json()["items"]   # posted + pending; tags + notes attached

What lands in your repo

• An OpenAPI 3.1 specification for the mapped portal endpoints (accounts, transactions, statements, transfers, RDC status, cards, alerts), with the auth flow documented inline.
• A protocol and auth report — the cookie / CSRF / consent-header chain, refresh behaviour, and any device-binding the app uses, written for an engineer who will maintain the build.
• Runnable Python and Node clients for the mapped surfaces, packaged so a CI job can pull the latest tag.
• Integration tests against a consenting account or a sponsor sandbox, with fixtures for the aggregated-account case (it is the most fragile surface, and worth its own test pack).
• A normalization layer that separates BIH-owned balances from aggregated upstream balances, each carrying its own freshness stamp.
• An operations note: how to renew the consent reference, what an examiner-readable access log should look like, and what to do when the front end shifts.

Quirks we plan around

• Aggregated balances drift. The app pulls in non-BIH balances behind the scenes. Those feeds depend on an upstream aggregator's session state, and they can be hours stale while the BIH-native balances are fresh. We mark each balance with its source institution and a per-source freshness, so a stale outside balance does not get reported as a stale Bank-of-BIH balance.
• Mobile remote deposit is not instant. RDC submissions can sit in a holding queue for a business day or longer, especially over weekends and the bank's holiday calendar. We model an explicit pending_review state rather than letting a submitted check look settled.
• User-added metadata matters. Tags, notes, and receipt photos are first-class in the app and a lot of the integration's value is preserving them. We normalize them into a per-transaction attachments object rather than dropping them as extra fields.
• The Plain customer base shapes operational hours. Some branch-level functions follow the rotation of the bank's mobile-branch ("Gelt Bus") units. Where it affects an integration (a card-reissue request, for example), we surface an availability window instead of assuming 24x7.
• Front-end change risk. A small bank's portal can be re-skinned with little notice. We ship a re-validation step with the hand-off so a portal change can be patched the same day rather than rediscovered weeks later.

Pricing and how to start

Source-code delivery for Bird in Hand Mobile starts at $300, billed only after the build is in your hands and you have confirmed it runs against the agreed scope. If you would rather not host it, the same surfaces are available as a hosted endpoint metered per call, with no upfront fee. The build cycle is one to two weeks from kickoff in either case; access (sandbox or a consenting account) is arranged with you during onboarding. Open a brief with the desk — the app name and the surfaces you actually need is enough to scope it.

Peer community-bank apps in the same neighborhood

• Penn Community Bank — Bucks County PA community bank app; similar consumer and small-business surface set, fewer aggregation features.
• Mid Penn Bank — Central PA community bank; mobile app with the same authenticated-portal data shape.
• ESSA Bank (goVivo) — Northeast PA community bank app with a PFM / budgeting layer overlaying the transaction feed.
• C&N Bank — NY/PA community bank; comparable digital-wallet and mobile-deposit surfaces.
• Community Bank N.A. — PA / WV-spanning community bank; broader footprint, the same per-customer data model.
• Univest Financial — Southeastern PA bank often grouped with BIH in regional coverage; richer commercial cash-management features.
• Fulton Bank — Lancaster-headquartered mid-size bank; bigger institution, the same kinds of consumer-side surfaces.
• Lanco Federal Credit Union — Lancaster County credit union; member-side data model is comparable for aggregation purposes.

What we worked from

Pages opened for this brief: the bank's Wikipedia entry for founding date and ownership context; the FDIC BankFind record for charter status and supervision; the CFPB's Personal Financial Data Rights reconsideration page for the current §1033 posture; the iOS App Store listing for app metadata. Mapping by the OpenBanking Studio integration desk · 24 May 2026.

Questions an integrator usually asks first

Does Bank of Bird-in-Hand's small size affect what is reachable?

It changes the regulatory posture more than the technical map. The basis the integration depends on is the customer's own consent to read their own account data — at any sized institution. At a small bank that consent posture is doubly load-bearing. The technical work has the same shape it would at a larger bank; the operational posture leans on consent records, minimum scopes, and an examiner-readable trail.

What happens to the accounts the user has pulled in from other banks?

Those balances live inside the app's aggregation layer, not in the Bank-of-BIH core. We extract them as a separate, clearly-labelled feed with the upstream institution noted on each balance, and we surface freshness per source — so a stale Capital One balance pulled in last Tuesday does not get mistaken for a stale Bird-in-Hand balance.

Where does §1033 leave a fintech that wants to read this account today?

On the consumer's side, the right to authorize a third party to read one's own data is the basis we build on. The federal §1033 rule that would have set obligations on the institution itself is currently enjoined and back in CFPB reconsideration, so it is a forward-looking variable rather than a present rule the integration depends on. We design the build so that when the rule lands, the same access becomes a tokenized API call rather than a re-engineering project.

How fragile is this to an app update?

Front-end updates are the routine maintenance risk. The build includes contract tests that fail loudly when a labelled field, a session endpoint, or a status code shifts; we ship a re-validation step with the hand-off so a portal change can be patched the same day rather than rediscovered weeks later.