Building a working data feed against Mabrey Bank's mobile portal

Mabrey Bank operates 14 branches across Oklahoma and reports into a single Jack Henry-hosted core (the bank moved its IT infrastructure and core processing to Jack Henry in late 2016, per FinTech Futures, and ran a follow-on core banking system upgrade in April 2025 per the bank's own notice). The mobile app is the consolidated customer-facing surface on top of that core, and it is where balances, transaction history, Zelle activity, statements and the Money Manager aggregation layer all meet in one place — which is exactly why integrators ask us how to read it.

The short answer for an integrator: the dependable basis here is the customer's own authorization, the route is a credential-based session against the mobile portal under that authorization, and the surfaces worth pulling are the ones Mabrey already concentrates inside the app — not a scraped marketing site, and not a generic statement parser.

Data that actually lives in the Mabrey Bank app

The Play Store description and the bank's own digital-banking pages line up cleanly on what the app surfaces. Below is the mapping we work from.

Authorized routes that actually apply here

Customer-authorized credential access against the mobile portal

The most reliable route for Mabrey today. The integrator's end-user — who is a Mabrey customer — authorizes the studio's build to act on their behalf. The build handles the bank's two-factor challenge the same way the real mobile app does, holds the resulting session, and reads the surfaces the user can already see. This is how community-bank integrations ship while the US §1033 picture is still moving. We design the consent record, the credential vault, and the revoke path on the integrator's side so the authorization is the durable artifact, not the credentials.

Authorized protocol analysis of the app traffic

Used when the integrator wants their own server-side client rather than embedding a browser session. We capture the live request and response pairs the Mabrey iOS/Android binary makes — login, MFA, account list, transaction range, statement fetch, Zelle history — and rebuild them as a documented, testable HTTP client with the same auth chain. Access onboarding, the consenting test account, and the NDA scoping are arranged with the integrator as part of the kickoff.

Native exports as a fallback for archival history

Mabrey's portal lets a customer download monthly statements and export transaction ranges into accounting software. Where an integrator only needs periodic, low-frequency reconciliation, we wire a thin downloader against those native exports rather than a live session, with the trade-off that the freshness is whatever the export schedule gives.

For most Mabrey use cases the credential-authorized session is what we build first, with the protocol-analysis client coming second when the integrator wants a clean server-to-server shape, and the native export route reserved for archival catch-up. We say this in prose rather than as a checkbox because the right mix depends on which of the surfaces above the integrator actually needs.

What lands in your repo

• An OpenAPI 3 specification of the Mabrey endpoints we use — login, MFA challenge, account list, transaction range, statement download, Zelle history — written to the shape your team consumes, not the raw bank shape.
• Runnable Python and Node.js source for the client, with the auth chain, session refresh, retry policy, and the rate-limit behaviour observed during the build.
• A protocol & auth-flow report explaining exactly which cookies and tokens the Mabrey portal sets, when they rotate, and how the MFA challenge is satisfied on subsequent calls.
• A normalized account-and-transaction schema (sample below) so the Money Manager aggregated records and the native Mabrey records arrive in one shape.
• Automated tests against a consenting account, including regression tests for the session-rotation behaviour we observe after the April 2025 core upgrade.
• Interface documentation covering the consent record, the revoke path, the data retention defaults, and the operational playbook for when the portal front end shifts.

Illustrative call against the authenticated session

This is the shape, not the verbatim contract — the exact field names and the MFA chain are confirmed during the build against a consenting account. The point is that the session-cookie-plus-CSRF pattern is what the Mabrey mobile portal uses, and that the range query is per-account rather than across the roster.

POST /api/session/login
Host: my.mabreybank.com
Content-Type: application/json

{ "username": "<authorized>", "password": "<authorized>" }

=> 200 OK
   Set-Cookie: MBSESSION=...; Secure; HttpOnly
   { "mfaRequired": true, "challengeId": "c-9f..." }

POST /api/session/mfa
{ "challengeId": "c-9f...", "code": "<OTP>" }

=> 200 OK
   { "authenticated": true, "expiresIn": 900 }

GET /api/accounts
=> 200 OK
   [
     { "id": "ACC-1234", "kind": "CHECKING",  "source": "MABREY",         "available": 4218.55 },
     { "id": "ACC-1235", "kind": "SAVINGS",   "source": "MABREY",         "available":  912.00 },
     { "id": "EXT-77a1", "kind": "CHECKING",  "source": "MONEY_MANAGER",  "linkedAt": "2026-03-09" }
   ]

GET /api/accounts/ACC-1234/transactions?from=2026-04-01&to=2026-04-30
=> 200 OK
   { "items": [
       { "postedAt":"2026-04-03","amount":-42.15,"rail":"CARD","memo":"OKMULGEE COFFEE" },
       { "postedAt":"2026-04-07","amount":-120.00,"rail":"ZELLE","counterparty":"J. RHODES" },
       { "postedAt":"2026-04-15","amount":1480.22,"rail":"ACH","memo":"PAYROLL"  }
   ] }

Normalized shape we hand the integrator

The Money Manager mirror is the reason we normalize on our side rather than handing through the bank's raw fields — it lets the integrator treat an aggregated Chase checking the same way they treat a native Mabrey checking, and dedupe on a stable id when both feeds reach them.

{
  "account": {
    "id": "ACC-1234",
    "institution": "MABREY_BANK",
    "source": "NATIVE",
    "type": "CHECKING",
    "currency": "USD"
  },
  "balance": { "available": 4218.55, "asOf": "2026-04-30T23:00:00Z" },
  "transactions": [
    {
      "id": "t-2026-04-07-zelle-001",
      "postedAt": "2026-04-07",
      "amount": -120.00,
      "rail": "ZELLE",
      "counterparty": "J. RHODES",
      "tags": [],
      "memo": null
    }
  ]
}

The authorization basis we ride for Mabrey

Because Mabrey Bank is a US community bank, the dependable basis for this kind of integration is the consumer's own authorization, captured and revocable by them. The CFPB's §1033 Personal Financial Data Rights rule is sometimes assumed to be the US equivalent of a regulated AIS regime, but that is not the current state: in late October 2025 the Eastern District of Kentucky enjoined the CFPB from enforcing the rule, and on August 22, 2025 the CFPB itself issued an Advance Notice of Proposed Rulemaking reopening the rule for reconsideration. We do not build a Mabrey integration on §1033 today, and we do not promise compliance with a rule that is currently stayed. Where §1033 ultimately lands — and how a community bank of Mabrey's size is treated by whatever asset-size phasing returns — is something we will revisit with the integrator when it lands; until then the consent record between the integrator and the customer is the artifact that carries the access.

On the operational side we run authorized, logged, data-minimized access, with NDA scoping where Mabrey's brand or screens appear in materials the integrator will publish. Credentials live encrypted on the integrator's side; the studio retains the protocol report and tests, not the customer credentials.

Mabrey-specific build notes we plan around

• Money Manager / native dedup. The same record can appear once as a native Mabrey account and again as a Money Manager-aggregated mirror when the customer has also linked an external bank that we already pull directly. We label every account with its source (native vs Money Manager) and reconcile on stable identifiers before handing the data over, so the integrator does not double-count on dashboards.
• April 2025 core upgrade window. Mabrey ran a core banking system upgrade in April 2025, after which some pre-cutover history sits behind a separate read-only archive view. We design the history fetch to call the live portal first and fall through to the archive view when the requested date range pre-dates the cutover, so an integrator's monthly close does not silently miss the boundary.
• MFA challenge handling. Mabrey's portal uses two-factor authentication on session establishment rather than only at login. The build holds and re-presents the MFA-derived session token on subsequent calls, with a planned re-challenge path on token expiry rather than treating expiry as a hard error.
• Mobile check deposit business rules. Daily $7,500, 30-day $15,000 and 100-item caps (per the bank's mobile banking page) are mirrored as validation rules in the integrator's reporting layer when the integration is meant to drive reconciliations — so projected dispositions do not exceed what Mabrey will actually post.
• Front-end shifts at a community bank cadence. Mabrey's portal is small enough that UI changes ship without a public release calendar. We bundle a thin re-check that runs against the live login and account-list responses on a schedule, and route any structural drift to a tracked task rather than to a failing customer call.

Other Oklahoma bank apps in the same integration shape

Customers who want a Mabrey integration often want to wire up neighbours in the same OK community-banking footprint at the same time. The list below names the real apps; for the same-shape integration our route does not change much across them.

• Arvest Go (Arvest Bank) — the largest of Mabrey's local peers; broader product set, same authorized-credential route for third-party access.
• RCB Bank Mobile — community bank with ITM access and a familiar transactions-plus-Zelle surface for the integrator to read.
• BancFirst Mobile — Oklahoma-only state-chartered bank, integration follows the same session-and-MFA pattern.
• F&M Bank Mobile (Oklahoma) — Citizens Potawatomi Nation-owned community bank; comparable PFM and bill-pay surfaces.
• BOKF Mobile (Bank of Oklahoma) — larger regional with richer treasury features; a useful peer when the integrator's customer footprint spans both.
• First Oklahoma Bank Mobile — small community bank; same authorization basis and a similar Jack Henry-style mobile portal.
• Stride Bank Mobile — sponsor bank for several fintech programs; the integrator side here is usually the fintech, not the customer directly.
• Vision Bank Mobile — community bank with a tight branch footprint, similar in scope to Mabrey.
• Citizens Bank of Edmond Mobile — small OK community bank with active digital and PFM features.
• IBC Mobile (International Bank of Commerce) — regional bank with an Oklahoma presence; useful when an integrator wants Mabrey alongside a Texas-anchored peer.

Questions Mabrey integrators actually ask

Does Mabrey Bank's app surface Zelle transaction history the same way the native portal does?

Yes — Zelle activity is folded into the same transaction stream as ACH and card items inside the mobile portal, so we treat it as one history feed and tag the rail per item rather than calling a separate Zelle endpoint.

Money Manager already aggregates external accounts. How do you keep that from double-counting?

We pull the account roster first and label each record as a native Mabrey account or a Money Manager aggregated mirror. Anything mirrored gets deduped against the source record by stable identifier, not by description, so a Chase checking pulled via Money Manager isn't counted twice when the integrator also has a direct Chase feed.

Mabrey Bank ran a core banking system change in April 2025 — does that affect the integration?

It affects the field set, not the route. After the April 2025 conversion some history pre-cutover lives behind a separate read-only archive surface, so the build pulls live data from the current portal and reaches the legacy window through the archive view when an integrator needs deeper history.

Mabrey only operates 14 branches in Oklahoma. Does that constrain testing?

It actually helps — the customer base is small enough that we can run the build against a consenting account in the integrator's name without queueing behind a large change-management process, which is how community-bank work tends to ship faster than money-center work.

What this brief leans on

Worked off Mabrey Bank's own mobile and digital banking pages for the feature set and the mobile-check-deposit limits, the FDIC BankFind record for the charter and certificate, the bank's core upgrade notice and a FinTech Futures item from late 2016 for the Jack Henry relationship, and the CFPB's own page (plus the August 2025 Federal Register notice) for the §1033 reconsideration status. Sources are linked inline below.

• Mabrey Bank — Mobile Banking (features and check-deposit limits)
• FDIC BankFind — Mabrey Bank, certificate 10667
• Mabrey Bank — Core Banking System Upgrade (April 2025)
• FinTech Futures — Mabrey Bank turns to Jack Henry for IT infrastructure and core processing
• CFPB — Personal Financial Data Rights (§1033) status page

Mapping written by the OpenBanking Studio integration desk, 2026-05-30.

The engagement is short and concrete on this one: source-code delivery starts at $300 and is paid after delivery once the integrator is satisfied with what runs against their consenting account, and the pay-per-call hosted option keeps the same client behind our endpoints with no upfront fee. Either way the cycle is 1–2 weeks, and the conversation starts when you tell us which of the Mabrey surfaces above you actually need. Send the brief through /contact.html and we will write back with the access plan and the scope.