Wiring Cape Cod 5 mobile banking into a third-party stack

FDIC certificate 23287 — that's the institution behind Cape Cod 5 - Mobile Banking, per the FDIC BankFind record for The Cape Cod Five Cents Savings Bank: an 1855-vintage mutual community bank, headquartered in Hyannis, with twenty-three branches across Cape Cod, Nantucket, Martha's Vineyard, and Southeastern Massachusetts (per the same record). The app, package com.capecodfive.grip per its Play Store listing, is the consumer face on that ledger. It's small. It's specific. And for an integrator who needs a customer's account read out of it, that is the right size of problem to scope precisely.

The basis we work from is the customer's own right to read their own account, executed through the same authenticated session the app itself uses. The 1–2 week build cycle is short because the surface is small — a few well-understood resources, not a sprawling product catalog.

What sits behind the login

The Play Store description lists the surfaces in the bank's own words; mapping them to integrator-useful rows:

Routes that actually apply

1. Customer-authorized session against the mobile interface

The customer signs in. The studio's code stands in for the mobile client, holds the session, and reads the resources above on the customer's behalf. This is the route that works today, on the smallest community bank in the country or the largest. Effort is moderate — one careful pass to map the auth flow (login, 4-digit passcode setting referenced in the app description, any 2FA step), then resource-by-resource mapping for the data domains the project actually needs. Durability is good in practice provided we keep a thin re-validation pass on the bank's release cadence.

2. User-consented credential access via an aggregator the customer already trusts

Where the customer already authorizes Plaid, MX or Finicity against their Cape Cod 5 login, the integration can ride that consent rather than build a new one. We wire to the aggregator the customer picked, normalize the shape, and keep your code free of credentials. Faster, but limited to whatever fields the aggregator exposes — PFM tags, deposit images and card controls are usually not in that set.

3. Native export as a fallback

Cape Cod 5's online banking serves statements as PDF and transaction history as CSV/QFX through the customer's portal. For one-off pulls, or as a safety net under the live route, these are perfectly serviceable. They give you ledger rows; they don't give you the PFM enrichment or the deposit images.

For most engagements here, route 1 carries the build and route 3 is wired as a fallback for monthly statements — that's the shape we'd recommend unless the customer is already on an aggregator they're happy with, in which case route 2 is cheaper and we layer route 1 only for the fields the aggregator does not return.

Wire-level sketch

Indicative shape — exact field names and the 2FA branch are confirmed during the build, not asserted here:

POST /mobile/auth/login
  body: { username, password, deviceFingerprint }
  -> 200 { sessionToken, requires2fa: true|false, accountIds[] }

# 4-digit passcode setting the app advertises is a client-side gate
# the server still issues the session token only after primary auth
POST /mobile/auth/2fa/verify
  body: { sessionToken, otp }
  -> 200 { sessionToken }

GET /mobile/accounts/{accountId}/balance
  headers: { Authorization: Bearer <sessionToken> }
  -> 200 { accountId, available, current, asOf }

GET /mobile/accounts/{accountId}/transactions?from=YYYY-MM-DD&to=YYYY-MM-DD
  -> 200 { items: [{
      txId, postedAt, amount, currency, type,
      description, merchant,
      pfm: { category, tags[], note, imageRef, geo: { lat, lon } }
    }], cursor }

GET /mobile/deposits?from=YYYY-MM-DD
  -> 200 { items: [{ depositId, amount, status, frontImageRef, backImageRef }] }

Token refresh, idle-timeout, and the failure modes (expired token, locked card, MFA challenge mid-session) are mapped to typed exceptions in the generated client so callers don't have to read raw HTTP back.

What lands in your repo

• An OpenAPI 3.1 specification covering the resources the project picked from the table above — balances, ledger, deposits, transfers, bill-pay, card controls, messages.
• A short protocol & auth-flow report: the live login sequence, where the 4-digit passcode actually gates client behaviour, how 2FA branches resolve, token shape and refresh window.
• Runnable source for those endpoints in Python (httpx + pydantic) and Node.js (undici + zod) — pick one, both are shipped.
• Automated tests against recorded fixtures plus a thin live smoke pass we run against a consenting account before handover.
• Interface documentation written for the engineer who will maintain it, including the bank-side surfaces we deliberately left out and why.
• A short compliance note: consent scope, log retention, data-minimization defaults aligned with Reg P and Massachusetts 201 CMR 17.

Consent and the US data-rights picture

The straightforward part: Cape Cod 5 is a Massachusetts state-chartered, FDIC-supervised commercial bank (per the FDIC BankFind record). Customer data carried in this app is covered by GLBA / Regulation P at the federal layer and by Massachusetts 201 CMR 17 for safeguards; an integration that reads the customer's own account on their authority sits inside the customer's existing right to access their own records.

The unsettled part: the CFPB's Personal Financial Data Rights rule under §1033, finalized in late 2024, would have placed a small bank like Cape Cod 5 in a later compliance tranche; it is currently enjoined and the Bureau is reconsidering it (Forcht Bank, N.A. v. CFPB stayed the compliance dates in October 2025; the Bureau issued an Advance Notice of Proposed Rulemaking on reconsideration in August 2025, per the Federal Register). We don't ride §1033. We don't assert it's settled. The build runs on the customer's own authorization, with the option of pivoting to whatever standardized endpoint Cape Cod 5 publishes if and when the rule re-emerges in a form that obliges it.

Operationally: consent is recorded with the customer's stated scope and expiry; credentials are not logged; access is rate-limited to what the project actually needs; an NDA covers the engagement where the integrator asks for one.

Build notes specific to this app

• Personal vs business is a deliberate split. Cape Cod 5 migrated its business and Treasury Management mobile platform on its own schedule, and the auth and resource shapes differ from the consumer app. We scope per side; if you need both, we sequence them rather than pretending they're one surface.
• PFM enrichment is part of the same response — we surface it. Tags, notes, image references and geo coordinates the customer added through the app come back in the same per-transaction payload the dashboard renders. We map them as first-class fields rather than dropping them on the floor, because for most integrators that enrichment is the reason to go past a CSV export in the first place.
• Mobile RDC images are by reference, not inline. The deposit log returns image identifiers; the binaries pull lazily against the same session. We wire that as a two-stage fetch so a transactions-only consumer never accidentally drags every cheque image over the wire.
• Release-cadence drift is planned for. The app description references the standard community-bank update rhythm; we set up a re-validation pass against a consenting account on a defined cadence so the integration doesn't quietly rot when the bank ships a UI revision. Access for that pass is arranged with you during onboarding — sandbox where available, a real consenting account otherwise.

Pricing and how this runs

Source-code delivery starts at $300 for a focused Cape Cod 5 integration — you pay after the build is in your hands and reads your test account cleanly, not before. The other path is a hosted endpoint on our side that you call per request and pay per call, no upfront fee. Either way the cycle is one to two weeks from the moment we have the app name and a sentence on what you want out of it. Tell us what you need at /contact.html; access, consent paperwork, and a sandbox or consenting account are arranged with you as part of getting started.

App screens, in the bank's own UI

The seven Play Store screenshots are useful evidence for the surfaces we mapped — dashboard, ledger view, deposit, transfers, alerts.

Sources we opened

The institutional facts above were checked against the FDIC's BankFind record (banks.data.fdic.gov — cert 23287) and the bank's own online & mobile banking page (capecodfive.com/online-mobile-banking). The US data-rights status was checked against the CFPB's Personal Financial Data Rights page (consumerfinance.gov) and the Federal Register notice of reconsideration (federalregister.gov, 2025-16139). Mapped at the OpenBanking Studio integration desk, May 2026.

Peer community-bank apps an aggregator usually sees alongside this one

Useful context for anyone planning a multi-bank Massachusetts integration — the apps below sit in the same regional pool, run comparable surfaces, and would all be candidates for the same authorized-route playbook. Listed neutrally, not as a ranking.

• Salem Five Banking — checking, savings, RDC, transfers; eastern Massachusetts footprint.
• Rockland Trust Mobile — full retail banking with biometric login, mobile deposit.
• Eastern Bank — community-bank consumer app across MA, RI, NH branches.
• Cambridge Savings Bank Mobile — retail banking and PFM-style enrichment.
• Berkshire Bank Mobile — checking, savings, transfers across New England.
• Middlesex Savings Bank Mobile — the largest Massachusetts mutual savings bank.
• Dedham Savings Mobile — retail banking app with mobile deposit.
• The Cooperative Bank of Cape Cod Mobile — same geographic market as Cape Cod 5.
• Mechanics Cooperative Bank Mobile — southeastern Massachusetts community bank.
• Meredith Village Savings Mobile — northern New England mutual savings bank.

Questions integrators ask

For a community bank this size, what's the actual route — FDX, an aggregator, or just the customer's own consent?

The US §1033 rule that would have pushed community banks of this size onto a shared FDX-style standard is currently stayed and back in agency reconsideration, so we don't plan a build around it. The dependable basis for the integration is the customer's authorization to read their own account, exercised against the live mobile interface — optionally layered through an aggregator the customer is already using.

Can we pull the PFM enrichment — tags, notes, photos, geo — or only the raw transaction?

The enrichment is part of the same per-transaction response the app renders, so when we map the transaction endpoint we surface tags, notes, image references and geo fields alongside the core ledger row. Image binaries are pulled on demand by reference, not inline.

Mobile check deposit images — are those reachable?

Each deposit log entry exposes a server-side image reference for front and back; we wire it as a lazy fetch behind the same session token. Retention follows the bank's own window, which we mirror but do not extend.

Can one integration cover both the personal and the Cape Cod 5 business / Treasury Management sides?

They are separate flows with separate entitlements — Cape Cod 5 migrated the business and Treasury Management platform on its own timeline, and the auth and resource shapes differ. We scope per side and you choose which one ships first.