Getting structured account data out of Mabrey Bank

Mabrey Bank has run as an independent Oklahoma bank out of Bixby since 1924, per its own about page and the ICBA community-bank directory, and the GRIP mobile app (com.mabreybank.grip on Google Play; iOS listing id 1598174922 per the App Store) is where a member's day-to-day records actually live. For an integrator the interesting part is not a single balance number. It is the depth behind the account: years of posted transactions a customer has annotated with tags, notes and photographed receipts, the monthly statement archive, and a running record of transfers, bill payments and Zelle activity. Reaching that means a first-run bulk backfill, then incremental catch-up — and that backfill is where most of the engineering lives.

The route we would take here is the consented-session one, with monthly statements used as a reconciliation backstop. That gives a faithful copy of the member's ledger and document set without depending on how the app chooses to present it. What follows maps the surfaces, shows the shape of the backfill code, and states plainly how the engagement runs.

What the account actually holds

Each row below is a surface the app exposes to a signed-in member, named the way Mabrey Bank describes it, with where it comes from and what an integrator does with it.

The shape of the backfill

The first sync is the expensive one. It walks each account's ledger from newest to oldest behind a cursor, parking a checkpoint after every page so an interrupted run resumes instead of restarting. Later runs read forward from the last checkpoint only. The snippet is illustrative — exact field names get pinned during the build against the live session — but the control flow is the real one we ship.

# Illustrative — confirmed against the live session during the build.
def backfill_account(session, account_id, store):
    cursor = store.last_cursor(account_id)   # None on a first full backfill
    pages = 0
    while True:
        page = session.get(
            f"/accounts/{account_id}/transactions",
            params={"before": cursor, "limit": 200},
        )
        txns = page["transactions"]
        if not txns:
            break
        for t in txns:
            store.upsert({
                "account_id": account_id,
                "posted_at": t["posted_at"],
                "amount_minor": t["amount_minor"],   # signed integer cents
                "kind": t["kind"],                   # transfer | billpay | zelle | deposit | card | ach
                "counterparty": t.get("counterparty"),
                "tags": t.get("tags", []),           # member-added
                "memo": t.get("memo"),
                "image_refs": t.get("image_refs", []),  # check / receipt captures
            })           # keyed on (account_id, source_id) so a re-run overwrites, never duplicates
        cursor = page["next_before"]
        pages += 1
        store.checkpoint(account_id, cursor)
        if cursor is None:
            break
    return pages

Statements get a parallel, lighter pass that lists periods and stores each document with its period label, which is what later lets a reconciler match the streamed ledger against the figure a member would read off a PDF.

Ways in, and the one we pick

Consented-session integration (recommended)

A member authorizes access; we drive the same authenticated surfaces the app uses and read their balances, ledger, statements and payment activity. Reach is broad — effectively everything the member can see. Durability is good as long as we watch for app-version and auth changes, which we fold into maintenance. Setup is arranged with the member during onboarding against a consenting account.

Protocol analysis of the app traffic

Where a surface is awkward to drive directly, we analyze the GRIP client's own requests and responses to document the exact call shape, token handling and pagination. This is the work behind the backfill snippet above. It is reverse engineering for interoperability, done under the customer's authorization, and it is how we keep the normalized schema honest when a field changes.

Native export as a backstop

Saved monthly statements are a member-available export. On their own they are coarse — month-grained documents, not a queryable ledger — so we treat them as a reconciliation source rather than the primary feed, not as the integration itself.

For Mabrey Bank the first two combine into one delivery: consented session for breadth, protocol analysis to pin the contract, statements to check the result. That is the spine of the build.

What lands in your repository

• Runnable source — Python and Node.js clients for login, session refresh, the transaction backfill and the incremental refresh, plus statement retrieval. The code in your hands runs against a consenting account on day one.
• Webhook / notification handlers — if you want push rather than poll, handlers that turn balance-alert and posting events into normalized messages on your side.
• Automated test harness — fixtures and replayable responses for the ledger, statement and Zelle surfaces, so a changed field is caught by the suite before it reaches your data.
• Batch-vs-incremental sync design — written guidance on the one-time backfill window versus the steady refresh, with the cursor and checkpoint model documented.
• OpenAPI / Swagger description of the surfaces we standardize on, for your own client generation.
• Protocol and auth-flow report — the token and session chain as it actually behaves on GRIP, with error and retry handling.
• Interface documentation and data-retention notes — field-level mapping plus what we log and minimize.

Consent and the US data-rights picture

Mabrey Bank is FDIC-insured (cert 10667 per FDIC BankFind) and a Federal Reserve member, which puts it squarely in the US framework. The dependable legal basis for reaching a member's data today is the member's own authorization — explicit consent, scoped to the accounts and domains the project needs, revocable, with consent and access events logged. We minimize stored data to what the use case requires and work under an NDA where the engagement calls for one.

The federal rule that would have compelled banks to hand member data to third parties on request is not in force: a court has enjoined enforcement and the CFPB has reopened it for reconsideration, so its eventual shape and timing are unsettled. We design against consent now and keep the architecture ready to adopt a settled rule later, rather than building on a requirement a bank like Mabrey is not currently bound by.

Engineering notes specific to this build

Two things on GRIP shape the work, and we handle both as part of delivery rather than handing them back as conditions.

• Member-annotated fields are first-class. Tags, notes and photographed receipts and checks live on individual transactions here, not in a separate notes store. We carry them through the backfill as structured fields and preserve image references, because a categorizer that drops the member's own tags throws away the most useful signal in the ledger.
• Mixed event types in one stream. Internal transfers, scheduled bill payments, Zelle sends and receives, and mobile-deposit credits all post into the same account ledger. We classify them on the way in so downstream logic can tell a Zelle credit from a transfer from a captured check, instead of summing them blindly.
• Statements as a freshness check. Because monthly statements are an independent record, we reconcile the backfilled ledger against them at period boundaries; a drift between the two shows up in the test harness rather than as a quiet error in your numbers.

Where teams put this

• A budgeting product that wants a member's full Mabrey history on first connect, not just the trailing 90 days — the backfill is the whole point.
• A bookkeeping tool reconciling a small-business owner's bill-pay and transfer activity against invoices, using the classified event stream.
• A payout or payments service that needs to confirm Zelle receipts landed, separated cleanly from card and ACH credits.
• A personal dashboard that folds the member's Money-Manager-linked external accounts in alongside their Mabrey balances.

Interface evidence

Screenshots from the Google Play listing, for reference to the surfaces named above.

Comparable apps in the same market

Mabrey shares an Oklahoma footprint and a similar feature set with several other institutions; a team integrating one of these usually wants the rest mapped the same way, against one normalized schema.

• BancFirst — Oklahoma statewide bank; mobile banking with a money-management tool covering balances and spend.
• Arvest Bank — regional bank across Oklahoma and neighboring states; accounts, transfers and deposit capture.
• MidFirst Bank — Oklahoma-based bank; app covers balances, transactions, card controls, transfers, bill pay, deposit and Zelle.
• First United Bank — Oklahoma and Texas; balances, pending transactions, transfers, history and secure messaging.
• Tinker Federal Credit Union — large Oklahoma credit union; member balances, transfers and deposit in its mobile app.
• Communication Federal Credit Union — Oklahoma credit union with comparable account and payment surfaces.
• Truity Credit Union — Oklahoma-region credit union; similar member account and transaction data.
• Zelle — the P2P rail that posts inside many of the above, including Mabrey; relevant when reconciling cross-bank transfers.

How this was checked

Compiled from Mabrey Bank's own digital-banking and Money Manager pages, the Google Play and App Store listings, the FDIC BankFind record for certificate 10667, and current reporting on the status of the CFPB's data-rights rule, reviewed on 7 June 2026. Primary sources:

• Mabrey Bank — personal digital banking
• Mabrey Bank — Money Manager
• FDIC BankFind — Mabrey Bank (cert 10667)
• CFPB — Personal Financial Data Rights reconsideration

Compiled by OpenFinance Lab — data-integration assessment, 7 June 2026.

Questions integrators ask

Can you backfill years of Mabrey Bank transaction history, not just recent activity?

Yes. The first pull is a bulk backfill that walks the transaction list backward with a cursor until it reaches the oldest record the account exposes, then later runs only fetch what changed since the last cursor. Monthly statements give a second, document-level source to reconcile the backfilled ledger against, so figures line up with what the customer sees in the app.

Does Mabrey Bank's Money Manager aggregation mean the data is already normalized for us?

Money Manager organizes a member's view inside the app — budgets, savings goals, a cash-flow calendar — but it is not an outbound feed. We read the same underlying account, transaction and category data the member is entitled to and normalize it on our side into a stable schema you control, rather than depending on the in-app presentation.

What is the legal basis for reaching the data, given a US bank?

The member's own authorization. Mabrey Bank is FDIC-insured and a Federal Reserve member; the federal data-rights rule that would compel sharing is currently enjoined and back with the CFPB for reconsideration, so it is not something to build against today. We work from consented access, keep consent and access logs, and minimize what we store.

How do mobile check deposit and Zelle show up in what you can extract?

Both surface as posted transactions in the account ledger, with the deposit carrying check-image references and Zelle carrying the counterparty handle and a sent-or-received marker. We map those event types explicitly so a payout reconciler or a deposit tracker can tell a Zelle credit from an internal transfer or a captured check.

Working with us

You bring the app name and what you want out of its data; we arrange consented access with you and handle the protocol work. For Mabrey Bank that first deliverable is the backfill-and-refresh client plus the reconciliation harness, in about one to two weeks. Pricing is a one-time source-code delivery from $300 — you receive the runnable client and documentation and settle only after it is delivered and you are satisfied. If you would rather not run it yourself, the same integration is available as a hosted pay-per-call API: you call our endpoints and pay only for the calls you make, with nothing upfront. Tell us the surfaces you need and we will scope it — start at our contact page.