A Jack Henry-built community bank app, integrated for accountholder data

The bank itself is small. Four branches, family-managed since 1926, deposits reinvested locally, and a customer base that does most of its day-to-day on the same Jack Henry-built mobile app described on the Play Store listing. For an integrator, that smallness is the point: the data behind login is well-bounded — checking, savings, a handful of loan products, statement PDFs, mobile-deposit history, bill-pay and account-to-account transfers — and there are no exotic instrument types to model.

What changed in March 2024 matters. The bank retired its prior digital-banking platform and shipped a new one with 2FA on first login, a unified mobile-and-web look, and the SMS-text-banking surface gone. Anyone with code aimed at the older site is starting over. The route below assumes the current platform.

What customers see behind login

Domains drawn from the Play Store description and the bank's own help pages. Mapped to where they originate in the app and what an integrator typically does with each.

How we reach the data here

1. Customer-consented session through the app

The accountholder authorizes us in writing, supplies credentials and the 2FA factor at first sign-in, and we drive the same session a person would. The session yields balances, transactions, statements and deposit history exactly as the customer sees them. This is the route that works for any St. Johns Bank account today without depending on what the bank chooses to publish externally. Effort: moderate — the post-March-2024 platform is well-behaved; the 2FA enrollment is the only awkward step and we capture it once per device, per customer.

2. Native export, where it exists

Statements export as PDFs; transaction history can typically be exported to CSV / QFX from the desktop view. Useful as a low-risk baseline for accounting integrations, or for backfill when consent is established. Effort: low, but the format is human-oriented, so a small parser layer is part of what we ship.

3. Aggregator-mediated open-banking connection

Jack Henry has been moving Banno-platform institutions onto API-based links with Finicity, Akoya and Plaid in place of screen scraping (per Jack Henry's own December 2024 press release on the Banno phase-out). For a buyer who already has an aggregator relationship and a US-permissioned-data use case, this is the cleanest path; for buyers without that footprint, route 1 lands faster.

Of these, route 1 is what we lean on for a single-bank integration shipped to one customer. Route 3 is what we wire in alongside it when the customer is an aggregator or a fintech that already plugs into Finicity / Akoya / Plaid.

What lands on your repo

• OpenAPI specification for the endpoints we expose — account list, balances, transactions, statements, deposits, transfers, bill-pay history — described as you would expect to consume them, not as the app's internal calls look.
• Auth-flow report covering the login handshake, 2FA capture, token / cookie lifetimes observed against the post-March-2024 platform, and the renewal pattern we use to keep the session alive across the day.
• Runnable source in Python or Node.js. Login → token / session → typed clients for each endpoint above → a small CLI for smoke-testing against a real account. No vendored secrets; configuration via environment.
• Automated tests — unit tests on parsing and normalisation, integration tests against a consenting test account, and a thin replay harness so we (and you) can re-run a captured day without burning fresh logins.
• Interface documentation — a single Markdown brief that explains the auth chain, every endpoint, every quirk we ran into (and there are always quirks), and a re-validation checklist for when the bank changes its front end.
• Compliance & retention notes — what we log, what we deliberately do not log (PAN, full statements at rest), and where the consumer-consent record lives.

Auth and a balance call, in code

Illustrative shape, confirmed during the build against a consenting test account. Field names follow what we expose on the public side, not the internal call.

# Python client — illustrative
from openbankingstudio.stjohnsbank import StJohnsClient

client = StJohnsClient(
    username=os.environ["SJB_USERNAME"],
    password=os.environ["SJB_PASSWORD"],
    device_id=os.environ["SJB_DEVICE_ID"],     # bound at first 2FA enrollment
    on_otp=lambda channel: prompt_user(f"code sent via {channel}: "),
)

session = client.login()                       # handles primary + 2FA factor

# 1. List accounts
for acct in session.accounts():
    print(acct.id, acct.kind, acct.nickname, acct.balance.available)

# 2. Statement-window transactions
checking = next(a for a in session.accounts() if a.kind == "checking")
txns = session.transactions(
    account_id=checking.id,
    since="2026-04-01",
    until="2026-04-30",
)
for t in txns:
    print(t.posted_at, t.amount, t.sign, t.memo, t.category_hint)

# 3. Monthly statement PDF
pdf_bytes = session.statement_pdf(account_id=checking.id, cycle="2026-04")
open("sjb-2026-04.pdf", "wb").write(pdf_bytes)

# Errors raised by the client:
#   AuthChallenge       — secondary factor needed, on_otp callback fires
#   SessionExpired      — token aged out; session.refresh() re-issues it
#   ScopeNotAuthorised  — accountholder consent does not cover this account

Practical notes from building against this stack

• 2FA enrollment is per-device, not per-call. We treat the device-binding step as part of onboarding the integration — done once per customer with their cooperation, then the running service does not see fresh OTP prompts every login. We design the session manager around that asymmetry.
• Post-March-2024 surface only. The platform cutover on 12 March 2024 replaced the prior digital-banking site outright. Any reference notes or captures from before that date are not reusable; we build against the current platform and schedule a monthly smoke-test job as part of the handover so a Banno UI revision does not silently break the run.
• Statements live behind the session, not on a CDN. The monthly PDF retrieval is a cookie-attached request paged by cycle, so we fetch by month and cache locally rather than treating statements as a separate API. Bulk historical backfill is throttled to avoid looking like abuse.
• Mobile-deposit submission stays manual. The camera-image upload runs through anti-abuse checks that exist for good reason; we deliberately do not automate the submission side. The read side — accepted-deposit list, attached front/back images, resulting credit in transaction history — is fair game and is part of what we ship.
• Business and treasury entitlements are a separate scope. Business banking sits behind different roles (signer, viewer, ACH originator) and a separate authorization. We price retail and business as two integration targets so the smaller buyer is not paying for entitlement plumbing they do not need.

Authorization and the rules around it

The dependable basis here is the customer's own consent. The accountholder authorizes us to act on their session under Reg E and the bank's online-banking agreement — the same agreement that already governs how they themselves reach their data through the app — and we keep a signed record of that authorization on file.

The bigger federal piece — CFPB §1033, the Personal Financial Data Rights rule — is not in force right now and is back in agency reconsideration with no replacement issued. For a community bank of this size with FDIC cert 8898 and a four-branch footprint, we treat §1033 as a forward-looking question to track, not the present-day rulebook the integration runs on; we revisit the scope only if and when the agency lands a new rule. State-level Missouri privacy obligations and FFIEC guidance shape what we log and how long we keep it.

Operationally that translates to: signed customer authorization on file, NDA with the buyer where the use case touches third-party clients, minimal logging (no PAN, no full statements at rest), and an explicit revocation path the accountholder can trigger that wipes credentials and stops the service.

Cost and how the work runs

Source-code delivery starts at $300, paid only after the codebase is in your repo, the smoke tests pass on your machine, and you have signed off. The hosted alternative bills per call against our endpoint with no upfront, and is useful when you want to skip the run-ops part entirely. One to two weeks from kickoff to handover either way; the schedule slips only when access onboarding on the customer side slips, and we manage that with you.

To start, send the app name (you have) and a short note on what the integration is for. We handle access, the consent paperwork with the accountholder, the test environment, and the build. Reach out via /contact.html and we will reply with the first-week plan.

What we checked

Sources opened for this brief — primary pages only, no aggregator summaries:

• St. Johns Bank — New Digital Banking Platform announcement (March 2024 cutover)
• FDIC BankFind — St. Johns Bank & Trust Company, cert. 8898
• Jack Henry — phase-out of screen scraping on the Banno digital banking platform
• CFPB — Personal Financial Data Rights reconsideration (§1033 status)

Notes compiled at the OpenBanking Studio integration desk; mapping reviewed 2026-05-20.

Other small US banks integrators ask about

• Bank of Old Monroe — Lincoln & St. Charles County community bank with its own mobile app; same domain shape (balances, transfers, mobile deposit), useful as a peer when a buyer needs both banks covered.
• Midwest BankCentre — St. Louis-headquartered community bank; mobile package covers transfers, bill pay, mobile deposit, biometric login. Frequent companion integration for St. Louis-metro buyers.
• Reliance Bank — St. Louis area community bank; data domains read very similar (consumer checking, savings, bill pay).
• Enterprise Bank & Trust — larger Missouri-headquartered commercial bank; the business-banking surface (treasury, ACH, wires) is the interesting piece for a corporate-side integrator.
• Lindell Bank & Trust — small St. Louis private bank with a comparable customer-app footprint.
• Carrollton Bank — Illinois / Missouri community bank; similar Jack Henry-style digital footprint.
• Bank of Sullivan — small Missouri community bank, useful in multi-bank rural-portfolio integrations.
• Community First Bank (Missouri) — west-central Missouri community bank with a comparable consumer-app surface and a similar customer-consent integration profile.

App names appear here as factual references for landscape mapping; nothing on this page is affiliated with these institutions.

Interface evidence

Public Play Store screenshots, opened on click — useful when scoping which surfaces a buyer wants covered.

Questions integrators ask about St. Johns

Did the March 2024 platform switch break older integrations against St. Johns Bank?

Yes. The bank cut over to a new digital-banking experience on 12 March 2024 with a different look, a different login flow, and mandatory 2FA on first sign-in. Any code aimed at the old platform will not authenticate. We re-map the integration against the post-March-2024 surface and design the auth chain to survive minor Banno UI revisions.

Is the mobile check-deposit (camera-photo) flow reachable from the integration side?

We do not automate the deposit submission itself for third-party integrators — the camera-image upload runs through anti-abuse checks that we leave alone on purpose. What we do expose is read-side coverage: a list of deposits already accepted, image retrieval for those checks, and the resulting credits in transaction history.

Does the bank participate in Akoya, Finicity or Plaid through the Banno open-banking layer?

Jack Henry has been migrating Banno-platform institutions off screen scraping and onto API-based connections with Finicity, Akoya and Plaid. The specific opt-in state for St. Johns Bank is not publicly published and we confirm it during onboarding; either way the consumer-consent route through the app remains available as a fallback.

Are St. Johns Bank business and treasury accounts covered the same way as retail?

Business banking sits behind a separate authorization flow with different roles (signer, viewer, ACH originator). We scope these as a second integration target — the retail path covers personal checking, savings and statements; the business path adds ACH batches, wires and entitlements and is priced separately. Reach out via /contact.html for a business-only scope.

Mapping reviewed 2026-05-20.