Reaching account data inside the Century Savings Bank app

Century Savings Bank has run out of Vineland, New Jersey since 1865, and carries FDIC certificate 30428 per the FDIC's BankFind register. Its mobile app — package id com.centurysb.imobile on Google Play — is where a member sees checking and savings balances, mortgage and auto-loan positions, card controls, and, per the bank's own mobile-banking page, up to a year of transaction history. When a business wants those records inside its own systems, the job is a consented client that signs in the way the member does and reads the same screens through a stable interface.

This brief is written from the ingestion side. The thing that earns its keep here is a small language client — Python or Node.js — that holds a user-authorized session, lists accounts, and pages transaction history into whatever store you run, on a cadence you choose. The regulatory framing matters and it sits below; it follows the code rather than leading it.

What sits behind a Century Savings Bank login

The app description and the bank's site name the surfaces plainly. Here is how each maps to something an integrator would consume.

Getting at the data: the routes that fit this app

Three routes are realistic for a bank app of this shape. We pick by what you need and how durable it has to be.

1 · User-consented session integration (the one we usually run)

A member authorizes the pull; our client establishes a session the same way the app's login does — token or cookie chain, biometric sign-in handled on-device by the member — and then reads accounts, balances and history. Reachable: everything the app itself shows. Effort: moderate, mostly in mapping the session handshake and the history cursor. Durability: good while the app's own surfaces are stable; we re-validate on a schedule. Onboarding access is arranged with you during the engagement, against a consenting account.

2 · Documented protocol analysis

Where a screen does not map cleanly to a single call, we trace the traffic the app makes for that view, document request and response fields, and rebuild the call in your client. This is how the transaction-history paging and the deposit-status surface get pinned down. Effort sits in the analysis, not the runtime.

3 · Regulated open-banking aggregation (forward-looking)

If and when a US consumer-data-access rule settles and Century's core participates, an aggregation route under that regime becomes an option. It is the most durable path on paper, but it depends on a regulatory picture that is not fixed today, so we treat it as a migration target rather than the first build. For most clients route 1 is what ships, with route 2 filling the gaps; route 3 is where the integration moves later.

What lands in your repository

The headline deliverable is code that runs. For Century Savings Bank Mobile that is:

• A runnable Python or Node.js client — consented-session login, accounts(), and cursor-paged transactions() against the ~12-month window.
• A webhook or polling layer for change delivery, so balance and posting updates can be pushed to your queue instead of polled, if that suits the stack.
• An automated test suite that exercises login, the account list, and history paging against a consenting account, so a change in the app's surface shows up as a failing assertion rather than a quiet gap.
• A normalized account/transaction schema (below) so a mortgage and a checking account arrive in the same shape.
• Secondary, and still included: an OpenAPI description of the rebuilt interface, an auth-flow report covering the token/cookie chain, interface documentation, and a short data-retention note.

A sketch of the account-history call

Illustrative — field names are confirmed against the app's own screens during the build, not copied from a published contract.

# century_savings/client.py
from centurysb import MobileSession      # the client we generate for you

s = MobileSession.from_consent(consent_token)   # member-authorized session

# the home screen lists deposit, loan and card positions together
for acct in s.accounts():
    print(acct.id, acct.kind, acct.balance_current, acct.balance_available)

# history is exposed to ~12 months; page by the server's own cursor
page = s.transactions(account_id="chk_****", since="2025-06-08", cursor=None)
while page.items:
    for t in page.items:
        store(t.posted_at, t.amount, t.description, t.running_balance)
    if not page.next_cursor:
        break
    page = s.transactions(account_id="chk_****", cursor=page.next_cursor)

The shape it normalizes to

Deposit and loan products often live on different back-end systems. We flatten them into one account record and one transaction record so downstream code does not branch per product.

{
  "account": {
    "id": "chk_8842",
    "kind": "checking",            // checking | savings | mortgage | auto_loan | card
    "balance": { "current": "1840.55", "available": "1790.55", "currency": "USD" },
    "as_of": "2026-06-08T13:20:00Z"
  },
  "transaction": {
    "account_id": "chk_8842",
    "posted_at": "2026-06-05",
    "amount": "-54.20",
    "description": "ACH bill payment",
    "running_balance": "1840.55"
  }
}

Where US data-rights rules sit right now

Century Savings Bank is a New Jersey-chartered, FDIC-insured institution, so the operative privacy framework is the Gramm-Leach-Bliley Act and Regulation P — how a US bank handles and shares a customer's financial data. That is the in-force ground.

The CFPB's Section 1033 personal-financial-data-rights rule is the part still in motion. It was finalized, then a federal court enjoined enforcement and the Bureau reopened it for reconsideration, so it is not a rule to build against as settled law today. We track it because that is plausibly where US open banking lands, but the dependable basis for this work is the account holder's own authorization — consent captured and logged, scoped to the accounts the client needs, revocable, and refreshed on its own clock. Access is authorized and documented, records are kept, and an NDA covers the engagement where the client wants one.

Things we plan around for this build

Two details of this specific app shape the work, and we account for both rather than handing them to you as conditions.

One account model across several cores

The home screen shows checking, savings, mortgage, auto loan and cards side by side, but those products usually come from different subsystems with different field names. We map each product type onto the single normalized record above, so a consumer of the feed treats a loan balance and a deposit balance the same way.

Session lifetime and the long backfill

A first run has to walk roughly twelve months of postings while the consent session is alive. We schedule re-authorization on the session's own clock so a long backfill completes on one continuous run, then later syncs only append what is new — no repeated full pulls. History is bounded to about a year in-app, so for longer ledgers the incremental store on your side is what accumulates beyond a single window.

Read-only by default

Transfers and bill pay are write surfaces. We keep the integration read-only unless you specifically want payment initiation, which changes the authorization posture and is scoped separately — most data work needs only the read path.

Screens we worked from

The Play Store listing's screenshots, used here to map the surfaces named above.

What we checked

Surfaces were read from the Google Play listing and the bank's own pages; the institution and charter facts from FDIC BankFind; the US rule status from the CFPB's own reconsideration page, in June 2026. Primary sources:

• Google Play — Century Savings Bank Mobile listing
• FDIC BankFind — Century Savings Bank (cert 30428)
• Century Savings Bank — personal services and mobile banking
• CFPB — Personal Financial Data Rights reconsideration

Compiled by OpenFinance Lab integration engineering, 2026-06-08.

Other NJ banking apps in the same integration set

If Century is one institution in a wider footprint, these neighbours hold comparable data and tend to come up in the same unify-the-accounts conversation. Listed for context, not ranked.

• NJFCU Mobile — North Jersey Federal Credit Union; member balances, bill pay and e-statements.
• CU of NJ — Credit Union of New Jersey; balances, transfers and ATM locator behind a member login.
• Columbia Bank Mobile Banking — NJ community bank; biometric login, account management and deposit.
• OceanFirst Bank — personal and business checking, savings and bill pay across a NJ branch network.
• Provident Bank — large NJ deposit and lending footprint with a consumer mobile app.
• Kearny Bank — NJ thrift; deposit accounts and mobile deposit for retail members.
• Parke Bank — South Jersey community bank with online and mobile account access.
• Community Bank (CBNA) — regional bank app for accounts, bill pay and check deposit.

Questions integrators ask about this one

How current is the data a sync returns, and how far back does history go?

Balances read close to real time — the same current and available figures the home screen shows. Transaction history is bounded to roughly twelve months in the app, so a first pull backfills that window and every run after it appends only what is new into an incremental store you keep on your side.

Can you reach mortgage and auto-loan balances, or only checking and savings?

Every position the home screen lists is in scope under the account holder's consent: checking and savings with current and available balances, mortgage and auto-loan balances, and card records. Loan and deposit products often sit on different back-end systems, so we map each one to a single normalized account shape.

Which US rules apply to pulling this data?

The in-force framework is the Gramm-Leach-Bliley Act and Regulation P, which govern how a US bank handles and shares customer financial data. The CFPB's Section 1033 personal-financial-data-rights rule is the forward-looking piece — finalized, then enjoined and back in agency reconsideration — so it is not something to build against today. The dependable basis for the work is the account holder's own authorization.

Which language do you ship the client in?

Python or Node.js, whichever fits your stack, with the consented-session handling, cursor paging and a test suite that exercises the account and history calls. We can add a thin webhook or polling layer if you want changes pushed rather than pulled.

Working with us

A working Century Savings Bank client comes back inside one to two weeks. Take it as source — runnable code, the auth-flow notes and the tests, from $300, paid only after delivery once you are satisfied — or skip hosting and call our endpoints on a pay-per-call basis with nothing upfront. Tell us the app and what you want out of its data on our contact page and we scope it from there.