The authorized way into Kennebec's account data
Kennebec Savings Bank moved its digital banking onto Alkami's platform in 2023, and that single fact shapes every integration decision on this page. The customer-facing app is a white-label Alkami client, so the work is not guesswork against an unknown backend — it is a mapping of one known platform as it is provisioned for Kennebec's tenant, under the account holder's authorization.
Three routes genuinely apply here. We say which one we would pick.
1 — User-consented interface integration (recommended)
With the account holder's consent, we drive the same authenticated mobile interface the app uses: login, the registered-device and step-up challenge, then the accounts, transactions, statement and deposit-status calls. Reachable: nearly everything a customer sees in-app. Effort: moderate, because the Alkami auth chain is well understood and we map Kennebec's specific tenant rather than reverse a bespoke core. Durability: good between Alkami platform releases, with a re-check tied to those releases. Access is arranged with you and the consenting customer during onboarding — a registered, consenting device, not a wall you clear first.
2 — Native in-app export as a fallback
The app already lets a customer sort, categorize and export transaction detail. That export is a lower-fidelity but stable secondary path. We wire it as a degraded mode so a sync keeps producing data if a screen shifts mid-cycle.
3 — Open-banking-style consented aggregation
Where a downstream consumer prefers an aggregation-style consent grant rather than direct interface access, we model the same data behind a consent token and revocation hook. This matters more for the US data-rights picture below than for day-one delivery.
Recommended spine: route 1, with route 2 kept warm as the degraded path. We would not lead with aggregation here because the federal rule that would standardize it is unsettled, and route 1 already returns the full surface today.
What a signed-in customer sees, and where it lives
The app's own description and help pages name these surfaces: instant balance, account history, fund transfers, bill pay, mobile check deposit, card management, and transaction sort, categorize and export. Mapped to what an integrator would actually do with each:
| Data domain | Where it originates in the app | Granularity | What an integrator does with it |
|---|---|---|---|
| Account balances | Accounts home tiles (Alkami) | Per account, available and current, near real time | Cash-position dashboards, low-balance and sweep triggers |
| Transaction history | Account detail; in-app sort, categorize, export | Per posted item: date, amount, description, in-app category, running balance | Bookkeeping sync, reconciliation, feeding categorization models |
| Transfers | Internal and scheduled transfers between accounts | Instruction, amount, schedule, status | Treasury automation, scheduled-movement mirroring |
| Bill pay | Bill-pay module | Payee list, payment amount, date, status | Accounts-payable status feeds and audit |
| Mobile check deposit | Remote deposit capture flow | Deposit item, amount, status, hold | Deposit-confirmation pipelines, funds-availability tracking |
| Card management | Card Management screen | Card last four, lock or unlock state, controls | Mirroring card controls into fraud or expense workflows |
| Statements | Statement documents | Per-period documents | Document archival and period reconciliation |
A login-then-statement call, sketched
Shapes below are illustrative. The exact host, header names and token format are confirmed during the build against Kennebec's own Alkami tenant, not assumed here.
# 1. Authenticate against the Kennebec Alkami tenant
POST https://{kennebec-alkami-tenant}/api/authentication/login
{ "username": "...", "password": "...", "deviceId": "<registered>" }
-> 200 { "challenge": "mfa_otp", "txId": "..." } # step-up expected
POST https://{...}/api/authentication/challenge
{ "txId": "...", "answer": "<otp>" }
-> 200 { "accessToken": "<bearer>", "expiresIn": 900,
"refreshToken": "..." }
# 2. Accounts and balances
GET https://{...}/api/accounts Authorization: Bearer <accessToken>
-> 200 [ { "accountId":"...", "type":"checking",
"available": 1843.20, "current": 1850.00,
"currency":"USD" }, ... ]
# 3. Categorized transaction history
GET https://{...}/api/accounts/{id}/transactions?from=2026-01-01&to=2026-05-18
-> 200 [ { "postedDate":"2026-05-12", "amount":-42.18,
"description":"...", "category":"groceries",
"status":"posted", "runningBalance": 1801.02 }, ... ]
# Handling we build in:
# 401 / token expiry -> silent refresh via refreshToken, one retry
# challenge re-issued -> resume from the consenting registered device
# in-app export available -> degraded path so the sync slows, not stops
What the build hands you
Everything is keyed to the surfaces above, not a generic banking template.
- An OpenAPI specification covering the mapped Kennebec endpoints — accounts, transactions, statements, deposit status, transfer and bill-pay reads.
- An auth-flow report documenting the Alkami token, registered-device and step-up challenge chain as it behaves for this tenant, including refresh and re-challenge handling.
- Runnable source in Python and Node.js for the core calls: authenticate, list accounts, page transactions with the in-app category preserved, pull statement documents, read deposit status.
- An automated pytest suite that exercises token expiry, a re-issued challenge, and an empty-range query — the failure modes that actually break a bank sync.
- Interface documentation a developer can hand to a teammate, plus data-retention and consent guidance written for a Maine-supervised institution.
Consent, and the US data-rights picture for a Maine bank
Kennebec is supervised by the Maine Bureau of Financial Institutions and is FDIC-insured, as the app states. At the federal level, the consumer financial data-rights rule that would have standardized a bank-provided data interface is, as of mid-2026, enjoined and back under reconsideration after the Eastern District of Kentucky halted enforcement. The practical effect for Kennebec: an integration today is not built on a regulator-mandated interface — it runs on the customer's own consented access to their Kennebec digital banking. We do not state the rule's proposed thresholds or compliance dates as settled, because they are exactly what is being reconsidered.
So consent is the legal spine, and we treat it that way. Written customer authorization on file. Access scoped to the accounts the customer names. Credentials never stored in clear, every pull logged, and an NDA where the engagement needs one. Revocation propagates: when the customer withdraws consent, the token is killed and retained data is handled per the retention guidance we ship.
What we account for on this one
Two things specific to Kennebec drive the engineering, and we handle both rather than hand them back as conditions.
- It is a multi-tenant white-label deployment. Kennebec's app sits on its own Alkami tenant with its own host and auth parameters, and Alkami ships platform releases on a roughly quarterly cadence. We pin to Kennebec's tenant specifically and schedule a re-check against each Alkami release, so a platform-side change surfaces as a caught test rather than a silent break.
- Server-side auth is device-and-challenge, not just biometrics. The Face ID and fingerprint login is local convenience; the real gate is a registered device plus a challenge-response that Alkami uses against credential stuffing. We design the consent flow around a registered, consenting device and a token-refresh loop, so the sync survives a step-up instead of dying on it.
- Categories already exist client-side. Because the app categorizes transactions for the customer, we capture both the raw line and the in-app label as distinct fields, so your downstream categorization is never silently overwritten.
Access to a consenting account or a sponsor environment is arranged with you during onboarding. It is part of the project, not a checklist you clear before we start.
Where teams take this data
- A nightly pull of categorized history into accounting software, with the bank's own categories kept beside the firm's chart of accounts.
- A cash-position view for a customer who runs several Kennebec accounts, refreshed off the balances call.
- Statement-line reconciliation against an ERP, matching posted items and running balance.
- A deposit-status bridge that turns remote-deposit-capture item status into an internal event when funds clear.
Working with us, and the price
A working pull of Kennebec balances, categorized history and statement data — auth chain mapped, tests green — is a one-to-two-week piece of work. From there you pick how you take it. Source-code delivery starts at $300: you receive the runnable client, the spec, the tests and the docs, and you pay after delivery once it works for you. Or run it as a pay-per-call hosted API: we host the integration, you call the endpoints and pay only for calls, with nothing upfront. You give us the app name and what you need from its data; access and compliance are arranged with you as part of the work. Start the conversation at /contact.html.
Screens from the app
Store screenshots, used here to point at the surfaces named above. Select one to enlarge.
Sources we opened
Checked in May 2026: the FDIC BankFind record for Kennebec Savings Bank; the bank's own announcement that it launched Alkami's digital banking platform; the federal court order halting Section 1033 enforcement; and the Maine Bureau of Financial Institutions list of regulated institutions. The data surfaces come from the app's store description and Kennebec's mobile-banking help pages.
- FDIC BankFind — Kennebec Savings Bank (cert. 17897)
- Kennebec Savings Bank launches Alkami's digital banking platform
- Court temporarily halts Section 1033 rule enforcement (ABA Banking Journal)
- Maine Bureau of Financial Institutions — who we regulate
Mapping reviewed 2026-05-18 by OpenBanking Studio's integration desk.
Other Maine and New England bank apps in the same picture
A unified integration usually has to span several of these, since a customer's money rarely sits at one institution. Listed neutrally for context, not ranked.
- Bangor Savings Bank — large Maine mutual; mobile app covers balances, transfers and deposits across personal and business accounts.
- Camden National Bank — Maine's largest publicly traded bank; 24/7 digital banking with the same account and payment surfaces.
- Bar Harbor Bank & Trust — northern New England bank with an online and mobile portal holding account and transaction history.
- Kennebunk Savings — Maine and New Hampshire savings bank; online and mobile banking with transfers and bill pay.
- Maine Community Bank — balances, transfers, bill pay and person-to-person payments through its mobile app.
- Machias Savings Bank — eastern Maine bank with personal and business mobile banking and deposit capture.
- Norway Savings Bank — western Maine mutual; mobile app with standard account, transfer and deposit surfaces.
- Gorham Savings Bank — southern Maine bank holding authenticated balances, history and payments.
What integrators ask about Kennebec
Does the Kennebec app run on Alkami, and does that change how you integrate it?
Yes. Kennebec moved its digital banking onto Alkami in 2023, per the bank's own announcement. In practice the mobile traffic reaches an Alkami tenant provisioned for Kennebec, with bearer tokens and a registered-device challenge-response. We map that tenant's host and auth parameters specifically rather than assuming a generic core.
Can you get categorized transactions, or only raw ledger lines?
The app already sorts, categorizes and exports transactions for the customer, so both the raw ledger and the in-app category labels are reachable. We surface them as separate fields so your side can keep its own categorization if it prefers.
Are mobile check deposit and bill pay in scope?
Both are first-class surfaces in the app: remote deposit capture and the bill-pay module. We can mirror deposit-item status and payee or payment records as read sync. Write actions such as initiating a payment are scoped explicitly with you, since they carry more risk than reading.
If Kennebec changes its app after you deliver, what happens?
Alkami ships platform releases on a roughly quarterly cadence. We keep a check that runs against Kennebec's live app after those releases, so a changed screen shows up as a failed test instead of a quiet gap, and the fix is a small maintenance item.
App profile — neutral recap
Kennebec Savings Bank's mobile banking app, Android package com.kennebecsb.kennebecsb per its Google Play listing (an iOS build is also listed on the App Store). Per its store description, the app lets a customer check balances, view account history, transfer funds, pay bills and deposit checks, and is a member FDIC institution. Help pages add card management, transaction sort, categorize and export, and Face ID and fingerprint login. The institution is a Maine state-chartered savings bank chartered in 1870 per the FDIC BankFind record (FDIC certificate 17897), running Alkami's digital banking platform since 2023 per the bank's announcement. Kennebec Savings Bank is an independent company; OpenBanking Studio is not affiliated with it or with Alkami, and this page references public materials only.