Integrating First State Bank of the Ozarks, the Purdy-chartered community bank app

Five branches in southwest Missouri, an FDIC-insured charter (cert no. 16162, per the FDIC BankFind entry for First State Bank of Purdy), an 80-plus-year history, and a phone-based digital banking front end on top of the same web-based Internet Banking — that is what an integrator actually meets with First State Bank of the Ozarks. The bank rebranded from First State Bank of Purdy in recent years; the iOS bundle still carries the prior trading name (id 1640090022 on the App Store) while the Android package id com.fsbpurdy.grip reflects the legacy Purdy lineage. None of that changes the integration shape; it does change what we watch for during the build.

What the app actually holds for a customer

The app's own description spells out most of this in plain English, and the screenshots confirm the shape of the data. We have mapped it back to integration-grade rows.

Routes in, and the one we would actually take

For a community bank this size, the realistic question is not which scheme to pick — it is which way the customer's own access can be re-expressed as something a piece of code can call.

Authorized interface integration of the digital banking front end

The bank's own description tells the integrator the shape: the mobile app and Internet Banking share credentials, so we work the Internet Banking front end as the primary surface and use the mobile app's traffic only as cross-confirmation of field names and flows. Effort is moderate; durability depends on whether the bank refreshes its digital banking vendor. We set up access with the customer during onboarding — typically a consenting account holder or a sponsoring business owner — so the build runs against a live, authorized session.

User-consented credential access

The cleanest version of route 1 for a single business customer: the customer authorizes the studio to act on their behalf using their own digital banking enrollment, with credentials held in a secrets manager the customer controls. Effort is lower; the access is exactly as wide as their account.

Native export as a fallback

Statements are downloadable PDFs and transaction history is downloadable from Internet Banking. For one-off backfill, or for the part of the pipeline that does not need fresh data, we wire that path so we are not re-fetching what the bank already gives the customer for free.

For most engagements at this bank, route 1 anchored on route 2's consent is what we would actually build and ship; native export earns its keep for backfill and audit, not as the primary live feed. The pipeline reads the front end on schedule, the customer's consent stays revocable, the export path fills gaps.

A sketch of what calling the front end looks like

The shape below is illustrative — exact field names and headers are confirmed during the build against a consenting session. It exists to show what the integrator is signing up for, not to be copy-pasted.

import requests
from cryptography.fernet import Fernet

class FsbOzarksClient:
    BASE = "https://digital.fsbozk.com"  # confirmed at build time

    def __init__(self, user_id, pwd_box, totp=None):
        self.s = requests.Session()
        self.s.headers["User-Agent"] = "fsbozk-integration/0.1 (consented)"
        self._user, self._pwd, self._totp = user_id, pwd_box, totp

    def login(self):
        # 1. fetch login page, harvest CSRF + device-binding cookie
        r0 = self.s.get(f"{self.BASE}/login")
        csrf = _extract_csrf(r0.text)
        # 2. post credentials; treat MFA + device-trust as separate steps
        r1 = self.s.post(f"{self.BASE}/login",
                         data={"u": self._user,
                               "p": self._pwd.decrypt(),
                               "_csrf": csrf})
        if "challenge" in r1.url:
            self._answer_challenge(r1)
        return self.s.cookies.get("session") is not None

    def accounts(self):
        r = self.s.get(f"{self.BASE}/accounts.json")
        # normalize ag-loan, mortgage, checking onto a single schema
        return [normalize(a) for a in r.json()["accounts"]]

    def transactions(self, account_id, since):
        r = self.s.get(f"{self.BASE}/accounts/{account_id}/tx",
                       params={"since": since.isoformat()})
        return [normalize_tx(t) for t in r.json()["tx"]]

    def statement_pdf(self, account_id, period):
        # statements ride a separate vendor host; we follow the
        # signed link and stream the PDF to the caller
        link = self.s.get(f"{self.BASE}/statements/link",
                          params={"acct": account_id,
                                  "period": period}).json()["url"]
        return self.s.get(link, stream=True).content

    def card_off(self, card_id):
        # card controls ride yet another vendor; idempotency key matters
        return self.s.post(f"{self.BASE}/cards/{card_id}/state",
                           json={"state": "OFF",
                                 "idem": _new_idem_key()})

What the sketch shows in one frame: a session that has to carry CSRF plus device-binding, a challenge step that is not optional, three downstream vendors (account host, statement renderer, card-controls vendor) hiding behind one front door, and a normalize step doing the work of turning "agricultural loan" and "personal checking" into rows a downstream system can reason about.

What ships at the end of the engagement

• OpenAPI 3.1 specification covering the endpoints reached during the build — accounts, transactions, statement download, card state, RDC submission, alerts — with response schemas reflecting the bank's actual field names.
• Auth-flow report describing the login chain, CSRF and device-binding cookies, the challenge step, and the session-refresh behaviour we observed.
• Runnable client source in Python (the sketch above, fleshed out) and Node.js, with the secrets boundary, retry behaviour and idempotency keys spelled out.
• Automated tests against a consenting sandbox or live account, including a "front end drifted" detector that fails loudly when field names move.
• Interface documentation — markdown plus diagrams — describing each vendor sub-flow as a separate diagram so the next engineer is not surprised.
• Compliance and data-retention guidance sized to a US community bank engagement: NDA in place; consent records logged; data minimization; deletion path defined.

For pay-per-call customers, the same surface lives behind our hosted endpoints; no client-side source ships.

The authority the integration actually rides on

First State Bank of the Ozarks is an FDIC-insured Missouri bank under the usual federal/state community-bank supervision; the privacy frame is GLBA plus Missouri's UDAP and breach-notification statutes. The federal "data portability" question — CFPB's section 1033 Personal Financial Data Rights framework — is currently the forward-looking piece, not the working ground: as finalized it would have phased obligations in over time, but enforcement has since been stayed by the Eastern District of Kentucky and the rule is back in agency reconsideration. We do not present it as in-force and do not rely on it. The basis we actually ride on is the bank customer's own authorization to act on their digital banking enrollment, with NDA, consent records and access logs sized to that posture. That is durable today and stays durable whatever shape §1033 settles into.

Engineering judgment specific to this bank

1. Rebrand drift. The bank now trades as First State Bank of the Ozarks but the FDIC charter and the Android package id (com.fsbpurdy.grip) still reflect First State Bank of Purdy, and the iOS App Store listing still surfaces the older trading name on bundle 1640090022. We pin to the live front end at fsbozk.com, watch for trading-name strings in responses, and add a small re-validation pass so a future signage update does not silently break a downstream report.
2. Three vendors behind one door. The mobile RDC capture flow, the e-statement PDF flow and the debit-card on/off + reorder flow each ride a separate vendor endpoint distinct from the main account host. We scope each as its own sub-integration, document the auth handshake separately, and let the maintenance pass watch them independently so a vendor swap at one of them does not cascade.
3. Product mix matters at the schema layer. The bank lends across personal, business, mortgage and agricultural products, all behind one login. We carry the product type through to the normalized row rather than collapsing it, because downstream code at, say, a farm-bookkeeping ISV wants to treat an ag-loan very differently from a personal checking account.
4. Session shape, not screen shape. The mobile UI and the Internet Banking web UI share credentials but render differently; we anchor the integration on the session and field names the host returns, not on what the screen happens to show this quarter. That is the difference between an integration that survives a UI refresh and one that does not.

Interface evidence

App store screenshots, used here as a public reference for what the customer sees. Click any image to enlarge.

What was checked and where

This brief is built from the bank's own public materials and a small handful of regulatory references. Specifically: the Play Store listing for com.fsbpurdy.grip (feature set, store description, screenshots); the iOS App Store listing on bundle id 1640090022, which still carries the prior trading name First State Bank of Purdy; the bank's own website at fsbozk.com (history, branch count, product mix); the FDIC BankFind entry at banks.data.fdic.gov (charter and supervision); and, for the federal data-portability frame, the CFPB's own page at consumerfinance.gov together with the ABA Banking Journal item on the October 2025 stay at bankingjournal.aba.com. Identifiers and counts are stated as the bank or the regulator publishes them; anything not publicly disclosed is not asserted here.

Mapping reviewed by the OpenBanking Studio integration desk — May 2026.

Peer apps an integrator typically meets in the same engagement

A unified financial-data integration in Southwest Missouri usually involves a handful of these neighbours; we list them as plain references, not as a ranking.

• Mid-Missouri Bank Mobile — Springfield-headquartered community bank with personal and business banking, ag lending, and a similar single-login app shape.
• OakStar Bank Mobile — another Springfield-based bank with multiple Missouri branches; same family of digital banking flows, separate vendor stack.
• The Bank of Missouri Mobile — broader-footprint Missouri community bank; same kind of accounts/transactions/statements scope behind the login.
• Community Bank of Missouri — small-bank app with the same picture-of-check deposit and card-controls flows.
• Arvest Go — Arkansas-rooted regional with strong Missouri presence; larger institution, different vendor mix, similar customer-data shape.
• Together Credit Union — St. Louis-area credit union app; closely related data domains, NCUA rather than FDIC supervision.
• CommunityAmerica Credit Union — Kansas City-metro credit union; comparable scope of authenticated-portal data.
• Table Rock Community Bank — Branson-area community bank that recently completed a regional merger; a useful comparator for rebrand-and-merger churn we already track.

Questions an integrator at this bank actually asks

Does the rebrand from First State Bank of Purdy change the integration target?

The bank now trades as First State Bank of the Ozarks but the same digital banking front end is in place — the Apple listing even still shows the prior trading name on bundle id 1640090022. We pin to the live front end at fsbozk.com, watch for trading-name strings in responses, and add a small re-validation pass for future rebrand churn.

Can the integration tell an agricultural loan apart from a checking account at this bank?

Yes. The bank lends across personal, business, mortgage and agricultural products, and the digital banking front end returns a product type per account. We normalize ag-loan, mortgage, business checking and personal checking onto distinct schema rows so downstream code does not have to guess from a label.

What happens when mobile deposit or e-statement vendors cycle?

Mobile remote deposit capture and e-statements typically ride separate vendor endpoints from the main account host. We map each sub-flow once during the build — image upload plus receipt for RDC, timed link plus session for e-statement PDFs — and a re-validation pass watches each one independently.

Which US framework gives us the right to keep doing this?

For an FDIC-insured Missouri bank this size, the dependable basis right now is the customer's own authorization as the bank's digital banking user. CFPB's section 1033 Personal Financial Data Rights rule is the forward-looking piece but its enforcement is currently enjoined and the rule is back in agency reconsideration, so we do not rely on it as in-force.

How we work with you, in one paragraph

A First State Bank of the Ozarks engagement runs 1–2 weeks end to end: the client gives us the app name and what they want to do with its data, and we handle the rest — the authorized access path, the consenting account or sponsor, the front-end mapping, the normalized schema, the runnable client, the tests, and the documentation. Source-code delivery starts at $300 and is paid after delivery, once you have the source and the docs in hand and are satisfied; or, instead of taking the source, you call our hosted endpoints and pay per call with no upfront fee. Either way, the build is the same, the cycle is the same, and the next step is the same — tell us what you need at /contact.html and we will scope it back the same week.