Syncing MCB Go: balances, transactions and the aggregated account view

Every MCB Go session loads a consolidated ledger — Meade County Bank deposit accounts plus whatever outside institutions a customer has linked — and refreshes it after login. That refresh is the integration problem. A third party that wants this data is really asking how to re-pull the same view on a schedule, catch only what changed since last time, and keep the customer's own annotations attached. The app is read-and-organize software for a Brandenburg, Kentucky community bank, per its Google Play listing (package com.meadecountybank.grip); it sits on top of an account-aggregation layer rather than a single ledger. So the work is a delta sync, not a one-shot dump.

The bottom line: most of the value is the aggregated transaction stream with its enrichments, and the cleanest read is the authorized app session because that is the only place the customer's tags, notes and receipt images exist. Where a downstream system only needs the raw deposit-account data, a consented aggregator link gives a more durable feed. We usually combine the two.

What sits behind the MCB Go login

The listing names the surfaces fairly precisely. Mapped to what an integrator would actually consume:

Getting to the aggregated feed

Three routes apply here. They differ mostly in how much of the enrichment layer they return and how long they stay stable.

Consumer-permissioned aggregation

The underlying Meade County Bank deposit and transaction data is reachable through a US data aggregator — Plaid, MX, Finicity, Akoya or Yodlee all operate at this layer, per MX's own aggregator roundup. The customer authorizes the connection; the aggregator returns normalized accounts and transactions. Durable, low-maintenance, and the natural choice when you only need core banking data. It will not return the tags, notes, images or geo a customer added inside MCB Go — those never reach the bank feed. We set up the aggregator connection and consent flow with you as part of the build.

Authorized protocol analysis of the app session

To reproduce exactly what MCB Go shows — including the cross-institution aggregated view and the enrichment fields — we work from the app's own session under the account holder's authorization. We capture the login and 4-digit-passcode flow, document the token and session chain, and map the JSON the screens consume. This returns the richest surface and is what we usually recommend when the enrichments or the unified multi-institution view matter. It tracks the app, so it carries a modest maintenance cost as screens change; we account for that with a regression suite.

Native export

The app is built to organize and search, not to bulk-export, so a built-in feed is a thin fallback at best. We treat it as a sanity check against the session pull, not a primary route.

For most briefs that come in on this app, the session route is the spine and an aggregator link rides alongside it for the durable deposit data — the session gives you the enrichments, the aggregator gives you longevity on the core feed.

A delta poll against the session

The shape of the pull is a cursored poll: establish the session, list the aggregated accounts, then ask each account for activity newer than the last cursor and page until it is empty. Illustrative — exact paths are confirmed during the build against a consenting account.

# Establish the session: Internet Banking credentials, then the app's local passcode gate
session = mcbgo.login(username, password)
session.passcode("****")                   # MCB Go's 4-digit local re-auth

# List the aggregated accounts: MCB deposits + linked external institutions
accounts = session.get("/accounts")
# -> [{account_id, institution, type, balance, currency, link_status}]

# Delta-pull transactions per account using a cursor / since-timestamp
for acct in accounts:
    cursor = store.last_cursor(acct["account_id"])     # None on the first run
    while True:
        page = session.get(
            "/accounts/%s/transactions" % acct["account_id"],
            params={"since": cursor, "limit": 200})
        for tx in page["items"]:
            # tx: {id, posted_at, amount, description, merchant, category,
            #      tags[], note, image_ref, geo, pending}
            upsert(tx)                     # keyed on tx["id"] — a re-run overwrites, never duplicates
        cursor = page.get("next_cursor")
        if not cursor:
            break
    store.save_cursor(acct["account_id"], page.get("server_time"))

# If a poll returns 401, re-run login + passcode and resume from the stored cursor.
      

Normalized shape we hand back

We separate the bank-sourced fields from the user-generated enrichment, so a later aggregator pull of the same account can be merged in without colliding with what the customer wrote.

{
  "account": {
    "id": "acct_2f1a",
    "institution": "Meade County Bank",
    "type": "checking",
    "balance": 1843.20,
    "currency": "USD",
    "link_status": "connected"
  },
  "transaction": {
    "id": "txn_90e7",
    "posted_at": "2026-06-11",
    "amount": -42.17,
    "merchant": "local grocery",
    "category": "groceries",
    "pending": false,
    "enrichment": {                 // lives only in MCB Go, not in the bank feed
      "tags": ["reimbursable"],
      "note": "client lunch",
      "image_ref": "receipt_4471",
      "geo": { "lat": null, "lng": null }
    }
  }
}
      

What lands in your repo

The headline deliverable is code that runs against MCB Go, not a document set:

• A runnable client in Python and Node.js: login, passcode entry, session refresh, and the paginated delta pull of accounts and transactions shown above.
• A polling worker with per-account cursor checkpointing, so incremental ingestion resumes cleanly instead of refetching full history.
• An automated test suite built from captured response fixtures, with assertions that flag schema drift when the app's payloads change.
• The normalized account/transaction schema plus the mapping for the enrichment layer (tags, notes, image refs, geo) keyed by transaction id.
• An OpenAPI/Swagger description of the surfaces we touched, secondary to the running code.
• A protocol and auth-flow report covering the credential, passcode and token/session chain.
• Data-retention and consent-record guidance for operating the sync.

Things this build has to get right

A few facts about MCB Go shape the engineering, and we handle each on our side:

• The aggregated external balances depend on upstream connection health. We build the sync to read each account's link status and surface a stale or disconnected institution as an explicit field, rather than letting a dropped feed quietly understate a customer's position.
• The enrichments are user-generated and exist only inside MCB Go. We map them as a distinct layer tied to the transaction id, so a downstream aggregator pull of the same deposit account can be merged with the tags, notes and receipt images instead of overwriting them.
• History depth is governed by each linked institution, not by the app. We set the initial backfill window and the delta cursor to match what the feed actually provides, so the first sync does not assume more history than exists.
• The app gates on Meade County Bank Internet Banking enrollment and a 4-digit passcode. Access is arranged with you during onboarding against a consenting account, and we design the poller to re-establish the session and resume from its cursor when the passcode gate or session times out.

Authorization and the US data-rights picture

The dependable basis for this work is the account holder's own authorization — their consent to reach their data through their credentials or a consented aggregator link. That is what every route here rests on. The federal open-banking rule that would otherwise frame it, the CFPB's Section 1033 Personal Financial Data Rights rule, is not currently in force: a judge in the Eastern District of Kentucky enjoined enforcement in October 2025 in the Forcht Bank litigation, and the CFPB has reopened the rule for reconsideration following its August 2025 notice. There is a local irony worth noting, since Meade County Bank is itself a Kentucky institution and the injunction came out of a Kentucky court. We treat 1033 as where US data-rights rules may eventually settle, not as present law, and we do not build against its specific obligations while they are unsettled.

How we operate, regardless of where the rule lands: authorized and documented access only, consent and access records kept, data minimized to what the integration needs, and an NDA where the engagement calls for one.

Screens from the listing

Store screenshots, useful for confirming which surfaces a sync would touch. Select to enlarge.

Where MCB Go sits among money apps

MCB Go is a bank-branded take on the personal-finance aggregation category. These named apps occupy adjacent ground and help frame a unified integration; listed for context, not ranked.

• Quicken Simplifi — syncs balances and transactions from thousands of US institutions into one budgeting dashboard.
• Monarch Money — multi-institution aggregation with net worth, budgets and shared household access.
• Copilot Money — machine-learning categorization across linked accounts, strong on iOS.
• Rocket Money — aggregation centered on subscriptions, bills and balance tracking.
• YNAB — imports linked-account transactions for zero-based budgeting.
• PocketGuard — aggregates accounts to surface a spendable-after-bills figure.
• Lunch Money — aggregation and categorization with multi-currency and crypto support.
• MyPoint CU Mobile — another community-institution app with the same tag, note and receipt-enrichment surface as MCB Go.

Questions integrators ask about MCB Go

Once the first pull is done, how do follow-up syncs stay incremental?

Each account carries a cursor — a server timestamp or page token from the previous run. The poller asks only for activity after that mark, walks the pages until they run dry, and writes rows keyed on the transaction id so a re-run overwrites rather than duplicates. When the session times out, the client re-establishes it and resumes from the stored cursor instead of refetching the whole history.

Do the tags, notes and receipt photos come through, or only the bank's raw transactions?

The tags, notes, receipt images and geo-information are added by the customer inside MCB Go and live in that app, not in the underlying bank feed. A plain aggregator pull will not return them. We capture them through the authorized app session and hand them back as an enrichment layer keyed to each transaction id, so you can merge them onto a separate deposit-account pull later.

With the CFPB open banking rule frozen, what is the legal basis for the access?

The basis is the account holder's own authorization to access their data through their credentials or a consented aggregator link. The CFPB Section 1033 rule is not in force: a Kentucky federal court enjoined enforcement in October 2025 and the agency has reopened it for reconsideration. We treat 1033 as where US data-rights rules may head, not as current law the build relies on.

We bank elsewhere but want MCB Go's aggregated cross-institution view — can you still build it?

Yes. MCB Go requires Meade County Bank Internet Banking enrollment, so the work runs against a consenting account; access is arranged with you during onboarding. The aggregated external accounts a customer has linked are visible through that session, which is the surface we map for a cross-institution sync.

Working together

A first MCB Go sync client — login, the cursored delta pull, and the enrichment mapping — typically lands within one to two weeks. You can take it as source code from $300, paid after delivery once you have run it against your own consenting account and you are satisfied; or skip the build and call our hosted endpoints, paying per call with nothing up front. Tell us the app and what you need from its data, and we arrange the access and compliance side with you: start a conversation.

Sources and review

Checked against the app's store listing and the current US data-rights record on 15 June 2026. Primary references: the MCB Go Google Play listing and its App Store entry for the feature and enrollment details; the Federal Register reconsideration notice and the ABA Banking Journal report on the Kentucky injunction for the Section 1033 status.

OpenFinance Lab · interface mapping, 2026-06-15.