What it actually takes to integrate Waldo State Bank Mobile

Waldo State Bank is a one-branch state-chartered community bank in Waldo, Wisconsin (Sheboygan County), with an FDIC certificate dating to 1913 (per its FDIC BankFind entry). Its mobile app is not a one-off build for Waldo. The Play Store package com.mfoundry.mb.android.mb_685 identifies it as tenant 685 on the mFoundry mobile-banking platform — the platform FIS acquired in 2013 — and the app talks to a backend hosted under m.mbanking-services.mobi. That single fact does most of the work on how this integration is shaped: Waldo's branding sits on top, but the call shapes, session model, and behaviour quirks are the platform's. We work with both layers, and most of what is delivered for one mFoundry tenant carries over with controlled changes to the next.

What a member sees inside the app

These are the surfaces present in the live Android app, named the way the Play Store listing names them. The integrator-use column is what we usually hear from clients asking for this app specifically.

Two practical routes to the data

For a tenant of Waldo's size there are two routes that actually work, plus a manual fallback. None of them depend on Waldo publishing anything itself.

Route A — Aggregator-mediated, member-consented

The member authenticates through an aggregator widget (Plaid, MX, Finicity / Mastercard Open Banking) and the aggregator presents normalised balance and transaction data downstream. Setup is fast — days, not weeks. The trade-off is coverage: small mFoundry-hosted community banks sit in the long tail, where field coverage can be thinner than for a top-50 institution, and the contract you write is against the aggregator's schema rather than against the bank. Good fit when you need breadth across many small banks and can accept the aggregator's terms and pricing.

Route B — Authorized direct interface integration

The member authorises us specifically. We map the actual handshake the Waldo app performs against the FIS-hosted endpoint — login, session, anti-replay tokens, the transaction-query and check-deposit calls — and deliver a runnable integration plus its specification. The work is durable because the platform changes slowly and across many tenants at once. This is the route we usually recommend when the consumer-facing API needs to be yours, the field set must be stable, and the SLA is between you and the integration rather than you and a third-party data vendor.

Route C — Native export, used as a fallback

The app supports per-account statement and transaction views with date filtering and check-number search. Where a low-volume member only needs a periodic file, a member-initiated export can carry the load while the live integration sits in the wings. We use this as a stop-gap, not a primary route.

Our standing pick on this one: B as the primary build, with A as a complement for breadth-of-bank coverage if you also need other institutions, and C kept around for the off-quarter exception cases.

What lands in your hands at the end of a build

Concrete deliverables, all tied to Waldo's actual surfaces and the FIS-hosted backend behind them:

• An OpenAPI 3 specification for the consumer-facing endpoints we expose on your side — accounts, transactions, internal transfers, deposit confirmations, bill-pay status — written against the field set the Waldo app actually serves.
• A short protocol and auth-flow report: the login handshake, session-cookie lifetime, the anti-replay / CSRF token chain, and how re-authentication is triggered when a session lapses mid-call.
• Runnable source for the integration in Python (FastAPI) or Node.js (Fastify) — pick one — with the FIS-side client cleanly separated from the consumer-facing API, so future tenant additions (other mFoundry banks) reuse the client and not the surface.
• Automated tests at three levels: contract tests against the consumer API, recorded-cassette tests against the FIS-side client, and a small live smoke test that runs against a consenting member account on a schedule you control.
• Interface documentation suitable for both a backend engineer (how to deploy, how to rotate, how to revoke) and a product owner (what each field means, where it comes from, when it can be stale).
• A short compliance note covering consent capture, retention windows, data minimisation choices, and the token-revocation path.

A look at the actual call shape

Illustrative, not verbatim from a proprietary spec. The exact paths, headers and parameter names are confirmed during the build against the live FIS-hosted endpoint under the member's authorization; the shape below is what the equivalent transaction-history call looks like in the family of mFoundry tenants we have worked with.

# Transaction history — Waldo State Bank Mobile (tenant mb_685)
# Confirmed during the build:
#   * traffic terminates on *.mbanking-services.mobi over TLS 1.2+
#   * session cookie + anti-replay token survive across calls until idle TTL
#   * date range + optional check_no map directly to the app's filters

POST /mb2/res/685/api/transactions HTTP/1.1
Host: m.mbanking-services.mobi
Content-Type: application/json
Cookie: mfsession=<opaque>; XSRF-TOKEN=<opaque>
X-MF-Client: integration/1.0

{
  "account_id": "<member-scoped id>",
  "from":       "2026-04-01",
  "to":         "2026-04-30",
  "check_no":   null
}

# 200 OK
# {
#   "items": [
#     {"posted":"2026-04-03","amount":-42.18,"type":"DEBIT_CARD",
#      "description":"AMZN MKTP","check_no":null},
#     {"posted":"2026-04-05","amount": 1875.00,"type":"DEPOSIT",
#      "description":"PAYROLL ACME","check_no":null},
#     {"posted":"2026-04-09","amount":-260.00,"type":"CHECK",
#      "description":"CHECK 1042","check_no":1042}
#   ],
#   "next_cursor": null
# }
#
# 401 -> session expired; the client re-runs the login handshake the app uses,
#        not a generic OAuth refresh — mFoundry's session model is not OAuth.

The shape your service consumes is yours, not this. We translate the response above into the contract on your OpenAPI document, and the FIS-side oddities (session model, idle-timeout behaviour, check-deposit asynchronicity) stay inside the client layer.

Member consent and the §1033 question

For a Waldo customer the legally dependable basis for any data-sharing build today is the member's own authorization. They sign in on their side, the scope of data and the retention window are written down before the first call goes out, and revocation removes both the live tokens and the cached state. We log consent acceptance with timestamps and keep an audit trail; NDAs cover anything the engagement needs to touch on your side. Data minimisation is built in — we pull the fields the consumer-facing API actually serves, not the union of everything reachable.

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is the federal piece worth tracking, but it is named here as the forward-looking variable rather than today's compliance floor. It is currently not in force — enforcement is enjoined and the rule is back at the bureau under reconsideration — so the integration is designed against member consent and the rule is parked as a planned-for, not built-on, dependency. For a single-branch state-chartered bank at Waldo's size, the asset-tier conversation that surrounded the original timeline reads very differently than it does for the largest institutions, and we factor that in without writing it into the present-tense contract.

Engineering notes specific to a tenant this small

A few things we account for on this specific app, all on our side and arranged during the build, not asked of you as preconditions.

• We measure the FIS session-cookie idle TTL on this tenant before scheduling any long-running pull. Idle expiry on mFoundry tenants is short by mobile-banking standards, and a backfill that ignores it gets a silent 401 partway through; the client we deliver wraps every call with re-handshake logic that survives an expiry without dropping rows.
• Because Waldo runs a single branch, there is no per-region routing, no split BIN handling, and no multi-charter eligibility logic to model. We keep the integration layer thin instead of importing a multi-tenant abstraction that buys nothing here. If you later add another mFoundry tenant, the FIS-side client is reused and a new tenant slot is wired in — the consumer API does not need to change.
• Mobile check deposit comes back asynchronously: submission, image acceptance, and posting are three separate events with their own status transitions. We model the deposit lifecycle in the consumer API (submitted → accepted → posted, with a rejection branch) rather than collapsing it into a single OK response, so downstream A/R tooling does not have to invent its own state machine.
• Because FIS rolls front-end updates across the whole mFoundry client base at once, the integration carries a small recurring smoke job on our side that hits the live endpoints under a consenting member and alerts us the moment a field disappears or a status code drifts. You hear about a change from us, not from a downstream user noticing a missing transaction.

Interface evidence

The Play Store screenshots, useful as a visual record of the screens an integration is reading from. Click any image to enlarge.

Sources checked while drafting this

Pages opened during the mapping: the FDIC BankFind record for the bank's charter, the bank's own mobile-app page, the Google Play listing for the Android build (which is where the mb_685 tenant identifier comes from), and the CFPB's own page for the Personal Financial Data Rights rule and the federal-court enforcement posture noted above.

• FDIC BankFind — Waldo State Bank (certificate 8700)
• Waldo State Bank — mobile app page
• Google Play — Waldo State Bank Mobile (package com.mfoundry.mb.android.mb_685)
• CFPB — Required Rulemaking on Personal Financial Data Rights (§1033)

Mapped 2026-05-30 by the OpenBanking Studio integration desk.

Other community-bank apps in the same lane

Apps a buyer who needs Waldo coverage usually also asks about. Most of these run on the same mFoundry/FIS platform and benefit from the same client layer; a few are listed for category comparison rather than backend overlap. Plain mention — neither endorsement nor disparagement.

• MidFirst Bank Mobile — another mFoundry tenant; carries balances, transactions, transfers and deposit features in the same family of call shapes.
• Coastal Community Bank Mobile — small-bank mFoundry app with a similar member-facing surface area.
• Community Bank of Elmhurst — single-charter community bank on mFoundry, useful as a sibling-tenant reference.
• Chickasaw Community Bank — mFoundry tenant exposing balances, transfers, bill pay and check deposit through the same backend family.
• First Community Bank SC Mobile — South Carolina community bank, mFoundry-hosted member portal.
• Community Bank Topeka Mobile — Kansas community bank on the same platform, similar field set.
• Maine Community Bank — mFoundry tenant, comparable size and feature set to Waldo.
• Community Trust Bank — older mFoundry tenant (mb_524), useful as a reference for an integration spanning multiple small US banks.
• MCCB Mobile (Madison County Community Bank) — Florida community bank on mFoundry; the surface area is the standard balances / transfers / bill pay set.
• FSB Odem Mobile — small-bank mFoundry app, often grouped with Waldo when buyers want broad small-bank coverage.

Questions integrators ask about a tenant like this

Does the mFoundry tenant code (mb_685) change anything from our side?

For the client, no. The mb_685 identifier in the Play Store package name is the tenant slot Waldo occupies on the shared FIS-hosted backend; we use it on our side to scope traffic to this bank, but you only ever see the consumer-facing API we deliver, not the underlying tenant routing.

Will a US data aggregator like Plaid already cover Waldo, or do we still need a custom build?

Plaid, MX and Finicity carry a long tail of mFoundry-hosted community banks via member-credential flows, and Waldo can usually be picked up that way. The custom build matters when you need fields the aggregator does not surface for a small tenant, when you want a stable contract for check-deposit metadata, or when you need delivered source you control end-to-end rather than a third-party SLA.

Is mobile check deposit really reachable, or only the read-side?

The check-deposit flow is a member-initiated action through the same authenticated session as the read calls, so it is reachable in principle. We treat it carefully on scope: many integrators only want the deposit confirmation feed (image hash, posted amount, decisioning status), and that is the slice we usually expose first, with the submit-side gated behind explicit member intent.

If the CFPB Personal Financial Data Rights rule comes back in a different shape, do we have to redo the work?

The build is anchored on the member's own authorization, which is the basis that does not move whatever the bureau lands on. If the reconsidered rule introduces new consent-receipt fields or a different revocation flow, the change surface is the consent layer; the core transaction and balance pulls stay where they are.

On how this gets bought: source-code delivery on a tenant like Waldo typically lands inside one to two weeks for $300 and up — paid only once the build is in your hands and you are satisfied with it — or you can call the hosted endpoints we run for this app and pay per call, with no upfront fee. Either way the starting point is just the app name and what you want done with its data; access arrangements with you and with the FIS-hosted side are part of the engagement, not a wall to clear first. Talk to us when you are ready.