Reading MCB Go: the aggregation surface behind a community-bank PFM app

Two surfaces sit behind this app, not one. The Internet Banking portal at my.meadecountybank.com handles the day-to-day teller-style functions for Meade County Bank; MCB Go is the decision-support layer the bank bolts on top — multi-institution aggregation, merchant-spending averages, transaction tags and receipt photos. That distinction shapes the integration. An integrator who wants the member's MCB accounts alone has one route. An integrator who wants what the member sees inside MCB Go — their MCB accounts plus the outside accounts they've linked — has to reach the PFM aggregation surface, not just the core.

This brief covers both. We have built against community-bank PFM stacks of this shape before and treat the work as authorised interface integration: member consent on the record, traffic patterns documented as we go, deliverables shaped so they survive the inevitable portal redesign.

Data the app actually holds for a logged-in member

The Play and App Store listings, plus the bank's own mobile-banking page, line up on the surface. Treat the table below as what an integration can in principle reach behind a consented session — granularity varies per linked institution and per how much the member has personalised their transactions.

How we'd reach the data

Three real routes apply to MCB Go. We'd usually run one as primary and keep a second warm.

1. Member-consented session against the PFM aggregation layer

The member authenticates with their Meade County Internet Banking credentials inside MCB Go; behind that, the app talks to the bank's PFM aggregation backend. With explicit member consent and an authorised mandate, we replicate that traffic shape from a service: the same auth handshake, the same session lifetime, the same paged reads. Reachable: everything the member can see in-app, including their externally linked institutions. Effort: a focused build, because the auth surface is small and well-scoped. Durability: tied to the PFM vendor's release cadence — covered by the contract-test fixture noted further down.

2. Aggregator path (Plaid, Finicity, MX) hitting Meade County Bank directly

Where the integrator needs only the member's MCB accounts and wants a longer-lived link than a credential session, the established aggregator network covers Meade County Bank like other US community institutions. We arrange the aggregator relationship as part of onboarding, scope down to the accounts the use case actually needs, and document fallback if a particular aggregator's coverage degrades.

3. Native export from the Internet Banking portal

For batch use cases — month-end reconciliation, accountant hand-off — the Internet Banking portal supports member-driven exports (CSV / OFX / QFX in the way most community-bank cores do). It is the lowest-effort path, but it is point-in-time rather than streaming. We use it as a stop-gap or to backfill history while a live route is being wired.

For MCB Go specifically, we'd lead with route 1 when the customer cares about what the member sees in the app — including their linked outside accounts and their personalisation — and lead with route 2 when the customer only wants the MCB accounts and wants the link to survive the member's next phone change.

What lands in your repo

Concrete artefacts, tied to the surfaces in the table above:

• An OpenAPI 3 spec covering the endpoints we actually use — auth handshake, accounts list, transactions per account (paged), the user-metadata fields where the member has set them, and the alert preferences read.
• A protocol & auth-flow report: the session lifecycle, token refresh, cookie chain, and where the PFM layer differs from the bare Internet Banking portal.
• Runnable source in Python (httpx + pydantic) and Node.js (undici + zod), with a normalised account/transaction schema so MCB-origin and externally-linked rows arrive in the same shape.
• Automated tests against recorded fixtures (auth happy path, paged history, empty-history edge, an outside-institution row going stale, a tag round-trip).
• An interface document for your team: each field's source, its observed nullability, and the parts of the surface that are member-augmented vs. bank-canonical.
• A short compliance memo covering consent capture, retention, and the data-minimisation toggles in the client we hand over.

On the wire — what a reads-only client looks like

Illustrative, not a copy of any specific endpoint. The exact paths, header names and field names are confirmed during the build against the live consented session.

# Python sketch — member-consented reads against the PFM layer
import httpx

def open_session(member_id: str, ib_password: str) -> httpx.Client:
    s = httpx.Client(base_url="https://pfm.<tenant>/api", timeout=15)
    r = s.post("/session", json={
        "institution": "meade-county-bank",
        "username": member_id,
        "secret":   ib_password,            # held only for the consented run
    })
    r.raise_for_status()
    s.headers["Authorization"] = f"Bearer {r.json()['session_token']}"
    return s

def list_accounts(s: httpx.Client) -> list[dict]:
    return s.get("/accounts").json()["accounts"]   # MCB + linked institutions

def read_transactions(s: httpx.Client, account_id: str, since: str):
    page, out = None, []
    while True:
        r = s.get(f"/accounts/{account_id}/transactions",
                  params={"since": since, "cursor": page, "limit": 200})
        body = r.json()
        out.extend(body["transactions"])           # incl. tags, notes, geo when set
        page = body.get("next_cursor")
        if not page: return out

# Errors we explicitly handle:
#   401 on expired session  -> refresh once, then surface to the consent UI
#   409 on linked-account re-auth needed -> mark stale, do not blanket-fail the run
#   429 -> backoff per Retry-After; the PFM tier rate-limits per member, not per app

Consent and the current US posture

The dependable legal basis for this integration today is the member's own authorisation under Meade County Bank's Internet Banking enrolment terms — captured in writing, scoped to the data domains the use case needs, and revocable. That's what we build against and that's what survives a regulatory re-shuffle.

Section 1033 of Dodd-Frank — the CFPB's Personal Financial Data Rights piece — is the forward-looking question, not the settled answer. As of this writing the rule has been enjoined by the Eastern District of Kentucky and the CFPB has reopened it for reconsideration through an Advance Notice of Proposed Rulemaking; the original compliance schedule is paused. Whatever the eventual shape, the smallest community depositories such as Meade County (FDIC cert 25173, per the bank's call-report record) were always at the back of any phased timeline. We track it because it changes the long-run path of the integration; we do not depend on it for today's build.

Operationally the studio works under NDA where the customer wants it, logs every consented read, minimises the data we hold to what the use case needs, and writes a deletion/retention rider into the deliverable.

How we'd build it for this app specifically

• We treat the PFM layer and the core as two separate surfaces, not one. MCB Go's data is the PFM-aggregated view; the Internet Banking portal is the bank-canonical view. They overlap on MCB accounts but diverge on the linked-outside accounts and on user-augmented metadata. We document which surface each field came from so a downstream system isn't quietly reconciling against two truths.
• We design the sync around the consent-refresh and credential-re-auth windows so it does not silently expire. Aggregated rows for outside institutions can fall into a "re-auth needed" state without the parent session breaking; the client we hand over marks those accounts stale, keeps reading the rest, and surfaces a re-consent prompt on a clear schedule rather than blanket-failing the run.
• We ship a contract-test fixture that runs on a schedule. Community-bank PFM vendors push releases on their own cadence, and a field rename or pagination tweak is the usual failure mode. The fixture replays a small known read against the live surface and flags a drift before a customer notices.
• We scope user-augmented fields as optional, not required. Tags, notes and geo only exist where the member set them; treating them as mandatory in the normalised schema would turn a sparse data source into a wall of nulls in the downstream ledger.

What it costs to commission the MCB Go build

Source-code delivery for this build starts at $300, paid only after delivery once you're satisfied with what the runnable client produces against the MCB Go aggregation surface — typical cycle one to two weeks from a confirmed scope and a consented test member. The alternative is the hosted route: call our endpoint, pay per successful call, no upfront fee, useful when you don't want to host or rotate the credentials yourself. Either way the next step is the same — describe the surface you want and the member-consent path you can offer, on our contact page, and we'll come back with a scoped quote.

Apps in the same shape

Neutral list of community-bank and credit-union apps with comparable PFM-or-core data surfaces that integrators frequently ask about alongside MCB Go. They are mentioned for context, not ranked.

• MyMCB Mobile — Monterey County Bank's customer-facing app, same naming family, similar Internet Banking-tied auth model.
• Forcht Bank Mobile — Kentucky community-bank mobile app, similar core-plus-PFM split.
• Republic Bank Mobile (KY) — larger Kentucky-based bank with a richer authenticated portal and matching transaction-detail data.
• Stockyards Bank & Trust Mobile — Louisville-area community bank, similar account/transaction surface behind member auth.
• WesBanco Mobile — regional bank app whose authenticated session exposes a broader set of treasury and bill-pay endpoints.
• L&N Federal Credit Union Mobile — Kentucky credit-union app with member-shares, loan and transaction data behind a consented session.
• Park Community Credit Union Mobile — comparable Kentucky credit-union surface, useful as a contrast for the CU side of aggregation.
• Banno Mobile — Jack Henry's white-label mobile platform that powers a large share of US community-bank apps; useful as the reference shape if you're mapping multiple banks at once.
• Central Bank Mobile (KY) — Lexington-headquartered community bank, similar member-consent integration pattern.

Questions integrators usually ask

What we checked, and where

Sources we opened while preparing this brief: the MCB Go listing on Google Play and the App Store for the feature surface; Meade County Bank's own website for the institution profile and the Internet Banking enrolment path; the CFPB's Personal Financial Data Rights Reconsideration notice for the current §1033 status. Mapping reviewed by the OpenBanking Studio integration desk, 2026-05-24.