Pulling Oakwood Bank WI accounts through a consumer-authorized rail

Oakwood Bank — chartered April 6, 1920 as Pigeon Falls State Bank per local-history records, and renamed Oakwood Bank effective November 27, 2018 per the Wisconsin Department of Financial Institutions structure-change list — runs a small four-branch Wisconsin and Minnesota footprint (per the ICBA directory) and ships its mobile app, package net.oakwoodbank.grip, on the Banno "Grip" white-label platform that Jack Henry & Associates acquired in March 2014 per its SEC-filed acquisition press release. That tells an integrator most of what they need to know about reach and route: the data sits in Jack Henry's core behind a consumer login, and a third party wanting it pulls through a consumer-authorized aggregator the customer signs into, not a bank-published interface.

What most teams who ask us about this actually want is a normalized account and transaction feed flowing into their own platform — without the consumer pasting in a statement PDF. That is the build we run: pick the aggregator with the cleanest live coverage of Oakwood Bank (Akoya is the natural first pick on a Jack Henry core), wrap its OAuth2 and FDX-shape responses into the caller's schema, accept the aggregator's transaction-updated webhook into a small intake service, and run a polled cursor loop alongside for the gaps. The Oakwood side of the pipe is fixed; the engineering work sits on our end.

The authorized route into Oakwood Bank's records

Three routes apply here in practice. We pick between them at kickoff based on what the data is for.

Route A — consumer-permissioned aggregator (Plaid, MX, Finicity, Akoya)

The end customer signs into Oakwood through an aggregator widget, grants the scopes (balances, transactions, identity, statements), and the aggregator returns the records over its own API. For a Jack Henry-cored bank like Oakwood, Akoya has the structural edge — Akoya has a Jack Henry integration that gives it tokenized, no-credentials-sharing access to roughly four hundred small bank and credit-union customers on that core (per American Banker's reporting on the Akoya–Jack Henry deal). Plaid is the broadest fallback in the US; Finicity (owned by Mastercard since 2020) is strong for lending and cash-flow underwriting; MX is strong for community banks and data enrichment. What's reachable here: live balances, posted and pending transactions, transfer history, identity, and statement metadata. Effort: two to three days to wire the aggregator client, five to seven days to normalize and forward downstream. Durability: high — this is the path the US system is converging on.

Route B — member-authorized interface integration

When a single business or fiduciary needs a surface richer than the aggregator exposes — the bill-pay payee list with scheduled-payment metadata, deposited-check JPEGs front and back, or full monthly PDF eStatements with attachments — we run an interface integration against the consumer's own session under their written authorization, on infrastructure agreed with them. We replicate the OAuth2 / JWT exchange the Banno client uses (token-based authentication with short access and longer refresh, the documented modern community-bank pattern), fetch the in-app surfaces, and ship a normalized export. This is the right route for one-off bulk pulls — account migration, audit work, lending verification where the canonical PDF statement matters.

Route C — native PDF / CSV export

The Grip client surfaces monthly statements as downloadable PDFs from the bank's authenticated portal — the app's own Play Store description names "view and save your monthly statements" as a core function. For low-volume, one-shot moves we wrap that download in a small script the customer runs against their own credentials. Lowest effort, narrowest yield, no ongoing sync.

For ingesting teams, Route A is what runs in production: events on transaction commits, cursor sync for backfill, refresh handled inside the aggregator's consent renewal. Route B is the right call when the data needed sits outside the FDX clusters the aggregators expose — check images, full statement PDFs, scheduled payments — or when one client needs every record for a multi-year window in one drop.

What's reachable behind the Grip login

The domains below reflect Oakwood's app surfaces as the Play Store description names them, mapped to where each domain originates in the Jack Henry / Banno stack and what a downstream consumer typically does with it.

What we ship for an Oakwood Bank build

The headline artifact is runnable code, not paperwork. The shape that lands in the caller's repo:

• Connector source in Python and Node.js. A client that wraps the chosen aggregator's authorize / token / refresh flow against Oakwood, normalizes the FDX-shape or Plaid-shape payload into one schema, and exposes pull(account_id, since=...) plus a webhook handler that subscribes to the aggregator's transaction-updated events.
• Webhook intake service. FastAPI on the Python side, Express on the Node side. Verifies the aggregator's HMAC over the raw body, drops duplicates against a short replay window keyed on event id, persists the normalized record, then emits a downstream event onto whatever bus the caller uses — SQS, Kafka, or a plain HTTP fan-out.
• Polled cursor backfill worker. Nightly catch-up for anything the push side missed, parameterized by account_id and a per-account cursor. Retries are idempotent against the destination store; the cursor advances only after the downstream commit.
• Automated test harness. Pytest and Jest fixtures with recorded aggregator responses in Akoya, Plaid, and MX shapes, so the normalizer is exercised under each upstream. Live integration tests run against the aggregator sandboxes the studio sets up during onboarding.
• SDK-style README and reference app. A minimal Flask reference shows the full loop end to end — consumer authorizes, connector links the account, webhook fires, downstream record appears.
• OpenAPI specification for the normalized account / transaction / transfer / statement endpoints the caller exposes upstream, so the rest of the caller's service tree can consume them as ordinary REST.
• Auth-flow and protocol report. Short engineering write-up of the OAuth2 / JWT exchange, refresh-token rotation, signature verification, and the consent-renewal path. Useful for the caller's security review.
• Interface documentation — schema field by field, examples, plus an operational runbook for the things that happen on day forty: a consent expires, an aggregator drops a connection, a deposit posts late.
• Compliance and retention memo covering Wisconsin DFI recordkeeping defaults (the DFI-Bkg administrative chapters), the current limbo around federal §1033, data-minimization defaults, and the shape of the consent log the caller should keep.

A worked transaction pull against the consent rail

Illustrative Python sketch from a recent Oakwood-shaped build — confirmed against the aggregator sandboxes used during the project. The endpoint paths and field names track the documented FDX-aligned shapes and may differ in the live product version at delivery time.

# Pull posted transactions for an Oakwood Bank WI consumer-authorized link
# and forward them as a normalized event the caller's stack consumes.

import os, httpx
from datetime import datetime

AKOYA_BASE = "https://sandbox-products.akoya.com"

def refresh_access_token(refresh_token: str) -> dict:
    r = httpx.post(
        f"{AKOYA_BASE}/auth/token",
        data={
            "grant_type": "refresh_token",
            "refresh_token": refresh_token,
            "client_id": os.environ["AKOYA_CLIENT_ID"],
        },
        auth=(os.environ["AKOYA_CLIENT_ID"], os.environ["AKOYA_CLIENT_SECRET"]),
        timeout=10,
    )
    r.raise_for_status()
    return r.json()  # access_token, refresh_token, expires_in

def pull_transactions(access_token: str, account_id: str, since: datetime):
    cursor = None
    while True:
        r = httpx.get(
            f"{AKOYA_BASE}/accounts-info/v2/oakwoodbank/accounts/{account_id}/transactions",
            headers={"Authorization": f"Bearer {access_token}"},
            params={"startTime": since.isoformat(), "cursor": cursor},
            timeout=15,
        )
        if r.status_code == 401:
            # Consent likely expired. Surface a re-prompt to the end user.
            raise PermissionError("re-consent required")
        r.raise_for_status()
        body = r.json()
        for txn in body.get("transactions", []):
            yield normalize(txn)              # FDX-shape -> caller's schema
        cursor = body.get("nextCursor")
        if not cursor:
            return

def normalize(t: dict) -> dict:
    return {
        "id": t["transactionId"],
        "account_id": t["accountId"],
        "posted_at": t.get("postedTimestamp"),
        "amount_cents": int(round(float(t["amount"]) * 100)),
        "currency": t.get("currency", "USD"),
        "memo": t.get("description"),
        "status": t.get("status"),            # POSTED or PENDING
        "source": "akoya.oakwoodbank",
    }

On the push side, the shipped intake accepts transaction.posted and transaction.updated callbacks from the aggregator, verifies the HMAC over the raw request body, drops duplicates against a small replay window keyed on the event id, and persists before acknowledging. Where the aggregator does not push for a given account type, the cursor loop above runs on whatever cadence the caller wants — every ten to fifteen minutes for near-live, nightly for batch reconciliation.

Where US data-rights law sits right now

Two things shape what a third party can ask Oakwood Bank for today. First, the consumer's own authorization — a person can permission a third party to act on their banking records under existing federal and Wisconsin law, and that is the dependable basis we work on every time. Second, the federal §1033 Personal Financial Data Rights rule, which the CFPB finalized in October 2024 and which contemplated a phased compliance start in 2026 for the largest depository institutions. That schedule never came into force. In late 2025 the U.S. District Court for the Eastern District of Kentucky (Judge Reeves) entered a preliminary injunction blocking the CFPB from enforcing the rule, after Forcht Bank N.A., the Kentucky Bankers Association, and the Bank Policy Institute sued; in parallel the CFPB published an Advance Notice of Proposed Rulemaking in August 2025 reopening the substance for reconsideration. The rule is, as of this writing, enjoined and back in agency reconsideration — we describe it on the page as the forward-looking piece, not the present-tense legal basis.

For an institution of Oakwood's size — FDIC certificate 13030, four branches across two states — the largest-institution phase would not have touched it anyway. The practical channels remain the consumer-authorized aggregator network (Plaid, MX, Akoya, Finicity) and direct written consent from the account holder; the FDX standard, which the CFPB recognized in January 2025 as an eligible §1033 standard-setting body, is the technical shape on which the aggregator surfaces increasingly converge. The Wisconsin DFI, Division of Banking, supervises Oakwood Bank under the DFI-Bkg administrative chapters; its recordkeeping rules are what we point to for connector data-retention defaults.

Build details we work through with you

1. Coverage check at kickoff. Before any code is cut, we verify which aggregator currently has Oakwood Bank (FDIC 13030) wired up against its Jack Henry connector and how cleanly — Akoya's Jack Henry integration is the strongest structural match for a Banno-cored bank, but coverage shifts and we do not promise a route we have not just tested. If the caller already has an aggregator contract, we use that one; if not, we line one up with the caller during onboarding.
2. Check images and statement PDFs are a separate surface. Deposited-check JPEGs come off the Mitek capture → Ensenta or Jack Henry SmartPay RDA pipeline into the bank's archive; FDX and aggregator clusters typically do not expose them. If the use case needs check images or full PDF statements with their attachments, we plan that on Route B against the consenting consumer's authorized session, budget the extra time, and say so at kickoff rather than discovering it three weeks in.
3. Refresh and re-consent timing. Aggregator access tokens for the major networks against a Banno-cored bank are short — minutes for access, days to weeks for refresh, with a consumer-side re-consent at the end of the longer window. We design the sync so the refresh fires well before the access-token expiry and so the re-consent UI lands in front of the end user with enough lead time to renew before the connection actually drops.
4. Statement attachments and retention. Oakwood's monthly PDFs include check-image attachments; the bank's retention practice matters for any audit-driven use case. We map the connector's local cache to Wisconsin DFI recordkeeping defaults and to the caller's own retention policy, and we prune to whichever is tighter.
5. Vendor identification stays hedged in the deliverables. The Banno "Grip" lineage is inferred from the package namespace and the SEC-filed Banno acquisition documentation; Oakwood Bank itself has not publicly identified its mobile-banking vendor. We document the connector against what is observable and avoid promising vendor-specific behavior we cannot verify.

Common asks teams arrive with

• Small-business cash-flow signal for a lender. Twenty-four months of transactions on the borrower's Oakwood Bank checking account, refreshed weekly until the underwriting decision. Route A against the borrower's link; transaction events push into the lender's decision service in normalized shape.
• Multi-bank cash-management dashboard for a holding company. Live balance and overnight reconciliation across Oakwood and a handful of other community banks. Fan-in: one aggregator handles all of them, the connector normalizes per-institution shape to one schema, the dashboard receives a single feed.
• One-time migration off Oakwood to a new platform. Bulk pull of every account, every monthly statement, every check image for the relationship. Route B against the consenting account holder's session, written authorization in hand, bundle handed over, contract closes.

Cost and how the work is paid for

Source-code delivery is the most common shape on a build like this: a fixed price from $300, payable after we hand over the runnable repository, the OpenAPI specification, the test harness, and the operational notes — and only once it runs in your environment against the data you actually need. The alternative is a hosted endpoint: you call our API on Oakwood Bank, you pay per call, and there is no upfront fee. Either path runs on a 1–2 week cycle from kickoff to delivery for a single-institution build of this shape. Tell us the bank (Oakwood Bank WI is enough) and what you need from it; aggregator selection, sandbox access, and written authorizations where the route requires them are arranged with you as the project's first week of work. Start a conversation at /contact.html.

Screens we mapped against

The screens below are from the Play Store listing for net.oakwoodbank.grip — the surfaces a third-party connector ends up touching, in the order the consumer sees them. Tap to enlarge.

Banks and credit unions in the same lane

For teams comparing options across the small-bank and credit-union mobile-banking landscape, these are the apps Oakwood Bank WI sits next to — same depositor audience, similar data shape, very similar integration story. A unified connector covers them under one normalized schema; per-app builds cover each in isolation.

• Royal Credit Union — member-owned Wisconsin and Minnesota credit union app with check deposit, account view, and credit-score lookup.
• North Shore Bank Personal — Wisconsin community bank's consumer mobile-banking app.
• Nicolet Bank Digital — Nicolet National Bank's consumer app with mobile check deposit, Zelle, internal and external transfers, bill pay, and real-time alerts.
• bankNOW — Nicolet National Bank's separate small-business mobile-banking app.
• WCCU Mobile — Westby Co-op Credit Union (Wisconsin) app with balance, transfers, check deposit, and bill pay.
• CSB Simple Banking — Community State Bank Wisconsin app with Zelle P2P, transfers, mRDC, and debit-card controls.
• First Citizens State Bank (Whitewater, WI) — community-bank app with balance and transaction history, transfers, bill pay, and mobile check deposit.
• Citizens State Bank — La Crosse-area Wisconsin community bank app, accessed with online-banking credentials.
• Community Bank Mobile (CBWIL) — built on the Apiture Xpress Mobile platform; a typical small-community-bank stack comparable to Oakwood Bank WI.
• Surety Bank — small US community bank running on the Apiture Digital Banking Platform.

Most of these (Banno-cored, Apiture-cored, Q2-cored) reach the same US aggregator network from the integrator side; a single Akoya or Plaid client covers most of them with per-institution normalization in the connector.

Questions integrators ask

Does Oakwood Bank's Banno "Grip" app emit webhooks I can subscribe to directly?

No. The push side of the integration runs through the aggregator (Akoya, Plaid, MX, Finicity), not the bank itself. Banno is the consumer-facing client over Jack Henry's core; the bank's backend does not publish a third-party push interface. What we wire is the aggregator's transaction-updated callback into the caller's stack, with a polled cursor loop alongside for institutions and account types where the push path is incomplete.

If a consumer-authorized connection drops, how does the connector recover without re-collecting credentials?

The aggregator's refresh-token flow is the recovery path: the connector renews the short-lived access token from the longer refresh token, and surfaces a re-consent prompt to the end user before the longer window closes. If a consent does lapse, the consumer reauthorizes through the aggregator's widget; we keep the account_id stable across reconnection so the caller's downstream records line up.

Which aggregator do you actually use for an Oakwood Bank build?

Whichever has the cleanest tokenized coverage of Oakwood Bank (FDIC #13030) at build time. Akoya is the natural first pick because its Jack Henry integration gives it tokenized access to a large pool of small community banks on that core. Plaid is the broad-coverage fallback; MX and Finicity are sometimes the right answer when the caller already has a contract. We verify against the live sandboxes at kickoff rather than promising a route from memory.

Can you pull full PDF statements and check images, not just transactions?

Yes, but those typically need Route B (interface integration against the consenting consumer's session), not the aggregator. FDX clusters cover transactions, balances, identity and statement metadata — the canonical monthly PDF and the deposited-check JPEGs sit outside. We say up front whether your use case needs Route B and budget the extra time.

Where these notes come from

This page draws on five primary sources: the Wisconsin Department of Financial Institutions structural-change record for the 2018 Pigeon Falls State Bank → Oakwood Bank rename; the SEC-filed Jack Henry & Associates press release on the Banno acquisition (March 2014), which establishes the Banno / Grip lineage behind the net.oakwoodbank.grip package namespace; Cozen O'Connor's write-up of the §1033 enforcement injunction in the Eastern District of Kentucky; the CFPB's August 2025 Advance Notice of Proposed Rulemaking reopening the §1033 substance; and the Jack Henry Payments developer documentation on consumer RDC pipelines (Mitek + Ensenta + SmartPay RDA). Wisconsin DFI's banking rules (DFI-Bkg administrative code) inform the retention defaults the connector ships with.

• Wisconsin DFI — 2018 banking structure changes (Pigeon Falls State Bank renamed to Oakwood Bank)
• SEC EDGAR — Jack Henry & Associates 8-K exhibit: Banno acquisition press release (March 2014)
• Cozen O'Connor — §1033 compliance date passes while rule is enjoined and under reconsideration
• Federal Register — Personal Financial Data Rights Reconsideration ANPR (22 August 2025)
• Jack Henry Payments — consumer remote deposit capture integration patterns (Mitek, Ensenta, SmartPay RDA)

Assessment compiled by OpenFinance Lab on 2026-05-31. The engineer who would build this connector cross-checked the sources above against the live Play Store listing for net.oakwoodbank.grip; the Banno vendor inference rests on the package namespace and the SEC filing rather than on a disclosure by Oakwood Bank itself.