Getting at the account data behind Scottsburg Building and Loan's app

Scottsburg Building and Loan has run from one branch in Scott County, Indiana since 1889, per the bank's own history and the Indiana DFI depository record. Everything Mobile SBLA shows a customer — balances, the activity list, transfers, a deposited check — comes back from a single hosted online-banking session. That makes this a tight, well-bounded integration target: one consumer login, one backend, a handful of data surfaces that map cleanly to what a third party would want to sync.

The bottom line first. The mobile app is a thin client over the same Secure Internet Bank session a customer would use on the desktop site, so the work is one protocol-analysis effort against a single host rather than a chase across many endpoints. We would build it as an authorized capture of that session against a consenting SBLA account, normalize the four surfaces below, and hand back runnable code plus the auth-flow report. Read access is the safe core; the money-moving transfer is wired separately behind a flag.

What the SBLA ledger actually holds

None of these are guessed. Each is named the way the app's own store listing names it, then matched to where it surfaces in the Secure Internet Bank session.

Authorized ways into the data

Protocol analysis of the app session — the one we would run

The app authenticates to web2.secureinternetbank.com under a fixed institution code embedded in SBLA's own login and password-recovery URLs. We capture that session against a consenting account, document the login and challenge sequence, and rebuild the balance, history and transfer calls as a typed client. Reachable: every surface in the table. Effort: moderate, because there is one host and one auth chain. Durability: good while the host front end is stable; the bank itself is not changing platforms casually. Access is arranged with you during onboarding, against a consenting SBLA login or the platform's test environment — we set that up, you do not have to clear it first.

User-consented credential access

The same session can be driven on behalf of a consenting customer who supplies their own credentials and handles any step-up challenge. This suits aggregation-style use where the end user is in the loop. It reaches the read surfaces cleanly; transfers stay gated.

Native export as a low-effort fallback

Where the online-banking front end offers a transaction or statement download, we use it as a cheap backstop for history when a live session is not warranted. It is partial by nature — no live balances, no transfer — so it supplements the protocol route rather than replacing it.

Federal data-rights rails

Account-aggregation rails under the US personal financial data-rights framework are a fourth path in principle. For a thrift at this scale it is not the spine — the reasons are under data-rights footing below — so we treat it as optional context, not the build.

We would put the protocol route at the centre and keep credential access as the consented-user variant of the same client; the export path stays in reserve for history-only needs. That ordering follows from there being exactly one backend here.

What lands at the end of the build

For Mobile SBLA specifically, delivery is:

• An OpenAPI description of the normalized surface — accounts, balances, transactions, transfer, deposit-capture — written against what the Secure Internet Bank session actually returns, not a generic banking template.
• A protocol and auth-flow report: the login post, session/cookie handling, any MFA or forced-password-change branch, and how the institution code scopes the calls.
• Runnable source for the key endpoints in Python and Node.js — sign in, list accounts, pull paged history, post an internal transfer, submit and poll a remote deposit.
• Automated tests covering session refresh, an empty-history account, a declined transfer, and a deposit returned with a hold.
• Interface documentation and data-retention guidance written for a state thrift under FDIC and Indiana DFI supervision.

A look at the session and statement calls

Illustrative shapes from the Secure Internet Bank session; exact field names are confirmed during the build against a consenting account.

# 1. Authenticate against the SBLA-scoped host
POST https://web2.secureinternetbank.com/PBI_PBI1151/Login/{institution_code}
  form: { user, password, deviceToken }
  -> 200 + session cookie
  -> 200 with { challenge: "OTP" }        # step-up: handled, not bypassed
  -> 200 with { forcePasswordChange: true } # branch the client must catch

# 2. Account summary
GET  /PBI_PBI1151/Accounts            (session cookie)
  -> [ { acctId, mask: "****8420", nickname,
         type: "SHARE|LOAN", ledgerBal, availBal } ]

# 3. Paged transaction history
GET  /PBI_PBI1151/Accounts/{acctId}/History?from=YYYY-MM-DD&page=N
  -> { items: [ { postedDate, amount, drCr,
                  description, checkNo?, runningBal } ],
       nextPage? }

# 4. Internal transfer  (gated behind an explicit allow flag)
POST /PBI_PBI1151/Transfers
  { fromAcctId, toAcctId, amount, effDate }
  -> { confirmId, status: "POSTED|SCHEDULED" }
  -> 4xx { code: "INSUFFICIENT_FUNDS" | "LIMIT" }  # mapped, surfaced

# 5. Remote deposit
POST /PBI_PBI1151/Deposits   (multipart: frontImg, backImg)
  { toAcctId, amount }
  -> { depositId, state: "ACCEPTED|REVIEW|HELD" }
      

Error handling is part of the deliverable, not an afterthought: the OTP and forced-password-change branches, session expiry mid-paging, and a transfer rejected on funds or limit each have a defined path in the client.

Where it gets used

• A bookkeeping tool that pulls dated SBLA postings nightly and reconciles them against invoices for a Scott County small business.
• A treasury view that watches ledger and available balances across a customer's SBLA accounts and fires an alert before an account runs short.
• A scheduled internal sweep that moves a fixed amount between two SBLA accounts on a date, with the confirmation id captured for audit.
• A consented personal-finance app that reads history and balances for a customer who banks only with SBLA and has no aggregator coverage otherwise.

Engineering realities we plan around

Two things shape how we build this, and we account for both rather than passing them to you.

First, the institution code in the login URL scopes every call to Scottsburg Building and Loan. We treat it as a configured constant the client carries, and we design the capture so a front-end change on the shared Secure Internet Bank host shows up as a typed mismatch the client raises before it reaches your data, not as a silent gap. The same platform serves many small banks and tends to move in lockstep, so one watch covers the risk.

Second, the transfer and remote-deposit surfaces move money and are not symmetric with read calls. We isolate them behind an explicit allow flag, add a confirmation step, and map the host's funds-availability, limit and deposit-hold rules into typed states so an integrator handles a held deposit or a limit rejection deliberately. Read sync and money movement are delivered as separate, independently switchable capabilities.

Data-rights footing for a thrift this small

Scottsburg Building and Loan is a state-chartered Indiana stock savings and loan, supervised by the Indiana Department of Financial Institutions with the FDIC as primary federal regulator, per public bank directories and the DFI depository record. On consumer data access, the relevant US instrument is the CFPB's Personal Financial Data Rights rule under Section 1033. As that rule was finalized it placed the smallest depositories — institutions below the SBA small-bank size standard — outside its compliance tiers entirely, and the rule has since been stayed and reopened for reconsideration. A single-branch 1889 thrift sits well inside that smallest band, so an integration here does not, and need not, rely on a rule compelling the bank to expose data. We work from authorized protocol analysis or explicit user consent instead: access is documented, sessions and consent are logged, data is minimized to the surfaces an integrator actually needs, and an NDA is in place where the engagement calls for one.

App screens referenced

Public store screenshots used while mapping the surfaces above.

Sources and the date checked

Checked on 17 May 2026: the Indiana DFI depository record for the institution's charter and supervision, the Google Play listing for the app's stated features and package id, the bank's own site for the Secure Internet Bank login host, and the CFPB's data-rights material for the regulatory footing. Primary references: Indiana DFI institution record, Mobile SBLA on Google Play, Scottsburg Building and Loan website, CFPB Section 1033 reconsideration notice.

Compiled by the OpenBanking Studio integration desk, 17 May 2026.

Similar apps in the same data space

Other small US institutions whose apps hold the same kind of consumer ledger, listed for ecosystem context — a unified integration treats them as variants of one balance-and-history shape:

• American Community Bank of Indiana — deposit and loan account access for an Indiana community bank.
• First Federal Savings Bank (Indiana) — balances, transfers, bill pay and camera mobile deposit for a savings bank.
• Mutual Savings Bank — consumer account access for an Indiana savings institution.
• Community First Bank of Indiana — mobile deposit, money movement, card controls and sub-users.
• Indiana Members Credit Union — member account balances and transaction history.
• Beacon Credit Union — checking, savings and loan account data across many Indiana counties.
• People's Community Bank of Monticello — online and mobile account access for a small community bank.
• GBC Bank — community-bank deposit and loan account data in central Indiana.

Questions integrators ask about Mobile SBLA

Does Mobile SBLA pull from the same backend as the SBLA website login?

Yes. The bank's online banking and the Mobile SBLA app both sit on the Secure Internet Bank host (secureinternetbank.com) under the institution code carried in SBLA's login URL. The app is a thin client over that session, so the integration targets one protocol surface rather than two unrelated ones.

Can internal transfers between SBLA accounts be driven through an integration, or is it read-only?

The transfer-between-SBLA-accounts action is a posted operation against the same session that returns balances and history, so it can be driven, not only read. We isolate it behind an explicit allow flag and confirmation step because it moves money, and we map the funds-availability and same-day rules the host enforces.

Who regulates Scottsburg Building and Loan, and does the federal data-rights rule force access here?

It is a state-chartered Indiana stock savings and loan supervised by the Indiana Department of Financial Institutions, with the FDIC as primary federal regulator per public bank directories. A single-branch thrift this small sat at or below the smallest band of the CFPB Section 1033 rule as finalized, and that rule has since been stayed and reopened, so the practical route does not depend on a rule compelling access.

Mobile deposit works from check photos — can that capture flow be integrated too?

The remote-deposit step is a multipart upload of front and back images plus an amount and a deposit-to account, followed by a status the host returns. We can wrap submission and status polling, with the caveat that image quality and hold rules are enforced server-side and surfaced as deposit states the integration must handle.

A Mobile SBLA build runs one to two weeks against a consenting account, and ends with the runnable client, the auth-flow report and the tests in your hands. You can take it as source-code delivery from $300, paid only after delivery once the code runs and you are satisfied; or as a pay-per-call hosted API with no upfront fee, where you call our endpoints and pay only for the calls you make. Either way the only things we need from you are the app name and what you want out of its data — access and the compliance paperwork are arranged with you as part of the work. Start the conversation at /contact.html.