Integration work against the Skowhegan Savings Bank app

Founded October 1869. Twelve branches across central and northern Maine, per the FDIC's BankFind record. State charter under the Maine Bureau of Financial Institutions, FDIC certificate 19532. The mobile app — com.skowhegan.grip on the Play Store, app id 1487718276 on the App Store — does something most community-bank apps don't, and that something is the integration angle on this page: it aggregates accounts from other banks and credit unions into one view, the bank's own description calling it a "personal financial advocate." For a downstream integration that is two distinct data sources hidden behind one interface, and the build has to treat them differently.

Where the data lives inside the Skowhegan app

The bank's own online-banking FAQ and the Play Store description between them describe the surfaces the app exposes to a logged-in account holder. Mapped to what an integrator actually wants:

Routes worth taking, and the one we'd pick

Three approaches are realistic on this app. They differ in coverage and in how much engineering hangs on Skowhegan's own release cadence.

1. Interface integration against the secure portal session

The mobile app and secure.skowhegan.com share an authenticated session; a build authorized by the account holder works against that session. This gets the full set of surfaces above — native ledger, aggregated view, statement downloads, alert configuration — at whatever cadence the consumer requires. Durability depends on the bank's release cycle for its digital banking front end; the bank announced a website refresh within the last few years (per its own news post), and a public-site refresh tends to drag the post-login session structure with it.

2. Native export

The app and portal already produce downloadable monthly statements. For an integration whose only job is statement archival or tax workflows, the export route is the lowest-touch option and is what we recommend when the consumer's needs end there.

3. Proxy via a US data aggregator the customer already pays

If the integrator is already on Plaid, MX or Finicity for other accounts, Skowhegan is reachable through that path. Coverage is narrower than route 1 — typically balances, transactions, ownership — and you don't get the aggregated-external-accounts view at all, since aggregators don't re-aggregate aggregators.

What we'd pick: route 1. The aggregated-view surface only exists there, the bank's own product is interesting precisely because of that surface, and a treasury or finance team integrating the app is almost always the kind of customer that wants it.

A call against the secure portal, in shape

Illustrative — exact field names and the auth chain are confirmed during the build, not asserted here.

# Skowhegan Savings Bank — illustrative integration call
# Route: authorized interface integration against secure.skowhegan.com

import httpx
from typing import Iterator

SESSION = "https://secure.skowhegan.com"

class SkowheganClient:
    def __init__(self, session_cookie: str, csrf: str):
        # session and CSRF are obtained during the consented login flow,
        # not from credentials stored on our side
        self.http = httpx.Client(
            base_url=SESSION,
            cookies={"SECURE_SESSION": session_cookie},
            headers={"X-CSRF-Token": csrf, "Accept": "application/json"},
            timeout=20.0,
        )

    def accounts(self) -> list[dict]:
        # native Skowhegan accounts only — aggregated externals
        # come from a separate "advocate" surface and are labelled as such
        r = self.http.get("/api/accounts")
        r.raise_for_status()
        return [
            {
                "id": a["accountId"],
                "type": a["productCode"],     # CHK / SAV / LOAN
                "available_cents": int(round(a["availableBalance"] * 100)),
                "as_of": a["asOf"],
                "origin": "skowhegan-core",
            }
            for a in r.json()["accounts"]
        ]

    def transactions(self, account_id: str, since: str) -> Iterator[dict]:
        cursor = None
        while True:
            r = self.http.get(
                f"/api/accounts/{account_id}/transactions",
                params={"since": since, "cursor": cursor, "limit": 200},
            )
            r.raise_for_status()
            payload = r.json()
            yield from payload["items"]
            cursor = payload.get("nextCursor")
            if not cursor:
                return

    def statements(self, account_id: str) -> list[dict]:
        # returns metadata; the PDF body is fetched by a separate call
        return self.http.get(f"/api/accounts/{account_id}/statements").json()["statements"]

What lands in your repo at the end

One Skowhegan engagement closes with a small, opinionated set of artifacts, all built around the surfaces above:

• An OpenAPI 3.1 spec covering the endpoints we map — accounts (native), accounts (aggregated, separately namespaced so the staleness story is explicit), transactions, statements metadata, statement PDF retrieval, alert configuration.
• A protocol & auth-flow report: how the login flow, 2FA step-up, biometric pairing on supported devices, CSRF rotation and session lifetime actually behave on this front end, with the bits we observed quoted.
• Runnable source in Python (3.11+) or Node, your call, with the example client above filled in and tested against a real consenting account.
• An automated test suite — recorded fixtures, golden files, a small live-smoke target you can run against your own session.
• Interface documentation written for a developer who has not seen the Skowhegan app: what the surfaces are, how each field is sourced, what the staleness curve looks like.
• Consent and retention guidance: what the authorization needs to say, how long to keep what we cache, and how the integration revokes cleanly when an account holder withdraws consent.

Engineering judgements that come up on this build

Three are specific enough to flag up front, because they shape the contract more than the wire format does.

Tagging the origin of every balance. The Skowhegan app shows native balances and externally-aggregated balances on the same screen, which is fine for a person and dangerous for an automated consumer that might, for example, use a balance to gate a payment decision. We namespace the two surfaces — origin: "skowhegan-core" versus origin: "aggregated" on every record — and we ship a separate as_of field so downstream code can choose its own freshness floor.

Designing around a public-site refresh. The bank refreshed its public website within the last few years, and a public-site refresh on a community-bank stack typically reshuffles the post-login routes too. We bake a small canary client into delivery: it does a no-op login and a structural check on the key endpoints, runs on a cron the customer owns, and pages when selectors or response shapes shift. The maintenance contract sits on top of that signal rather than on a calendar.

Biometric and 2FA on supported devices. The app supports passcode plus fingerprint or face reader on supported devices, which means the session establishment on Android and iOS isn't symmetric with the desktop portal. We anchor the integration to whichever surface the account holder is happy to consent through and document the trade-off — desktop session is easier to refresh, mobile session captures device-binding flows the bank may push to harder later. This is decided with you during onboarding, not declared up front.

Authorization, and the §1033 question for a Maine bank this size

Skowhegan is supervised by the Maine Bureau of Financial Institutions and the FDIC; it is a state-chartered mutual savings bank, not a national bank, and the consumer-data flows for this integration sit on the account holder's authorization rather than on a regulator-mandated developer interface. The authorization is scoped per data domain (native ledger, aggregated view, statements, alerts), names the integrator, and is logged with a withdrawal path; NDA cover where the integrator is acting for a business customer of the bank.

The CFPB's Personal Financial Data Rights rule under §1033 is the forward-looking piece that may eventually change the picture for US data access. As of this writing, the rule's compliance dates are stayed by court order and the CFPB has opened a reconsideration via an Advance Notice of Proposed Rulemaking; it is not in force and is not the basis this integration relies on. If the reconsideration lands on a final shape that names Skowhegan-class community banks as data providers under a defined developer interface, the integration would map its existing endpoint contract onto that interface — small adapter work, not a rebuild — and the consent records we already keep are the right shape for whatever fee or representative-test the reconsideration adopts.

Other Maine institutions integrators ask about in the same breath

Integrators rarely want one Maine bank in isolation. These are the institutions whose customers or members tend to sit on the same dashboards as Skowhegan accounts, with one neutral line each:

• Bangor Savings Bank — the largest Maine-headquartered mutual, with seventy-odd branches across Maine and New Hampshire and a deeper digital-banking product set; same authorized-route shape, much wider surface area.
• Kennebec Savings Bank — Augusta-based mutual savings bank with its own online-banking and bill-pay product; similar consumer-deposit data domains.
• Norway Savings Bank — community mutual covering western and southern Maine; comparable mobile-banking surfaces.
• Camden National Bank — publicly-listed Maine commercial bank with its own iOS and Android apps and a broader commercial-banking data set worth namespacing separately.
• Maine Community Bank — the merged Biddeford/Mechanics institution; consumer and small-business deposit surfaces.
• Maine Savings Federal Credit Union — federally-chartered credit union with a top-rated mobile app; NCUA rather than FDIC framing.
• Maine State Credit Union — large state credit union with its own mobile platform and credit-score features in-app.
• Gorham Savings Bank — southern Maine community mutual; comparable retail surfaces.
• Town & Country Federal Credit Union — Portland-area credit union with transfer-to-other-institution support in its app.
• Midcoast Federal Credit Union — Bath/Brunswick credit union with a multi-device digital banking front end.

Things integrators ask before signing

The app already aggregates accounts from other banks and credit unions. Can the integration pick up that aggregated view too, or only the native Skowhegan ledger?

Both, with different caveats. The native Skowhegan ledger is canonical and refreshes in real time against the core. The aggregated external accounts are a re-export of third-party balances that the app pulls on its own cadence, so the freshness curve is whatever the bank's aggregator vendor delivers — typically once a day, sometimes longer when an external institution rate-limits or breaks. We label each field with its origin so downstream consumers can decide whether to trust an aggregated balance for, say, a loan decision.

What does account-holder authorization actually look like on a state-chartered Maine savings bank?

A signed authorization from the account holder, scoped to the specific data domains and the integration's purpose, plus the consent records and an NDA where the integrator is acting for a business customer of the bank. Skowhegan is supervised by the Maine Bureau of Financial Institutions and the FDIC, so the framing is consumer consent under standard US privacy expectations; there is no separate UK-style open-banking sandbox to apply for. We draft the authorization language with you as part of onboarding.

How fresh is data from secure.skowhegan.com once it's running through the integration?

Balances and the transaction ledger come straight off the session against the bank's core, so they reflect what the account holder sees in-app to within the polling interval we agree (commonly five to fifteen minutes for a treasury feed, on-demand for a query API). Monthly statements drop on the bank's statement cycle. Branch and ATM directory data updates rarely and is cached aggressively.

If the CFPB Personal Financial Data Rights reconsideration lands on a different shape, does the Skowhegan integration have to be rebuilt?

The integration sits on the account holder's authorization, not on the §1033 framework, so the day-one build does not change with whatever the CFPB lands on. If a future rule names Skowhegan-class institutions as data providers under a defined developer interface, we'd map our existing endpoint contract onto that interface — that is mostly a thin adapter, not a rewrite. We're tracking the reconsideration so the question doesn't surprise anyone.

Sources and timing for this brief

This page was put together against the bank's own product pages and the public regulatory record: the Play Store listing for com.skowhegan.grip, the bank's online & mobile banking FAQ, the FDIC BankFind record for certificate 19532, and the CFPB's own Personal Financial Data Rights Reconsideration page for the §1033 status. Where this brief states an identifier, a date or a count, that source is the one being cited — anything we couldn't verify is stated as a gap, not a guess.

Concretely: the Skowhegan build is at the smaller end of the work we do — a single institution, one mobile front end, a familiar US community-bank stack — and the engagement reflects that. We deliver the runnable source for the interface, in Python or Node, for a flat fee starting at $300, billed after delivery once you've run it against a real consenting session and signed off. Or we host the endpoints ourselves and you pay only per call, with nothing upfront. Either route, the turnaround is one to two weeks from the day the authorization and access are arranged. Send us the app name and what you want pulled and we take it from there.

Mapping reviewed 2026-05-26 — OpenBanking Studio integration desk.