Account data inside The Pineries Bank, and the authorized way in

The Pineries Bank has banked out of Stevens Point, Wisconsin since 1997, and carries FDIC certificate 9526 according to the FDIC's BankFind register. Its mobile app is not a bespoke build: the Android package id, com.mfoundry.mb.android.mb_075905994, sits in the mFoundry namespace, and mFoundry is now part of FIS — so the app is one tenant on FIS Digital One Flex Mobile. The trailing 075905994 looks like the bank's routing number and keys that tenant. For an integrator, the upshot is concrete: the data a customer sees after login lives behind structured FIS endpoints, and there is already a consumer-consented aggregation path into the same accounts.

Account data the app surfaces

Everything below is drawn from the app's own description of what a logged-in customer can do. These are the surfaces an integration would map.

Routes in

Two paths genuinely apply to this app, and they complement each other rather than compete.

Consumer-permissioned aggregation

The Pineries Bank is listed as covered by Finicity, a Mastercard company, for consumer-permissioned data access (per the Fintable coverage page). With the account holder's consent, this reaches balances and transaction history cleanly through a documented aggregation API and a tokenized connection — no stored credentials. It is the most durable path for the read-heavy surfaces, because it rides an existing data-access relationship rather than the app's private traffic, and it survives most front-end changes. Onboarding the consenting account is arranged with you as part of the build.

Documented protocol analysis of the FIS endpoints

Aggregation does not expose every surface equally. Scheduled bill payments, the exact transfer-trigger flow, and deposit events are easier to reach by mapping the app's own calls to the FIS backend under the account holder's authorization. Because the backend is FIS Digital One Flex, the request and response shapes are reasonably stable across its institutions; we capture and document the auth chain, the accounts and transactions calls, and the transfer and bill-pay endpoints for the Pineries tenant. More effort than aggregation, more reach.

For most teams the aggregation path carries the balances and transaction feed, and we add protocol analysis only for the bill-pay, transfer and deposit surfaces aggregation handles poorly — that split keeps the durable read traffic on the durable channel while still giving you the write-adjacent flows. If you only need balances and history, the second route is unnecessary.

A statement pull, sketched

Illustrative shapes only — exact paths and field names are confirmed during the build, not asserted here. The point is to show how this app's stated search-by-check-number behavior maps onto a request.

# The app rides FIS Digital One Flex Mobile (package com.mfoundry.mb…mb_075905994).

POST /auth/v1/session                 # device-bound login, MFA / biometric step-up
  { "fiId": "075905994", "username": "…", "deviceId": "…", "challenge": "<otp|biometric>" }
  -> 200 { "access_token": "…", "refresh_token": "…", "expires_in": 600 }

GET  /accounts                        # one row per deposit / loan account on the profile
  Authorization: Bearer <access_token>
  -> 200 [ { "id": "…", "nickname": "Checking", "available": 1042.55, "current": 1100.00 } ]

GET  /accounts/{id}/transactions?from=2026-01-01&searchBy=checkNumber&q=1287
  Authorization: Bearer <access_token>
  -> 200 [ { "postedDate": "…", "amount": -84.20, "checkNumber": "1287", "desc": "…" } ]

# Consumer-consented alternative for balances + history:
#   Mastercard / Finicity account-aggregation API — Pineries already covered (per Fintable).

What lands in your repo

The deliverable is working code and the documents around it, tied to the surfaces above:

• An OpenAPI/Swagger specification for the accounts, transactions, transfer and bill-pay surfaces we map.
• A protocol and auth-flow report: the device-binding and token/refresh chain, the MFA step-up behavior, and how sessions are kept alive.
• Runnable source for the key endpoints in Python or Node.js — login and refresh, account list, transaction query (including the by-check-number filter), and the consented-aggregation client.
• Automated tests against a sponsor sandbox or a consenting account, so the integration is verified, not just described.
• Interface documentation plus consent-capture and data-retention guidance written for a US deposit institution.

Consent & US data rights

The basis we build on is the account holder's own authorization. They consent to their Pineries data being accessed, the consent is logged, and they can revoke it — that is what makes the work authorized whichever route runs. The consumer-permissioned aggregation path through Finicity is built around tokenized access rather than shared credentials, which fits this model directly.

The CFPB's Section 1033 Personal Financial Data Rights rule is the forward-looking part of the picture, not today's settled law: it was finalized, but a federal court has enjoined its enforcement and the CFPB has reopened it for reconsideration, so its specific obligations are in flux. We treat it as where US data-sharing may go, design consent and revocation to stand on their own regardless, and revisit if a rewritten rule lands. Data handling follows the usual posture for a bank integration — data minimized to what the use case needs, access logged, NDA in place where the engagement calls for it.

FIS-platform notes

A couple of things about this specific app shape the build, and we handle each:

• Shared multi-tenant backend. Digital One Flex Mobile serves many institutions off one platform. We pin the integration to Pineries' tenant — the 075905994 institution key — so responses resolve to the right bank and routing context and never bleed in from a sibling on the same backend.
• Biometric and device step-up. FIS has bolstered this app family with biometrics and device binding. We design session handling around device registration and step-up challenges, so the integration re-authenticates cleanly instead of breaking the first time an MFA prompt appears.
• Consent-refresh window. On the aggregation route we build the sync around token expiry and revocation, so it re-consents on schedule rather than silently going stale.
• Deposit-image minimization. Remote deposit events can carry full check images. We scope capture to the metadata a use case actually needs and leave raw images out unless they are required, keeping the data footprint small.

Screens from the app

Store screenshots, useful for spotting which surfaces the front end exposes. Click to enlarge.

Where teams use it

Concrete cases a Pineries integration tends to serve:

• A bookkeeping or accounting tool that needs a consenting customer's checking transactions pulled and categorized nightly, with check numbers preserved for reconciliation.
• A small-business cash-flow view that reads balances across the customer's Pineries accounts and tracks scheduled bill payments against expected outflows.
• A lending or verification workflow that uses consented balance and transaction history for income and cash-flow checks, rather than asking the customer to upload statements.
• An internal treasury process that triggers transfers between a business's own Pineries accounts on a schedule.

Nearby apps in the same map

Other Wisconsin and community-institution apps that hold comparable account data; a unified integration usually has to span several of them. Listed for context, not ranked.

• Valley Communities Credit Union — Stevens Point–area member accounts, balances and mobile deposit.
• WESTconsin Credit Union — Wisconsin member banking with mobile deposit and digital wallet data.
• Wolf River Community Bank — real-time balances, debit-card controls and mobile check deposit.
• Community First Bank — southwest Wisconsin community bank with online and mobile account data.
• Town Bank — Wisconsin deposit accounts within the Wintrust community-bank network.
• Nicolet National Bank — multi-branch Wisconsin bank spanning personal, business and wealth accounts.
• Associated Bank — larger Wisconsin-based footprint with retail and business account data.
• Pioneer Bank — another mFoundry/FIS-platform community bank app, similar backend shape to Pineries.

Questions integrators ask about Pineries

Does Pineries run on a shared FIS platform, and does that change the integration?

Yes. The Android package namespace is com.mfoundry.mb.android.mb_075905994, and mFoundry is now part of FIS, so the app is a tenant on FIS Digital One Flex Mobile rather than a one-off build. That helps us: the request shapes are consistent across FIS institutions, and the trailing 075905994 keys the bank's own tenant. We pin the work to that institution id so balances, transactions and transfers resolve to Pineries and not a sibling on the same backend.

Can transactions be pulled the way the app searches them — by date, amount, or check number?

The app itself lets a customer search recent transactions by date, amount, or check number, which means those filters exist on the backend the app calls. We map the same query parameters so an integration can request, for example, a single check number on a checking account, instead of pulling everything and filtering client-side. Posted line items carry the date, amount, description and check number where present.

Is the Mastercard/Finicity aggregation route enough, or do you also analyze the app traffic?

It depends on the granularity you need. The Pineries Bank is already listed as covered by Finicity (a Mastercard company) for consumer-permissioned aggregation, which is the cleanest path to balances and transaction history. When you need surfaces aggregation does not expose well — scheduled bill payments, internal transfer triggering, deposit events — we add documented protocol analysis of the app's own FIS endpoints under the account holder's authorization.

What's the US regulatory basis for accessing this data right now?

The dependable basis today is the account holder's own consent: they authorize access to their Pineries data and can revoke it. The CFPB's Section 1033 Personal Financial Data Rights rule is the forward-looking piece — it was finalized but its enforcement is currently enjoined and the rule is back under CFPB reconsideration, so we do not build against it as settled law. We design consent capture, logging and revocation so the integration stands on consumer authorization regardless of where 1033 lands.

How this was built

Put together on 31 May 2026 from the app's Play Store listing and stated feature set, the FDIC BankFind record for the bank, the Finicity coverage entry for Pineries, FIS's own material on Digital One Flex Mobile, and current reporting on the Section 1033 reconsideration. Sources opened:

• FDIC BankFind — The Pineries Bank, cert 9526
• Fintable — The Pineries Bank coverage (Finicity)
• CFPB — Personal Financial Data Rights reconsideration
• ABA Banking Journal — court halts §1033 enforcement
• Mastercard / Finicity Open Banking US API reference

Compiled at the OpenBanking Studio integration desk · 31 May 2026.

Working with us

You bring the app name — The Pineries Bank — and what you want out of its data; we map the route, write the code, and arrange the consenting-account or sandbox access with you along the way. The build runs in a one-to-two-week cycle. There are two ways the work gets paid for. We can hand over the source code and documentation, billed from $300, which you pay after delivery once you have what you asked for and are satisfied with it. Or you skip the build entirely and call our hosted endpoints, paying per call with nothing upfront. Tell us which fits and what you need at /contact.html.

Mapping checked 2026-05-31.