Pulling payments, statements and check-deposit history out of Oakwood Bank WI

Oakwood Bank's mobile front end carries the everyday primitives a small Wisconsin community bank gives a customer: balances on deposit and farm-loan accounts, the bank's stored monthly statements, in-house transfers, person-to-person and bill payments, and remote check deposit by camera. The institution itself is the former Pigeon Falls State Bank — founded in 1920 and renamed Oakwood Bank in late 2018, per FDIC records — with four branches across western Wisconsin and southeastern Minnesota and an unusual concentration of farm loans for a bank of its size. The app is what a third party would actually integrate against; the brief below maps what is reachable, the authorized path to reach it, and what we deliver.

Data the app holds for a customer

The surfaces below are what a customer sees in the app screens and what a properly authorized integration can serialize through the same paths. Granularity is what the bank's portal actually returns — not what the schema can theoretically carry.

How we'd reach it

Two routes apply cleanly for an app of this profile, and a third sits as a fallback. We choose between them based on what the integrator needs the data to do, not on which is technically purest.

1. Consented authorized interface integration (recommended)

The account holder grants the integration access to their own Oakwood account, under a written authorization that names the data fields and the lifetime. We then drive the same authenticated paths the app drives — login, MFA, session, listing, detail, statement download — and serialize the response into a stable JSON shape. Effort sits in mapping the bank's portal session to a normalized model and in handling re-auth gracefully. Durability is good as long as we wire a small re-check step that catches the day the vendor changes a field; access onboarding is something we arrange with you, not a hurdle on your side.

2. Native statement export, on a schedule

The bank's app and online portal expose monthly statements as PDFs and, on many surfaces, transaction history in a downloadable form. For integrators whose downstream is reporting rather than real-time, a scheduled export pipeline — pull, parse, archive — covers a surprising amount of ground at lower complexity. We use this as the spine when daily granularity is enough.

3. User-consented credential broker (fallback)

If the integration must live in a third-party environment we don't control end-to-end, the consenting customer can route their credentials through a broker session that the studio configures. Same compliance footing, narrower data scope. This is the path of last resort and we say so up front, because the operational risk lives with the broker.

For most callers, route 1 carries the weight, with route 2 layered in for archival statements. We make the call in the kickoff and put it in writing.

Endpoint sketch (authenticated request, in outline)

The following is illustrative — exact field names get confirmed during the build against the live portal — but it shows the shape of what gets serialized for an Oakwood Bank WI customer who has authorized the integration.

# 1. Acquire a session against the consumer banking portal,
#    on behalf of an authorized account holder.
POST /m/login
{
  "username":  "<customer-id>",
  "secret":    "<passcode-or-token>",   # 4-digit passcode or biometric-derived token
  "device_id": "<persisted device fingerprint>"
}
-> 200 { "session": "<opaque>", "expires_in": 900, "mfa_required": false }

# 2. Pull the customer's account list.
GET /m/accounts   (session)
-> 200 [
  { "id":"acct_001", "type":"checking",  "nickname":"Everyday",
    "ledger_balance": 4218.62, "available_balance": 4218.62, "currency":"USD" },
  { "id":"acct_044", "type":"farm_loan", "nickname":"South 40 line",
    "principal": 38211.10, "next_due":"2026-06-01", "rate_apr": 7.25 }
]

# 3. Pull statements for an account, paged by cycle.
GET /m/accounts/acct_001/statements?from=2025-01&to=2026-04   (session)
-> 200 [ { "cycle":"2026-04", "pdf":"/m/statements/acct_001/2026-04.pdf",
           "opening_balance": 3902.11, "closing_balance": 4218.62 }, ... ]

# 4. On session expiry, refresh transparently or re-prompt for MFA.
#    The integration does not silently lose authorization mid-day.

Real responses carry more fields than this — masked account numbers, posting versus effective dates, RDC item statuses, scheduled-payment rows. The shape and pagination get pinned down during the build, not assumed in advance.

What lands in your hands

The delivery is one bundle, against one institution, against one consenting account or sandbox at first:

• An OpenAPI 3.1 specification covering the endpoints the integration actually exercises — accounts, transactions, statements, transfers, payments, RDC items, farm-loan detail.
• Runnable source in Python (and a Node.js port on request) for those endpoints, with the auth/session module isolated so swapping a credential strategy doesn't touch the data layer.
• A protocol and auth-flow report: how login goes from the 4-digit passcode or biometric-derived token through to the session cookie, where MFA may step in, and how the session expires.
• Automated tests against a recorded fixture set, with optional pass-through tests against a consenting live account when that fits the engagement.
• Interface documentation written for the integrator who has to maintain this — not just an OpenAPI dump, but the operational notes that decide whether a 5xx is a real outage or a normal mid-statement-cycle blip.
• Consent records and data-retention guidance shaped to Wisconsin state-bank supervision and to whichever federal posture is in force on the day we ship.

Wisconsin and federal posture

Oakwood is state-chartered, supervised by the Wisconsin Department of Financial Institutions, with deposit insurance via the FDIC under certificate 13030. That puts the institutional rules — privacy, customer-data handling, vendor-management oversight — under the Wisconsin DFI examination program first, with federal consumer-protection rules layered on. The CFPB's Personal Financial Data Rights rule under §1033 was finalized in late 2024, but as of this writing the Bureau is enjoined from enforcing it and the rule is back in agency reconsideration following an Advance Notice of Proposed Rulemaking published in August 2025. We do not treat §1033 as the governing framework today; it is the unsettled forward-looking piece. The dependable basis on the day we ship is the account holder's own authorization, which works the same whether §1033 settles, is rewritten, or vacates.

Inside that frame, the consent we collect names the customer, the institution (Oakwood Bank), the data domains the integration touches, the lifetime, and the revocation path. Access is logged. Data is minimized to what the integrator asked for. NDAs apply where the engagement calls for them. These are the studio's operating defaults, not optional add-ons.

Build notes specific to Oakwood

A few items that matter for this particular institution, all things we handle as part of the build rather than gate the engagement on:

• Session timeout window. Community-bank portals at this scale tend to keep sessions short — minutes, not hours — so we design the sync around the refresh window, not against it. The integration re-auths transparently where the bank's vendor allows it, and re-prompts cleanly where it doesn't, so it does not silently lose authorization in the middle of a long pull.
• Two app surfaces, one bank. Oakwood publishes a separate Commercial Center app for business clients alongside the consumer Oakwood Bank WI app (net.oakwoodbank.grip). They run on different session contexts and may sit behind different vendor portals. We scope the integration to one surface at a time and map only what the consenting account actually has access to, so a consumer-side integration does not accidentally try to reach commercial endpoints (and vice versa).
• Farm-loan accounts as a first-class object. Oakwood's loan book skews toward farm loans more than a typical Wisconsin community bank. We model loan accounts with their own metadata — collateral references, payment schedule, principal and accrued interest — rather than flattening them into a generic deposit shape. If your downstream model only handles deposits and revolving credit, that gets surfaced during scope so you can extend it before integration.
• Vendor-front-end drift. Small community banks sit on vendor digital-banking platforms whose front ends get touched on a release cadence outside the bank's direct control. We schedule a quiet weekly check against the integration's critical paths, so when the vendor moves a field or renames a flow we tell you before a customer does.

Other Wisconsin community-bank apps in the same shape

The neighboring institutions below sit in the same regulatory and technical zone — Wisconsin (or Minnesota/Wisconsin) chartered, customer-facing mobile app, balances and statements and RDC behind a consented login. They are listed for ecosystem context, not as ranked alternatives; a unified integration across several of them is the kind of work the studio is built to do.

• Citizens State Bank (Clayton, Eau Claire, La Crosse) — community bank with checking, mobile deposit, statement access through its own app.
• CCFBank (Citizens Community Federal, Eau Claire) — community bank serving Wisconsin and Minnesota with full digital banking.
• Community State Bank (Wisconsin) — community-bank mobile app, similar consumer-side surfaces.
• Tri City National Bank — southeastern Wisconsin community bank with retail mobile banking.
• Town Bank — Wisconsin community bank inside the Wintrust network; consumer mobile app with the same primitives.
• Nicolet National Bank — Wisconsin community bank with personal and business mobile banking.
• North Shore Bank — Wisconsin community bank with retail mobile banking across eastern Wisconsin and northern Illinois.
• Royal Credit Union — Wisconsin and Minnesota credit union with a customer-facing mobile app and remote deposit.
• WESTconsin Credit Union — Wisconsin credit union with mobile deposit and account access.

Integrator questions

Does the size of Oakwood Bank — a small Wisconsin community institution — change how this integration is built?

Not in the way that matters. The auth surface and statement pipeline behave the same as a larger bank's; what changes is the regulatory posture. Oakwood is state-chartered by the Wisconsin DFI and supervised by the FDIC, and the federal §1033 data-rights question is paused under reconsideration, so the dependable basis for an integration is the account holder's own consent rather than a federal access mandate. That happens to work the same regardless of asset size.

How does the integration handle Oakwood's high share of farm-loan accounts compared to a typical retail bank?

Farm-loan accounts come back with different metadata than a checking account — collateral lines, payment schedules tied to seasonal cycles, sometimes split principal/interest installments. We map those onto a loans schema that's wider than a generic 'account' object so an integrator can render or sync them without losing the agricultural detail. If your downstream model only handles deposits and revolving credit, we flag that during scope so you know what to extend.

If the same customer also uses Oakwood Bank Commercial Center, can one session reach both?

No. The consumer app (net.oakwoodbank.grip) and the Commercial Center app run on different session contexts and, where present, different vendor portals. We integrate one at a time. If a customer wants both, that's two consents and two integration paths — the cost is incremental, not double, because the auth and serialization work overlaps.

Are previously deposited check images available historically through the export?

Statements typically reference each cleared check by date, amount, and check number, and the bank's portal usually serves front/back images on demand within a retention window measured in months or low-digit years. The integration can backfill those images as long as the account is still in good standing and the retention window covers them. We confirm the actual window during the build because it depends on which vendor service the bank is using for image archive.

How this brief was put together

The institutional facts above come from the FDIC BankFind record for certificate 13030 and the bank's own digital-services page; the app facts come from the Play Store listing for net.oakwoodbank.grip and the screens the app itself shows. The §1033 status anchors to the August 2025 Federal Register Advance Notice of Proposed Rulemaking. Specifically:

• FDIC BankFind — Oakwood Bank, certificate 13030
• Oakwood Bank — Digital Services
• Google Play — Oakwood Bank WI (net.oakwoodbank.grip)
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 2025)

Notes from the OpenBanking Studio integration desk, May 2026.

App screenshots

Engagement & contact

Give us the app name and what you want done with the data; consent paperwork, sandbox access, and the scope agreement with the customer are part of the engagement, handled with you during onboarding. Source-code delivery for the Oakwood Bank WI integration starts at $300 and is paid only after the build runs on your machine and you have signed off. If you would rather not host it yourself, the pay-per-call hosted endpoint is available with no upfront fee — call our API, pay per call, scale as needed. Either path runs in one to two weeks. Send the brief to /contact.html and we will come back with the route map and a quote.