Torrington Savings Bank Mobile, from login to a clean account feed

Torrington Savings Bank has run as a depositor-owned mutual since its 1868 charter, serving the towns of Northwest Connecticut, and the app carries the whole member relationship rather than a marketing slice of it. Behind one login sit checking and savings balances shown as current and available, mortgage and auto-loan positions, mobile check deposit, transfers that reach other institutions, debit-card controls, and a Money Manager view that links external accounts. That is the data a third party usually wants to read or sync. This page maps where it lives in the app, the authorized route we use to reach it, and what we hand back at the end of a build.

The short version: this is a single-institution US bank with no live data-rights regime to ride, so the dependable footing is a member who authorizes the pull. We model that member's session, re-implement the calls the app already makes to its backend, and normalize what comes back into accounts, transactions and statuses you can store. The sections below get specific about each surface.

Records behind the login

Every row here is something the app itself shows a signed-in member, named the way Torrington Savings Bank names it where the listing makes that possible. Nothing in the table is a generic banking placeholder.

Reaching the records

Three routes genuinely apply to a bank like this. They overlap, and a real build usually uses more than one.

Member-consented session access

A member authorizes the work and we operate the authenticated session their credentials open — the same User ID and password used for TSB Online Banking, with biometric sign-in acting as a device-local gate over a server-issued token. Reachable: everything in the table above, because it is exactly what the member sees. Effort is moderate; durability is good as long as the consent and the session-refresh path are handled. This is what we build the core of an integration on.

Authorized protocol analysis

We observe the traffic between the app and its backend under the member's authorization, document the auth chain — device registration, the multi-factor step-up TSB applies to new devices, and the session token or cookie that follows — and re-implement those calls as a clean client. Reachable: the request and response shapes for accounts, transactions, transfers, deposit status and card state. Effort is front-loaded into the mapping; once mapped it is fast to maintain.

Member-facing export and Money Manager plumbing

The app's own Money Manager already links external accounts and categorizes spend, refreshing those links on an MFA cadence. Where a member can export statements or activity, that export is a useful cross-check that our normalized records line up with what the bank shows. It is narrow on its own, valuable as corroboration.

For a US community bank with no live regime to lean on, the call is straightforward: the consenting member's session is the foundation, protocol analysis is how we turn that session into a stable client, and the bank's own export and aggregation behavior is the check that the numbers reconcile. We would not promise a regulator-backed feed that does not exist here; we would promise a member-authorized one that does.

A pull in code

Illustrative only — field names and the exact auth chain are confirmed during the build against a consenting account, not assumed from a store listing. It shows the shape, not a guaranteed contract.

from tsb_client import Session, MfaRequired

# Same User ID / password as TSB Online Banking. Biometric sign-in is a
# device-local gate; the backend still issues the session token.
s = Session(user_id=member.user_id, secret=member.secret, device=registered_device)

try:
    s.authenticate()
except MfaRequired as challenge:
    # TSB applies a step-up to new or unrecognized devices.
    s.complete_mfa(challenge, code=member.one_time_code())

# Accounts span deposit and loan products in one list.
for a in s.get("/accounts"):
    print(a["nickname"], a["type"], a["current_balance"], a["available_balance"])
    # type in {checking, savings, mortgage, auto_loan, ...}

# Mobile check deposits show as processing before they post.
pending = s.get("/deposits", params={"status": "processing"})

# Posted activity, paged. Retry on a refreshed token, not on the same one.
try:
    tx = s.get("/accounts/{id}/transactions", params={"page": 1})
except s.SessionExpired:
    s.refresh()                       # stay inside the member's consent window
    tx = s.get("/accounts/{id}/transactions", params={"page": 1})

What lands in your repo

Each deliverable is tied to a surface above, not a generic checklist:

• An OpenAPI/Swagger specification covering the accounts, balances, transactions, transfers, deposit-status, card-control and alert reads and writes we map.
• A protocol and auth-flow report: the User-ID/password sign-in, device registration, the MFA step-up, and the session token or cookie chain as it actually behaves on this app.
• Runnable source in Python and Node.js for the key endpoints — session auth, account and balance pull, paged transaction history, transfer initiation, deposit-status polling, and a card on/off toggle.
• Automated tests that run against a consenting account or recorded fixtures, so a changed response shape fails loudly.
• Interface documentation a developer who has never seen the app can follow.
• Compliance and data-retention guidance: consent records, what we log, and how long normalized data is kept.

Consent and the US data-rights picture

There is no federal open-banking rule in force that we can point to as the legal engine here. The CFPB's Section 1033 Personal Financial Data Rights rule was finalized in October 2024, then enjoined by a federal court and reopened by the Bureau for reconsideration; an August 2025 advance notice put representative authority, fees, data security and data privacy back on the table, and the April 2026 compliance date passed without becoming an enforcement trigger. We treat Section 1033 as where US data-rights rules may go, not as something governing this build today. What we rely on instead is concrete: a Torrington Savings Bank member who authorizes access to their own data at an FDIC-insured institution (certificate #16636 per the FDIC BankFind record). Consent scope is written down, expiry and revocation are honored, access is logged, data is minimized to what the use case needs, and an NDA is in place where the work touches anything sensitive.

Engineering notes we plan around

A few things specific to this app shape how we build, and we handle each as part of the work:

• Device step-up and session refresh. TSB challenges new devices with an MFA step-up. We carry that exchange through and design the session store so re-authentication happens cleanly inside the member's consent window, instead of a token quietly expiring mid-sync.
• Money Manager's external links go stale on a cadence. The bank's own aggregation notes that some linked institutions require multi-factor re-validation at intervals. When a build surfaces that aggregated data, we mirror the refresh cadence and read TSB's existing spend categories rather than inventing a competing taxonomy.
• Loans are not deposits. Mortgage and auto-loan reads are servicing positions, not transaction streams. We model them as their own object so a payoff figure is never forced into a checking-account transactions table.
• Front-end churn between releases. Community-bank apps ship on a vendor release cadence and screens shift. We keep a small contract-test suite that flags a changed response shape before it reaches your data, and fold any fix into ongoing maintenance.

Access and compliance are arranged with you during onboarding — typically a consenting account or, where you prefer, a sponsor sandbox — so the build runs against real responses from day one.

Freshness, by domain

Not every surface updates at the same speed, and the docs say so explicitly. Balances and posted transactions are current within the live session. Mobile deposits move through a processing-to-posted transition that we poll rather than assume. Money Manager's linked external accounts refresh on the aggregator's cadence and can lag, which is why we label aggregated figures with their last-refresh time instead of presenting them as live.

Cost and how a build runs

A working TSB pull — session auth, balances, paged transaction history, transfer initiation and deposit-status polling — comes together in one to two weeks. From there you pick how you want it. One option is source-code delivery from $300: you get the runnable client, the OpenAPI spec, the tests and the interface docs, and you pay after delivery once it works to your satisfaction. The other is a pay-per-call hosted API: we run the integration, you call our endpoints and pay only for the calls you make, with no upfront fee. Tell us the app name and what you want out of its data, and we handle the rest — start a conversation here.

Screens we worked from

Public store screenshots of the app, used while mapping the surfaces above. Tap to enlarge.

Other Northwest Connecticut and CT bank apps in the same picture

Anyone unifying account data across small Connecticut institutions runs into the same neighbors. Each holds a comparable record set behind its own app, which is why one normalized integration usually has to speak to several of them.

• Thomaston Savings Bank — a state-chartered mutual a few towns over (established 1874); its app carries balances, transfers and bill pay.
• Union Savings Bank — Danbury-based, with a mobile app exposing balances and account activity to members.
• Northwest Community Bank — a free app for 24/7 account access; Litchfield Bancorp and Collinsville Bank now operate under this single brand.
• Connecticut Community Bank — biometric login, mobile deposit, bill pay and transfers on iOS and Android.
• Newtown Savings Bank — a Newtown mutual whose app holds the usual deposit and payment records.
• Chelsea Groton Bank — a Groton mutual savings bank with mobile account access and deposit features.
• Ion Bank — a Naugatuck mutual holding company bank with retail mobile banking.
• Bank of Danbury — a local commercial bank with a mobile app over checking, savings and transfers.

Named for context only, with no ranking implied; each is independent of Torrington Savings Bank.

Questions integrators ask

Can balances and transaction history both come through, or only balances?

Both. The app shows current and available balances plus posted activity for checking, savings, mortgage and auto-loan accounts, and those same records arrive through the authenticated member session we build against.

How does a mobile check deposit appear in the data?

As a processing item that later flips to posted. We poll the deposit-status read so your system sees the transition rather than guessing when funds clear.

Which US regulation governs pulling a member's data here?

No federal open-banking rule is in force. The CFPB's Section 1033 rule was finalized in October 2024, then enjoined and reopened for reconsideration, so the build rests on the consenting member's own authorization at an FDIC-insured bank.

Do you need TSB-side credentials or a sandbox before any of this works?

We work against a consenting member's session, and access plus compliance are arranged with you during the engagement. You bring the app name and what you want from its data.

What we checked

Mapped against the bank's own pages and the public listings on 11 June 2026: the mobile-banking feature page for card controls, deposit and transfers; the Money Manager page for external-account aggregation and its MFA-refresh note; the FDIC BankFind record for charter and insurance detail; and the CFPB's reconsideration page for the live status of Section 1033. Citations below open in a new tab.

• Torrington Savings Bank — Mobile Banking features
• Torrington Savings Bank — Money Manager (account aggregation)
• FDIC BankFind — The Torrington Savings Bank, cert #16636
• CFPB — Personal Financial Data Rights reconsideration

Mapped by the OpenBanking Studio integration desk, June 2026.