Reaching Skowhegan Savings Bank's aggregated account data from your own stack

The GRIP app (package com.skowhegan.grip, per its Play listing) pulls a member's Skowhegan accounts and their outside bank and credit-union accounts into one balance view, and it does the everyday work alongside that: posting transfers, paying bills, capturing check deposits from a photo, and firing an alert when a balance drops below a set figure. That alert is the useful part for anyone ingesting this data. It means the app already has a push surface, so a downstream system does not have to sit and poll to learn that something changed.

For an integrator the bottom line is short. The data a third party would want — combined balances, categorized transactions, statements, account and routing numbers — sits behind a member's authenticated session that reuses the bank's Internet Banking credentials. The route we would take is to capture and re-implement that session against the member's consent, hang a receiver off the alert event for freshness, and reconcile the full history on a scheduled pass. No mandated feed exists for a bank this size; the member's own authorization is what the whole thing stands on.

What the app holds, surface by surface

Each row below is a real surface the app exposes to a logged-in member, named the way the app names it where possible.

Authorized routes to the data

Three routes genuinely apply here. We set up whichever one fits, and the access and consent arrangements are handled with you while the build runs.

1. Member-consented session integration

Skowhegan tells members to log in to the app with the same Internet Banking credentials they already use, per its mobile banking FAQs. We capture that login and token-refresh exchange against secure.skowhegan.com and re-implement it so the integration runs on the same short-lived session tokens the app uses, refreshed under the member's authorization. This reaches everything the member sees: balances, transactions, statements, transfer and payment status. It is the route we would recommend as the backbone, because it is the most complete and does not depend on any feature the bank may or may not expose externally.

2. Aggregation-layer access for the linked outside accounts

The combined view is the app's headline feature, and the outside-bank and credit-union balances inside it arrive through the app's data-aggregation layer rather than from Skowhegan directly. Where you need those linked accounts and not just the Skowhegan-held ones, we read them through the consented aggregation tokens, which is cleaner and more durable than re-scraping each downstream institution.

3. Native export as a fallback

Members can view and save monthly statements. Where a use case only needs periodic documents — bookkeeping, a lending file — the saved-statement export is a low-effort fallback that needs no live session, at the cost of freshness.

What lands in your repo

The deliverable is working code first, with the written artifacts behind it. For this app that means:

• Runnable source for the core surfaces — authenticated session bootstrap, balance and transaction reads, statement fetch — in Python and Node.js, structured as a small client you can drop into your own service.
• A webhook handler wired to the balance-alert event, normalizing the push into your schema and acknowledging it so the app does not retry into a backlog.
• An automated test harness that exercises the login, refresh and read paths against a consenting account or a captured fixture, so a change in the app's responses shows up as a failing assertion rather than a quiet data gap.
• A sync design covering the split between the real-time alert path and the scheduled history pull, with the cursor and de-duplication logic spelled out.
• An OpenAPI description of the normalized surface, a protocol and auth-flow report covering the cookie and token chain, interface documentation, and data-retention guidance for the member records you hold.

A webhook receiver, sketched

The shape below reflects this app's actual push surface — the balance-threshold alert — normalized into a single event your services can consume. Field names are illustrative and confirmed against captured traffic during the build.

POST /ingest/skowhegan/alert      # our edge receives the bank's alert push

def handle_alert(req):
    evt = verify_and_parse(req)            # check signature, reject replays by event_id
    record = {
        "member_ref":   evt["member_ref"], # opaque, consent-scoped member handle
        "account_id":   evt["account_id"],
        "kind":         evt["kind"],       # "balance_below" | "posted_txn"
        "threshold":    evt.get("threshold"),
        "balance":      evt["available_balance"],
        "currency":     "USD",
        "observed_at":  evt["ts"],
    }
    emit(normalize(record))                # push onto your stream
    return 200                             # ack so the bank stops retrying

# Backfill path: reconcile full history on a schedule, not on the event
def pull_history(session, account_id, since_cursor):
    s = refresh_if_stale(session)          # session reuses the app's token chain
    page = s.get(f"/accounts/{account_id}/transactions",
                 params={"cursor": since_cursor})
    return page["items"], page["next_cursor"]

The alert path keeps you current; the cursor-based history pull fills the gaps and lets you reconcile anything the push missed.

Consent and the Maine regulatory picture

Skowhegan is a state-chartered Maine savings bank under the Maine Bureau of Financial Institutions, and an FDIC member per its own disclosures. The federal rule that would have forced a standardized consumer-data feed — the CFPB's Personal Financial Data Rights rule, Section 1033 — is not in force: a court enjoined the Bureau from enforcing it and the agency has reopened it for reconsideration. That is where US open banking may go, not what governs a Skowhegan integration today. The dependable basis is the member authorizing access to their own data. We work to that: access is logged, scoped to what the use case needs, data is minimized, and consent records are kept. Where the engagement touches member PII we work under an NDA. Consent expiry and revocation are honored in the session design, so a withdrawn authorization stops the sync rather than leaving it running.

Engineering notes specific to this build

Two things about this app shape the work, and we handle both on our side.

First-party versus aggregated fields. The single balance view mixes Skowhegan-held accounts with outside accounts pulled through the aggregation layer. Those two sources have different freshness and different reliability, so we tag each normalized record by origin and keep the aggregation-sourced balances on a separate confidence track — a stale linked-bank balance should not be mistaken for a live Skowhegan one.

Credential reuse and session lifetime. Because the app logs in with the member's existing Internet Banking credentials, the session is the access boundary. We design the refresh around the token lifetime we observe so the sync renews on the member's consent rather than failing mid-run, and we never persist the underlying password — the integration holds session material only, under the member's authorization. Access to a consenting account or a captured fixture is arranged with you during onboarding; the build runs against that.

Pricing and how we run it

Source for the core surfaces — session bootstrap, balance and transaction reads, the alert receiver — typically lands inside one to two weeks. From $300 you get the runnable source-code delivery: the client, the webhook handler, tests and interface documentation, and you pay after delivery, once it works for you. If you would rather not run anything yourself, the second model is a hosted API — you call our endpoints for Skowhegan data and pay per call, with no upfront fee. Tell us the app and what you want out of its data and we will point you at the model that fits. Start a Skowhegan integration

Where this plugs in

• A budgeting or net-worth tool syncing a member's Skowhegan and linked outside accounts into one ledger.
• A bookkeeping service pulling monthly statements and categorized transactions for a small-business member.
• A lender verifying balances and cash flow from a consenting applicant rather than asking for PDFs.
• A treasury dashboard listening for the balance-drop alert to trigger an automated sweep.

App screens

Captured from the public store listing, useful for mapping the surfaces above to what a member actually sees.

Sources and review

Checked in June 2026 against the app's public listings and primary regulatory sources: the Google Play listing for the feature set and package id, the bank's online and mobile banking FAQs for the credential and deposit behavior, the Maine Bureau of Financial Institutions for oversight, and the CFPB's Section 1033 reconsideration notice for the open-banking status. OpenFinance Lab · interface mapping, 7 June 2026.

Other Maine banking apps in the same picture

Same-category institutions an integrator often meets alongside Skowhegan, framed only by the data each holds.

• Bangor Savings Bank — statewide Maine and New Hampshire retail banking with its own balances, transactions and mobile deposit.
• Camden National Bank — personal and commercial banking with a digital platform spanning Maine and coastal New England.
• Maine Community Bank — mutually owned community bank with balance, transfer, bill-pay and P2P data.
• Bar Harbor Bank & Trust — Bar Harbor Online accounts with balances, transfers and eStatements.
• Machias Savings Bank — MSB Online accounts plus text-banking balance and history surfaces.
• Kennebec Savings Bank — Augusta-based community bank holding member account and transaction records.
• Norway Savings Bank — Maine savings bank with personal and business account data.
• Kennebunk Savings — Maine and New Hampshire savings bank with online and mobile account access.

Questions integrators ask

The GRIP app already aggregates outside accounts — can we read the combined view, or only the Skowhegan-held accounts?

Both, with the right consent. The app folds a member's Skowhegan accounts and their linked outside-bank and credit-union accounts into one balance view, per its Play listing. The Skowhegan-held side is read directly from the member's authenticated session. The aggregated outside accounts are held through the app's data-aggregation layer, so reading those cleanly means going through the consented aggregation tokens rather than scraping each downstream bank. We map both surfaces and tell you which fields are first-party and which arrive via aggregation.

How fresh is the data — do balance and transaction changes push to us, or do we poll?

The app already emits balance-threshold alerts, which is the natural push surface. We wire a receiver to that event so a balance crossing a limit or a new posting reaches you without waiting on a poll cycle, and we back it with a scheduled pull for full statement and transaction history. The build documents which fields are event-driven and which are reconciled on the scheduled pass, so you know the freshness of every record you store.

Skowhegan reuses Internet Banking credentials for the app — how does the integration authenticate without holding them?

We capture the app's real login and token-refresh sequence against secure.skowhegan.com, then design the integration to run on the short-lived session tokens the app itself uses, refreshed on the member's consent, rather than parking the member's Internet Banking password. The auth-flow report documents the exact cookie and token chain, and the runnable source refreshes the session under the member's authorization so access does not quietly lapse.

Maine is a small market — is there a regulated feed we ride, or is this consent-based?

It is consent-based. Skowhegan is a state-chartered Maine savings bank overseen by the Maine Bureau of Financial Institutions, and the federal open-banking rule that would have compelled a standardized data feed (CFPB Section 1033) is not in force — a court enjoined it and the Bureau reopened it for reconsideration. So the dependable basis is the member's own authorization to access their data, which is exactly what the integration is built on.