Reaching the account data inside Central Penn Bank & Trust-NNB

Behind this app sits one small national bank wearing several names. The Play listing reads Central Penn Bank & Trust-NNB; the package is com.norrybank.imobile; the institution is The Northumberland National Bank — Norry Bank — an FDIC-member community bank rooted in Northumberland, Selinsgrove and Mifflinburg, per its own site and FDIC BankFind. For a business that wants those balances and transactions in its own systems, the name on the icon matters less than the digital banking back end every name shares. That back end is what we integrate.

The route we would actually run is authorized analysis of the app's own traffic under a consenting account holder, with the output shaped to FDX resource names so it stays portable if the bank later turns a standardized feed on. Native statement export backs up the audit trail. The sections below map what the app holds, how each route behaves, and the code that lands at the end.

What the app actually holds

Every domain here is something the published feature list and screens show a logged-in member seeing. We name them the way the app names them.

The authorized routes that fit this bank

Consumer-permissioned access aligned to FDX

FDX became the CFPB-recognized standard-setter for US data sharing in January 2025, and its API model already covers deposit and loan accounts. Where the COCC stack exposes a permissioned feed, we consume it directly. This is the most durable shape; for a bank this size, not every standardized endpoint is necessarily switched on yet, so we treat it as the target format rather than assume coverage.

Authorized session analysis of the app traffic

Under a consenting account holder, we observe the mobile and web digital banking session — login, token issuance, the cookie chain to the COCC-hosted host — and read everything the member can see. This is reverse engineering of the interface for interoperability, done with authorization. Coverage is broad because it mirrors the real app. Durability depends on front-end stability, which we account for in maintenance.

User-consented credential access

A consenting member supplies access; the session is maintained server-side and refreshed on schedule. Useful when a continuous sync is needed and a standardized feed is not yet available.

Native export

Statement and transaction downloads from the portal, where offered, give a clean historical backfill and a paper-trail format that reconciles cleanly. Narrow but dependable.

For this specific bank, our recommendation is route two as the build and FDX shapes as the contract: authorized session analysis gives complete coverage today, and naming the output to FDX resources means a later standards feed is a swap, not a rewrite.

A sketch of the session

Illustrative only — exact field names and the host are confirmed during the build against a consenting account. It shows the auth-then-read shape we implement, not captured secrets.

# Authorize once against the COCC-backed digital banking layer,
# then read accounts. Field names normalized toward FDX on output.

POST /dbank/live/app/login/consumer
  body: { username, password, deviceId }
  -> 200 { sessionToken, mfaRequired: true, txId }

# Step-up (device biometric / SMS one-time code), per the bank's MFA
POST /dbank/live/app/auth/otp
  body: { txId, otp }
  -> 200 Set-Cookie: dbsession=...; sessionToken refreshed

GET /dbank/live/app/accounts
  header: Authorization: Bearer <sessionToken>
  -> 200 [
       { accountId, type: "DDA", nickname,
         balanceCurrent, balanceAvailable, currency: "USD" },
       { accountId, type: "LOAN", nickname,
         balanceCurrent, nextPaymentDue }
     ]

# Normalized toward an FDX-style account resource:
# { "accountId","accountType":"DEPOSITORY","balance":{
#   "current":..., "available":... }, "currency":"USD" }

on 401 -> re-run auth; refresh token before expiry, never mid-page
      

The code and documents that land

Each deliverable is tied to the surfaces above, not a generic checklist.

• An OpenAPI/Swagger spec covering the account, transaction, transfer and deposit-status reads, with the FDX-aligned response shapes.
• A protocol and auth-flow report documenting the login, MFA step-up, token refresh and cookie chain against the COCC digital banking layer.
• Runnable source for the key endpoints in Python or Node.js — balance pull, paged transaction history, transfer status — with retry and re-auth handling.
• Automated tests against recorded fixtures so a front-end change shows up as a failing test, not a silent gap.
• Interface documentation a developer can hand to the next engineer, plus data-retention and consent-logging guidance for the account-holder data involved.

Things we handle going in

Two points specific to this bank that shape the build.

• One back end, several skins. Central Penn Bank & Trust, Norry Bank and the Mifflinburg-branded login all sit over the same COCC-hosted digital banking host. We key the integration to that host rather than to any one branded front end, so a marketing re-skin does not break parsing.
• Credit Sense is a separate tenant. The embedded credit score has its own vendor authorization, distinct from the bank's account data. We isolate that path so a change on the score widget never stalls the core account sync, and only include it when the member consents to that scope.
• MFA shapes the schedule. The app uses device biometrics and SMS step-up. We design the session refresh around that token lifetime so renewal happens ahead of expiry instead of failing inside a sync run.
• Front-end drift. Community-bank portals get periodic UI updates. We re-check the live flow when the front end moves and ship the fix as part of maintenance; access for that is arranged with you during onboarding, against a consenting account.

Consent and the rules that actually apply

For a small FDIC-member national bank like NNB, the dependable basis for reaching member data is the account holder's own documented consent — scoped to the domains they approve, with an expiry and a revocation path, and held to data minimization so only requested fields move. FDX gives us the recognized US format to express that sharing. The CFPB Section 1033 rule that would have compelled a free data feed is enjoined and back in the agency's reconsideration, so we build against consent as it stands today and treat 1033 as a direction the rules may take, not current obligation. We work authorized, log access, keep consent records, and sign an NDA where the engagement calls for one.

Where teams put this to work

• A bookkeeping or accounting tool pulling categorized transactions for a member who banks here, kept in sync nightly.
• A personal-finance dashboard aggregating Central Penn deposit and loan balances next to accounts at other institutions.
• A lending or underwriting workflow reading consented balance and transaction history with a clear audit trail.
• A treasury view for a small business reconciling transfers and bill-pay status against its own ledger.

Screens from the listing

Published app screenshots, useful for spotting the surfaces named above. Click to enlarge.

Similar apps in the same integration space

Other central- and eastern-Pennsylvania community bank apps that hold the same kind of member data. Listed for context — an aggregator usually wants several of these behind one schema. Names are reference only.

• Mid Penn Bank — deposit accounts, external transfers and mobile deposit across PA and NJ.
• Penn Community Bank — Bucks County deposits, transactions and cleared-check images via its moreMobile app.
• First Keystone Community Bank — northeastern PA deposit and loan accounts with mobile banking.
• Mifflinburg Bank & Trust — a nearby Union County community bank with the same online-banking feature set.
• Jersey Shore State Bank — Penns Woods Bancorp deposit and loan data in north-central PA.
• CNB Bank — Clearfield-based bank holding deposits, loans and transaction history.
• Kish Bank — central PA deposits and lending with mobile balances and transfers.
• Community Bank N.A. — multi-state deposit and loan accounts with a broad mobile feature set.

How this was checked

Compiled in June 2026 from the app's Google Play and App Store listings, the bank's own sites (centralpennbank.com and norrybank.com), FDIC BankFind for the charter, COCC's partnership announcement for the core, and CFPB and FDX sources for the US data-sharing picture. Where a detail was not publicly disclosed, it is left to be confirmed during the build rather than guessed.

• Google Play listing — com.norrybank.imobile
• FDIC BankFind — The Northumberland National Bank
• COCC — Northumberland National Bank core partnership
• CFPB — Personal Financial Data Rights reconsideration

OpenBanking Studio integration desk · mapping reviewed June 2026.

Questions integrators ask

Central Penn Bank & Trust and Norry Bank look like two names — which one does the integration actually target?

They are the same institution. Central Penn Bank & Trust is the current brand for The Northumberland National Bank, long known as Norry Bank, per the bank's own site and FDIC records. The Android package is com.norrybank.imobile and the digital banking back end is shared, so the integration targets one set of endpoints regardless of which front-end name or skin a member sees.

Does the COCC core affect how this integration is built?

It shapes the auth and session model. The bank selected COCC as its core partner, and the mobile app talks to a COCC-backed digital banking layer rather than to the core directly. We map that layer's login, token and cookie chain, then read accounts, transactions and transfers through it. If the bank later switches on a standardized FDX feed, the data shapes we hand you already mirror those resource names.

Can the Credit Sense credit score be part of the feed, or just balances and transactions?

It can, but it is treated separately. Credit Sense is an embedded third-party score widget with its own authorization, distinct from the account data the bank holds. We isolate it so a change on that vendor's side does not break the core account sync, and we only include it when the account holder consents to that specific scope.

Which US rules govern pulling this data from a small national bank like NNB?

The dependable basis is the account holder's own documented consent. FDX is the CFPB-recognized open-banking standard-setter as of January 2025, so we shape output to its formats. The CFPB Section 1033 rule that would compel a free data feed is enjoined and back in agency reconsideration, so we do not treat it as settled law — it is where the rules may go, not today's requirement.

Tell us the app — Central Penn Bank & Trust-NNB — and which of its surfaces you need, and we arrange access and any compliance paperwork with you from there. Source-code delivery starts at $300, billed only after we deliver and you are happy with the runnable source and documentation. Prefer not to host it? Call our endpoints and pay per call, with nothing upfront. Either way the build runs in one to two weeks. Start the conversation on the contact page.