Feeding Millbury National Bank Mobile balances and transactions into your stack

Millbury National Bank Mobile, in one panel

Millbury National Bank has run on a single national charter since 1933, FDIC certificate 2616 per the FDIC's BankFind record. The mobile app is the customer-facing front for that one institution's core ledger. Everything it shows — current and available balances, posted history, scheduled payments, deposits still in flight — sits behind an authenticated session. That session is the feed. Our work is to read it under the accountholder's authorization and hand you the data as something your own code can call, either as source you run or as an endpoint you hit.

The account records the app keeps

The rows below track what the app puts in front of its own users, where each piece originates, how granular it is, and the kind of thing an integrator does with it.

How we'd reach those records

Consumer-permissioned interface read

With the accountholder's consent, we drive their authenticated session and read what they can already see — every record in the table above. Effort is moderate; the durability is good but tied to the online-banking platform, so we re-validate on app and platform releases. Access is arranged with you during onboarding, against a consenting account.

Aggregator consent path

Where an aggregator already reaches this institution, the consumer-permissioned path through Plaid, MX or Finicity is the fastest way to a first balance-and-transaction feed. Coverage of a bank this small is uneven, so we wire the aggregator client and normalization but never lean on it as the only door.

Native export as a backstop

e-Statements give a coarse, lagged, but dependable record per statement period. Low effort, durable, and useful for backfill and audit when a live read is paused.

For a feed you can count on month to month, the consumer-permissioned interface read is the one we'd build the integration around, with the aggregator path as a quick first connection and statements as the cold backstop. Which mix we recommend depends on how fresh you need the numbers and whether an aggregator already lists the bank.

A consent-driven read, in code

Illustrative, not copied from the wire — the shapes below are what we confirm and lock down during the build. The accountholder authorizes; we drive their session and never retain the PIN.

# Consumer-permissioned read against the authenticated MNB online session.
session = mnb.authenticate(
    member_id = consent.member_id,        # supplied under consent, not stored
    device    = consent.bound_device,     # Touch ID / Face ID enrollment binds the session
)

# A step-up (Face ID prompt or one-time code) can be demanded mid-flow.
if session.requires_step_up:
    session.satisfy_step_up(consent.step_up_handler)

accounts = session.get("/accounts")       # checking, savings, mortgage, auto loan
# -> [{ "id": "...", "type": "checking",
#       "balance_current": 4182.55, "balance_available": 4060.00,
#       "nickname": "Everyday" }, ...]

fast = session.get("/fast-balances")      # available balances only, refreshes sooner

for acct in accounts:
    txns = session.get(f"/accounts/{acct.id}/transactions",
                       params={"since": cursor.for_(acct.id)})
    queue.publish("mnb.transactions", txns, key=acct.id + cursor.token)

# An expired session or a step-up re-queues the account rather than aborting the run.

How the records come out normalized

Whatever route feeds the data, you receive it in one stable shape so a balance from the interface read and one from the aggregator path look identical downstream.

{
  "account": {
    "id": "acct_8c1f",              // opaque, stable across syncs
    "institution": "Millbury National Bank",
    "type": "mortgage",             // checking | savings | mortgage | auto_loan | other
    "balance": { "current": 182340.11, "available": null },
    "as_of": "2026-06-08T13:20:05Z"
  },
  "transaction": {
    "id": "txn_77a2",
    "account_id": "acct_8c1f",
    "posted": "2026-06-05",
    "amount": -54.20,               // signed; debits negative
    "status": "posted",            // pending | posted
    "description": "BILL PAY - ELECTRIC"
  }
}

What lands in your repository

• Runnable client source in Python and Node.js for the session authentication, the accounts and Fast Balances pulls, and the per-account transaction cursor.
• A small queue-and-worker scaffold that publishes each account's deltas and replays a step-up or an expired session, so a paused account resumes where it left off.
• An automated test harness with recorded fixtures for the accounts, Fast Balances and deposit-status surfaces, so a change in the online platform surfaces as a failing assertion instead of a quiet gap.
• Webhook and poller handlers you can point at your own infrastructure for balance-change and deposit-status events.
• Secondary, but included: an OpenAPI description of the normalized endpoints, a protocol and auth-flow write-up covering the session, the step-up and the token/cookie chain, interface documentation, and a short data-retention note.

Authorization and the US data-rights picture

Millbury National Bank is OCC-supervised and FDIC-insured, certificate 2616 in BankFind, and it is a single-charter bank rather than a multi-brand group. That keeps consent scope simple: one accountholder, one institution, the accounts they can already open in the app. The dependable basis for reading that data is the accountholder's own authorization — recorded consent, a defined field scope, revocable at will. Section 1033, the CFPB rule people reach for when they say "US open banking," is not settled law right now: enforcement was enjoined in late 2025 and the rule is back in reconsideration, so we treat it as a possible future and build on consent today. Whatever we run is logged and minimized to the fields you asked for, under an NDA where the work warrants one.

What this app in particular makes us handle

The core session versus the satellite modules

The transactional core runs on the bank's online-banking platform, but several features live in third-party modules bolted around it — Kasasa-powered rewards on some checking and savings tiers, the Finli portal for certain loan payments, CardValet for card on/off and travel controls, all named on the bank's own digital-banking page. A single "everything on one screen" view has to know which numbers come from the core session and which from those satellites, so we map them up front rather than quietly dropping the card-control or loan-portal pieces.

Available is not posted

The app surfaces a Fast Balances available figure that updates ahead of posted history, and a mobile check deposit sits in a processing state before it clears, with next-day availability if it is lodged before the bank's afternoon cutoff. We model available, current and pending as separate quantities and represent each deposit as a small state machine, so downstream cash logic does not count a pending deposit twice or treat a processing amount as spendable.

Device-bound, step-up sessions

Touch ID and Face ID enroll a device against the session, and the server can ask for a step-up part way through. We design the consenting-account capture and the sync around that, so an interactive challenge pauses and continues the batch. None of this is something you have to set up first; we arrange access with you as part of the build.

Engaging us, and what it costs

A first working feed for Millbury National Bank Mobile — accounts, balances and a transaction cursor — usually lands within a week or two of kickoff. You can take it as source you own: runnable code plus the OpenAPI description, the protocol notes and the tests, billed from $300 and paid only once it is delivered and you are satisfied. Or skip hosting it and call our endpoints, paying per call with nothing upfront. Either way you give us the app name and what you want from its data; access and the compliance paperwork we arrange with you as the project runs. Tell us what you are after and we will scope it — start the conversation here.

Screens we worked from

The app's own store screenshots, for reference on which surfaces the integration touches.

Other community-bank apps in the same shape

Same data domains, same authorization logic — useful context if you are aggregating several New England banks into one feed.

• UniBank — A Central Massachusetts community bank whose app carries the same checking, savings and loan balances plus mobile deposit, normalizing into an identical account-and-transaction shape.
• Middlesex Savings Bank — An eastern-and-central-Massachusetts bank with bill pay, mobile deposit and transfers in its app; its data domains line up one-for-one with this one.
• bankHometown — A Massachusetts-and-Connecticut community bank holding per-account balances and payment history behind an authenticated app session.
• Cambridge Savings Bank — A larger Massachusetts institution whose app exposes balances, transfers and statements, handy as a second source in a multi-bank aggregation.
• BankProv — A New England commercial bank with consumer and business accounts whose records map cleanly into the same normalized feed.
• Cornerstone Bank — A Worcester-County community bank with mobile deposit, transfers and loan balances familiar from this integration.
• Webster Five — A mutual savings bank near Worcester whose app holds the same balance, transaction and bill-pay surfaces.
• Avidia Bank — A central-Massachusetts mutual bank carrying consumer and business banking in-app, with the account and payment data a unified feed would gather.

What we checked, and when

Checked on 8 June 2026 against the bank's own digital-banking pages, the Google Play listing for com.mnbonline.imobile, the FDIC's BankFind entry for certificate 2616, and the CFPB's current reconsideration docket for the section 1033 rule. Where a detail is not public — the exact session endpoints, the online platform's internals — this write-up says so rather than guessing. Sources: MNB digital banking, Google Play listing, FDIC BankFind (cert 2616), CFPB section 1033 reconsideration.

OpenFinance Lab · engineering notes, 2026-06-08

Questions integrators ask about this one

How current is a synced balance, given the app's Fast Balances?

Fast Balances exposes an available figure that moves ahead of posted history, so we sync that on a tighter refresh and reconcile it against posted transactions on a slower pass. You get an available balance that is close to live and a posted ledger that is authoritative, kept as distinct values rather than one blended number.

Can you read mortgage and auto-loan balances, or just deposit accounts?

Both. The app's accounts view lists mortgage, auto loan and other balances alongside checking and savings, and the integration maps each as its own account record with its type preserved.

Does the Kasasa rewards or Finli loan-portal data arrive through the same feed?

Those sit in modules the bank adds around its core — Kasasa for rewards tiers, Finli for some loan payments, CardValet for card controls. We can stitch them into one view, but we map each separately because they are distinct surfaces with their own data and refresh behavior.

What is the lawful basis for reaching this data — it's a national bank?

The accountholder's own authorization. Millbury National Bank is OCC-supervised and FDIC-insured, and we read a customer's data under their recorded, scoped, revocable consent. The CFPB's section 1033 rule is not settled right now, so we build on consent rather than on a rule that is back in reconsideration.

What if a data aggregator doesn't cover a bank this small?

Then the consumer-permissioned interface route carries the feed on its own. Aggregator coverage of small national banks is uneven, which is why we treat Plaid, MX or Finicity as a convenient first connection where it exists, not as the only way in.

Last checked 2026-06-08